Great, I will start updating PDFBox to use the FOrayFont, I believe 
this will go pretty smoothly because FOrayFont is already being used 
for PDF creation.  More details on the FOray list.

We have had some recent discussions about supported JRE's, from the 
main page of FOray[1] it says that 1.4 is used.  There is a desire 
among the FOP developers to maintain compatibility with 1.3.  Do you 
know if FOrayFont compatible with 1.3?

Ben

[1]http://foray.sourceforge.net/

> 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 ;-)
> 
> Cheers,
> Vincent
> 
> 
> 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 :
> > Jeremias,
> > 
> > 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.
> > 
> > 
> > Ben
> 
> 


Reply via email to