Re: can gnuplot do UTF-8 at all?

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 10 December 2006 09:53, Petr Mikulik wrote:
> 
> There is a file "ps2utf8.ps" at
>         http://djvu.cvs.sourceforge.net/djvu/gsdjvu/

That particular file contains two translation tables. 
One is for the UTF-8 encodings of Adobe's standard set of glyphs.
That gets you something like 1000 characters, I think 
(the table is ~300 lines with about 3-4 mappings per line).
That's nice, but it is only a small part of the total
Unicode/UTF-8 character space.

The second table is a mapping from TeX to Adobe, which is also
interesting but has nothing directly to do with UTF-8.

> It looks as it could use utf8 strings in postscripts, but maybe it requires
> djvu-enabled ghostscript? Or is it something different?

I only know what I could glean from their web site, but it looks to me that
djvu doesn't know anything about encodings or characters.  It is a
compression scheme for scanned images. I think (but here I'm speculating
wildly) it benefits from repeated high contrast regions in the scanned image.
If you scan text, typically there are many copies of the same character glyph.
The compression scheme doesn't care what the character is, just that it
appears more than once.  But I could be totally misunderstanding.

> There are also "u2ps" and "enscript" program that can handle UTF-8 files, 
> how do they do it?

I have used enscript on my machines to print from Japanese UTF-8 documents.
It sort of works, but not reliably.  Every version upgrade to any piece
breaks the whole process.  I have one 'magic' set of compatible versions
that does OK, but it I have not been able to reproduce this success with
more recent versions.
In particular I have not been able to make it work at all with 
ghostscript 8.x   If someone could help me with that, I'd be gratefull!

Anyhow, my limited understanding is that it requires you to identify one
or more existing single-byte encoded fonts that contain the characters
needed by your document. Then it creates a document-specific translation
table that is applied character-by-character to map your original 
character encodings with some equivalent in that specific non-UTF8 font.

This is similar to the approach used by the translation table in the
URL you referenced, except of course that the portion of the Unicode
character space is entirely different.

It is also similar to what Harald Harders did for UTF-8 encoding of the
isolatin1 character set (patchset #1252232).  The problem is, this doesn't
generalize easily to arbitrary Unicode code points.  Even aside from the
issue of supported non-isolatin character languages, we would need to 
handle the Unicode pages for various math and technical symbols. 

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742