From GNOME: http://bugzilla.gnome.org/show_bug.cgi?id=166665 [copied text from bug] ggv can read ps files in Chinese and acroread can read pdf files after installing an extra language package. When I use evince, it gives the error "Error (59677): No font in show/space Error: Unknown font tag 'TT2' Error: Unknown font tag 'TT2' Error: Unknown font tag 'TT2' Error: Unknown font tag 'TT2' Error: Unknown font tag 'TT2' Error: Unknown font tag 'TT2' Error: Unknown character collection 'Adobe-GB1' Error: Unknown font tag 'TT2' Error (62614): No font in show/space Error: Unknown font tag 'TT2' ", I also try evince, ggv and acroread with other ps/pdf files, and find for some files, it can display clearly. My platform is FC3, gnome 2.10 beta 1 ------- From Marco Pesenti Gritti 2005-02-08 09:06 ------- Does xpdf/gpdf work? ------- From blewz 2005-02-11 20:45 ------- gpdf does not work, but ggv work. ------- From Bryan W Clark 2005-03-28 10:17 ------- Copying from RH bug https://bugzilla.redhat.com/beta/show_bug.cgi?id=151125 Description of problem: evince cannot display most of my pdf files correct. The files are loaded ok but the chinese characters turn out to be random meaningless symbols. Running in terminal, I can see a lot of error output such as ===== Error: Unknown character collection 'Adobe-GB1' Error: Unknown character collection 'Adobe-GB1' Error: Unknown font tag 'F5' Error: Unknown font tag 'F5' Error: Unknown font tag 'F5' Error: Unknown font tag 'F8' Error: Unknown font tag 'F3' Error (205398): No font in show/space Error: Unknown font tag 'F8' Error (205407): No font in show/space ===== and my system turned very slow when loading these files. These files are produced by Acrobat Distiller 5.0 (Windows) and/or CTeX suite (Windows) It can render some pdf files very well, which are produced using pdflatex in tetex-latex-2.0.2 or dvipdfmx(20031207), the source file is in UTF-8. Version-Release number of selected component (if applicable): evince-0.1.9-1.1.fc3.nr How reproducible: Always Steps to Reproduce: 1. open a terminal 2. run evince 3. load a file that contains chinese characters Actual Results: If the pdf file is created using adobe distiller under windows, then there would be alot of Error output, no chinese characters can be seen, but a lot of strange symbols. Since most of my pdf files are produced that way (adobe distillers + windows) and the source files(ppt, doc, etc.) are lost(bad luck!), I cannot reproduce them under OOo. Most of the times, acroread displays them well. Expected Results: nothing should happen in the terminal, and the page displays correctly, like acroread (with CHSKIT, language pack of acroread installed) does. Additional info: My default locale is zh_CN.UTF-8 when I switch to zh_CN.GB2312, the problem remains the same, so does the output on terminal.
please try the patch I sent poppler mailing-list. http://lists.freedesktop.org/archives/poppler/2005-August/000885.html This patch maybe fixes your problem. and you need xpdf-chinese or something to view correct chinese characters.
Created attachment 3040 [details] a screenshot without patch
Created attachment 3041 [details] a screenshot with patch The both document is http://www.adobe.co.jp/aboutadobe/pressroom/pressreleases/pdfs/19960311cid.pdf
I don't know whether this bug is somehow related to the correct displaying of CID encoded fonts using poppler-cairo. (Maybe I've drawn the wrong conclusions from the fact that this document seem to use CID encoded fonts.) Would it be possible to create a new patch so that poppler correctly renders CID encoded fonts? (https://bugs.freedesktop.org/show_bug.cgi?id=4223)
CID font detection seems to be fixed in release 0.4.2. Maybe this bug should be closed.
This bug is not fixed yet. It is not concerned with BUG #4223.
Hiroyuki, does your patch work on poppler CVS HEAD/0.5.x?
This should be fixed in CVS, provided the new poppler-data package is installed.
Closing bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.