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

[Levantovsky, Vladimir]

Dear all,

If you're replying to a thread that was originally started on mpeg-OTspec list, or was copied to both of the lists (as the subject line suggests) - please [please ...] make sure that you include mpeg-OTspec at yahoogroups.com list as a recipient. This is especially important if you want to see your comments incorporated in the spec at some point of time - the messages to MPEG-OTspec list are archived and can be referenced at a later time.

A plea to Clive - please modify the OpenType list software so that it will allow "Reply to all" and will not remove other recipients copied on the email sent to this list.

Thank you,
Vlad


> -----Original Message-----
> From: listmaster at indx.co.uk [mailto:listmaster at indx.co.uk] On Behalf Of
> Behdad Esfahbod
> Sent: Tuesday, May 08, 2012 10:18 AM
> To: multiple recipients of OpenType
> Subject: Re: [OpenType] Re: [mpeg-OTspec] Vertical ligatures
> 
> Message from OpenType list:
> 
> 
> On 05/03/2012 12:48 AM, Eric Muller wrote:
> > Message from OpenType list:
> >
> >> 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...
> >
> > That still leaves the neutrals in limbo.
> 
> Right.  But there's bigger problems with neutrals... DFLT is your only
> chance...
> 
> 
> >> Just wondering, which rtl flag are you referring to? The one in
> >> LookupFlag?
> >
> > Yes.
> 
> I thought that's used for something else.  From the spec:
> 
> "This bit relates only to the correct processing of the cursive
> attachment lookup type (GPOS lookup type 3). When this bit is set, the
> last glyph in a given sequence to which the cursive attachment lookup
> is applied, will be positioned on the baseline."
> 
> And that's what I implement.  I thought we all agree on this one?
> 
> 
> >> How about allocating two bits of three reserved bits in LookupFlag
> to
> >> mean "vertical only", and "horizontal only"?
> >
> > That's essentially what Peter suggested.
> >
> > This seems like a sensible path to me, but I would like to be a bit
> > forward-looking, and have a broad enough scope for this additional
> > selection mechanism, and consequently also understand the situations
> > it won't accommodate (and agree they are not worth handling).
> >
> > Also, for the multi-glyph problem,  I would not characterize the
> > selection as horizontal/vertical, but rather as the relative
> > arrangement of the glyphs, which is what matters to the font
> designer.
> > Essentially, it should be which of the four sides of the first (in
> > glyph order) glyph is touching which side of the second glyph. That's
> > 16 combinations, of which three are necessary:
> >
> > - right side/left side
> > - left side/right side
> 
> Right.  I suggest we document that each script tag has an inherent
> horizontal direction, and how that direction should be determined from
> Unicode data.
> (eg. any script that has characters with bidi category R or AL).
> 
> If we do add bits to let lookups specify which horizontal direction
> they assume, that would need considerable changes to the engines, but
> may be more useful if longterm we like to be able to kern across script
> boundaries.  Eg, a kern lookup can be implemented LTR and referenced
> from the Arabic script as well as DFLT...
> 
> > - bottom side/top side
> 
> Right.  I guess we're just interested in TTB.
> 
> behdad
> 
> > The other combinations are not that common and can probably be
> shaping
> > barriers (i.e. shaping happens independently on each side, much like
> > bidi level run boundaries today).
> >
> > 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
> >
> >
> >
> 
> 
> 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
>