Bug 41104 - Xpdf(pdfedit/poppler) renders specidic pdfs differently than e.g., Acrobat/Sumatra
Summary: Xpdf(pdfedit/poppler) renders specidic pdfs differently than e.g., Acrobat/Su...
Status: RESOLVED NOTABUG
Alias: None
Product: poppler
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium major
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-21 23:00 UTC by misutkajunior
Modified: 2016-03-20 16:26 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
test file (329.54 KB, application/octet-stream)
2011-09-21 23:00 UTC, misutkajunior
Details
viewers/editors comparison (195.60 KB, image/png)
2011-09-22 03:34 UTC, misutkajunior
Details

Description misutkajunior 2011-09-21 23:00:30 UTC
Created attachment 51504 [details]
test file

Copy of 
http://pdfedit.petricek.net/bt/view.php?id=372

GfxFont.cc

int GfxCIDFont::getNextChar(
...

  *code = (CharCode)(cid = cMap->getCID(s, len, &n));
  if (ctu) {
    ...
  } else {
    *uLen = 0;
  }

if i am not mistaken, if ctu == NULL it means identity, so it should be 
  } else {
    u[0] = *code;
    *uLen = 1;
  }

at least this is the acrobat/sumatra behaviour.

Steps to reproduce:
open attached file in pdfedit/xpdf/okular/kpdf vs sumatra/acrobat
compare the first letter
Comment 1 Albert Astals Cid 2011-09-22 03:19:34 UTC
My Acrobat in Linux complains the pdf is malformed and renders two small balls for the first character. Can you attach a rendering of what you get?
Comment 2 misutkajunior 2011-09-22 03:34:52 UTC
Created attachment 51508 [details]
viewers/editors comparison
Comment 3 Thomas Freitag 2016-03-18 16:54:38 UTC
You are not true: the problem is NOT a charcode and/or map-to-unicode problem, the problem is that the fonts are not embedded in this font! 
Therefore poppler ask fontconfig to find a suitable font for in this case ArialMT and gets one where 'ě' has no glyph, so the replacement char is rendered.
'ě' is only in the unicode version for Arial, which is used (and delivered!!) by Acrobat, therefore You can render it correctly on windows platforms also with poppler, but not on unix platforms.

Poppler doesn't deliver any fonts because poppler has no rights on fonts!
Comment 4 Jason Crain 2016-03-20 16:26:14 UTC
I do not consider this a poppler bug either because this PDF does not embed fonts and it looks up glyphs by the glyph ID, which is a bad idea because glyph IDs are only meaningful for one specific font.  The PDF spec even has a line forbidding this behavior.

As a workaround, you can install Microsoft's Arial font.  You might also need to add something like this to your ~/.fonts.conf to make sure that ArialMT (the font referenced in the PDF) gets matched to Arial:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<match target="pattern">
    <test name="family">
	<string>ArialMT</string>
    </test>
    <edit name="family" mode="prepend">
	<string>Arial</string>
    </edit>
</match>
</fontconfig>


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.