Composite Font Standard

[Ken Lunde]

Many thanks, Tony, for the comments and suggestions. As I wrote to you in a separate email, my reply will include the AHG so that others can benefit from the discussion.

Anyway, you wrote:

> Thanks for sending the proposal.  I have been following some of the  
> forum discussions but it was covering wide spread of issues ranging  
> from fine details of implementation to off topics.
> 
> The spec looks as it is moving in the right direction and I have the  
> following to discuss:
> 
> 1). Why not assume UniqueName our old friend "postscript" name, so far  
> this has been used successfully to identify fonts. In this case, we  
> are defining a synthetic postscript name.

I agree. One of the benefits of a PostScript (or PostScript-like) name is that it uses the lowest common denominator in terms of the characters used for the string, specifically a subset of our old friend ASCII. This guarantees maximum portability.

> 2). MenuName could be optional as one can use the name of the first  
> component font. This does bring back the ATC (Adobe Type Composer)  
> construct where the top level component provides everything. May be  
> this should be a tag instead.

I think it makes more sense to have this specified as an attribute of the <cfs:CompositeFont> tag as opposed to a separate tag, specifically because it is defining characteristics and attributes that apply to the top-most level of the CFS object, which is primarily about naming properties.

> The comments (in parents) about the PlatformID=3 and ScriptID=1 and  
> requires LanguageID. Why not just specify that in unicode? If we worry  
> about localised names, we should list alternatives with language ID  
> which could be ISO tags.

I think that we're saying the same thing, but with different wording. ;-)

Thus, I think that we're in agreement. I will work on improving the wording, which is currently written in terms used by the OpenType specification.

> 3) In the component font, the attributes other than Target should all  
> be optional tags for simplicity. The location hint is nice, but most  
> ad-hoc creators would not care. The transformation is only needed if  
> the component font does not match the set-width of the intended look.  
> The tracking is complete redundant, it one would like optional  
> tracking values, why not just added another transform that the decoder  
> can choose to ignore?

We have explicitly chosen not to discuss the notions of "required" and "optional" at this time, in terms of the tags and their attributes. For simplicity, it might be best to simply state that everything is optional.

> 4) For efficiency and clarity, the encoding should not be required.  
> The character-set should be defined in component ONLY, rather than as  
> a tag in the composite font. The latter will create confusion for the  
> creator and nightmare for the decoder. What if the original code  
> points are either missing or duplicated in a component font? After  
> all, each component may be physically missing.

Again, specifying the <cfs:Encoding> tag is optional. Also, regarding your comment about defined in the component font only, the three functional tags -- <cfs:ComponentFont>, <cfs:Language>, and <cfs:Encoding> -- can be specified in any desired hierarchy. In other words, you can have a construct as follows:

  <cfs:ComponentFont
      Target="Font1">
      <cfs:Encoding
          Target="\u4E00-\u9FFF"/>
  </cfs:ComponentFont>

Although <cfs:Encoding> is a separate tag, the hierarchy in the above example specifies that it applies only to the <cfs:ComponentFont> tag in which it is nested.

> The simple approach would be these optional tags in the component font  
> (one can have combinations of them):
> 
> a) Nothing. When no encoding info is given, the encoding data from the  
> underlying component font is used. This would be the encoding of the  
> physical component font which should have 'cmap' and other encoding  
> facilities.

Exactly. This is what happens when the <cfs:Encoding> tag is simply not specified.

> b) Unicode ranges. Simply specify some code points to enable a  
> restricted set of unicode code points, again through the use of the  
> component font encoding.

Exactly. Proper nesting of the three functional tags enables precisely this case.

> c) Character-glyph pairs. This is the most elaborated one. It  
> resembles the 'cmap' approach of the "Encoding" tag in your document  
> and it's intend (in our case at least) is only to alter the encoding  
> of an existing (component) font.

This sounds like an offshoot or extension to the "Original" attribute of the <cfs:Encoding> tag, but instead of specifying a mapping between code points of the same encoding, or between code points of different encodings, such as from Shift-JIS to Unicode, the mapping is from glyphs to Unicode code points. It indeed sounds useful.

> The decoder can then iteratively use the encoding within each  
> component to determine the glyphs (which leads to shaping). If a  
> character cannot be encoded, the next component is to be used and so  
> and so on. Simple. As versus to the global "Encoding" tag proposed,  
> the "Encoding" table here has to be constructed with much knowledge of  
> each component font and it may not even be feasible in real life.

I am not sure about fonts with 'glyf' tables, but for fonts with 'CFF' tables, glyph names or CIDs can be used, for name- and CID-keyed fonts, respectively, with a high degree of reliability and consistency. Specifying GIDs has some degree of unpredictability, because GID assignments can change from version to version of the same font.

> 5) Optional tag for font metrics for the composite font? At least a  
> bounding box or so for any font (format)! This tag would be truly  
> applicable for both composite and component.

This sounds like an additional attribute for the <cfs:CompositeFont> tag. At least, that is where I think it belongs, because it is a top-level attribute, to be applied to the CFS object as a whole.

> In general, I woud strongly suggest put some restrictions on what tags  
> to expect in composite font while others in component font. Some of  
> the combinations just does not make any sense in real life.
> 
> Here's a document 
> I meant to share with the forum about our XML Splice Font DTD,  
> the .dtd file has been in Mac OS X system 10.3. This also included a  
> sample font to illustrate some of the features.

I have attached the file for the benefit of others.

Regards...

-- Ken

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 339 bytes
Desc: Spliced Font - XML format.pdf
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20100108/6c038fca/attachment.bin>