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

[Yukihiro Nakai <ynakai redhat com>]

On 23 Nov 2000 12:42:05 -0200
Lauris Kaplinski <lauris@helixcode.com> wrote:

> Hello!
> > > 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

Input/output to/from files, XIM input methods or desktops(menu, or other.).
The future(next?)GTK+ powered by Pango will use utf strings in its internal, right?

> 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
> > 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.

OK, I see,

> > 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.

OK, I see your (and gnome-print's?) plan for the legacy but, for another example,
does Evolution development team in HelixCode also think so?
Evolution seems to send/receive only UTF-8 mails, but almost of all mailer in Japan
only handles JIS code so at least it needs optional feature to read/write a JIS code mail.
UTF-8 mails are still unacceptable in Japan. Our staff Tagoh have sent some patches already,
but it seems to be difficult for Evolution to accept them until its release.

Evolution will be introduced with GNOME 1.4 as one of the important GNOME features, but our people
will never find it useful without JIS code and XIM support. I'm very afraid of that, and of such
cases. (Japanese don't use pan, balsa, xchat, gnome-pilot, gtkhtml for same reason.)

> 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.

Really? 

> 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.

Sorry I can't find downloadable CJK PostScript font anywhere.
Some printer has its own font in itself and we usutally test with our printer
or our Japanized version of ghostscript. (We still need to make patches for every
ghostscript. It's also a headache...)

But there are many ttf font and some Adobe CID fonts.

CIDFont: ftp://ftp-pac.adobe.com/pub/adobe/acrobatreader/unix/4.x/
  jpnfont for Japanese
  korfont for Korean



---
Yukihiro Nakai, Red Hat Japan, Development.