[
https://issues.apache.org/jira/browse/PDFBOX-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472256#comment-16472256
]
John Hewson edited comment on PDFBOX-4220 at 5/11/18 4:56 PM:
--------------------------------------------------------------
[~tilman] Thread safety is only part of the problem, the overall problem is
actually that fonts are shared objects. In other words the following situations
cause problems: 1) reuse of a font within just one document (e.g. imagine using
Arial Unicode MS to write some Arabic with those features enabled, then turning
them off and writing some English - the subsetter now has an inconsistent view
of the font). 2) Reuse of a font between documents (e.g. if I'm writing with
the same TTF font file to two PDF files even with just one thread, fonts are
shared between them). 3) Reuse of a font across threads - this is just a more
general version of (2).
The fix will be to move the enabled/disabled feature state out of the font.
This actually works out nicely because features don't belong at the font-level
but at the text-level. One expects to have an API such as showText(string,
List<Feature>) which allows features to be changed many times while working
with a single font (an example would be the "dlig" feature which enables
discretionary stylistic ligatures to add some visual decoration, perhaps for a
title or heading).
was (Author: jahewson):
[~tilman] Thread safety is only part of the problem, the overall problem is
actually that fonts are shared objects. In other words the following situations
cause problems: 1) reuse of a font within just one document (e.g. imagine using
Arial Unicode MS to write some Arabic with those features enabled, then turning
them off and writing some English - the subsetter now has an inconsistent view
of the font). 2) Reuse of a font between documents (e.g. if I'm writing two PDF
files using just one thread, then fonts will be shared between them). 3) Reuse
of a font across threads - this is just a more general version of (2).
The fix will be to move the enabled/disabled feature state out of the font.
This actually works out nicely because features don't belong at the font-level
but at the text-level. One expects to have an API such as showText(string,
List<Feature>) which allows features to be changed many times while working
with a single font (an example would be the "dlig" feature which enables
discretionary stylistic ligatures to add some visual decoration, perhaps for a
title or heading).
> 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
