No subject

 ran out of steam. I can see the rationale for defining a standard Com=
ponent font structure, but this would need considerable revision befor=
e it was workable.<br>
<br>
> and an optional character mapping (cmap) that defines how Unicode char=
acters map to glyphs in the component font<br>

<br>
If the components are treated as atomic, you wouldn't want access to their&=
nbsp;glyphs; just to characters. That is, logically, the component font wou=
ld tell you which font to use for which range(s) of Unicode characters=
, optionally with a transform of the metrics.<br>

<br>
Ideally, you'd want to have a bit more elaborate a structure for determinin=
g the ranges, because you can end up with a situation ABCdefGHI, where=
 ABC should definitely be in Font1, and GHI should definitely be in Fo=
nt2, but where def could be in either one, and you want a more interes=
ting algorithm to determine that (such as handling matching braces, et=
c.)<br></blockquote><div><br></div>The decision for which font to use for a=
 certain character is purely dependent on the order of the component fonts =
in the posing font. The author can creatively limit each component for what=
 glyphs (or characters, as options of the cmap-overrides) to control the fl=
ow by using the character set mechanism which is default to the character s=
et of the component font (e.g., 'cmap' of a TrueType font).</div><div><br><=
/div><div>As for characters or glyphs to specify in the component font, I t=
hink we had characters first and then added character-glyph mapping because=
 of a specific case that cannot be don't by just characters. This is purely=
 for convenience.  Is there any particular reason you think character =
ranges is better than specify glyph (character to) mappings?  This is =
not a format just for font vendors but could be extended to general clients=
 such as end users given the available tools.</div><div><br></div><div>For =
the example you gave above, the response is below.</div><div><br><blockquot=
e type=3D"cite">
<br>
> language =3D "string"<br>
> Optional. The two-letter ISO 639 code that corresponds to the language=
 of the 'string' attribute.<br>
<br>
<br>
In 2 places. Should be the BCP47 language tag=85<br>

<br>
> Required. A series of Unicode code points or code point ranges that ar=
e specified according to ICU's UnicodeSet pattern syntax. As an exampl=
e, the ranges U+0020 through U+007E and U+4E00 through U+9FCC can thus=
 be expressed as [[\u0020-\u007E]|[\u4E00-\u9FCC]].<br>
<br>
<br>
Syntax is wrong, and a better example would be something like [[\u0020=
-\u007E][:script=3DGreek:]].<br>
More importantly, the spec doesn't discuss what to do when two different&nb=
sp;components have intersecting UnicodeSets (or contents).<br></blockquote>=
</div><br></div><div><br></div><div>I agree with you that the language (loc=
ale) code standard designation is incorrect in the spec. I should revise th=
e spec soon when I have a chance to do it and consult with the other author=
s.  Is there any up to date spec about the uset? The one I had worked =
off were from 6 years ago from a header file by Stephen.</div><div><br></di=
v><div>When the character sets of two components intersect, the order of th=
e components appear in the posing font determines the character set to use.=
 For example. to render "ABCD" with the posing font of two components, comp=
onent 1 has [ABC] and component 2 has [BCD], since component 1 is before co=
mponent 2, "ABC" is rendered with component 1 and only "D" is rendered with=
 component 2. I will add this explanation to the spec somewhere. It is true=
 that a more elegant solution could be used to ensure the typographic consi=
stency such as match braces, but here, the simple mechanism can serve the p=
urpose making sure a missing glyph is rendered with sufficiency. The author=
 can always consider the character set before creating the components and s=
equence. There could even be components of the same font appearing in the p=
osing font many times, the objective is to have way to specify how to arriv=
e at a glyph for a character that would have been rendered with '.notdef'.<=
/div><div><br></div><div>Regards</div><div><br></div><div>Tony</div></body>=
</html>
--Apple-Mail=_3BB19120-1E0B-4177-A469-FE3ACC899599--