Pdf.js: PDFjs not displaying some Acrofield checkboxes

[rmhrisk]

Link to PDF file (or attach file here):
212241 (6).pdf

Configuration:

• Web browser and its version:
  Chrome

• Operating system and its version:
  OSX

• PDF.js version: Latest

• Is an extension:
  No

Steps to reproduce the problem:

1. Open the file
2. Notice the checkboxes not filled in

What is the expected behavior? (add screenshot)
Checkboxes to be filled in.

If you view this PDF in Acrobat you see:

But if you viiew it in PDFjs you see:

What went wrong? (add screenshot)
The checkboxes do not get rendered, all other field types seem to work.

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):
N/A

[rmhrisk]

I should add this seems to be related to this file in particular.

[timvandermeij]

The console displays the following:

Warning: fontRes not available
Warning: Error during font loading: Font 5CF49813725A4731BB7389F7A2FDE6CD is not available

I think the checkboxes are actually glyphs in a font that cannot be loaded.

[rmhrisk]

Thanks Tim, it's odd that adobe has the glyphs, Ill look into this then close if appropriate.

[timvandermeij]

I have inspected the file with https://brendandahl.github.io/pdf.js.utils/browser and the font is available in Trailer / Root / AcroForm / DR / Font / Helv / FontName. However, we don't parse the AcroForm entry yet, but it is tracked in #7613. Therefore this looks like a PDF.js issue as the necessary data appears to be present in the PDF file.

[YuryStrozhevsky]

So, the font used in the PDF as a font for checkboxes has name "26EBF91525C1400B96AF9B0E30E84747", not "5CF49813725A4731BB7389F7A2FDE6CD". The "5CF49813725A4731BB7389F7A2FDE6CD" used for text fields only.

I think here PDF.js has a problem with reading "/Font" property for appearance object dictionary:

92 0 obj
<</FontFamily (Verdana) /Name /26EBF91525C1400B96AF9B0E30E84747 /BaseFont /ZapfDingbats /Subtype /Type1 /Type /Font>>
endobj

99 0 obj
<</Length 84 /BBox [0 0 11 12] /FormType 1 /Matrix [1 0 0 1 0 0] /Subtype /Form /Type /XObject /Resources <</ProcSet [/PDF] /Font <</26EBF91525C1400B96AF9B0E30E84747 92 0 R>>>>>>
stream
BT
/26EBF91525C1400B96AF9B0E30E84747 8.74 Tf
2.853 1.7846626231993854 Td
(4) Tj
ET
Q
endstream

[rmhrisk]

Yes, I think @YuryStrozhevsky is right, I noticed the font is being rendered:

It just does not have the color.

[rmhrisk]

@timvandermeij don't mean to be a bother but can you confirm you see this as an issue? in this case @YuryStrozhevsky makes this file so we can probably find a way to work around pdfjs but it does not seem like the right solution.

[timvandermeij]

This definitely looks like an issue on the PDF.js side, yes. I tried loading the fonts from the AcroForms dictionary locally a few days ago, but it didn't resolve any of the open issues regarding this. I'm not too familiar with the font conversion code myself, so I must have made some kind of error there. Maybe someone with more font knowledge can find out what's going wrong here.

[rmhrisk]

@timvandermeij is there someone on the PDFjs team we might be able to tag for insights here?

[timvandermeij]

I did more debugging for this and managed to trace the problem to src/display/canvas.js. The problem is that a setFillRGBColor(255, 255, 255) operation is done, but not reset when the annotations are drawn. This makes the checkmarks appear white instead of black, but they are in the correct position. When I manually add this.setFillRGBColor(0, 0, 0) in CanvasGraphics_beginAnnotation, the checkmarks are displayed correctly.

I'm not sure why this happens though. For each annotation, we do a save/restore of the state. However, in the stepper these saves/restores are not always shown. Moreover, when saving/restoring we copy the previous state (also the one on this.ctx), so if the color is set to white and not reset anywhere else, it remains white. So, in short, I suspect that save/restore does not work properly here, but I'm missing the final piece of the puzzle to solve it. Either another operation is not saving/restoring the state properly, or saving/restoring does not take the fill color into account properly.

Maybe @yurydelendik or @Snuffleupagus know more about this, but at least the problem is traced to the drawing state not being correctly (re)set. The font and the positions of the checkmarks are fine.

[yurydelendik]

@timvandermeij, I guess we need to reset state somehow. At the https://github.com/mozilla/pdf.js/blob/4e3e97be8eafede8637eff749282af609661b88f/src/core/document.js#L236 we just place annotation operator list in the same queue. I would say beginAnnotation will be best place to reset state. It can be done by checking all properties and their default value. Alternative will be to add e.g. beginContent/endContent commands for main content and perform save/restore there.

[timvandermeij]

Good point. I did try to reset the state there, but it wasn't successful. Moreover, I think we already try to do it with https://github.com/mozilla/pdf.js/blob/master/src/display/canvas.js#L1920, but also no success there. Therefore, I'm wondering how to actually reset the state, because as far as I can see it's already being done. However, the state change only seems to be effective when OPS.setFillRGBColor is actually called so that the previous values are overwritten, i.e., just creating a new canvas state and using save/restore does not seem to do the trick for some reason.

[Snuffleupagus]

I've (quickly) looked into this issue, and I can't help thinking that there are two separate issues at play here:

• First of all, it seems to me that we might need to treat every annotation separately, and thus reset the state before each one rather than just once before all of them.
• Second of all, creating a new CanvasExtraState will not reset the canvas ctx itself, which ought to explain the problem with the incorrect colours as described earlier in the thread. Hence, in-line with the separate handling the annotations, we need to also reset the canvas context explicitly.

Provided that the above makes sense, the most "correct" solution might be to simply render every annotation on a temporary canvas which is then placed (using ctx.putImageData) onto the main one.
However, that seems like a larger re-factoring effort, so I've tried to implement a workaround where all of the state is reset for each annotation; please see the following WIP https://github.com/mozilla/pdf.js/compare/master...Snuffleupagus:issue-8047.

[timvandermeij]

If the patch above does resolve the issue, then I'm fine with this solution as it's kept minimal.

@yurydelendik Is this also what you had in mind?

[rmhrisk]

@Snuffleupagus and @timvandermeij thank you both for working on this one!

[rmhrisk]

@yurydelendik is this what you had in mind?

[rmhrisk]

@yurydelendik what is the next step on this item?

[rmhrisk]

@yurydelendik Is this an OK solution?

[timvandermeij]

The pull request above fixes this issue and is in review now.

[rmhrisk]

Thanks 👍