tttool oid-table produces fuzzy OID codes

[m7thon]

Using tttool --pixel-size 3 oid-table schatzsucheH4.yaml or seemingly more severely tttool --pixel-size 3 --code-dim 10 oid-table schatzsucheH4.yaml on my project (just as an example) produces schatzsucheH4.pdf. Opening this in Preview.app (on Mac OS) or Gimp (1200 dpi, no anti-aliasing) and zooming in (800%), I can see that the OID codes are fuzzy (unscharf). My guess is that the conversion of the codes to pdf by tttool has incurred some anti-aliasing.

Also, when printed, the recognition is noticeably worse than the codes printed (using the same print settings) from the pngs that are generated by tttool --pixel-size 3 oid-code <number>.

Would it be possible for tttool oid-table to output a png as well?

[nomeata]

My guess is that the conversion of the codes to pdf by tttool has incurred some anti-aliasing.

That'd be surprising. All tttool is doing is creating a simple bitmap image and embedding it in the PDF as it.

Can you use pdfimages or a similar tool to extract the bitmap from the PDF and see if it is also fuzzy? If not, then the problem is either the way the images are embedded in the PDF and/or the way you view them.

[m7thon]

Can you use pdfimages or a similar tool to extract the bitmap from the PDF and see if it is also fuzzy?

Yes, the embedded images are indeed ok.

If not, then the problem is either the way the images are embedded in the PDF ...

Maybe their position in the pdf does not align exactly with pixel boundaries, so when the pdf is rendered at 1200 dpi it incurs anti-aliasing?

... and/or the way you view them.

Possible. But opening in Gimp at 1200 dpi should give pixel-equivalent images, no? It doesn't.

[m7thon]

I think I understand what is going on:

Maybe their position in the pdf does not align exactly with pixel boundaries, so when the pdf is rendered at 1200 dpi it incurs anti-aliasing?

That's sort of the problem. I set all page paddings in src/OidTable.hs to zero and regenerated the oid-table pdf. Then the codes end up right next to each other. I opened in Gimp (1200 dpi, no anti-aliasing), zoomed to 400% and chose a position where four different OID codes meet:

As you can see, depending on the offset of the OID within the page, it either gets fuzzy, or not. So this must be interpolation due to the fact that the pixels of the embedded OID images don't align with the pixels of the pdf rendered at 1200 dpi.

[nomeata]

Thanks. I merged the pull request and made slight modifications to the code (mostly for better understanding on my side). Can you verify that I did not break your fix?

[m7thon]

Yes, your modifications are clear and do the same thing.

I -- once again -- played around a bit with printing, and still get strange results when printing:

• If I print the pdf from Preview.app, I get some code patches (reproducibly) that are not recognized well. This is the same even when using this alignment fix, but in this case other patches (also reproducibly) have recognition problems.
• If I print the pdf via Acrobat Reader DC (same printer driver settings), all patches are recognized well (with or without this alignment fix).
• If I convert the pdf to png via Gimp (this only works with this alignment fix at all), and then print via Preview.app, I once again get another set of patches that have poor recognition.
• Strangely, I have not encountered any problems using the png oid-table generated by my modified generate-oid-table script (printed via Preview.app).

I don't know what to make of this. I do think that aligning the oids in the pdf is a good idea, but for me this really only helps when using Gimp (eg. when converting to png). My pdf viewers both seem to be doing some magic, with Acrobat Reader doing much better than Preview.app.