xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Adams <gl...@skynav.com>
Subject Re: Fonts in XG
Date Mon, 12 Nov 2012 16:01:10 GMT
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 <peter.hancock@gmail.com>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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message