[
https://issues.apache.org/jira/browse/PDFBOX-5143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17533504#comment-17533504
]
Andreas Lehmkühler commented on PDFBOX-5143:
--------------------------------------------
I've finally found the reason for the confusion when removing the functional
interface the first time.
Looking at the interface one might assume the purpose if {{handleSequence}} is
the same for Type1- and Type2CharStrings, but it isn't. Within a
Type1CharString {{handleSequence}} is used for the rendering of the glyph and
within Type2CharString it is used to convert the sequence of type2 commands
into a sequence of type1 commands when instantiating a Type2CharString. In the
end that converted sequence is used to render the Type2CharString.
In my first attempt I overwrote the {{handleSequence}} so that the
Type2CharString version of that method was used to convert the sequence and to
render the glyph itself so that everything was mixed up and ended in a
ConcurrentModificationException.
I've renamed the methods in question to emphasize the purpose and removed the
functional interface so that the code is mixed up again
> Refactor/Simplify CFF parsing
> -----------------------------
>
> Key: PDFBOX-5143
> URL: https://issues.apache.org/jira/browse/PDFBOX-5143
> Project: PDFBox
> Issue Type: Improvement
> Components: FontBox
> Affects Versions: 3.0.0 PDFBox
> Reporter: Andreas Lehmkühler
> Assignee: Andreas Lehmkühler
> Priority: Major
> Fix For: 3.0.0 PDFBox
>
> Attachments: evince-bug431088.pdf
>
>
> The classes used for the parsing of CFF-based fonts have some room for
> improvements w.r.t. the memory footprint, the complexity of the code and the
> test coverage.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
