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

[Ken Lunde]

Karsten,

Given that a transformation matrix can be used to apply three distinct transformations -- translate, scale, and rotate -- I would thus advocate that we eliminate the BaselineShift attribute. One reason would be to avoid confusion when a transformation matrix specifies a translate transformation that results in a Y-axis shift, thus the possibility of a conflict with the BaselineShift attribute.

A CFS object encoder could certainly offer these three transformations as part of a UI for creating a CFS object, but when the CFS object is written, a single attribute can be used to capture the desired settings.

I still see value in #2 and #3 below, but I would favor using X and Y over Horizontal and Vertical in the attribute names. And, because we now using arrays, why not simply combine them into a single two-element array, whereby the integer value 0 or string value "None" is used for a no-op meaning? Thus, the following two attributes would results:

  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)

  Tracking (expressed as an array of two percentage values, for X- and Y-axis tracking, respectively)

And, getting back to my point about testing, these transformations and how they affect GPOS features are not specific to CFS objects. They apply to any contemporary font. As I already pointed out, these transformations are to be applied on a per-component font basis. Given that a CFS object can reference multiple component fonts, the way in which these transformations are described or baked into the CFS object brings some level of formality to their use, thus the difficulty in getting our collective heads around it. Instead of specifying these transformations through an application UI, perhaps as part of a character or paragraph tag, it is now set into the font itself.

I'd like to get daan's thoughts about these discussions, as someone on the "decoding" end of the equation.

Regards...

-- Ken

On 2009/12/17, at 3:19, Karsten Luecke wrote:

> 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