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

Aaron Madlon-Kay commented on PDFBOX-4106:
------------------------------------------

[~tilman] Thanks for the comments.

{quote}I looked at the first patch; are you aware that UnicodeScript is a JDK7 
class? This would mean your improvement can't be used in PDFBox 2.*, only in 3. 
That one has no planned release date, it could be several months or several 
years.{quote}

I was aware of everything but the timeline for version 3. I have prepared an 
alternative implementation that can run on Java 6. Should I simply replace my 
patches?

{quote}I see you made an effort in patch 5 to make it non-breaking, but I 
suspect that in patch 4 the use of the new CmapLookup interface would be a 
breaking change, isn't it? That would be another reason it couldn't be used in 
2.*.{quote}

Yes, the way I added {{CmapLookup}} would be breaking. What if I did the 
following instead:
# Add new {{getUnicodeCmapLookup}} getters to {{TrueTypeFont}} that return 
{{CmapLookup}}
# Deprecate the existing {{getUnicodeCmap}} getters
# Almost all uses of {{CmapSubtable}} in other classes are local variables or 
private members that don't leak outside of the class; for these we simply move 
to {{CmapLookup}}
# The one exception is {{TrueTypeEmbedder}}, where it is a protected member. 
Here we mark the member deprecated and add {{CmapLookup}} as a separate member, 
which we use in all cases.

{quote}The sample code (...) is too difficult for an average user. I'd prefer 
to have something on a high level, e.g. an option in an additional vertical 
loader, or a method. The "natural" setting should be the default. (What would a 
newbie "vertical font user" expect? (2) or (3) in your sample PDF ?){quote}

Actually that is somewhat intentional: if you are using a vertical font you 
would always want vertical glyph substitution as far as I know (at least for 
Japanese, you always want (2) and never (3)). I added the 
{{disableGsubFeature}} method to complement the {{enable}} method, on the off 
chance that a power user (who would surely know which GSUB features they 
wanted) needed more control. 99% of the time you would not be finagling 
features manually at all.

 I will submit the ICLA shortly.

> Vertical text creation
> ----------------------
>
>                 Key: PDFBOX-4106
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-4106
>             Project: PDFBox
>          Issue Type: New Feature
>          Components: FontBox, Parsing, Writing
>            Reporter: Aaron Madlon-Kay
>            Priority: Major
>              Labels: embed, gsub, parsing, vertical
>         Attachments: 0001-Parse-GSUB-table.patch, 
> 0002-Abstract-cmap-lookup-into-an-interface.patch, 
> 0003-Implement-GSUB-substitution-on-TrueTypeFont.patch, 
> 0004-Use-vhea-vmtx-to-fix-vertical-displacements-in-PCIDF.patch, 
> 0005-Add-factory-methods-for-loading-TTF-as-vertical-font.patch, 
> 0006-Implement-vertical-metrics-support-when-embedding-su.patch, 
> sample_code.txt, vertical.pdf
>
>
> I needed to output vertical Japanese text, but was stymied by several 
> limitations:
> * No API to load a TTF as Identity-V encoding
> * No support for 'vert' glyph substitution
> * No support for vertical metrics ('vhea' and 'vmtx' tables are parsed but 
> not used at all)
> I have attached a series of patches that implement the above features. 
> Highlights:
> * The GSUB glyph substitution table is parsed (limitation: type 1 lookups 
> only; this is sufficient for many features including 'vert'/'vrt2' vertical 
> glyph substitution)
> * Cmap lookup makes use of GSUB when features are enabled on a TTF
> * 'vhea' and 'vmtx' metrics are applied to PDCIDFont when appropriate, and 
> are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary
> * An API has been added for loading a TTF as a vertical font, setting 
> Identity-V encoding and enabling 'vert'/'vrt2' substitution
> Each patch could approximately be split out into a separate ticket, if 
> desired.
> Also attached is some sample code that exercises these patches and 
> illustrates the effect of vertical glyph positioning. The sample output PDF 
> is also attached.



--
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