Created attachment 94958 [details] Test PDF When using Arial font, GfxFont.ascent becomes equal 0.718, but it needs to be equal to 0.905. The problem occurs in GfxFont.cc, near this comment: // for non-embedded fonts, don't trust the ascent/descent/bbox // values from the font descriptor Because of this block, Arial's GfxFont.ascent becomes equal to Helvetica's ascent, which is wrong. Test PDF is attached.
This bug is related to LibreOffice Bug 40513
Created attachment 94963 [details] Test PDF #2 Attaching test for different fonts
I don't know what i'm supposed to see in the pdf.
(In reply to comment #3) > I don't know what i'm supposed to see in the pdf. I don't know how many software are affected by this problem. But LibreOffice do. Here is instruction to how track this bug with LibreOffice: 1. Open PDF with LibreOffice Draw. You will see that underlines are crossing the text. If you will not see, this means that my patch was commited. No need to worry - bug is still there. 2. This happens because text is rendered slightly below it's actual position. Navigate to \sdext\source\pdfimport\xpdfwrapper\pdfioutdev_gpl.cxx, function PDFOutDev::drawChar(). There you can find function call 'state->textTransformDelta(0.0, state->getFont()->getAscent(), &x2, &y2 ); This is transition from LibreOffice code to poppler code. And here getAscent() returns incorrect value. 3. Incorrect value assigned here: \poppler\GfxFont.cc, precisely in this lines: 'if (builtinFont && embFontID.num < 0) { ascent = 0.001 * builtinFont->ascent; ...'. "Arial" font's property ascent gets value from "Helvetica"'s builtinFont->ascent, which is incorrect (0.905 needed, 0.718 - what we get) Switched state back to NEW. Switch back again if needed.
Created attachment 95004 [details] Screenshot of LibreOffice+Poppler problem Here is the screenshot of problem.
I don't know, both okular and evince render the PDF file, unless you can convince me it's a poppler bug I'd say it's a libreoffice bug,
Created attachment 95073 [details] PDFtoHTML underline bug (In reply to comment #6) > I don't know, both okular and evince render the PDF file, unless you can > convince me it's a poppler bug I'd say it's a libreoffice bug, PDFtoHTML have the same problem with underlines: Run pdftohtml.exe -c underlined2.pdf underlined2-1.html Attaching screenshot of result. Is that enough?
Unconvinded, pdftohtml code is pretty bad to be honest. If you can code a patch I'll reg-test it, otherwise let's hope someone else from the team is interested in this :)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/51.
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.