W3C home > Mailing lists > Public > www-svg@w3.org > October 2008

Re: [1.2T-LC] i18n comment 8: Text rendering order (ISSUE-2110)

From: Doug Schepers <schepers@w3.org>
Date: Thu, 16 Oct 2008 16:50:13 -0400
Message-ID: <48F7A905.2050506@w3.org>
To: Chris Lilley <chris@w3.org>
CC: www-svg@w3.org, public-i18n-core@w3.org

Hi, Chris. I18N-

Chris Lilley wrote (on 10/13/08 1:55 PM):
>  
>> "The glyphs associated with the characters within text content block
>> elements are rendered in the logical order of the characters in the
>> original document, independent of any re-ordering necessary to
>> implement bidirectionality. Thus, for text that goes right-to-left
>> visually, the glyphs associated with the rightmost character are
>> rendered before the glyphs associated with the other characters"
> 
> This is my own viewpoint and has not yet been discussed with the WG.
> 
> Good catch about other reasons for reordering besides bidi. I agree
> the current text suggests its the only reason for reordering. Would
> this text be better?
> 
>   "The glyphs associated with the characters within text content block
>   elements are rendered in the logical order of the characters in the
>   original document, independent of any re-ordering necessary for
>   visual display (e.g., to implement bidirectionality). Thus, for text
>   that goes right-to-left visually, the glyphs associated with the
>   rightmost character are rendered before the glyphs associated with
>   the other characters, as they come earlier in logical order."
> 
> The reason we need to describe rendering order is to cover the case
> where glyphs overlap, have different colours, and use transparency. In
> that case, the rendering order affects the visual result.

Your rationale makes sense to me, since SVG is a largely
presentation/design format, and we need to account for these graphical
aspects of language.  This is consistent with the Painter's Model.

I do wonder, though, if the reordering of glyphs into presentational
order might be a pre-processing step before rendering.  In some
implementations (implementor feedback welcome!), this might even be
necessary, since the text engine and rendering engine might be unrelated
components in the pipeline, and I'd expect the text handling to be done
first... in other words, the output from the text engine might not be
controllable by the implementation, which just passes it on to the
renderer, in which case the document order is superseded by the "logical
order".  (I suspect I'm talking gibberish, so I'll break off there.)


Also, perhaps we can be more explicit about cases where the
presentational ordering of glyphs may not match most Western-language
developers, so they know why we are qualifying the case so much?  Based
on this comment from Richard...

ishida@w3.org wrote (on 10/10/08 3:44 PM):
>
> Does this allow for reordering of glyphs in Indic and South East
> Asian languages, where the glyphs are not in the same order as the
> characters in the text stream?

Should we add something along the lines of the following?
[[
For example, in Indic and South East Asian languages, where the glyphs
are not necessarily in the same order as the characters in the text
stream, reordering occurs ((before/after)) the rendering processing,
with regards to transparency, color compositing, application of paint
servers, and overlapping of glyphs.
]]

This will be interesting to discuss at TPAC.


Regards-
-Doug, speaking for himself
Received on Thursday, 16 October 2008 20:50:21 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:40 GMT