[OpenType] Re: [mpeg-OTspec] Vertical ligatures
Levantovsky, Vladimir
vladimir.levantovsky at monotypeimaging.com
Thu May 3 01:59:30 CEST 2012
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
> Behdad Esfahbod
> Sent: Friday, April 27, 2012 10:42 PM
> To: multiple recipients of OpenType
> Subject: Re: [OpenType] Re: [mpeg-OTspec] Vertical ligatures
>
> Message from OpenType list:
>
>
> On 04/27/2012 05:26 PM, Eric Muller wrote:
> >
> > 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 OpenType specs assume that text is in the /natural/ logical
> horizontal direction of the script being shaped. In HarfBuzz, we
> implement this by always ensuring that direction. So, if you pass
> <RLO, f, i, PDF> to HarfBuzz, we detect that Latin is naturally left-
> to-right, so we reverse the glyph stream, shape, and reverse back...
>
> Your point re vertical is of course, very valid. If the font doesn't
> know which direction it is shaping, it's hard to know what to do. GPOS
> partially addresses this, for advances, but not offsets, because each
> GPOS adjustment value can have both horizontal advance adjustment and
> vertical, and horizontal is only used when shaping horizontal text and
> vertical only in vertical.
> Would be nice to streamline these across the spec.
>
> If fact, what may be useful is all the major implementors getting
> together and document from the bottom up what features are being
> applied for each script and writing mode (and what is desired). The
> way the standard is organized right now, ie. listing hundreds of
> features, without a coherent story of what is to be applied and when,
> is just not that useful and leaves of lot of guesswork for
> implementations and font designers.
>
> behdad
>
>
> 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
>
More information about the mpeg-otspec
mailing list