- From: Glenn Adams <glenn@skynav.com>
- Date: Fri, 15 Aug 2014 12:45:00 -0600
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: John Daggett <jdaggett@mozilla.com>, fantasai <fantasai.lists@inkedblade.net>, WWW International <www-international@w3.org>, www-style list <www-style@w3.org>
- Message-ID: <CACQ=j+eQmnhRYhZ2D8PYB-cE=M9BBHQzQEC-X7a-AvdiQ70tGg@mail.gmail.com>
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 >
Received on Friday, 15 August 2014 18:45:49 UTC