Some text in PDFs cut off at the top about atril HOT 8 CLOSED

I don't know much of anything about this but:

• the same issue happens with Evince (pretty much expected, as Atril is a fork)
• does not happen with xpdf, so it doesn't seem to be merely a Poppler issue as I believe it uses poppler as well (albeit likely with another rendering backend)
• GS works fine (pdf2ps, ImageMagickl's display, etc.)

More interestingly: try opening it in Inkscape choosing the Poppler import. You'll see the same clipping issue, but you'll also be able to see that the G clef shape is inside a clip area. If you extract the clef from the clip, it renders fine.

Steps in Inkscape:

• inskcape dd.pdf
• In Import settings select Poppler/Cairo import
• Zoom in and click then double-click on the first staff's clef 2 times (once to open the main group, second to open the clef's)
• Open the Layers and Objects tool panel, and scroll down to the selection (it's g2217 here, but might not be entirely stable)
• You see that use2215 is inside g2217, which itself is inside the clipping group g2219. If you look at the bounding boxes for those, you'll notice that g2219 is smaller than g2217, hence cutting the top off.
• Right click on g2217 and select Pop selection out of group: 🎉 no more clipping.

So… I have no idea what is the root cause, is it the PDF actually generated with incorrect clipping (and only some rendering libraries honor it properly), or is Poppler/Cairo miscalculating the clip area? Or does the font have incorrect extents or clipping or something that Poppler/Cairo try to enforce while some other just let it "bleed out"?
I guess you'll have to figure this part out 🙂

HTH

from atril.

Thanks, this helps a lot!

Seeing at whether this is clipped somehow was the reason I used qpdf to look at it in QDF form, but my PDF-fu is not good enough to detect it there. I hadn’t seen that Inkscape also shows the clipping.

And indeed. Right-click, “Release Clip”, and painting the clip red shows:

Or does the font have incorrect extents or clipping or something

Definitely not, after looking at it in exhaustive detail in FontForge, the FontForge SFD file format and a ttx dump of the TTF.

This confirms my rough guess that Mu͒seScore and/or Qt5 have a bug somewhere there that clips the texts drawn. Now I’ll “just” have to find that… (to both fix that and, maybe, find a way to hack the fonts to work around it, for older versions) wish me luck ;-)

Now at least I have a tool with which I can inspect and measure the clipping.

I’m closing the issue here, as we good as confirmed that the bug is exclusively in the PDF producer.

from atril.

This confirms my rough guess that Mu͒seScore and/or Qt5 have a bug somewhere there that clips the texts drawn. Now I’ll “just” have to find that… (to both fix that and, maybe, find a way to hack the fonts to work around it, for older versions) wish me luck ;-)

"just" indeed 🙂 Good luck 😉

I’m closing the issue here, as we good as confirmed that the bug is exclusively in the PDF producer.

This, or the PDF renderer is another possible option (albeit less likely I'd think). At least the fact that not all renderers give the same result suggests the clipping it either not handled by some, or mishandled my others.

from atril.

It’s a Qt bug.

I reported it to the Debian packagers as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070406 because I don’t have the means to deal with Qt upstream and hope they’ll forward it.

from atril.

I could actually use some PDF-side debugging help with this tiny reproducer PDF from the C++ MWE in that article.

The entire page content (expanded by qpdf) is:

stream
/GSa gs /CSp cs /CSp CS
0.059999999 0 0 -0.059999999 10.0199999 831.980000 cm
q q
Q
Q q
q
q
1 0 0 1 0 0 cm
/CSp cs 0 0 0 scn
/GSa gs
BT
/F7 1200 Tf 1 0 0 -1 0 0 Tm
100 -1000 Td <0001> Tj
600 0 Td <0002> Tj
600 0 Td <0003> Tj
600 0 Td <0004> Tj
600 0 Td <0005> Tj
600 0 Td <0006> Tj
600 0 Td <0007> Tj
600 0 Td <0008> Tj
600 0 Td <0004> Tj
600 0 Td <0009> Tj
600 0 Td <000a> Tj
600 0 Td <000b> Tj
ET
Q
Q Q
endstream

Where in that is the clipping?

I have now found that this is generated by src/gui/painting/qpdf.cpp in Qt5, in the QPdfEnginePrivate::drawTextItem method, which basically spits out PDF magic directly:

    *currentPage << "BT\n"
                 << "/F" << font->object_id << size << "Tf "
                 << stretch << (synthesized & QFontEngine::SynthesizedItalic
                                ? "0 .3 -1 0 0 Tm\n"
                                : "0 0 -1 0 0 Tm\n");
[…]
        *currentPage << x - last_x << last_y - y << "Td <"
                     << QPdf::toHex((ushort)g, buf) << "> Tj\n";
[…]

I don’t know the PDF format well enough to proceed from here without burning another couple of days. (I do know the general command format, the subsetting and the addressing of its glyphs by number, <0004> is space here for example, and 600 is probably the advance width, it’s a monospaced font.)

from atril.

OK, now this is interesting:

15 0 obj
<<
  /Ascent 835
  /CapHeight 835
  /Descent -177
  /Flags 4
  /FontBBox [
    0
    -177
    509
    835
  ]
  /FontFile2 16 0 R
  /FontName /QMAAAA+Inconsolatazi4varl_qu-Regular
  /ItalicAngle 0
  /StemV 50
  /Type /FontDescriptor
>>
endobj

Opening object 16 (the embedded subset font) in FontForge, I get totally different metrics than the original font!

The entire font has been scaled from 1000 ppem (PostScript and OTF/CFF default) to 2048 ppem (suitable for TrueType/t42), which, while questionable (we’re outputting to PDF, which is PostScript on drugs, after all) not incompetently done, but the OS/2 metrics have not been scaled, and the /FontBBox also bases on the metrics of the orginal font file.

And the cutoff I’m seeing is roughly at the height of 1000 (or 1024?) above the baseline.

from atril.

According to https://bugreports.qt.io/browse/QTBUG-586 Qt “cannot” embed OTF/CFF fonts. It apparently does so, but not correctly.

The (missing half the metrics) scaling to 2048 is done for TTF fonts as well, though.

And when I quickly scale the TTF version of the font to 2048, it works in Atril.

sigh…

But okay, so I don’t think there’s a bug on the viewer side, just an inconsistency in the face of bad input (GIGO).

from atril.

And to finish the Atril part of the discovery, it’s the entry in the hhea table that Atril uses.

from atril.