[mpeg-OTspec] Feedback on CFR

[Tony Tseung]

Vladamir,

Thanks for posting the feedbacks on CFR. My response to the feedback from Mark Davis is below.

Tony
__________

Mark,

Thanks for the feedback. It has been a while since we had spoken even though I have seen you around.

On Jan 17, 2011, at 9:21 PM, Levantovsky, Vladimir wrote:

> Feedback from Mark Davis:
> 
> 
> From a quick review, I see the following issues. I see other ones, but just ran out of steam. I can see the rationale for defining a standard Component font structure, but this would need considerable revision before it was workable.
> 
> > and an optional character mapping (cmap) that defines how Unicode characters map to glyphs in the component font
> 
> If the components are treated as atomic, you wouldn't want access to their glyphs; just to characters. That is, logically, the component font would tell you which font to use for which range(s) of Unicode characters, optionally with a transform of the metrics.
> 
> Ideally, you'd want to have a bit more elaborate a structure for determining the ranges, because you can end up with a situation ABCdefGHI, where ABC should definitely be in Font1, and GHI should definitely be in Font2, but where def could be in either one, and you want a more interesting algorithm to determine that (such as handling matching braces, etc.)

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 flow by using the character set mechanism which is default to the character set of the component font (e.g., 'cmap' of a TrueType font).

As for characters or glyphs to specify in the component font, I think 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.

For the example you gave above, the response is below.

> 
> > language = "string"
> > Optional. The two-letter ISO 639 code that corresponds to the language of the 'string' attribute.
> 
> 
> In 2 places. Should be the BCP47 language tag…
> 
> > Required. A series of Unicode code points or code point ranges that are specified according to ICU's UnicodeSet pattern syntax. As an example, the ranges U+0020 through U+007E and U+4E00 through U+9FCC can thus be expressed as [[\u0020-\u007E]|[\u4E00-\u9FCC]].
> 
> 
> Syntax is wrong, and a better example would be something like [[\u0020-\u007E][:script=Greek:]].
> More importantly, the spec doesn't discuss what to do when two different components have intersecting UnicodeSets (or contents).


I agree with you that the language (locale) code standard designation is incorrect in the spec. I should revise the spec soon when I have a chance to do it and consult with the other authors.  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.

When the character sets of two components intersect, the order of the components appear in the posing font determines the character set to use. For example. to render "ABCD" with the posing font of two components, component 1 has [ABC] and component 2 has [BCD], since component 1 is before component 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 consistency such as match braces, but here, the simple mechanism can serve the purpose making sure a missing glyph is rendered with sufficiency. The author can always consider the character set before creating the components and sequence. There could even be components of the same font appearing in the posing font many times, the objective is to have way to specify how to arrive at a glyph for a character that would have been rendered with '.notdef'.

Regards

Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20110118/15b1834b/attachment.html>