Bug 205813

Summary: evince doesn't display CJK pdf files properly
Product: [Fedora] Fedora Reporter: Akira TAGOH <tagoh>
Component: evinceAssignee: Kristian Høgsberg <krh>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: eng-i18n-bugs
Target Milestone: ---Keywords: i18n
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-09-22 21:29:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 150224    
Attachments:
Description Flags
testcase none

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):
evince-0.6.0-1.fc6
poppler-0.5.3-2.fc6

How reproducible:
always

Steps to Reproduce:
1.run evince with CJK pdf
2.
3.
  
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]
testcase
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
guess.
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.