[mpeg-OTspec] Composite Font Standard 2009/12/16 DRAFT

[Ken Lunde]

Karsten,

You wrote:

>> Attribute: MetricsTransformationX (X-axis metrics transformation, expressed as a scale factor, and affecting only X-axis metrics, leaving the glyph impression and attachment points unchanged)
>> 
>> Attribute: MetricsTransformationY (Y-axis metrics transformation, expressed as a scale factor, and affecting only Y-axis metrics, leaving the glyph impression and attachment points unchanged)
>> 
> 
> Since attachment points are explicitly excluded from MetricsTransformationX and MetricsTransformationY, are these supposed to be adjusted by GlyphTransformation?

The descriptions were written according to what daan wrote on 2009/12/14:

> As per discussion in September, modifications to metrics and glyph impression were to be as follows:
> 
> • Metric scaling, subject to x/y scale factors, and not applying to the glyph impression or attachment points.
> • Glyph transformation, subject to full 2-D graphic transformation matrix, not affecting metrics.
> 
> I propose these values should not be percentages, but rather scale factors; that is, 1.0 represents no scaling; 0.5 represents 50% shrinkage. The transformation matrix should be six values representing a 2-D scale/shear/rotation matrix plus translation as defined in the PostScript model.

What is currently in the document (the 2009/12/16 version) should accurately reflect the above.

> If so, I wonder how specific one needs to get in the spec as regards specific OT features* -- would this, then, require a per-feature list saying that GlyphTransformation" does not apply to "kern" & others but does apply to "curs", "mark", "mkmk" & others, to make sure decoders apply transformations correctly?
> 
> * In case of fonts whose layout behavior is determined via OTL tables.

The best way to characterize OpenType feature interaction is that the glyphs must be present in the same component font. Glyphs that belong to different component fonts thus cannot interact via OpenType features. I believe that this is simply one of the limitations of a CFS object, and I also feel that it is a reasonable limitation. GSUB and GPOS feature operate at the GID level, and it would be unwise to introduce GID-specific behaviors in a CFS object.

In terms of your specific question, someone who has more experience dealing with curs, mark, mkmk, and friends should take a crack at answering it.

Regards...

-- Ken