Hi,
I'm sorry to resurrect a month old thread. I was browsing
i18n list archive and thought that the following point made by Markus had
not gathered kind of support it deserves (except for Brian's message in
which he wrote he could see no reason to get rid of iso10646-1 XLFD).
To begin with, I for sure agree that we have to come up
with a reasonable way to deal with sparse fonts, but I'm afraid relying
soley on fonts with legacy encodings (or using legacy encodings as sole
means of checking glyph availability) would results in as many problems
as it solves.
On 2001-08-28, Markus Kuhn wrote:
> On Mon, 27 Aug 2001, Keith Packard wrote:
>> What I think we can likely agree on is that the font's encoding is the
>> only application-visible information on which to base a guess. This means
>> that we should deprecate XLFD's using 10646 so that applications have a
>> chance of locating the necessary glyphs. A user-level library can convert
>> Unicode application data into the appropriate encoding for presentation.
> Sorry, but I think this is the exact opposite of what should be done. In
> most cases, users are perfectly able to pick their own fonts not only
> based on style preferences, but also based on whether the font has a
> sufficient coverage. There is now plenty of original Unicode text out
> there in use for which no combination of legacy encodings provides
> adequente coverage. Just one example: I have been using daily for quite
> some time the w3m-utf web browser and it makes good use of dingbats and
> line drawing characters that are not available in any of the
> non-ISO-10646-1 XLFD encodings.
Let me add yet another example. The legacy XLFD encoding for Korean
font ksc5601.1987-0 covers only a *fifth* of Unicode/ISO 10646 has for
Korean Hangul (1). There are many other writing systems and scripts for
which there's NO 'legacy' encoding defined in and outside X11. Unicode is
the sole character set available for them. Unless a whole bunch of 'new
legacy' (what an oxymoron) encodings are added to cover those scripts,
depreciating iso10646-1 XLFD completely and relying exclusively on fonts
with legacy encodings would make it hard to support them.
Jungshik Shin
(1) For Korean Hangul, actually there's a 'new? legacy' XLFD encoding
used in Solaris. It's 'ksc5601.1992-3' with *almost* the same (but not
as complete as) coverage of *modern* Korean Hangul as iso10646-1. The
encoding file for this along with a patch to the encoding file for
ksc5601.1987-0(which has hundreds of spurious entries) is now in patches
archive for inclusion in XF86 4.2.0. However, this is not the case for
tens, if not hundreds of, writing systems for which there's no legacy
encoding.
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
