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

[Karsten Luecke]

John and I seem to agree on this. His description and screenshot and 
those I made (posted 19 Sept 2009) essentially describe the same effect.

My conclusion so far is that all of a font's metrics, including those 
expressed in OTL tables, should be scaled along with glyph outlines via 
transformation matrix.* Outlines and metrics are part and parcel.**

And if, for CJK fonts, scaling of outlines but not metrics is required, 
this effect can be achieved by using the transformation matrix on 
everything (in this case only the linear scaling part, e.g. for scaling 
down), and then simply tracking in either x or y direction.

So there would be:

1) Transformation (a complete transformation matrix, expressed as the 
array of six values representing a 2D transformation matrix as defined 
in the PostScript graphics model, applied to all outlines and metrics)
2) TrackingHorizontal (expressed as a percentage,*** for (CJK) 
horizontal setting)
3) TrackingVertical (expressed as a percentage,*** for (CJK) vertical 
setting)
4) BaselineShift (baseline shift, expressed as a percentage)***/****

I should emphasize that mine is a "logical point of view". Another 
question is if implementers can or want to deal with this.

Best wishes,
Karsten


[notes]

* Even at the risk that applying rotation may have undesired effects on 
mark/cursive attachment. It is the creator's responsibility to check.

** This is little obvious with the mainstream approach to digital type 
which represents one character (or more, like in ligatures) by exactly 
one glyph as one unit. Here, outlines and metrics (mostly kerning) can 
still be regarded as independent of each other (omitting kerning 
information does not entirely "break" a font's appearance). Mark 
attachment and cursive attachment at least indicate that both are 
somewhat closer related.
Perhaps the dependency of outlines and metrics can be made more obvious: 
Think of one of the CJK font formats which compose letters from 
elementary strokes that are positioned relative to each other. For 
examples, see 
http://engineering.tufts.edu/GradResearch/documents/GradResearch2006/jakubiak.pdf 
(p.17 onwards). Metrics are constitutive for such letters' appearance. 
Scaling the outlines (the strokes) but not the metrics (positions 
relative) would mess such letters up.
It is essentially the same effect with Latin script (OpenType) fonts 
that make use of mark attachment (marks to attach at specific position 
in relation to a base glyph), or Arabic script fonts that use cursive 
attachment in addition (two base glyphs to have a specific position 
relative to each other). To maintain the text image, one needs to 
transform everything that contributes to line layout.

*** Percentage, I assume, refers to the font's UPM.

**** 4) BaselineShift might be expressed via 1) Transformation, but 
perhaps this extra attribute is nice for convenience.





Am 17.12.09 07:00, schrieb John Hudson:
> Ken wrote:
>
>> In other words, while I am clearly in unknown territory due to my area of expertise, these transformation must be implemented somewhere, and thus it should be possible to test these ideas to determine to what extent these transformations have an effect on mark attachment.
>
>> I am in the process of checking whether any of my colleagues are able to prepare a test font with mark attachment, but I am again at a loss as how to test these transformations.
>
> I'm likewise at a loss to know how this might be tested in a 'live'
> transformation of the kind proposed for CFS. I don't know very much
> about existing composite font implementations, so am not sure what might
> be possible.
>
> I do know, however, pretty intimately what happens when glyphs are
> transformed independently of GPOS. Let's say we're making an oblique
> version of a roman face, by mechanically slanting the upright outlines
> to a given value, e.g. 12 degrees. Presuming that all outlines are
> slanted relative to the 0,0 origin point, then all x-direction GPOS
> attachment positions will remain valid so long as there are no
> y-direction adjustments to the same attachments. Now lets consider that
> this font might use the same combining mark glyphs in both lowercase an
> uppercase letters (never an optimal design solution, but it happens).
> This means that the marks need to be raised over the uppercase letters,
> say 180 units. Let's say that we're looking at the uppercase I as a
> base: the anchor attachment for above marks is something like x=344
> y=180, on a 1000 UPM font. If we apply the unadjusted GPOS data from the
> roman font to the oblique, the mark will be positioned too far to the
> left (as in the attached image; the pale blue outline shows the desired
> position). In order to correctly position the mark, the transformation
> has to take into calculate the run-over-rise for the slant angle, and
> add this to the GPOS x-direction attachment.
>
> Regards, John