[poppler] PDF compliance, regarding Annot /Rect

[Tobias Deiminger]

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