Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 205813 - evince doesn't display CJK pdf files properly
evince doesn't display CJK pdf files properly
Product: Fedora
Classification: Fedora
Component: evince (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kristian Høgsberg
: i18n
Depends On:
Blocks: FC6Blocker
  Show dependency treegraph
Reported: 2006-09-08 13:30 EDT by Akira TAGOH
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-22 17:29:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
testcase (1.27 KB, application/pdf)
2006-09-08 13:32 EDT, Akira TAGOH
no flags Details

  None (edit)
Description Akira TAGOH 2006-09-08 13:30:45 EDT
Description of problem:
If pdf files doesn't embed glyphs from fonts when it's generated, evince doesn't
display it properly for CJK. they worked on xpdf because xpdf had CMap tables
and the configuration files to specify the CIDFont as well. and it was no
problem on FC5 because poppler also refers to the same xpdfrc where is at the
same place.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.run evince with CJK pdf
Actual results:
evince doesn't display any characters

Expected results:
should display characters

Additional info:
CMaps, Unicode mapping tables and xpdfrc files will be needed to solve this
issue anyway.
Comment 1 Akira TAGOH 2006-09-08 13:32:30 EDT
Created attachment 135865 [details]
Comment 2 Matthias Clasen 2006-09-10 16:38:18 EDT
I can confirm that instlling xpdf makes the sample document render in evince.
Hmm, adding those data files to poppler will cause file conflicts with xpdf, I
Comment 3 Matthias Clasen 2006-09-10 16:42:35 EDT
xpdf already requires poppler (indirectly, via poppler-utils), so one option would
be to just move the files to poppler and remove them from xpdf. A nicer,
upstreamable solution would be to make poppler look for /etc/popplerrc before
falling back to /etc/xpdfrc
Comment 4 Akira TAGOH 2006-09-10 22:31:39 EDT
looking for /etc/popplerrc sounds much nicer to me too.
Comment 5 Matthias Clasen 2006-09-11 13:11:51 EDT
Looking at the poppler sources, this seems a bit broken currently. 
We seem to first look at /etc/xpdfrc, then if thats not found,
at $HOME/.xpdfrc, then if thats not found, at /etc/xpdfrc again.
Comment 6 Matthias Clasen 2006-09-12 10:10:56 EDT
I'll talk to krh about this when he is back tomorrow.
Comment 7 Akira TAGOH 2006-09-20 01:10:58 EDT
How do we take this to fix then?
Comment 8 Matthias Clasen 2006-09-20 08:04:07 EDT
krh is working on it upstream, and we'll get a new poppler release soon.
At least thats my understanding, I'll check with krh later today.
Comment 9 Kristian Høgsberg 2006-09-22 17:29:28 EDT
Fixed with poppler-0.5.4.

Note You need to log in before you can comment on or make changes to this bug.