Ignore my last message. Chris got there first.

From: rme...@hotmail.co.uk
To: fop-dev@xmlgraphics.apache.org
Subject: RE: OTF CFF Implementation
Date: Thu, 10 Jan 2013 11:01:00 +0000




Hi Pascal,

My apologies as I should have provided the link [1]. I am guessing that the 
sourceforge project you linked to is the original version before it was merged 
with pdfbox.

The project is quite active and had its last patch submitted yesterday. There 
is also a PMC member on the project who is also a FOP committer (Jeremias), but 
I am sure the other committers are fairly active.

Regards,

Robert

[1] http://pdfbox.apache.org/dependencies.html

> Date: Thu, 10 Jan 2013 10:12:43 +0100
> Subject: Re: OTF CFF Implementation
> From: psancho....@gmail.com
> To: fop-dev@xmlgraphics.apache.org
> 
> Hi,
> 
> unless I'm missing something, fontbox dev activity is quite slow
> (latest commit was on 2007-10-01, 6 years ago, see [1]).
> IMHO, introducing a dependency on such project witch will need some
> improvement is not a good thing, unless we can ensure that submitting
> patches to it will be applied on demand.
> 
> [1] 
> http://sourceforge.net/projects/fontbox/stats/scm?repo=CVSRepository&dates=2007-01-10+to+2013-01-10
> 
> 2013/1/9 Robert Meyer <rme...@hotmail.co.uk>:
> > Hi All,
> >
> > Unless someone else has been developing this in secret, I am planning to
> > make a start on adding support for OTF CFF (Open Type - Compact Font
> > Format). There are two choices I can see which are available and would like
> > to ask for your opinion. These are:
> >
> > 1) Using the implementation from fontbox and write adapter classes to allow
> > it to work with FOP.
> > 2) Write a dedicated FOP implementation.
> >
> > There are pro's and con's to each. Firstly, using fontbox will create
> > another dependency to FOP which is generally never a good thing. It will
> > also means if there is a problem with their implementation, we have to rely
> > upon them to commit the patch (either written by us or by themselves). I
> > don't know what their uptake is on committing patches, but unlike FOP the
> > control would be taken out of our hands.
> >
> > Saying this however, using their implementation will cut the development
> > time as the majority of work will already have been done. There is also the
> > advantage that their implementation will have been around for a while and
> > will have benefited from subsequent use and have ironed out any bugs.
> >
> > If you have any other comments for or against each option please post them.
> >
> > Regards,
> >
> > Robert Meyer
> 
> 
> 
> -- 
> pascal
                                                                                
  

Reply via email to