At 03:38 PM 5/15/98 -0700, David Goldsmith wrote:
>Rick McGowan (firstname.lastname@example.org) wrote:
>How fast do Egyptian hieroglyphics have to draw?
>The point I'm trying to make is, even if ligatures were 50% slower than
>normal text, which I'm not saying they are, would that be a problem for
>characters outside the BMP? I mean, how many people have to get that
>important presentation in Linear B done ASAP?
There are two types of entities (to be) coded in extended space:
1) complete scripts
2) rare characters for an existing script
(These cases correspond "magically" to the proposed Plane-1 and Plane-2)
for case (2), a good argument can be made that the ligaturing process is
entirely appropriate. The performance penalties are by definition small
(rare characters occur rarely, and the bulk of the text would be in the BMP).
The same case (2) fares poorly under Murray's 'plane dependent fonts'
situation, as I would now need two perfectly matched (metrics wise) fonts to
cover a single script, one for the BMP and one for the non-BMP characters.
Case (1) would work well with any solution that uses a one code per glyph
approach, because whole lines, paragraphs or documents can be expected to be
in one of these scripts. Barring performance information to the contrary it
seems natutal to question ligaturing as an obvious answer.
Plane dependent fonts would still not work well, since SPACE and other
punctuation are shared with the BMP. One could require some reserved code
spaces in the higher planes in those locations that correspond to the MBP's
ASCII/LATIN-1 and GENERAL PUNCTUATION. This would allow a single font to
use 16-bit codes and still answer to the shared punctuation as well as the
non-bmp characters. (This would not be dual coding of characters, but
support for a glyph coding hack. I.e. in line breaking, the non-BMP
position corresponding to SPACE would simply be an unsasigned character).
Ugly, but it can be done.
Short of such hacks, providing an architecture that is both fast and can
provide for single fonts that cover all characters needed for a given
script can be an interesting challenge.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:40 EDT