[Gnome-print] Re: [jody: [ynakai redhat com: Re: Gnumeric bug 15607]]

> > I consider it very bad idea, to accept current miserable locale/encoding
> > scheme at all.
> > Instead we should:
> > 1) Use only utf-8 strings in application code
> > 2) Collect all input/output related code to single place (like EFonts
> > are in gal), where it can be dealt in systematic way.
> OK, you're saying to use utf-8 only internally, and keep input/output
> to be still traditional coding? I'm agree to it, though it is MS Windows' way.

Input/output to/from where?
Certainly all text formats should use utf-8 or utf-16.
Gtk (i.e. non-WYSIWYG graphic layer) will be ported to using utf strings
Printer output has to use fonr native traslatioun rules

So the layer for traditional encodings is extremely thin.

> > The current de-facto system of locale-specific encodings is way too
> > error-prone. To make is waterproof, one should include encoding tag
> > with every string passed in system - which results in much-much more
> > inconveniece than using utf-8 everywhere.
> > How can application know, what given character code really means? How
> > to determine, whether it is in iso-8859-1, koi-8 BIG-5 or whatever
> > encoding? You shouldn't force people using only 1-2 languages in
> > their documents - and what is even worse - you shouldn't expect that
> > received document is written in the same locale, where the reader
> > happens to be.
> > 
> > Locales/encoding are EVIL. They have to be replaced by languages/unicode
> > ASAP - and I think it is better to introduce major short-term pain,
> > that to make people suffer forever. The situation is bad enough, that
> > people browsers, mailreaders etc. have to support silly encodings
> > forever - better to not generate more such unhappy applications.
> Unicode(in the future) is good, but utf-8 is very EVIL. Japanese, Chinese
> and Taiwanese(Chinese in Taiwan) use many same characters in different glyphs.
> But utf-8 ignores that. Utf-8 maps one character in one glyph. So utf-8
> ignores and breaks our each culture, that's the point. Japanese and English
> may be in one utf-8 document, but Japanese and Chinese can't be in one utf-8
> document. Please don't think utf-8 is complete.

Just. The whole point is, that unicode is all about characters, not glyphs.
CJK characters all called 'unified', and AFAIK with reason. CJK glyphs
are not unified, but that is not, what unicode is about.
The situation is exactly the same, as for example, with English/German. In
german, one has to replace  (single glyph) with SS (2 glyphs), if switching
lower/uppercase. In English not.
So character->glyph translation is always language dependent.

> There should be a mime header including charset in documents, and applications
> should see that.

No. There have to be headers, identifying separate LANGUAGES, used in parts
of document. The whole thing has to be in some reasonable unicode format
UTF-8 is best, if you have to keep maximum compatibility. Otherwise you
can consider UTF-16.

> We know we should move to the Unicode world with utf-8 locales ASAP, but can
> never move so soon as single people do. There is many many non-GNOME apps and
> system in our Linux distro and Linux box , and almost of all are still not
> ready for utf-8. It will take more than 2 or 3 years for us to be ready for utf-8,
> but we can't use GNOME until that if GNOME is such too optimized to utf-8.
> People will not use GNOME, and also Linux for years!
> I think it's one of the good feature that all new and old can co-exist in GNOME.
> We can see, create and remove files from legacy terminals with legacy command,
> also from gmc. They don't conflict.
> So, we don't want you to ignore our legacy locales/encoding at least more 2 or
> 3 years...

Certainly we want to support them. Plus we need a good migration plan.

PS. Gnome-print is usable for CJK languages with very minimal changes. The
only thing you have to guarantee is correct translating from UTF-8 to
font native glyph mapping. Please note, that it is NOT 1:1 mapping for
europaean languages at moment, but instead it is font-specific one, and
constructed during font loading from PostScript glyph names. So supporting
CJK (in trivial case) means simply a standard way for populating CJK
character block in font unicode mapping, with correct glyph codes.

Btw: Are there C/J/K PostScript fonts for free download somewhere? I would
be very interested to test them out, but I have not found any.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]