Hello again Andreas,

I've completed my patch with a proposed fix for the problem described in my
bug report.  The patch is in a PR that I linked to
https://issues.apache.org/jira/browse/PDFBOX-5191

I think we probably need to have a short discussion about dependencies and
test coverage before that can merge.  I left notes and tried to explain
myself in threads on that Jira ticket and in comments on the github PR.

Thanks and Regards,
Larry Lynn



On Wed, May 12, 2021 at 10:17 AM Larry Lynn <[email protected]> wrote:

> Hi Andreas.
>
> I created a Jira ticket for this bug report, as you requested.  It is
> https://issues.apache.org/jira/browse/PDFBOX-5191.
> I am working on a patch to fix this bug now.
>
> Thanks and Regards,
> Larry Lynn
>
> On Tue, May 11, 2021 at 12:13 AM Andreas Lehmkuehler <[email protected]>
> wrote:
>
>> Hi,
>>
>>
>> thanks for your detailed report, it sounds valid and is very helpful!!
>>
>> Please create a JIRA ticket and attach a patch to it. If you prefer a PR
>> we are
>> able to handle that as well (add the URL of the PR to the JIRA ticket)
>>
>> Andreas
>>
>>
>> Am 10.05.21 um 22:41 schrieb Larry Lynn:
>> > Greetings pdfbox devs.  Longtime user, first time contributor here.
>> >
>> > First, I'd like to thank you all for your work on this awesome piece of
>> > software.  pdfbox is one of the powertools in our toolbox.
>> >
>> > Second, I'd like to lodge a bug report.  As per your support policy
>> posted
>> > here:
>> > https://pdfbox.apache.org/support.html
>> > I'm contacting the mailing list first before going straight to Jira.
>> >
>> > I think there's a bug in isEmbeddingPermitted() that makes it too
>> > restrictive about which fonts it will embed.
>> >
>> > The code is here:
>> >
>> https://github.com/apache/pdfbox/blob/trunk/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/TrueTypeEmbedder.java#L139
>> >
>> > I believe the bug was introduced with this change
>> >
>> https://svn.apache.org/viewvc/pdfbox/branches/2.0/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/TrueTypeEmbedder.java?r1=1878861&r2=1878860&pathrev=1878861
>> >
>> > For this ticket:
>> > https://issues.apache.org/jira/browse/PDFBOX-4882
>> >
>> > So, it looks like there was an earlier bug in isEmbeddingPermitted()
>> that
>> > made it too permissive.  But I think that in fixing that one, a 2nd bug
>> was
>> > introduced that makes it too strict.  The reason that I think there is a
>> > bug here is because there is no check in that code for
>> > ttf.getOS2Windows().getVersion().
>> >
>> > In the documentation linked on PDFBOX-4882,
>> > https://docs.microsoft.com/en-us/typography/opentype/spec/os2#fstype
>> > Please note the section on Version Differences
>> >
>> > "The specification for versions 0 to 2 did not specify that bits 0 to 3
>> > must be mutually exclusive. Rather, those specifications stated that, 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*."
>> >
>> > We have a font named ArialRoundedMTBold.ttf.  pdfbox versions 2.0.20 and
>> > lower would embed this without complaint, but pdfbox version 2.0.21 and
>> > higher throw an error when attempting to embed this font "This font does
>> > not permit embedding".
>> >
>> > We opened this font up in FontForge and verified that its OS/2 table is
>> > version 1.  We stepped through this code in a debugger and found that
>> > fsType is set to 6, so 2 permission bits are set, one for
>> FSTYPE_RESTRICTED
>> > & one for FSTYPE_PREVIEW_AND_PRINT. This is a legal configuration for a
>> > version 1 font, but not a version 3 font.  The code in
>> > isEmbeddingPermitted() is respecting the most restrictive permission
>> bit,
>> > which contradicts the spec.  It should be respecting the least
>> restrictive
>> > permission bit.
>> >
>> > I think the code as-is is correct for version 3 fonts and above
>> (presuming
>> > there is no font corruption on the permission bits), but is too
>> restrictive
>> > on font versions 0 - 2.
>> >
>> > I can provide code that reproduces the problem.  If you accept pull
>> > requests from external developers, I believe that I've looked at this
>> code
>> > long enough that I can provide a bugfix too.
>> >
>> > Thanks and Regards
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
> --
> *Larry Lynn*
> *Senior Software Engineer*
> *Workiva Inc*.
>
>
>
> *448 E. Main St, Bozeman, MT, 59715*
>


-- 
*Larry Lynn*
*Senior Software Engineer*
*Workiva Inc*.



*448 E. Main St, Bozeman, MT, 59715*

Reply via email to