On Tue, 28 May 2002, Cyrille Chepelov wrote: Bonjour,
Le Tue, May 28, 2002, 3:49:50PM +0800, Zhang Lin-bo a rit: OK. I'll try your patch, hopefully today, to check whether it breaks or not on a latin0 workload.
Thank you.
I'm afraid I'll need the ag1.sh script as well (I'm not running Red Hat).
It's part of the ghostscript distribution of rh7.3 (the filename is ag14.sh in rh7.2)
It would be interesting if you could send me a couple sample files (privately). I'm not a Postscript wizard, and while I can read some non-latin alphabets, I'm totally at loss with the CJK writing systems (big surprise)
I have attached some sample PS files in ps_samples.tar.bz2, They all contains two same Chinese character (ºº×Ö, or Han Zi, they mean "Chinese characters"). I don't know if the attachment is too large for the mailing list (131KB). If it can't get through, I'll send it to your address.
Then, what is shipped by RH ? I mean, how are encoded the Chinese fonts in the RH 7.3 Ghostscript package ?
I don't know much. A set of fontnames is defined in the CIDFont directory, and the ag1.sh script can create more font names in the Font directory (both are subdirectories in /usr/share/ghostscripts/Resource), it seems that none of them works with Dia's EPS files.
Would extending the table of known symbol names in lib/ps-utf8.c (to avoid \uni1234 notations on Chinese glyphs) help ?
I don't think so. I have tried with a document containing the single letter 'A' (whose unicode name is /A), and I got the same result as with Chinese characters.
I will try your patch with latin0 input; if people working on latin(!1 &&
!0)
systems had the time to test your patch as well, to see whether UTF-8 latin2
or KOI8-R is acceptable to Ghostscript, it would be a good knowledge data
point.
Then, what would be even more wonderful, would be to assemble the following
test PS files:
latin0-custom-encoding # I can make this yesterday
latin0-UTF8 # I'll do it this evening.
latin2-custom-encoding # I've got nell's EPS, which works on my
l0 system
latin2-UTF8
KOI8-custom-encoding
KOI8-UTF8
zh_CN-custom-encoding # what you call nonworking
zh_CN-UTF8 # what you call working
maybe also "zh_CN-GB-EUC", "zh_CN-Adobe-GB1", etc. I know nothing about these encodings, but they must represent some 'standard'.
ja_JP-custom-encoding # working, according to Akira TAGOH
ja_JP-UTF8
build a second set of files (the same but after going through ps2ps), and
then pass the whole batch of files to non-Ghostscript Postscript devices
(printers, high-end photocopiers, etc.), and see what works and what
doesn't.
For the moment, I assume the -UTF8 files are out of the PS spec; maybe they
aren't after all?
I'm able to generate only the latin0 files; I'll need volunteers for the
rest (the files you attached to your mail will be fine). And of course,
volunteers to print 20 pages of paper on high-end devices I have no access
to ;-) and on various-locale Ghostscripts.
As far as I know, there's no need to do this kind of test for simplified Chinese, because there're very few PostScript devices in the Mainland China, and fewer with Chinese PostScript fonts. BTW, I have found out the bug in the freetype support: With freetype support enabled, the fonts listed in 'font_data' are ignored (see the '#ifdef' line at font.c:904, and I don't know if this is a bug or a feature). Since rh7.3 uses xfs, no fontpath will be found through the 'XGetFontPath' function. The patch of Robert Young did not work because there was a bug in his code in parsing the fs/config file: most path names (in my system) were skipped because they have a trailing comma (and also I think the code needs to be rewritten to correctly retrieve fontpaths from the 'catalogue = ...' entry of the fs/config file (or one can borrow some lines from xfs, or simply run the 'chkfontpath' program?)). With freetype support enabled, dia now works fine for displaying and for exporting to png with the "Ar pl ..." Chinese fonts (gkai00mp.ttf and gbsn00lp.ttf), but exporting to eps does not work (even for ASCII characters). Another problem is that the output file is too large (10-20MB for a few characters) when using Chinese TTF fonts. So there's still a lot of work to do ... Finally, a suggestion: I think dia should save the locale information with a diagram since interpretation of characters is locale dependent (I have a diagram which contains some Chinese characters, when I try to open it in a non zh_CN locale, I get a lot of warnings, such as "** WARNING **: unicode_iconv(u2l, utf=å¼ ...) failed, because 'Invalid or incomplete multibyte or wide character'...", and the diagram is incorrectly displayed). LB
Attachment:
ps_samples.tar.bz2
Description: BZip2 compressed data