[Poppler-bugs] [Bug 107303] "8" shown instead of "x" inside checkbox when converting LibreOffice-generated form to PostScript

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107303

--- Comment #7 from Tobias Deiminger <haxtibal at posteo.de> ---
(In reply to Michael Weghorn from comment #6)
> > Your patch ensures this, if I got it right, and therefore it's a good patch:)
> 
> It doesn't really. E.g. for the example document, the font resource is no
> longer replaced with the fake one. It was before (i.e. without the patch),
> but the font resource was not found. Now, the original font resource with
> the "ZaDi" tag is used -- but if I understand you correctly, this might not
> be desirable if Poppler relies on the "ZaDb" being used at other places for
> the 'forceZapfDingbats' case...

Was on the wrong track too (I messed up with the return value of
GooString::cmp). Now I think the original code without patch is fine already,
at least wrt my above assertions.

I've just learned new things about poppler. When printing into PDF, poppler
obviously removes widget annotations, and replaces them with simple Content
items. Guess this is required because PostScript doesn't support annotations?
Anyway, AnnotAppearanceBuilder is then no longer responsible for displaying the
"8" in the printout.

The original simple_form_CHECKBOX_TICKED_CLEANED.pdf contains a widget
annotation, representing the check button:

3 0 obj
<<
  /Type /Annot
  /Subtype /Widget

  /DR <<
    /Font <<
      /ZaDi 4 0 R
    >>
  >>
  /DA (0.13725 0.14901 0.15294 rg /ZaDi 0 Tf)
  /MK <<
    /CA (8)
  >>
>>
endobj

Notably, /CA is string "8" ("the widget annotation's normal caption which shall
be displayed when it is not interacting with the user").

Now, when printed, the Widget object is gone. My decompressed printout.pdf
instead contains this:

5 0 obj
<< /Contents 6 0 R ... >>
6 0 obj
<< /Length 376 >>
stream
/R8 10.9815 Tf
[(8)-77]TJ
... % shortened
ET
10 0 obj
<< /BaseFont /DZBPUO+F1348788328_100000 /Encoding /WinAnsiEncoding /FirstChar
56 /FontDescriptor 11 0 R /LastChar 56 /Subtype /Type1 /Type /Font /Widths [
600 ] >>
11 0 obj
<< /Ascent 616 /AvgWidth 600 /CapHeight 616 /CharSet (/eight) /Descent -15
/Flags 65569 /FontBBox [ 0 -15 493 616 ] /FontFile3 12 0 R /FontName
/DZBPUO+F1348788328_100000 /ItalicAngle 0 /MaxWidth 600 /MissingWidth 600
/StemV 73 /Type /FontDescriptor >>
endobj
12 0 obj
<< /Subtype /Type1C /Length 396 >>
... % embedded font here

Here, the TJ ("show text") operator writes string "8". The "8" got copied from
MK CA of the very original document simple_form.pdf. Tf selects font /R8. R8
maps to Font Dictionary obj 10 0.  This is an embedded font that has only one
character 56 defined. 56 is ASCII for "8".

So the "8" sign appears on screen/printout, and that's exactly what the PDF
wants to happen. I'm not sure who we should accuse then. Maybe the software
that originally wrote "8" into /CA? Does this longish post make sense at all?

> Should I rather have a look why the "ZaDb" one is not found (like indicated
> by the pdftops output: "Syntax Error: Unknown font tag 'ZaDb'")?

I believe the Syntax Error is unrelated to the problem. But would be
interesting where it originates anyway.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/poppler-bugs/attachments/20180730/a150491b/attachment.html>