W3C home > Mailing lists > Public > www-style@w3.org > August 2014

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 15 Aug 2014 11:37:38 -0700
Message-ID: <CAAWBYDAjcRSN=sUAfHcXOJu7q0d7iYMLPi3NXynzwN+ZizFqRQ@mail.gmail.com>
To: Glenn Adams <glenn@skynav.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>
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.  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:38:26 UTC

This archive was generated by hypermail 2.3.1 : Friday, 15 August 2014 18:38:26 UTC