xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: Fonts in XG
Date Wed, 14 Nov 2012 08:02:12 GMT
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 <bowditch_chris@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 <glenn@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<general-unsubscribe@xmlgraphics.apache.org>
> > For additional commands, e-mail: general-help@xmlgraphics.**apache.org<general-help@xmlgraphics.apache.org>
> >
> >


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org


Mime
View raw message