diacritic stacking: positioning problem

[Erwin Denissen]

Note: Some of the inline images have disappeared from the server.

They are still here; maybe another issue with your browser?

[Bhikkhu Pesala]

Missing images at bottom of this topic:

Code: Select all

https://forum.high-logic.com/download/file.php?id=9410

More in this older thread: viewtopic.php?f=4&t=1215

Note the http:// prefix:

Code: Select all

http://forum.high-logic.com/postedimages/Diacritic%20Alignment.png
http://forum.high-logic.com/postedimages/Diacritic%20Position.png
http://forum.high-logic.com/postedimages/FontInformation.png
http://forum.high-logic.com/postedimages/LowProfileAcute.png

Code: Select all

http://forum.high-logic.com/postedimages/CopyCompositeGlyphMembers.png
http://forum.high-logic.com/postedimages/PasteCompositeGlyphMembers.png
http://forum.high-logic.com/postedimages/AlignCompositeGlyphMembers.png

[Erwin Denissen]

Oops; now I understand. I thought you referred to images in this topic, but you were talking about the old images. It should now be restored.

[Bhikkhu Pesala]

Looking good now. I deleted the missing attachment from the first thread.

[NinnaD]

They are the decimal code-points of the defined glyphs. See the Complete Composites Tutorial

Thank you. Having read the tutorial and the pdf, and after looking at CompositeData.xml, I still have some questions, if I may:
1. Can <InheritSB> with Boolean value be placed inside the <Member> tag?
2. What's the <Member id="Rule">?
3. Is there a limit to how many <GlyphName> tags can be placed inside <Member>?
4. Do the <GlyphName> tags or <GlyphMapping> tags order inside the <Member> tag determine the order in which they are used, or is it determined by name suffixes, such as ".case"?
4a. If the latter, are other suffixes also possible?
4a1. If yes, what's their order?
5. Can <GlyphName> tags be mixed with <GlyphMapping> tags inside the <Member> tag?
5a. f yes, does it have bearing on the order in which they are used?
6. <Offset> expressed in em: with or without a space?
7. Can any <Offset> expression (fixed/percentage/em) be used with any <Position> value?
8. Which elements are/aren't case-sensitive?
9. There are 2 cases of fractions omitting 0 before the dot. Is that an error or also allowed?

I apologise if some of these questions do have answers in the provided materials. Thank you for your help

[Bhikkhu Pesala]

They are the decimal code-points of the defined glyphs. See the Complete Composites Tutorial

Thank you. Having read the tutorial and the pdf, and after looking at CompositeData.xml, I still have some questions, if I may:
1. Can <InheritSB> with Boolean value be placed inside the <Member> tag?
2. What's the <Member id="Rule">?
3. Is there a limit to how many <GlyphName> tags can be placed inside <Member>?
4. Do the <GlyphName> tags or <GlyphMapping> tags order inside the <Member> tag determine the order in which they are used, or is it determined by name suffixes, such as ".case"?
4a. If the latter, are other suffixes also possible?
4a1. If yes, what's their order?
5. Can <GlyphName> tags be mixed with <GlyphMapping> tags inside the <Member> tag?
5a. f yes, does it have bearing on the order in which they are used?
6. <Offset> expressed in em: with or without a space?
7. Can any <Offset> expression (fixed/percentage/em) be used with any <Position> value?
8. Which elements are/aren't case-sensitive?
9. There are 2 cases of fractions omitting 0 before the dot. Is that an error or also allowed?

I apologise if some of these questions do have answers in the provided materials. Thank you for your help

1. No. It applies to the glyph only
2. Names must be unique. You may give them meaningful names.
3. Perhaps, but I never found it. Composites with 9 or 10 members can certainly be created.
4. The glyphnames or glyph mappings are used in the order in which they appear. Many composites have fallback glyphs in case the first glyph is not found in the font. I believe there are only a limited number of valid suffixes that will be recognised by the feature.
5. IIRC one may use either glyph names or glyph mappings in defining a glyph member, but not both. I think it is OK to define different glyph members using different methods. Try and see as I have never tried it. I compiled the CompositeData.xml file, but Erwin wrote the code that interprets it.
6. I have never used em. I suspect that the space is needed.
7. If any <Position> value means Left, Right, Center, Top, Bottom, Middle, then I assume that the answer is "yes."
8. Glyph names are case-sensitive: Agrave is not equal to agrave.
9. Which ones? Line number or glyph name. I doubt if it matters. 0.4 is easier to read than .4 that is all.

Take the above with a pinch of salt. I am tired and it is years since I worked on this stuff.

[NinnaD]

Great

The glyphnames or glyph mappings are used in the order in which they appear

But:

If glyphs are mapped to Uppercase diacritics they will be used in preference to regular sized diacritics over capitals

It is allowable to mix <GlyphName> with <GlyphMapping> in the same definition but if both are used for the same glyph member the one defined with a mapping will be used first.

IIRC one

What does it mean?

Glyph names are case-sensitive

But no other values?

9. 7455, 7456

[NinnaD]

And more questions:

10. Are there tags that are mutually-exclusive - not logically, but programmatically - in that using both in one definition will result in error?
11. Several tags designate decimal code-point - can all these cases use Hexadecimal instead?
12. In the case of fallback glyph members, I presume whatever is defined inside the <Member> tag will apply to all fallback glyph members uniformly and there's no way to have different instructions for different fallback glyph members?

