Doug made extremely good posting which I think deserves attention from all
people who read this.
> -----Original Message-----
> From: Doug Ewell [mailto:email@example.com]
> Sent: Tuesday, January 18, 2000 6:16 AM
> I read Janko's web page and had "a few" comments.
> First off, I agree with Janko's goal of avoiding the need for special
> Russian-language Cyrillic fonts and special Serbian-language Cyrillic
> fonts. After all, one of the most highly touted ideals of Unicode is
> to make it possible to enter, process, and display different scripts
> in one document without special "language packs" or different OS's.
> Russian Cyrillic and Serb Cyrillic ought to be no exception.
That's exactly what I tried to reach!
> Janko commented, "Up to now there is no known software which will
> render the same Unicode characters differently if they are tagged as
> text in Serbian!" True, but for that matter, up to now there is also
> no software which will handle Janko's proposed additional Unicode
I don't know if this was clear enough, I'm not trying to say that the best
solution for problem of different cursive forms of mentioned Cyrillic
letters in Serbian and Russian would definitely be adding five new
characters to Unicode. I am trying to move the things in the direction which
would give the BEST results in PRACTICE (read: before I grow too old to use
As far as I can see it can definitely be one very easy solution: once they
would appear in Unicode, every software which would support Cyrillic would
handle them properly.
I also don't see that adding these five letters would make any potential for
making domino effect in any way since the number of living Cyrillic
languages is quite small. If Unicode added even characters for older
Cyrillic scripts (old hundreds years ago) I don't see that five new
characters would make any big problem. And certainly now would be a good
time to do so, because Unicode is still not too widely used. As the time
passes it would be harder and harder.
> Remember that even if the Unicode committee members felt that the extra
> character codes were a good idea (which they don't), it takes quite a
> bit of time and many approval stages to get them added, and then there
> is always a lag between new versions of the standard and software which
> uses the new version.
True, but still this is very straightforward solution for the named problem,
since it does not require any new software concepts like "rendering based on
language tagging" which requires a lot of changes in many levels of the
software: since I'm Windows programmer, I know that such a request would
mean that API would have to be extended to pass the *language* information
to the font creation engine. This means that Microsoft would have to change
the API (very much!), MFC and all their applications etc. and all this just
to make possible to display five Serbian letters properly? I don't expect
this even in next ten years!
Now somebody would say that they'd do this because of Japanese or Chinese
market -- but I don't think so -- as far as I can see there are different
cultural preferences to the look of the same characters in Japan and in
China, but I don't expect that either Chinese or Japanese people will insist
that software becomes changed so that BOTH variants are visible in one
document. Japanese people would always recognize easier their variants and
Chinese their. And even so, information "China or Japan" can be squeezed in
"charset" field -- but there is not space to squeeze "Serbian" or "Russian"
Contrary to that, having Serbian and Russian text in the same document is
quite a small goal which should be handled gracefully.
> In the meantime, the concept and format of Plane 14 characters for
> language tagging have *already* been approved in the form of Technical
> Report #7. Furthermore, they can solve not only the Serbian problem
> before us, but also other problems in which the same characters need
> to be displayed differently depending on the language.
> I might add that this disproves Janko's statement that "nobody proposed
> any standard which would extend over HTML boundaries."
Doug, I'm sorry this was too hard statement. But I need your help to make
this things more clear, for me poor programmer. I think that this issue is
worth of opening a new thread of discussion here, which I'll do now.
> Finally, it may be possible to avoid this whole issue altogether in
> applications that do not require high-quality Cyrillic typography by
> using oblique (sloped roman) letterforms instead of "cursive" italics.
> That way neither Russian-style letters nor Serbian-style letters get
> preferential treatment. I know this will not be the preferred approach
> for many people and may generate some flames. The point is that not
> every Unicode-enabled application will require professional-quality
> rendering engines.
Can you give the example which applications "do not require high-quality
Cyrillic typography" at the days when nobody buys for printing anything that
is not capable of at least 600 dpi? We are not talking about character
terminals any more.
What we are interested in are "common" applications like poor Microsoft
Word. It is far from "professional" typesetting engine, but even such
applications should offer something decent. And anybody from the people who
here "do fonts for living" would tell you that using "sloped" letterforms
for Times or any Serif is more than unacceptable.
Doug, thank you very, very much, please keep on participating in this
discussion, I need people who can help me to make all things clear.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:58 EDT