Re: [css-text] Shaping Isolation and Layout Separation of Inlines

On Fri, Aug 15, 2014 at 12:37 PM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> On Fri, Aug 15, 2014 at 11:04 AM, Glenn Adams <glenn@skynav.com> wrote:
> > On Fri, Aug 15, 2014 at 11:34 AM, Tab Atkins Jr. <jackalmage@gmail.com>
> > wrote:
> >> On Fri, Aug 15, 2014 at 10:26 AM, Glenn Adams <glenn@skynav.com> wrote:
> >> > On Fri, Aug 15, 2014 at 11:09 AM, Tab Atkins Jr. <
> jackalmage@gmail.com>
> >> > wrote:
> >> >> You're right about full shaping across a word (thus the note about
> >> >> "shaping might not result in the glyphs joining correctly"), but
> >> >> per-character shaping (selecting the initial/medial/final/isolated
> >> >> form) is necessary for remotely correct rendering, and can happen
> >> >> regardless of what changes occur from one character to the next.
> >> >
> >> > Not necessarily. This could be made to work with, e.g., Arabic script
> in
> >> > combination with OpenType GSUB features 'isol', 'init', 'medi',
> 'fina',
> >> > but
> >> > this is only because OT Arabic script support requires the application
> >> > (in
> >> > this case the shaper code) to be able to independently determine which
> >> > form
> >> > applies and then use the related feature to map to glyph. However,
> this
> >> > situation does not necessarily hold for more advanced OT Arabic fonts
> >> > that
> >> > use different feature sets, for other complex scripts used with OT, or
> >> > for
> >> > TT fonts that use 'mort' table.
> >>
> >> Apologies, but you're speaking over my head. Can you dumb it down a
> >> little so I can understand what you just wrote?
> >
> > Ha, that's a change. It's usually the other way around. :)
> >
> > Basically I'm saying that "remotely correct rendering" of contextual
> forms
> > is highly dependent on script (e.g., Arabic vs Devanagari), on font type
> (OT
> > vs TT), on specific font tables use by fonts (on either side of style
> > boundary) (e.g., OT GSUB with {isol,init,medi,fina} features vs OT GSUB
> with
> > non-standard/cutom shaping features vs TT 'mort').
> >
> > Or to put it more simply, what John said:
> >
> > "Any property that affects the set of features applied to a given text
> run
> > is an input to shaping, so changes in those may affect shaping results."
> > "[C]omplexities of text handling at this level make it very difficult to
> > come up with easy generalizations like this [fantasai: shaping is not
> broken
> > across an inline element boundary unless ...]."
>
> Okay, cool.
>
> Based on the little I know, though, you don't need all that complexity
> just to recognize what basic form the letter will take.  The word
> won't look *good* if the letters are in the right form but not shaped
> correctly, but it'll be readable at least.


Not necessarily. A shaping engine may not have sufficient information to
determine which glyph in the font constitutes a particular form. It will
depend on font format, specific font, and script. I've given a few examples
of when it is not possible to find the glyph even if the basic form the
letter will take can be predicted.


>   It *won't* be readable (or
> at least will be much harder to read) if the letters are *also* in the
> wrong form, in addition to not shaping correctly.
>
> ~TJ
>