[Bhikkhu Pesala]

IIRC = If I recall correctly.
All code syntax words are case-sensitive, e.g. <Pos>Auto</pos> will produce a syntax error, e.g.

This page contains the following errors:
error on line 568 at column 18: Opening and ending tag mismatch: Pos line 0 and pos
Below is a rendering of the page up to the first error.

If uppercase diacritics are defined in the font, e.g. <GlyphMapping>57365</GlyphMapping>, they will be used before the fallback glyph grave accent (Decimal codepoint 96).
9. I could not find any errors on lines 7455, 7456 Paste the code for the entire composite definition where you think the error is. If it parses, then it passes. Don't worry about it.

Code: Select all

<Composite><!-- A Grave -->
<GlyphMapping>192</GlyphMapping>
	<Member id="1">
	<GlyphMapping>65</GlyphMapping>
		<UseMetrics>TRUE</UseMetrics>
	</Member>
	<Member id="2">
	<GlyphMapping>57365</GlyphMapping>
		<GlyphMapping>96</GlyphMapping>
		<Pos>Auto</Pos>
	</Member>
	</Composite>

10. If you open CompositeData.xml in a browser it will be parsed and will stop at syntax errors.
11. All tags use decimal code-points. I started programming with ANSI character sets, and got used to 65=A, 65+32=97 = a, etc. Hexadecimal codes may be used if you prefer them.
12. There is no way that I know of to apply different instructions for fallback glyphs.

In brief, CompositesData.xml that comes with the installed program can be modified to suit your own needs. Copy the user data files to the user data folder and edit the copy. If it exists, FontCreator will use it in preference to the default CompositeData.xml file.

There are hundreds of definitions that perhaps no one will use, but they were added to show what is possible with the code, and thousands more that could have been added for other languages, but my free time is very limited. Even more so now than when I was working on this for earlier versions of FontCreator.

[NinnaD]

All code syntax words are case-sensitive

Yes, I understand about the xml tags; I was asking about the values, other than <GlyphName> value, e.g. "Auto" vs. "auto", "TRUE" vs. "True" vs. "true", etc.

If uppercase diacritics are defined in the font, e.g. <GlyphMapping>57365</GlyphMapping>, they will be used before the fallback glyph grave accent (Decimal codepoint 96).

And in the case of fallback glyphs, do any other suffixes determine precedence - and if they do, what's the order of that precedence?

I could not find any errors on lines 7455, 7456 Paste the code for the entire composite definition

Code: Select all

<Composite><!-- Glottal Stop Mod -->
<GlyphMapping>704</GlyphMapping>
<InheritSB>63</InheritSB>
	<Member id="1">
	<GlyphMapping>63</GlyphMapping>
			<XScale>.65</XScale>
			<YScale>.75</YScale>
	</Member>
	<AlignVertical>
		<Source>
			<Position>CapHeight</Position>
			<Offset>-75%</Offset>
		</Source>
		<Dest>
			<Member>1</Member>
			<Position>Bottom</Position>
		</Dest>
	</AlignVertical>
	</Composite>

Copy the user data files to the user data folder and edit the copy. If it exists, FontCreator will use it in preference to the default CompositeData.xml file.

As in instead of, or will use both, and if there are definitions for the same composites, the user-created one will be used first?

and thousands more that could have been added for other languages, but my free time is very limited

I understand, and that's kind of what I'm working on - but I need to understand data and how it fits together, hence my various questions.

[NinnaD]

And this question is probably more for Erwin:

10. Are there tags that are mutually-exclusive - not logically, but programmatically - in that using both in one definition will result in error?

10. If you open CompositeData.xml in a browser it will be parsed and will stop at syntax errors.

because I meant conflicts that will arise from FC, not syntax errors, but more like:

IIRC one may use either glyph names or glyph mappings in defining a glyph member, but not both.

[Erwin Denissen]

4. Do the <GlyphName> tags or <GlyphMapping> tags order inside the <Member> tag determine the order in which they are used, or is it determined

The glyphnames or glyph mappings are used in the order in which they appear. Many composites have fallback glyphs in case the first glyph is not found in the font. I believe there are only a limited number of valid suffixes that will be recognised by the feature.

Glyphs mappings are always processed first, then the glyph names.

And this question is probably more for Erwin:

10. Are there tags that are mutually-exclusive - not logically, but programmatically - in that using both in one definition will result in error?

No, it usually will not generate errors, but there is a strict order in the positioning.

• NextPos
• AutoPos
• AlignHorizontal
• AlignVertical
• LSB
• RSB
• SB
• AW

Although Complete Composites can be of great use, we nowadays prefer the Anchor based approach.

[NinnaD]

Wonderful, thank you.
I think I got what I needed.

In spare time (sic!): I put together an xml file with what I understood about the CompositeData.xml and its rules. If it's correct, maybe it will help others.

[Erwin Denissen]

Yes, that seems to cover it all.

[NinnaD]

And the famous last question:

Copy the user data files to the user data folder and edit the copy. If it exists, FontCreator will use it in preference to the default CompositeData.xml file.

As in instead of, *or* will use both, and if there are definitions for the same composites, the user-created one will be used first?