[ 
https://issues.apache.org/jira/browse/PDFBOX-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16472260#comment-16472260
 ] 

John Hewson edited comment on PDFBOX-4220 at 5/11/18 4:51 PM:
--------------------------------------------------------------

Comment from PDFBOX-4106:

{quote}
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}


was (Author: jahewson):
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

Reply via email to