[OpenType] Re: [mpeg-OTspec] Vertical ligatures

[Levantovsky, Vladimir]

FYI - forwarding all missing emails to MPEG list

> -----Original Message-----
> From: listmaster at indx.co.uk [mailto:listmaster at indx.co.uk] On Behalf Of
> Eric Muller
> Sent: Friday, April 27, 2012 5:26 PM
> To: multiple recipients of OpenType
> Subject: [OpenType] Re: [mpeg-OTspec] Vertical ligatures
> 
> Message from OpenType list:
> 
> 
> I think there is a deeper problem here.
> 
>  From the point of view of the font, any transformation that involves
> multiple glyphs is of course dependent on the relative positions of
> those glyphs. Consider forming the usual "fi" ligature: that makes
> sense only if the "f" is on the left, and the "i" is on the right. The
> same applies to kerning, and also to contextual 1->1 operations.
> 
> However, the font has only an indirect access to those relative
> positions, and that indirect access is more or less robust.
> 
> A font typically *assumes* that if "f" is followed in the glyph run by
> "i", then "f" must be on the left, and therefore "i" is on the right.
> However, that's not true for the input <RLO, f, i, PDF>. Similarly, we
> have an assumption that "א" followed by "ב", then "א" is on the right,
> which may not be valid. Those cases are not too problematic because
> they are somewhat unlikely, but things get both more dicey and more
> likely when considering two glyphs for bidi neutral characters.
> 
> The case of vertical text is similar, in the sense that the assumption
> "f is on the left, i is on the right" is broken if f is actually above
> i. The saving grace is that, as Dave mentioned, the font is actually
> "informed" of this arrangement by the application of 'vert', and can
> remember it by combining this bit with the glyph id (because the glyph
> id is the only piece what is common between 'vert' and 'liga', i.e.
> where the bit can be stored). While this sort of works, it's really a
> big kludge.
> 
> I think that what John is looking for is an explicit and reliable
> indication of the relative positions of glyphs. Peter Constable
> mentioned to me this possibility: currently the resolution of feature
> tags to actual lookups takes into account an OT script and an OT
> language; it could also include another parameter, the relative
> position. Thus, ('liga', script, language, horizontal_lr) could resolve
> to lookups that forms the usual "fi" ligature for the run <f, i>, while
> ('liga', script, language, horizontal_rl) could resolve to lookups that
> form the "fi" ligature for the run <i, f>, while ('liga', script,
> language, vertical-lr) could resolve to lookups that forms the Kazuraki
> vertical ligatures.
> 
> There are multiple ways to incorporate this in OT: one way is to add
> one stage to the current mapping, another is to have feature tags
> resolve to lookups just as they do today, but to have flags on lookups
> that say under which conditions they should be applied. In fact, I have
> the intuition that the rtl flag was intended precisely for that use,
> and was later "deprecated" to its current noop status when everybody
> forgot the problem it was intended to solve.
> 
> > Indeed; we concluded that there was no real need to duplicate a set
> of
> > horizontal layout features for vertical use.
> 
> Can you explain vkrn?
> 
> Eric.
> 
> 
> 
> List archive: http://www.indx.co.uk/biglistarchive/
> 
> subscribe: opentype-migration-sub at indx.co.uk
> unsubscribe: opentype-migration-unsub at indx.co.uk
> messages: opentype-migration-list at indx.co.uk
>