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

Ken Lunde lunde at adobe.com
Thu Dec 17 06:25:02 CET 2009


John,

You wrote:

>> 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.
> 
> It's a tricky question, because in theory the problem of transformations to GPOS lookups is not feature-specific but could apply to any GPOS lookup in which there is both an x- and y-direction adjustment. If a slant transformation is applied to glyphs, then there needs to be a corresponding horizontal adjustment relative to any y-direction value in the affected lookup. In practice, this is most likely going to affect attachment lookups, i.e. anchor attachment or cursive attachment in the features that Karsten has identified. But in theory, since any GPOS lookup may have a y-direction value, it could affect even something like kerning.

It's tricky, but it should be testable. If it's not testable, then I would question whether it deserves to be considered for the specification.

Karsten then wrote the following only to me, but it is clearly worthy to bring up for discussion here (sorry, Karsten, but if we're going to make progress, we need to raise any and all issues, and you have raised good ones):

> Hello Mr Lunde, I'll keep this offlist to not distract from the main discussion:
> 
>> 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.
> 
> Somehow it slipped my attention that in this earlier email BOTH "metrics scaling" and "glyph transformation" (sticking to Mr Strebe's earlier terms) would ignore attachment points.
> 
> This makes, imo, the entire scaling functionality useless for future OT fonts that make heavier use of mark attachment. Including Latin script fonts. If "glyph transformation" does not affect metrics (nor attachment points) and "metrics scaling" does not affect attachment points either, attachment points are never scaled along with glyph outlines. Which leads to odd positioning of marks as well as cursive attachment (which is more visible) as soon as any scaling is defined.
> 
> I think the main issue is that there are different needs for Latin/Arabic/Devanagari script fonts and for CJK fonts, and the current description addresses the needs for CJK fonts but not Latin/etc fonts.
> 
> Couldn't the type department should do (or perhaps is already doing) a quick mini testfont with mark attachment to play with this and GlyphTransformation and MetricsTransformationX/Y as currently defined, and test implications of this? Simply to have some hands-on sample which helps making decisions.

While I am quite comfortable discussing things related to CJK, when it comes to mark attachment, I am in unknown territory. I must therefore defer to those with experience in this area.

With that said, the two types of transformation that we're discussing -- "metrics transformation" as X- and Y-axis scale factors, and "glyph transformation" as a six-element transformation matrix -- must be currently implemented in some applications or text engines, and the effects and interactions that have come up for discussion can be tested with today's fonts. After all, these are attributes for a component font tag, meaning that these transformations apply only to a single component font.

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.

Regards...

-- Ken




More information about the mpeg-otspec mailing list