pdfbox-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Hewson (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (PDFBOX-4220) FontBox sets GSUB features globally across shared fonts
Date Fri, 11 May 2018 16:52:00 GMT

    [ 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-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org


Mime
View raw message