[
https://issues.apache.org/jira/browse/PDFBOX-5191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17344140#comment-17344140
]
Larry Lynn edited comment on PDFBOX-5191 at 5/13/21, 9:26 PM:
--------------------------------------------------------------
Hi Tillman,
Thank you very much for your swift response, and for looking at my proposed
code change.
I think that our 2 ttf files (ArialNarrow-Italic.ttf & ARLRDBD.ttf) are
different at the binary level, even if they show the same glyphs visually.
I checked for a copy of ARLRDBD.ttf on my local machine. I could not find one.
I did find a font with the same filename here:
[https://freefontsdownload.net/free-arial-rounded-mt-bold-font-36927.htm]
I downloaded ARLRDBD.ttf from that URL and ran it through a modified version of
testPDFBox3747(). I was able to reproduce "This font does not permit
embedding" exception using the font from that download URL. I re-ran the test
in a debugger to see whether the code was correct to throw an exception.
Please see attached screenshot.
For this 3rd version of the font, the OS2 table is version 1. fsType is 14, so
the permission bits are set to 1110. This seems like a weird configuration,
but it's legal for a version 1 table, and since other, lenient permission bits
are set, we should be able to embed this font.
For the copy of ArialNarrow-Italic.ttf that we're using, fsType is 6, so the
permission bits are set to 0110. The permissions are 1 bit off, but the
failure mode is the same.
was (Author: larry.l...@workiva.com):
Hi Tillman,
Thank you very much for your swift response, and for looking at my proposed
code change.
I think that our 2 ttf files (ArialNarrow-Italic.ttf & ARLRDBD.ttf) are
different at the binary level, even if they show the same glyphs visually.
I checked for a copy of ARLRDBD.ttf on my local machine. I could not find one.
I did find a font with the same filename here:
[https://freefontsdownload.net/free-arial-rounded-mt-bold-font-36927.htm]
I downloaded ARLRDBD.ttf from that URL and ran it through a modified version of
testPDFBox3747(). I was able to reproduce "This font does not permit
embedding" exception using the font from that download URL. I re-ran the test
in a debugger to see whether the code was correct to throw an exception.
Please see attached screenshot.
For this 3rd version of the font, the OS2 table is version 1. fsType is 14, so
the permission bits are set to 1110. This seems like a weird configuration,
but it's legal for a version 1 table, and since other, lenient permission bits
are set, we should be able to embed this font.
> isEmbeddingPermitted() is too restrictive on TTFs with OS2 table versions 0-2
> -----------------------------------------------------------------------------
>
> Key: PDFBOX-5191
> URL: https://issues.apache.org/jira/browse/PDFBOX-5191
> Project: PDFBox
> Issue Type: Bug
> Components: PDModel
> Affects Versions: 2.0.21, 3.0.0 PDFBox
> Reporter: Larry Lynn
> Priority: Major
> Attachments: 2021-05-13_15-20-29.png
>
>
> PDFBOX-4882 fixed a bug that made isEmbeddingPermitted() too permissive. But
> it introduced a bug that made isEmbeddingPermitted() too restrictive for TTFs
> with OS2 table versions 0-2.
>
> TTFs with OS2 table versions 0-2 can have multiple permission bits set.
> According to the spec described in
> [https://docs.microsoft.com/en-us/typography/opentype/spec/os2#fstype]
> "in the event that more than one of bits 0 to 3 are set in a given font, then
> the _least-restrictive permission indicated take precedence_."
> Unfortunately, the current code essentially makes the most restrictive
> permission take precedence. This causes pdfbox to throw an error:
> "This font does not permit embedding"
> when attempting to process fonts that worked fine in pdfbox v2.0.20 and lower
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
