Evince can't display japanese vertical text correctly, because poppler lacks japanese vertical text feature.
Created attachment 10496 [details] PDF file cause this problem
Created attachment 10497 [details] correct image that acroread displayed.
Created attachment 10499 [details] incorrect image that evince displayed
Created attachment 10500 [details] [review] a patch solves this problem This is a patch for poppler source in CVS (2007/6/28).
Poppler can't display many CJK characters when displaying CID characters using TrueType font. This patch also make better about this.
Created attachment 10501 [details] PDF file displays Japanese CID characters.
Created attachment 10502 [details] image acroread displayed
Created attachment 10503 [details] image evince displayed evince couldn't display many characters.
Created attachment 10504 [details] image evince with patched poppler displayed If poppler is chaned with this patch, evince can display more characters with variant form characters.
Patch commited, thanks a lot, please keep contributing to poppelr with such high quality code :-)
This patch causes a regression in the rendering of http://people.freedesktop.org/~jrmuizel/16bitImage.pdf The wrong glyph is chosen for ft ligature in 'software' at the bottom of the page. Acroread displays the pdf correctly.
Created attachment 10922 [details] patch fixes bug comment #11 points out (In reply to comment #11) > This patch causes a regression in the rendering of > http://people.freedesktop.org/~jrmuizel/16bitImage.pdf > > The wrong glyph is chosen for ft ligature in 'software' at the bottom of the > page. > > Acroread displays the pdf correctly. > This is the case that the Encoding is "Identity" and ToUnicode exists. GfxCIDFont::getCodeToGIDMap makes CIDTOGID map from ToUnicde map, but when encodeing is Identity, it should not use ToUnicode map to get GID. If encoding is Identity, No CIDTOGID map is needed. I attached a patch fixes this bug. Thanks
Great. I've committed your fix. Thanks very much.
I've come across another possible regression caused by this patch. Around GfxFont.cc:1879 there is a comment that states: // fall-through, assuming the Identity mapping -- this appears // to match Adobe's behavior This causes pdf's that use the Adobe-Japan mapping to fall-through when the mapping file from the poppler-data package is not around. Falling through, instead of erroring causes the identity mapping to be used which is obviously not correct. Do you have any pdf's that rely on the fall-through behaviour? Perhaps known mappings should cause an error and only unknown mappings fall through? i.e. Adobe-Japan causes an error even if the .cidToUnicode file is not around. What do you think?
(In reply to comment #14) > I've come across another possible regression caused by this patch. > > Around GfxFont.cc:1879 there is a comment that states: > // fall-through, assuming the Identity mapping -- this appears > // to match Adobe's behavior > > This causes pdf's that use the Adobe-Japan mapping to fall-through when the > mapping file from the poppler-data package is not around. Falling through, > instead of erroring causes the identity mapping to be used which is obviously > not correct. > > Do you have any pdf's that rely on the fall-through behaviour? Perhaps known > mappings should cause an error and only unknown mappings fall through? i.e. > Adobe-Japan causes an error even if the .cidToUnicode file is not around. > > What do you think? > This code is to get toUnicode map. toUnicode map is not mandatory. And identity mapping may be correct. When embedded font is used, neither CMap nor toUnicode map is needed. Attached A.pdf can be displayed without language pack if it falls through. So, falling through is better here.
Created attachment 13028 [details] PDF file that embedded font is used.
(In reply to comment #15) > (In reply to comment #14) > > I've come across another possible regression caused by this patch. > > > > Around GfxFont.cc:1879 there is a comment that states: > > // fall-through, assuming the Identity mapping -- this appears > > // to match Adobe's behavior > > > > This causes pdf's that use the Adobe-Japan mapping to fall-through when the > > mapping file from the poppler-data package is not around. Falling through, > > instead of erroring causes the identity mapping to be used which is obviously > > not correct. > > > > Do you have any pdf's that rely on the fall-through behaviour? Perhaps known > > mappings should cause an error and only unknown mappings fall through? i.e. > > Adobe-Japan causes an error even if the .cidToUnicode file is not around. > > > > What do you think? > > > > This code is to get toUnicode map. toUnicode map is not mandatory. > And identity mapping may be correct. > > When embedded font is used, neither CMap nor toUnicode map is needed. Sorry I missed. When embedded font and Identity mapping are used. > Attached A.pdf can be displayed without language pack if it falls through. > So, falling through is better here. >
Created attachment 13029 [details] PDF file that embedded font and Identity map are used
So i'm lost :D Is this bug fixed or not?
(In reply to comment #19) > So i'm lost :D > > Is this bug fixed or not? > Sorry for confusing you with my bad english. This bug is fixed. Commnents after #13 are not about this bug, I think. You may close this.
Closing
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.