[
https://issues.apache.org/jira/browse/PDFBOX-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472260#comment-16472260
]
John Hewson commented on PDFBOX-4220:
-------------------------------------
Comment from PDFBOX-4106:
{quote}
amake Aaron Madlon-Kay added a comment - Yesterday
Hi John. Thanks for raising these concerns, and sorry for having gotten us into
this mess.
I am fine with any API changes deemed necessary. As for functionality, the only
non-obvious thing that I want to mention is that it's important to be able to
selectively enable/disable vrt2. The reason is that the substitutions performed
by vrt2 are not always more desirable than vert, and it is common to want to
use only vert substitutions with a font that supports both.
{quote}
> FontBox sets GSUB features globally across shared fonts
> -------------------------------------------------------
>
> Key: PDFBOX-4220
> URL: https://issues.apache.org/jira/browse/PDFBOX-4220
> Project: PDFBox
> Issue Type: Bug
> Components: FontBox, Parsing, Writing
> Affects Versions: 2.0.9, 3.0.0 PDFBox
> Reporter: John Hewson
> Assignee: John Hewson
> Priority: Major
>
> Migrating the following issue from PDFBOX-4106:
> {quote}
> (!) So we have a problem. While looking at building a proper ToUnicodeMap for
> PDFBOX-4189 I've encountered some significant issues related to this feature.
> Given that this was shipped in 2.0.9, we're likely going to face some hard
> choices.
> Most of the handling of vertical text in this patch is fine. It generally
> does a good job of handling the intricacies of both PDF and OpenType and
> juggling the sometimes competing concerns.
> The issue is that the new APIs added to FontBox's TrueTypeFont are
> incompatible with PDFBox's multi-threading. Unlike most of PDFBox, fonts in
> FontBox must be thread safe - they are cached and shared globally between all
> PDDocument instances. For this reason a FontBoxFont must not contain any
> document-specific state.
> The following fields added to TrueTypeFont contain document-specific state:
> {{List<String> enabledGsubFeatures}}
> The following methods added to TrueTypeFont write document-specific state:
> {{enableVerticalSubstitutions()}}
> {{enableGsubFeature(String)}}
> {{disableGsubFeature(String)}}
> The following methods added to TrueTypeFont read document-specific state:
> {{getUnicodeCmapLookup()}}
> {{getUnicodeCmapLookup(boolean)}}
> None of the additions are thread safe, anyone who calls these methods will
> clobber the corresponding state for all other threads. This problem can even
> occur if the user is manipulating more than one document within a single
> thread. *There's no way around this and no way to fix these methods* -
> document-specific state can't live in shared global fonts :(
> (flag) Tough choices: Given that these are all just auxiliary methods limited
> to just FontBox's TrueTypeFont class, we _could_ remove them. These are very
> obscure methods which have only been around for a few weeks. It's unlikely
> that _any_ users would be affected by their removal. Obviously the missing
> functionality will be implemented in the appropriate location*, so vertical
> text will still work in 2.0 and the existing PDType0Font.loadVertical API -
> which is the only thing that matters - will remain unchanged! :)
> Yes, I'm suggesting a *very obscure* breaking API change to 2.0 but as it
> stands we have just shipped a breaking functionality change to 2.0 and broken
> existing functionality in an irreparable manner, and that seems worse.
> Thoughts?
> \* And I have some ideas how to achieve this and am happy to do it
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
