Return-Path: X-Original-To: apmail-xmlgraphics-general-archive@www.apache.org Delivered-To: apmail-xmlgraphics-general-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8CEACD4FE for ; Tue, 13 Nov 2012 10:49:34 +0000 (UTC) Received: (qmail 52280 invoked by uid 500); 13 Nov 2012 10:49:33 -0000 Mailing-List: contact general-help@xmlgraphics.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@xmlgraphics.apache.org Delivered-To: mailing list general@xmlgraphics.apache.org Received: (qmail 52067 invoked by uid 99); 13 Nov 2012 10:49:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Nov 2012 10:49:32 +0000 X-ASF-Spam-Status: No, hits=2.3 required=5.0 tests=FREEMAIL_REPLY,RCVD_IN_DNSWL_NONE,SPF_PASS,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of bowditch_chris@hotmail.com designates 65.55.111.164 as permitted sender) Received: from [65.55.111.164] (HELO blu0-omc4-s25.blu0.hotmail.com) (65.55.111.164) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Nov 2012 10:49:23 +0000 Received: from BLU0-SMTP32 ([65.55.111.135]) by blu0-omc4-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Nov 2012 02:49:02 -0800 X-Originating-IP: [81.104.63.105] X-EIP: [lO+mMBl4+zxHzJkHOq+hCy/VZiYpxQix] X-Originating-Email: [bowditch_chris@hotmail.com] Message-ID: Received: from [192.168.3.87] ([81.104.63.105]) by BLU0-SMTP32.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Nov 2012 02:49:01 -0800 Date: Tue, 13 Nov 2012 10:49:00 +0000 From: Chris Bowditch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: general@xmlgraphics.apache.org Subject: Re: Fonts in XG References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2012 10:49:01.0527 (UTC) FILETIME=[7DE3B670:01CDC18C] X-Virus-Checked: Checked by ClamAV on apache.org Does FontBox have support for the tables needed by the ComplexScripts code added to the TTFReader classes? The scope of this work is already very large, I'm not in favour of further enlarging the scope. The current objective is to move the Font library to its own library so Batik can use it instead of AWT. We believe a lot of changes may be needed to Batik. If we also switch to FontBox at the same time we would need to rewrite large parts of FOP in addition to Batik. Thus increasing the scope of this work substantially. An alternative possibility that wouldn't dramatically increase the scope of this work is to leave FOP alone and see if Batik can use FontBox? I would accept that approach, but I don't think that is what you meant? Thanks, Chris On 13/11/2012 10:27, Peter Hancock wrote: > Quite possibly according to [1] and [2] and worth investigating. > > [1] http://markmail.org/message/jo56auecjd6skeci > [2] http://markmail.org/message/j3tbybb6s62u7v72 > > > On Mon, Nov 12, 2012 at 4:01 PM, Glenn Adams wrote: > >> Would it be useful to transition to use of the fontbox subsystem of the >> pdfbox project? >> >> On Mon, Nov 12, 2012 at 7:44 AM, Peter Hancock >> wrote: >>> The URI resolution work that Mehdi and myself recently work on [1] was >> one >>> of many requirements for running FOP in a environments with restricted >>> access to the filesystem (think The Cloud). Another requirement relates >> to >>> the accessing of Fonts: When FOP handles XSL-FO documents with embedded >>> SVG containing text, it delegates the layout and rendering job to Batik. >>> Batik will require font metrics that are associated with the text and >>> currently uses the AWT library to load the JDK fonts that are OS fonts. >>> This process is problematic for a few reasons: One is presented to us >>> when we wish to run FOP in a so-called multi-tenant environment; In this >>> scenario, fonts that are liscensed on a per-tenant basis must have their >>> availiability accordingly restricted accordingingly. How can this be >>> enforced when fonts are resolved at the JVM level? >>> >>> I am interested in feedback from the community to find out what other >>> problems are attributed to the current Font handling processes in FOP and >>> Batik, and what the solutions to these may look like. Would sharing code >>> between FOP and Batik help to unify the handling of fonts. FOP could >>> configure the font library so that Batik loads fonts accordingly. This >> was >>> proposed at the time of XML Graphics Commons' inception [2]. >>> >>> I am aware that Font handling has been discussed on XG mailing lists and >>> attempts made to extract a font library from FOP [3]. >>> >>> Thanks, >>> >>> Peter >>> >>> [1] http://markmail.org/message/4mocrzwpzaaudwz2 >>> >>> [2] http://markmail.org/message/fbck5tolipkkfw5u >>> >>> [3] >>> >>> >> http://apache-fop.1065347.n5.nabble.com/Foray-s-font-subsystem-for-Fop-tp18467.html --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org For additional commands, e-mail: general-help@xmlgraphics.apache.org