prawnpdf
Fix maxp table encoding
A wrong field size wash chosen for maxPoints. This shifted the rest of the fields and rendered the table invalid.
Fixes issues with 1.6.1 releases: #73, #74
This does not resolve #72
Adobe Acrobat does not complain about invalid fonts but still doesn't render special character (e.g. ö) correctly.
@pointlessone ok, it does appear that maxPoints should be a uint16, here are the docs.
I changed it to a uint32 (i.e. pack/unpack with N) because that's what the parse method uses. Accordingly we should change to n* everywhere.
Did you see my PR that reverts my recent changes to maxp? It seems to fix all the issues people are having: https://github.com/prawnpdf/ttfunk/pull/75
Did you see my PR that reverts my recent changes to maxp? It seems to fix all the issues people are having
But does it fix the original issue that the change was made for?
@mojavelinux the original changes were part of the OTF work I did, but were really only to be "more correct" rather than solve any particular issue. As it turns out, I made some assumptions that turned out to be quite incorrect, but since they weren't causing issues (or so we thought), we decided to keep them for the time being. We need full glyph outline data in order to accurately reconstruct the maxp table, but ultimately decided the original maxp code was good enough.
Thanks for the follow-up. I guess I'm looking for the simple answer of whether ghostscript will still show the warnings if #75 is merged. I can understand either way, I just need to know. (I suppose I could just test it ;))
@mojavelinux I tested the reverted code when I was working on the Ghostscript issue and everything seemed to work.
Accordingly we should change to
n*everywhere.
@camertron The whole table should be Nn* but we encode it in chunks. I get what you're saying, I'll check the parse method.
I did see your MR. To me it feels a bit too much like admitting defeat. 😅 The changes to the table are useful. I'd like to keep them. I'll try to investigate what exactly makes Ghostscript unhappy. If I'll come empty we'll get back to your MR.
@mojavelinux #75 would probably make gs happy but first I'd like to find out what exactly makes it grumpy in the first place.
Any news on that? It would be appreciated to merge this, since it's breaking our pdfs in Edge and Adobe Acrobat DC. Thank you!
@pointlessone I wouldn't look at it as admitting defeat, since the current maxp code is wrong anyway.
@camertron OK. I'll cut a new gem some time this week. Prob on weekend. And then will take a look at the table.
Update! Version 1.6.2 fixes the problem, so everything below this may be consigned to the dustbin of history...
I've been struggling with this issue (or something adjacent to it). Moving from ttfunk-1.6.0 to ttfunk-1.6.1 made my generated files unprintable (when specifying a font file). One of the two printers in the office just ignored the print attempt, while the other spits out "PDF Error 8: PostScript Error: INVALIDFONT"
Reverted to 1.6.0, and the printers started printing again. Specified a common font ("Helvetica") instead of a TTF file, and it printed again.
I did a diff between the two libraries and the only difference was the way the Maxp table gets encoded ( .pack('n*') --> .pack('Nn*') )
For now, I'll just pin my app to 1.6.0. Let me know if there's any other info I could provide.
