From: Philippe Verdy (firstname.lastname@example.org)
Date: Wed Aug 24 2005 - 17:27:52 CDT
From: "Eric Muller" <email@example.com>
> This is considerable work that has to be justified by the result: the
> ability to create a single font that covers all of Unicode. Even if the
> sixteen bit barrier was removed, the likelyhood of such a font to ever
> exist is essentially nil; it is already the case that we do not have a
> complete coverage of Unicode in any number of fonts. Furthermore, the mere
> complexity of such a font would be close to intractable; certainly, it
> would have many bugs for a long time, making it not too useful anyway.
> Finally, there are other problems which cannot be addressed by a single
> font, and more or less require some kind of font aggregation mechanism.
> When you have such a mechanism, the need for a single font decreases
> So, yes, the limit can be removed, but the benefit is not worth the cost.
I fully agree. It's best to have smaller fonts designed separately to give
the best coverage of a single script (or of related scripts, such as
Latin+Greek+Cyrillic), and then give to users a range of fonts for each
There's a difficulty with the fact that most Asian fonts implement at least
Basic Latin, or Latin-1, without covering the whole Latin script. This comes
because those fonts contain special forms for halfwidth or fullwidth ASCII,
which are typically used only in Asian ideographic or Hangul contexts with
But the simple solution would be to map only those special (compatibility)
forms in those fonts, and then exclude these Asian fonts for other encoded
Latin text (including general punctations unless they are decently
implemented in Asian fonts too).
My opinion is that those Asian fonts should have ALL their Latin and
punctuation characters removed, so that a renderer will not select those
fonts for rendering only partial Latin text with them, and the rest of the
text with another font designed for another script (the result looks
Instead the renders should only have to select a single font for each
script, without needing to mix several ones with distinct designs to cover
the whole needed script range. It's then important that fonts that pretend
to cover a range cover it fully, at least for a list of language (there may
be additions later in the script range).
Having fonts of small size will certainly help reducing the cost associated
to their necessary upgrade when a script is extended.
What I'd really like to have today is NOT a "pan-unicode" font, but good
fonts with excellent typography for each script. I would really prefer to
have a complete Latin font even if it does not fully support Greek or
Cyrillic, then have another complete font for Cyrillic, then another
complete one for Greek, and being able to design a document stylesheet with
a preference order for fonts based on those script distinctions.
It would really make the life easier for document authors. I don't need
another Arial Unicode MS (still not complete and not updated as often and
easily as we would wish). Instead I want an excellent Arial Latin, plus an
excellent Arial Cyrillic, plus an excellent Arial Greek, plus an excellent
Arial Arabic, and an Arial General (for punctuations, symbols, and digits,
etc.. but not for letters), and so on...
Then I want a authoring or viewing software that will allow selecting font
preference effectively by script type, and replacing that font separately
for a specific script for which I am not satisfied of the result (for
example because it lacks some features or characters). To make this
replacement possible at reasonable cost, the font must be small and easy to
design and manage.
Unfortunately, browsers are not prepared for that: even MSIE will not allow
you to select font preferences for new scripts, because it seems to use an
hardwired list of scripts, instead of consulting a registry of font
capabilities, and the capabilities of the OTLS shaping engine (if a script
requires to activate some OT features within some complex sequence before or
And updates to Uniscribe are still very difficult ot have in reasonnable
time, because it has a single source and cannot be extended by users
themselves (Uniscribe is not open and remains proprietary). Unfortunately,
lots of graphic device drivers only work with Windows GDI+ APIs to handle
accelerated text, and GDI+ only knows Uniscribe.
So applications have to redevelop all the rendering engine instead of just
having to extend some system hook to override the shaping engine behavior
for the graphics rendering they want to produce. The alternative is to use
completely new shaping engines, and that's a quite large software installed
twice on the host system.
There should exist a way, in Uniscribe, to base almost all of its work on
structured rules (we spoke about reordering, and that's effectively all that
has to be extended by users, because the rest is described by font
substitution and positioning tables), which should be accessible to
applications (using a common "UniscribeProvider" API)
This archive was generated by hypermail 2.1.5 : Wed Aug 24 2005 - 17:29:45 CDT