[
https://issues.apache.org/jira/browse/PDFBOX-5713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17786649#comment-17786649
]
Jaromír Dobrý edited comment on PDFBOX-5713 at 11/16/23 7:59 AM:
-----------------------------------------------------------------
Yes, my file is one of those weird things, unfortunately I haven't made it
myself.
If you want to support the specification fully, you should also support some
weirder things like wrapping a whole PFA file in a single ASCII segment (see
[^pfa_wrapped.pfb]). Collecting the ascii and binary segments separately
doesn't solve the problem because PFB specification doesn't care about what is
a text part of the font file and what is the encrypted part. Maybe you can
imagine even weirder things but I don't think that it is required for now...
Moreover if you collect ascii and binary segments separately without taking
care of their order, PfbParser may sometimes pass without any exception and
return an incorrect result for this font (Type1Parser expects the text part to
be segment1 and encrypted part to be segment2). I think this is much worse than
just saying that you do not support these kind of fonts.
This is the reason why I am suggesting only slight improvement of the
constraints on the input of PfbParser. Trying to support everything may be
impractically difficult and I don't think that there is an actual font that
will need it.
was (Author: JIRAUSER283200):
Yes, my file is one of those weird things, unfortunately I haven't made it
myself.
If you want to support the specification fully, you should also support some
werider things like wrapping a whole PFA file in a single ASCII segment (see
[^pfa_wrapped.pfb]). Collecting the ascii and binary segments separately
doesn't solve the problem because PFB specification doesn't care about what is
a text part of the font file and what is the encrypted part. Maybe you can
imagine even weirder things but I don't think that it is required for now...
Moreover if you collect ascii and binary segments separately without taking
care of their order, PfbParser may sometimes pass without any exception and
return an incorrect result for this font (Type1Parser expects the text part to
be segment1 and encrypted part to be segment2). I think this is much worse than
just saying that you do not support these kind of fonts.
This is the reason why I am suggesting only slight improvement of the
constraints on the input of PfbParser. Trying to support everything may be
impractically difficult and I don't think that there is an actual font that
will need it.
> PfbParser fails to parse PFB font with multiple binary records.
> ---------------------------------------------------------------
>
> Key: PDFBOX-5713
> URL: https://issues.apache.org/jira/browse/PDFBOX-5713
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox
> Affects Versions: 3.0.0 PDFBox
> Reporter: Jaromír Dobrý
> Priority: Major
> Attachments: 5040.Download_Fonts.pdf, DejaVuSerifCondensed.pfb,
> PDFBOX-5713.diff, PDFBOX-5713_minimal.diff, pfa_wrapped.pfb,
> type1_embedded.pdf
>
>
> * The attached PFB font can be opened in FontForge but PfbParser in fontbox
> fails to read it.
> * The problem is that fontbox assumes there are three records (ascii,
> binary, ascii) in the PFB file but the binary part is split into multiple
> shorter chunks (i.e. ascii, binary, ..., binary, ascii).
> * I didn't find that this is forbidden and according to FontForge behavior
> it seems to be valid.
> * The fix seems to be easy, it is probably sufficient to concatenate the
> binary records together in PfbParser and the result will work correctly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
