Hi Ben, hi All,

I finally have some time to chime in, sorry for the delay. Thank you for
your interest in the font subsystem.

My goal is to adapt the FOrayFont library to Fop. The main advantage of
FOrayFont over the Fop code is its ability to directly parse font files,
whereas currently with Fop there is a two-step process: first convert
the font metrics into an xml file, then use it within Fop through a
configuration file. You can have the process in [1].

I've submitted a first patch in december [2], that was refused because
of unacceptable shortcomings of FOrayFont. The main reasons were:
* lack of a default config file;
* configuration too complicated.
You will find all the details in [3]. Since that I'm working with Victor
on FOrayFont's improvement. We have recently ended the design phase and
have agreed on a set of changes that I still have to apply (you will
find the discussion on the FOray-dev mailing list archive from the last
two months. I'll add more on this on FOray-dev.). After that I believe
that the main shortcomings will be corrected and that an updated patch
can be submitted.

PDFBox is pretty independant of my work. I currently rely entirely on
the Fop PDF library for PDF outputs, and I'm only adapting necessary
things to make it use FOrayFont. FOrayFont is a low-level library that
tries to be independent of any output format, and thus may be used by
whatever renderer. So if PDFBox were to be used by Fop, for me it would
just mean that I would have to adapt PDFBox instead of the Fop library.

For FontBox this is different, and I think there is a possibility to
share resources in this area. I'll put more details on FOray-dev, but in
short it would be great if we could achieve the following:
* merge the best of FontBox and FOrayFont to obtain a good font library;
* agree on a common interface (i.e., an API) for the font library, that
  would be used conjointly by Fop, PDFBox and FOray;
* adapt PDFBox to make it use this resulting library;
* make it work with Fop in some manner.

I would like to work with you on the two first points. As you have
probably already noticed the discussion will be mainly held in the FOray
area. We will chime in here for Fop-specific things and to notify Fop
devs of advancements of the adaptation work.

I'm glad to see that there is place for collaboration. I'm sure that we
will be able to achieve Great Things ;-)


Current way to configure fonts in Fop:
[1] http://xmlgraphics.apache.org/fop/trunk/fonts.html

Patch for the adaptation of FOrayFont to Fop (now outdated):
[2] http://issues.apache.org/bugzilla/show_bug.cgi?id=35948

Reasons of the patch refusal:
[3] http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200512.mbox/browser

Ben Litchfield a écrit :

I'll start by answering your questions

1)What is minimum JDK required by PDFBox?

PDFBox currently requires 1.4, because it uses ImageIO and a couple other things that make development much easier. PDFBox was compatible with 1.3 for a long time, but I made a decision that sticking with 1.3 would cost too much in development time versus using existing stuff in 1.4. In addition 1.3 is now two major versions old and in the EOL phase. As this effort will take some time before it could be released would it be reasonable to move the minimum requirement up to 1.4 for Batik and FOP at that time?

2)Does PDFBox require log4j?

PDFBox used to be dependent on log4j, 0.7.2 has an optional dependency, the soon to be released 0.7.3 version will not use log4j at all. Currently PDFBox's only dependency is FontBox(see comments below), although bouncy castle will soon become an optional dependency for certificate based encryption and rhino(looks like Batik uses this as well) will also be an optional dependency for Javascript execution.

Some additional comments,
*After the 0.7.2 release, PDFBox split the font infrastructure into another project, so aptly named FontBox. No official version has been released yet but the project was created and all font parsing logic was separated from PDFBox. As far as I can tell there is no open source font library and for many of the same reasons we have discussed I thought it would be better as a separate project. It sounds like there has already been some discussion on making a separate font library project, I would be happy to collaborate on and donate what little font parsing code I have to that project. It only makes sense for PDFBox/FOP/Batik/... to all use a single font library. It is starting to sound like a unified font system might be the first task.

*I did not realize that other projects(Batik) were using FOP's pdf library, again a separate PDF&Font library makes that cleaner. As a side note, PDFs can contain SVG graphics, so I eventually saw PDFBox utilizing Batik, which makes things interesting :)

*If bringing PDFBox into ASF is what is necessary to make this work than I am willing to do that. As you say, this requires a fair amount of energy, so "just because" is not a good enough reason for me to to expend the energy.

It sounds like the first thing we need to do is get the font system working. I also like Jeremias' idea of experimenting with a copy of the PDFRenderer, low risk and little disruption to ongoing work.

At a high level this sounds reasonable to me
1)Separate font system
2)PDFBox and FOP are independently updated to use a common font system
3)A copy of the PDF renderer is created and updated to utilize PDFBox
4)Go from there

No matter what is decided, steps 1&2 are desired and are already in progress. I would like to help with the creation of the font sub system because I would like PDFBox to use it.


Reply via email to