You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xmlgraphics.apache.org by Peter Hancock <pe...@gmail.com> on 2012/11/12 16:44:37 UTC
Fonts in XG
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
Re: Fonts in XG
Posted by Mehdi Houshmand <me...@gmail.com>.
Sorry I meant to add, that rather than us necessarily using Fontbox, it
might be useful, once the font library has been created, to let the PDFBox
guys know since what they're looking for is a subset of what we're going
for. Though again, they make heavy use of AWT to convert the Glyf data into
Graphics2D, but if this is intended to work with Batik, we'll want to do
the same.
Food for thought,
Mehdi
On 13 November 2012 10:33, Mehdi Houshmand <me...@gmail.com> wrote:
> Hi Guys,
>
> I looked at this a long time ago (there's probably an email floating
> around somewhere), but the fontbox library won't in itself be useful for
> us. It does a subset of what we're asking for a fonts library and as such
> is designed differently. It also makes heavy use of AWT, which is exactly
> what we want to not do, which will make it trouble some.
>
> That's not to say it's not at all useful to us, it might be good to look
> at it and look at how PDFBox uses it, in order to better form an API that
> would make a font library more extensible and more usable for others.
>
> Hope that helps,
>
> Mehdi
>
>
> On 13 November 2012 10:27, Peter Hancock <pe...@gmail.com> 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 <gl...@skynav.com> 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 <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
>> > >
>> >
>>
>
>
Re: Fonts in XG
Posted by Mehdi Houshmand <me...@gmail.com>.
Hi Guys,
I looked at this a long time ago (there's probably an email floating around
somewhere), but the fontbox library won't in itself be useful for us. It
does a subset of what we're asking for a fonts library and as such is
designed differently. It also makes heavy use of AWT, which is exactly what
we want to not do, which will make it trouble some.
That's not to say it's not at all useful to us, it might be good to look at
it and look at how PDFBox uses it, in order to better form an API that
would make a font library more extensible and more usable for others.
Hope that helps,
Mehdi
On 13 November 2012 10:27, Peter Hancock <pe...@gmail.com> 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 <gl...@skynav.com> 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 <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
> > >
> >
>
Re: Fonts in XG
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Well, I'm not that familiar with FontBox. I've mostly worked with PDFBox.
Jeremias Maerki
On 13.11.2012 12:30:36 Mehdi Houshmand wrote:
> As far as a I'm aware, Fontbox doesn't read a lot of the tables necessary
> for CS. I don't know PDFBox handles arabic scripts, but I think much of
> that would be handled by AWT if at all. I'm not 100% on this, Jeremias
> might know more.
>
> Either way, we're going to have to make substantial changes to FOP (not
> necessarily the layout, that shouldn't be affected too much, but the font
> handling), but if the question is "which is the best starting point for the
> project Fontbox or our font classes?", I think that would need some
> investigation. Fontbox is certainly better structured than our classes, but
> it too needs some TLC. The point being, Fontbox uses AWT for interpreting
> the drawing commands, which we don't want, but we don't do that anyways...
> So Fontbox is still a valid fit, since as far as we're concerned, either we
> nor Fontbox do that appropriately (hope that makes sense).
>
> I think taking a look at Fontbox is certainly helpful, if only so that you
> get a better understanding for what PDFBox asks of fonts i.e. their glyph
> drawing data, metrics etc.
>
> Mehdi
>
>
> On 13 November 2012 10:49, Chris Bowditch <bo...@hotmail.com>wrote:
>
> > 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<http://markmail.org/message/jo56auecjd6skeci>
> >> [2] http://markmail.org/message/**j3tbybb6s62u7v72<http://markmail.org/message/j3tbybb6s62u7v72>
> >>
> >>
> >> On Mon, Nov 12, 2012 at 4:01 PM, Glenn Adams <gl...@skynav.com> 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 <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<http://markmail.org/message/4mocrzwpzaaudwz2>
> >>>>
> >>>> [2] http://markmail.org/message/**fbck5tolipkkfw5u<http://markmail.org/message/fbck5tolipkkfw5u>
> >>>>
> >>>> [3]
> >>>>
> >>>>
> >>>> http://apache-fop.1065347.n5.**nabble.com/Foray-s-font-**
> >>> subsystem-for-Fop-tp18467.html<http://apache-fop.1065347.n5.nabble.com/Foray-s-font-subsystem-for-Fop-tp18467.html>
> >>>
> >>
> >
> > ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: general-unsubscribe@**xmlgraphics.apache.org<ge...@xmlgraphics.apache.org>
> > For additional commands, e-mail: general-help@xmlgraphics.**apache.org<ge...@xmlgraphics.apache.org>
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Fonts in XG
Posted by Glenn Adams <gl...@skynav.com>.
I agree that the best near term solution is (2), which could the facilitate
a subsequent migration to (3).
On Tue, Nov 13, 2012 at 9:03 AM, Chris Bowditch
<bo...@hotmail.com>wrote:
> Hi Glenn,
>
>
> On 13/11/2012 15:29, Glenn Adams wrote:
>
>> On Tue, Nov 13, 2012 at 3:49 AM, Chris Bowditch
>> <bo...@hotmail.com>**wrote:
>>
>> Does FontBox have support for the tables needed by the ComplexScripts
>>> code
>>> added to the TTFReader classes?
>>>
>>> No. Clearly that would have to be added to fontbox to work. However, I'm
>> thinking more about a long term plan for font handling, which may (or may
>> not) make fontbox worth considering, in which case, the CS features would
>> need to be added to it and the AWT dependencies removed or segregated.
>>
>> If we had more than one joint committer (just JM is now), then it would be
>> possible to do this work more readily. The real question for me is whether
>> we want to (1) continue having a large and increasingly unwieldy font
>> subsystem in FOP, (2) move that into XGC (to share with Batik), or (3)
>> improve Fontbox to serve both Fop/Batik.
>>
>
> I realize there is a disadvantage with maintaining multiple disparate font
> libraries. The ideal would be combine them all into 1 library and use that
> across PDFBox, FOP and Batik. We will certainly take a look at fontbox, but
> everything I'm hearing so far leads me to believe it is a massive job
> compared to option (2) above. If we look into that and are confident that
> is not the case then I agree we can try to merge the 2 libraries and use
> the result in FOP and Batik.
>
>
>
>> If the level of effort of (2) and (3) is similar, then I would suggest
>> taking (3). I could readily move the CS code into FB I'm certain.
>>
>>
> Peter is looking into the font requirements of Batik right now. After
> doing that he will take a look at FontBox and we will discuss our findings
> here.
>
> Thanks,
>
> Chris
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: general-unsubscribe@**xmlgraphics.apache.org<ge...@xmlgraphics.apache.org>
> For additional commands, e-mail: general-help@xmlgraphics.**apache.org<ge...@xmlgraphics.apache.org>
>
>
Re: Fonts in XG
Posted by Chris Bowditch <bo...@hotmail.com>.
Hi Glenn,
On 13/11/2012 15:29, Glenn Adams wrote:
> On Tue, Nov 13, 2012 at 3:49 AM, Chris Bowditch
> <bo...@hotmail.com>wrote:
>
>> Does FontBox have support for the tables needed by the ComplexScripts code
>> added to the TTFReader classes?
>>
> No. Clearly that would have to be added to fontbox to work. However, I'm
> thinking more about a long term plan for font handling, which may (or may
> not) make fontbox worth considering, in which case, the CS features would
> need to be added to it and the AWT dependencies removed or segregated.
>
> If we had more than one joint committer (just JM is now), then it would be
> possible to do this work more readily. The real question for me is whether
> we want to (1) continue having a large and increasingly unwieldy font
> subsystem in FOP, (2) move that into XGC (to share with Batik), or (3)
> improve Fontbox to serve both Fop/Batik.
I realize there is a disadvantage with maintaining multiple disparate
font libraries. The ideal would be combine them all into 1 library and
use that across PDFBox, FOP and Batik. We will certainly take a look at
fontbox, but everything I'm hearing so far leads me to believe it is a
massive job compared to option (2) above. If we look into that and are
confident that is not the case then I agree we can try to merge the 2
libraries and use the result in FOP and Batik.
>
> If the level of effort of (2) and (3) is similar, then I would suggest
> taking (3). I could readily move the CS code into FB I'm certain.
>
Peter is looking into the font requirements of Batik right now. After
doing that he will take a look at FontBox and we will discuss our
findings here.
Thanks,
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Fonts in XG
Posted by Glenn Adams <gl...@skynav.com>.
On Tue, Nov 13, 2012 at 3:49 AM, Chris Bowditch
<bo...@hotmail.com>wrote:
> Does FontBox have support for the tables needed by the ComplexScripts code
> added to the TTFReader classes?
>
No. Clearly that would have to be added to fontbox to work. However, I'm
thinking more about a long term plan for font handling, which may (or may
not) make fontbox worth considering, in which case, the CS features would
need to be added to it and the AWT dependencies removed or segregated.
If we had more than one joint committer (just JM is now), then it would be
possible to do this work more readily. The real question for me is whether
we want to (1) continue having a large and increasingly unwieldy font
subsystem in FOP, (2) move that into XGC (to share with Batik), or (3)
improve Fontbox to serve both Fop/Batik.
If the level of effort of (2) and (3) is similar, then I would suggest
taking (3). I could readily move the CS code into FB I'm certain.
Re: Fonts in XG
Posted by Mehdi Houshmand <me...@gmail.com>.
As far as a I'm aware, Fontbox doesn't read a lot of the tables necessary
for CS. I don't know PDFBox handles arabic scripts, but I think much of
that would be handled by AWT if at all. I'm not 100% on this, Jeremias
might know more.
Either way, we're going to have to make substantial changes to FOP (not
necessarily the layout, that shouldn't be affected too much, but the font
handling), but if the question is "which is the best starting point for the
project Fontbox or our font classes?", I think that would need some
investigation. Fontbox is certainly better structured than our classes, but
it too needs some TLC. The point being, Fontbox uses AWT for interpreting
the drawing commands, which we don't want, but we don't do that anyways...
So Fontbox is still a valid fit, since as far as we're concerned, either we
nor Fontbox do that appropriately (hope that makes sense).
I think taking a look at Fontbox is certainly helpful, if only so that you
get a better understanding for what PDFBox asks of fonts i.e. their glyph
drawing data, metrics etc.
Mehdi
On 13 November 2012 10:49, Chris Bowditch <bo...@hotmail.com>wrote:
> 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<http://markmail.org/message/jo56auecjd6skeci>
>> [2] http://markmail.org/message/**j3tbybb6s62u7v72<http://markmail.org/message/j3tbybb6s62u7v72>
>>
>>
>> On Mon, Nov 12, 2012 at 4:01 PM, Glenn Adams <gl...@skynav.com> 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 <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<http://markmail.org/message/4mocrzwpzaaudwz2>
>>>>
>>>> [2] http://markmail.org/message/**fbck5tolipkkfw5u<http://markmail.org/message/fbck5tolipkkfw5u>
>>>>
>>>> [3]
>>>>
>>>>
>>>> http://apache-fop.1065347.n5.**nabble.com/Foray-s-font-**
>>> subsystem-for-Fop-tp18467.html<http://apache-fop.1065347.n5.nabble.com/Foray-s-font-subsystem-for-Fop-tp18467.html>
>>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: general-unsubscribe@**xmlgraphics.apache.org<ge...@xmlgraphics.apache.org>
> For additional commands, e-mail: general-help@xmlgraphics.**apache.org<ge...@xmlgraphics.apache.org>
>
>
Re: Fonts in XG
Posted by Chris Bowditch <bo...@hotmail.com>.
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 <gl...@skynav.com> 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 <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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: Fonts in XG
Posted by Peter Hancock <pe...@gmail.com>.
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 <gl...@skynav.com> 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 <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
> >
>
Re: Fonts in XG
Posted by Glenn Adams <gl...@skynav.com>.
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 <pe...@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
>