[
https://issues.apache.org/jira/browse/PDFBOX-3725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15934934#comment-15934934
]
Wolfgang Hamann commented on PDFBOX-3725:
-----------------------------------------
Hi, I recall having a "nice" time creating that software, about 20 years ago...
The T1 spec seems to written with the assumption that a font will be processed
by an actual interpreter, and that parts of the file may be read by a simple
parser, to extract info about the font. It specifically mentions
some restrictions to interoperate with good ol' Type Manager.
Consequently there are many ways to produce valid font code. Looking over
pdfbox, it obviously tries to handle the Adobe style but also handles a few
other styles that developers have encountered. Does it handle them right?
Readine Type1parser from the top, it expects
COUNT dict
followed by an optional dup (which would push the new fontdict on the stack)
and looks for values until it sees the
currentdict end
sequence, which also pushes the new fontdict. It is likely that a font with the
"dup" near the top would not use the "currentdict" and thus run into an
exception. Now, if the font designer were adding both codes but not
compensating with an extra pop, the code would be incorrect PS - it might work
in a PDF-only viewer but not in ghostscript. Should a validator accept a font
that leaves trash on the stack?
I dont think there is anywhere in T1 or PDF specs mandating the use of
/NAME COUNT dict dup begin ..... end def
instead of
/NAME COUNT dict def NAME begin ... end
This affects the Private dict and its contents as well. So, should a validator
accept or refuse the pattern?
I have had a look at various old fonts today, and found a few more variations
that I would consider valid (even some that defien RD and friends within
userdict - a set of fonts donated b ghostscript by Bitstream)
I cound not find any fonts declaring the BBox array besides mine ... I believe
it was documented in an earlier version of the Type1 spec but its withdrawal
not mentioned in the changes list.
Best regards
> Problem with Type1 font parser
> ------------------------------
>
> Key: PDFBOX-3725
> URL: https://issues.apache.org/jira/browse/PDFBOX-3725
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox
> Affects Versions: 2.0.5
> Environment: linux
> Reporter: Wolfgang Hamann
> Priority: Minor
> Attachments: ft70.ps, kcap.pdf
>
>
> the parser uses "readSimpleDict" to parse the Metrics.
> This allows
> /Metrics 100 dict dup begin ....... end def
> but not
> /Metrics 100 dict def Metrics begin ..... end
> This variant seems to work in most other pdf tools, however
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
