Hi, Ok, I've missed that. I did found only the sourceforge repos, I'm sorry.
So i'm +1 too. 2013/1/10 Chris Bowditch <[email protected]>: > Hi Pascal, > > FontBox is a small library within the PDFBox project. PDFBox is an active > Apache project, so getting patches committed there shouldn't be a problem. > Jeremias is a committer on PDFBox too. FontBox is no longer hosted on Source > Forge, as it was moved to Apache a few years back; which is probably why > there hasn't been a recent commit to the SourceForge version. Last commit to > the Apache version was still 2 years ago, see: > http://svn.apache.org/viewvc/pdfbox/ > > I think it makes sense to reuse code wherever possible, especially when we > are talking about fellow Apache projects. So I'm +1 to this proposal. > > Thanks, > > Chris > > > On 10/01/2013 09:12, Pascal Sancho wrote: >> >> 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 <[email protected]>: >>> >>> 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
