Re: Canonical equivalence in rendering: mandatory or recommended?

From: Peter Kirk (peterkirk@qaya.org)
Date: Thu Oct 16 2003 - 04:16:08 CST


On 16/10/2003 02:04, Bob_Hallissy@sil.org wrote:

>
> On 15/10/2003 21:44:20 Peter Kirk wrote:
>
> >On 15/10/2003 10:48, Asmus Freytag wrote:
> >>
> >> So we conclude: "rendering any string as if it was normalized" is
> >> *not* a performance issue.
> >
> >Thank you. This is the clarification I was looking for, and confirms my
> >own suspicions. But are there any other views on this? I have heard
> >them from implementers of rendering systems. But I have wondered if this
> >is because of their reluctance to do the extra work required to conform
> >to this requirement.
>
> It may not be just the extra work that gives rise to such reluctance:
> There may be pieces out of the implementer's control (e.g., fonts)
> that would also have to change.
>
> Bob

Surely not, in principle. If a font currently correctly renders the
canonical order (and perhaps other non-canonical orders) and the
rendering engine is changed to always present the text to the font in
canonical order, the rendering remains correct. It could be less
efficient, but is more likely to be more efficient because any attempted
reordering in the font is likely to be inefficient but will be bypassed
by this mechanism. And if a font correctly renders not the canonical
order but a tailored order, with permuted combining class weights as in
Table 5-6, and this tailored ordering is agreed and implemented by the
rendering engine provider and the font provider, rendering remains OK.

The problem only comes with fonts which have been written under the
assumption that they will be presented with a particular non-canonical
order, and designed to work with a rendering engine which does not
guarantee to render in that order. But such fonts are immediately
problematical in a number of ways e.g. they are unable to render
correctly HTML and XML text normalised as recommended. Unfortunately
such fonts are being produced - although this is not the font producers'
fault, for in some cases the Unicode canonical order is so far from the
logical order that it is not reasonably possible for the font to do the
reordering required to render the canonical order. The fix needs to be
made either in the canonical order (ruled out by short-sighted stability
guarantees) or in the rendering engine, not separately in each font.

By the way, as this permutation of combining class weights is for
rendering only and so does not need to be round trip, I don't see any
good reason for prohibiting combination of combining classes. As for the
prohibition on splitting classes, this is obviously necessary where
there is real typographical interference, to avoid unwanted reordering,
but in cases where the combining classes have been incorrectly allocated
so that there is no actual typographical interference and the rendering
must be independent of the actual order of the characters, splitting the
class or transferring the misallocated character to the class it should
have been in may be the best way to render correctly.

-- 
Peter Kirk
peter@qaya.org (personal)
peterkirk@qaya.org (work)
http://www.qaya.org/


This archive was generated by hypermail 2.1.5 : Thu Jan 18 2007 - 15:54:24 CST