I've stumbled upon the following issue several times, and it affects a
patch series I'm currently doing. Please let me ask about it here.
Suppose we've got an annotation object like
<<
/Type /Annot
/Rect [0.00 0.00 10.00 10.00]
% ... other required stuff, omitted for readability ... %
% Important: There's no /AP %
An annotation at position 0,0 with dimension 10x10 pts... There's no AP
entry, i.e. no embedded appearance. That's fine, AP is optional in ISO
32000. Poppler conforms and does its best to generate the missing
appearance at runtime.
But then poppler does something that seems buggy. In some cases it
ignores /Rect and draws the generated appearance with a new size chosen
by poppler. The new size is not written back to /Rect, nor is it
reflected in public APIs (this puzzles Okular [0]). As an example you'll
always get 24x24 pts icons for popup notes, even if /Rect says 10x10
pts.
My first question: Is ignoring /Rect for dynamically generated
appearances compliant with ISO 32000?
If not, then it's a poppler bug, and I'd prefer to fix the bug instead
of building workarounds into my patch.
If I got it right, "Algorithm: Appearance streams" from ISO 32000
describes how to do it right. We shall transform AP BBox to match with
Annot Rect. And we're almost there: Gfx::drawAnnot [1] sets up a matrix
to transform AP BBox into a rectangle given by xMin, yMin, xMax, yMax
arguments. It already works. We just have to use the original Rect
coordinates when calling Gfx::drawAnnot, instead of new ones. We might
loose aspect ratio for popplers own appearances, but that's imho better
than lying about the drawn size.
So my second question: Is calling Gfx::drawAnnot with original /Rect
coordinates a valid approach for a fix?
[0] https://bugs.kde.org/show_bug.cgi?id=388458
[1]
https://cgit.freedesktop.org/poppler/poppler/tree/poppler/Gfx.cc?h=poppler-0.63.0#n5125
_______________________________________________
poppler mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/poppler
