Bug 205813 - evince doesn't display CJK pdf files properly
Summary: evince doesn't display CJK pdf files properly
Alias: None
Product: Fedora
Classification: Fedora
Component: evince (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Kristian Høgsberg
QA Contact:
Keywords: i18n
Depends On:
Blocks: FC6Blocker
TreeView+ depends on / blocked
Reported: 2006-09-08 17:30 UTC by Akira TAGOH
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-22 21:29:28 UTC
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 17:32 UTC, Akira TAGOH
no flags Details

Description Akira TAGOH 2006-09-08 17:30:45 UTC
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 17:32:30 UTC
Created attachment 135865 [details]

Comment 2 Matthias Clasen 2006-09-10 20:38:18 UTC
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 20:42:35 UTC
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-11 02:31:39 UTC
looking for /etc/popplerrc sounds much nicer to me too.

Comment 5 Matthias Clasen 2006-09-11 17:11:51 UTC
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 14:10:56 UTC
I'll talk to krh about this when he is back tomorrow.

Comment 7 Akira TAGOH 2006-09-20 05:10:58 UTC
How do we take this to fix then?

Comment 8 Matthias Clasen 2006-09-20 12:04:07 UTC
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 21:29:28 UTC
Fixed with poppler-0.5.4.

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