coloring characters that participate in a grapheme cluster, ligature, etc., or produce context for surrounding characters (e.g., Arabic), is a legitimate use case and a real world requirement, so it can't be simply dismissed or discouraged; however, there may be constraints when a font transition (family or face) is required across a boundary: that would be sufficient to block ligature formation, and perhaps even contextual substitution On Tue, Jan 17, 2012 at 1:40 AM, Jonathan Kew <jonathan@jfkew.plus.com>wrote: > On 16 Jan 2012, at 23:15, fantasai wrote: > > > > Added: > > | The rendering characteristics of a <i>character</i> divided by an > > | element boundary is undefined: it may be rendered as belonging to > > | either side of the boundary, or as some approximation of belonging > > | to both. Authors should avoid dividing grapheme clusters by element > > | boundaries. > > > > How's that? > > That appears to specifically _discourage_ examples such as colouring a > diacritic differently from its base character, which is a use case that > gets requested from time to time: > > <div style="font:18px Times"> > Careful authors use the spelling > ‘naı<span style="color:red">̈</span>ve’ > rather than > ‘naı<span style="color:red">̇</span>ve’. > </div> > > Support for this is currently quite limited (the above renders nicely in > Gecko on OS X, where the Times font does not use precomposed glyphs for > these combinations, but the colour is lost on a platform where Times is > replaced by Times New Roman, for example); still, it seems unfortunate to > tell authors that they shouldn't be attempting to do this at all, rather > than just warning them that the desired rendering may not (yet?) be widely > implemented. > > JK > > >Received on Tuesday, 17 January 2012 15:35:04 UTC
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:09 UTC