Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 20854 - Ghostscript does not render Higher Unicode characters
Summary: Ghostscript does not render Higher Unicode characters
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Printing (show other bugs)
Hardware: x86 Linux
: High critical (vote)
Assignee: Printing Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-05-12 11:16 UTC by Zhen Lin
Modified: 2003-10-21 01:54 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
PS from Mozilla with the problem (mozilla.ps,35.68 KB, application/postscript)
2003-10-19 08:24 UTC, Zhen Lin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zhen Lin 2003-05-12 11:16:28 UTC
I find that Ghostscript refuses to render any of the higher unicode characters
(> 255), i.e. CJK ideographs.

I suspect it is the lack of fonts, or a limitation of Postscript... Or is it
just  a misconfigured piece of software?

The missing glyphs are rendered as 1 (one) hollow rectangle. 

If it is a limitation of Postscript, is there another way around this? PDFs seem
to support multi-byte encodings... But as soon as I try to print them, they come
out, with all the >255 characters as single hollow rectangles. (My printer is a
raster printer, therefore the PDF has to be processed by ghostscript)
Comment 1 Clemens Schwaighofer 2003-05-12 22:09:34 UTC
do you have the apropiate fonts installed? I can remember when I had to get CJK working with Tex I also found documents for ghostscript and you had to have those japanese fonts (eg wadalab) installed or you can't view/create them.
Comment 2 Zhen Lin 2003-05-13 04:08:46 UTC
I have appropriate fonts installed, I see them perfectly fine in Mozilla, gedit etc. But not after it has been converted to Postscript.

I think it is a limitation of Postscript, I read somewhere that it was impossible to use more than the first 256 glyphs in a Postscript font.
Comment 3 Zhen Lin 2003-05-13 06:11:23 UTC
I did some tests... The Postscript interpreter dies:

/SIL-Kai-Reg-Jian DoFont
Loading SIL-Kai-Reg-Jian font from /usr/X11R6/lib/X11/fonts/truetype/SIL-Kai-Reg-Jian.ttf... Error: /rangecheck in --string--
Operand stack:
   SIL-Kai-Reg-Jian   SIL-Kai-Reg-Jian   Font   SIL-Kai-Reg-Jian   770455   SIL-Kai-Reg-Jian   --nostringval--   SIL-Kai-Reg-Jian   (/usr/X11R6/lib/X11/fonts/truetype/SIL-Kai-Reg-Jian.ttf)   false   --nostringval--   77018   77018
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   %loop_continue   2   3   %oparray_pop   --nostringval--   --nostringval--   false   1   %stopped_push   .runexec2   --nostringval--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --nostringval--   2   3   %oparray_pop   3   3   %oparray_pop   --nostringval--
 --nostringval--   --nostringval--   --nostringval--   --nostringval--   false   1   %stopped_push   6   4   %oparray_pop   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   %array_continue   --nostringval--   --nostringval--   --nostringval--
%loop_continue   --nostringval--   --nostringval--   --nostringval--   11   --nostringval--   --nostringval--   false   1   %stopped_push   --nostringval--   --nostringval--   --nostringval--   --nostringval--   --nostringval--   %array_continue   --nostringval--   --nostringval--   --nostringval--   --nostringval--
Dictionary stack:
   --dict:1055/1123(ro)(G)--   --dict:0/20(G)--   --dict:116/200(L)--   --dict:17/17(ro)(G)--   --dict:1055/1123(ro)(G)--   --dict:28/50(ro)(G)--   --dict:12/40(L)--
Current allocation mode is local
Current file position is 25


It would seem that there are too many glyphs in the font... Or not.
Comment 4 Thomas Raschbacher gentoo-dev 2003-06-17 12:39:35 UTC
hmm.. u got cjk in USE ?
Comment 5 Zhen Lin 2003-06-18 02:53:22 UTC
Yes, I have CJK. I am almost certain it is a limitation of PostScript. Perhaps some patches and extensions need to be applied. Everytime I convert a Unicode TTF into a PostScript font (Type1), it warns me "glyphs higher than 255 will not be accessible"

In the meantime, I wait for someone to finish off the XPrint ebuild I have started in another bugreport.
Comment 6 Brian Jaress 2003-07-14 13:19:58 UTC
I have the same problem.  Ghostscript does require a patch for CJK (http://www.gyve.org/gs-cjk/).  That's probably what's needed.
Comment 7 Mamoru KOMACHI (RETIRED) gentoo-dev 2003-07-15 11:12:40 UTC
Hi,  I can use Japanese fonts with ghostscript-7.05.6-r2 with USE="cjk" (only use gs and ghostview to display ps file, though). kochi-substitute is known not to work with ghostscript-7.0x, but if you were using kochi-fonts you would be able to see Japanese PostScript file.  I'm not sure about the other languages, korean and chinese, but at least it works for me. 
Comment 8 Zhen Lin 2003-09-12 20:53:26 UTC
Well, it works better now - but it is still flaky for Postscript produced by Mozilla. Perhaps I should look for real CJK postscript files instead.
Comment 9 Heinrich Wendel (RETIRED) gentoo-dev 2003-10-12 04:53:00 UTC
what's the status of this?
Comment 10 Heinrich Wendel (RETIRED) gentoo-dev 2003-10-19 06:55:21 UTC
it's working for me and usata, if you still have problems, please reopen
the bug and attach an example file :)
Comment 11 Zhen Lin 2003-10-19 08:24:41 UTC
Created attachment 19476 [details]
PS from Mozilla with the problem

I am beginning to think it is because the fonts for the characters don't
exist... Could someone provide a file that works for them?
Comment 12 Zhen Lin 2003-10-21 01:54:00 UTC
OK, so it is a font problem and/or a Gecko problem. I printed a multilingual
document using (a) Monospace (b) Arial Unicode MS, and (b) printed with more,
but not all glyphs.

I also note that Ghostscript doesn't support BiDi... Hebrew and Arabic text
got rendered left-to-right, and obviously, the Arabic characters were rendered
using the isolated form.

Evidently, the Pango substitution happening at render-to-X11-time is not
happening at render-to-PostScript time.

RESOLVED INVALID is OK with me.