- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 18 Aug 2014 18:43:37 -0700
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: John Daggett <jdaggett@mozilla.com>, WWW International <www-international@w3.org>, www-style list <www-style@w3.org>
On Mon, Aug 18, 2014 at 6:29 PM, fantasai <fantasai.lists@inkedblade.net> wrote: > On 08/18/2014 06:02 PM, John Daggett wrote: >> >> >> fantasai wrote: >> >>>> Not sure what the intended purpose of this text is but I guess the >>>> first question is whether it's necessary or not. >>> >>> >>> We got requests to clarify when Arabic joining is broken or not >>> broken at an inline boundary. For example, some implementations >>> breaking joining even when there's no style change. This is clearly >>> bad. As another example, in another implementation joining was >>> preserved even when margin/border/padding was nonzero, which created >>> problems for a set of inlined list items that were now pretending to >>> be all part of the same word. >> >> >> I don't think it's an easy task to come up with a good definition of >> whether shaping is broken or not at inline boundaries, at least not one that >> will actually be useful for implementations to use as a guideline. Better to >> consider what's optimal and what's not. Breaking at presentational style >> changes (e.g. color) shouldn't happen. But any property change that affects >> positioning (e.g. nonzero margin/border/padding) or alters an input to >> shaping will potentially affect the output of shaping. Whether it does or >> not will depend on underlying implementation details. >> >> I'm not sure specifying this in great detail helps implementations that >> really need to understand the scripts that they are dealing with in the >> first place. Giving them general guidelines to follow is better I think. > > > I think there are three classes of guidelines here, actually: > > 1. Must not break shaping. (No style change case. You have no excuse.) > 2. Should not break shaping, if possible. YMMV depending on > implementation/font technology. Less breakage = better. > 3. Must break shaping. > > And I think we should be able to give interoperable results > on 1 and 3. And, for some languages, #2 can be subdivided further, such as the "give the correct Arabic letter form, even if you can't shape them properly" topic. ~TJ
Received on Tuesday, 19 August 2014 01:44:27 UTC