From dev-return-56569-archive-asf-public=cust-asf.ponee.io@pdfbox.apache.org Fri May 11 02:03:06 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id AB8AC18067B for ; Fri, 11 May 2018 02:03:05 +0200 (CEST) Received: (qmail 10102 invoked by uid 500); 11 May 2018 00:03:04 -0000 Mailing-List: contact dev-help@pdfbox.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@pdfbox.apache.org Delivered-To: mailing list dev@pdfbox.apache.org Received: (qmail 9790 invoked by uid 99); 11 May 2018 00:03:04 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 May 2018 00:03:04 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 364AF18082D for ; Fri, 11 May 2018 00:03:04 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -109.511 X-Spam-Level: X-Spam-Status: No, score=-109.511 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, KAM_ASCII_DIVIDERS=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id Sxy8GGd_cyz6 for ; Fri, 11 May 2018 00:03:02 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 61EA55F283 for ; Fri, 11 May 2018 00:03:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 8D15EE00C6 for ; Fri, 11 May 2018 00:03:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 4948A21298 for ; Fri, 11 May 2018 00:03:00 +0000 (UTC) Date: Fri, 11 May 2018 00:03:00 +0000 (UTC) From: "John Hewson (JIRA)" To: dev@pdfbox.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (PDFBOX-4106) Vertical text creation MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/PDFBOX-4106?page=3Dcom.atlassia= n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D164= 71291#comment-16471291 ]=20 John Hewson edited comment on PDFBOX-4106 at 5/11/18 12:02 AM: --------------------------------------------------------------- (!) So we have a problem.=C2=A0While looking at building a proper ToUnicode= Map for PDFBOX-4189 I've encountered some significant issues related to thi= s 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 d= oes a good job of handling the intricacies of both PDF and OpenType and jug= gling the sometimes competing concerns. The issue is that the new APIs added to FontBox's TrueTypeFont are incompat= ible with PDFBox's multi-threading. Unlike most of PDFBox, fonts in FontBox= must be thread safe - they are cached and shared globally between all PDDo= cument instances. For this reason a FontBoxFont must not contain any docume= nt-specific state. The following fields added to TrueTypeFont contain document-specific state: {{List 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 eve= n occur if the user is manipulating more than one document within a single = thread.=C2=A0*There's no way around this and no way to fix these methods* -= document-specific state can't live in shared global fonts :( (flag)=C2=A0Tough choices:=C2=A0Given that these are all just auxiliary met= hods limited to just FontBox's TrueTypeFont class, we _could_=C2=A0remove t= hem. These are very obscure methods=C2=A0which have only been around for a = few weeks. It's unlikely that _any_=C2=A0users would be affected by their r= emoval. Obviously the missing functionality will be implemented in the appr= opriate 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*=C2=A0breaking 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 wors= e. Thoughts? * =3D And=C2=A0I have some=C2=A0ideas how to achieve this and am happy to d= o it was (Author: jahewson): (!) So we have a problem.=C2=A0While looking at building a proper ToUnicode= Map for PDFBOX-4189 I've encountered some significant issues related to thi= s 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 d= oes a good job of handling the intricacies of both PDF and OpenType and jug= gling the sometimes competing concerns. The issue is that the new APIs added to FontBox's TrueTypeFont are incompat= ible with PDFBox's multi-threading. Unlike most of PDFBox, fonts in FontBox= must be thread safe - they are cached and shared globally between all PDDo= cument instances. For this reason a FontBoxFont must not contain any docume= nt-specific state. The following fields added to TrueTypeFont contain document-specific state: {{List 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 eve= n occur if the user is manipulating more than one document within a single = thread.=C2=A0*There's no way around this and no way to fix these methods* -= document-specific state can't live in shared global fonts :( (flag)=C2=A0Tough choices:=C2=A0Given that these are all just auxiliary met= hods limited to just FontBox's TrueTypeFont class, we _could_=C2=A0remove t= hem. These are very obscure methods=C2=A0which have only been around for a = few weeks. It's unlikely that _any_=C2=A0users would be affected by their r= emoval. Obviously the missing functionality will be implemented in the appr= opriate 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*=C2=A0breaking 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 wors= e. Thoughts? > Vertical text creation > ---------------------- > > Key: PDFBOX-4106 > URL: https://issues.apache.org/jira/browse/PDFBOX-4106 > Project: PDFBox > Issue Type: Bug > Components: FontBox, Parsing, Writing > Reporter: Aaron Madlon-Kay > Assignee: Tilman Hausherr > Priority: Major > Labels: embed, gsub, parsing, vertical > Fix For: 2.0.9, 3.0.0 PDFBox > > Attachments: 0001-Add-OpenTypeScript-class-to-get-OT-script-tags-= for-c.patch, 0002-Optimize-Unicode-script-storage-and-lookup.patch, 0003-Pa= rse-GSUB-table.patch, 0004-Abstract-cmap-lookup-into-an-interface.patch, 00= 05-Implement-GSUB-substitution-on-TrueTypeFont.patch, 0006-Use-vhea-vmtx-to= -fix-vertical-displacements-in-PCIDF.patch, 0007-Add-factory-methods-for-lo= ading-TTF-as-vertical-font.patch, 0008-Implement-vertical-metrics-support-w= hen-embedding-subsetting.patch, FIX-0001-PDFBOX-4106-Remove-early-outs-lead= ing-to-spurious-wa.patch, FIX-0002-PDFBOX-4106-Document-GlyphSubstitutionTa= ble-public-m.patch, FIX-0003-PDFBOX-4106-Correct-deltaGlyphID-data-size.pat= ch, FIX-0004-PDFBOX-4106-Remove-unnecessary-vertical-displacement.patch, FI= X-0005-PDFBOX-4106-Remove-duplicate-DW2-creation.patch, FIX-0006-PDFBOX-410= 6-Fix-non-embedded-vertical-font-rendering.patch, FIX-0007-PDFBOX-4106-Fix-= incorrect-parsing-of-W2-first-format.patch, FIX-0008-PDFBOX-4106-Rename-mis= leading-field.patch, FIX-0009-PDFBOX-4106-Allow-retrieving-vmtx-topSideBear= ing.patch, FIX-0010-PDFBOX-4106-Correct-vmtx-embedding-for-proportional-.pa= tch, sample_code.txt, vertical.pdf > > > I needed to output vertical Japanese text, but was stymied by several lim= itations: > * 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 bu= t not used at all) > I have attached a series of patches that implement the above features. Hi= ghlights: > * The GSUB glyph substitution table is parsed (limitation: type 1 lookups= only; this is sufficient for many features including 'vert'/'vrt2' vertica= l 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, an= d are embedded/subsetted correctly through the DW2/W2 CIDFont dictionary > * An API has been added for loading a TTF as a vertical font, setting Ide= ntity-V encoding and enabling 'vert'/'vrt2' substitution > Each patch could approximately be split out into a separate ticket, if de= sired. > Also attached is some sample code that exercises these patches and illust= rates the effect of vertical glyph positioning. The sample output PDF is al= so attached. -- 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