Re: css2xslfo

[Emmanuel Bourg <ebourg@apache.org>]

Hi Tristan,

Le 19/01/2014 15:54, Tristan Seligmann a écrit :
> I have just uploaded css2xslfo into pkg-java git (thanks to Sylvestre
> for adding me so quickly). In brief, css2xslfo is a tool for
> converting an HTML/XML+CSS document to XSL-FO; this is mainly useful
> in order to pass it to another tool (such as Apache FOP) to convert
> the XSL-FO into some final display format such as PDF.
> 
> I think the package is ready for upload now, but as this is my first
> Java package in Debian, and there are one or two tricky aspects to how
> the package works, I would very much appreciate a review by a more
> experienced Java packager.

I reviewed the package quickly and it looks good. I just renamed the
patch to add the .patch extension. If you want to clear the
incompatible-java-bytecode-format lintian warning you have to set the
source/target level to 1.6 on the <javac> Ant task. No jar is installed
in /usr/share/java, if css2xslfo can be used as a library that may be
useful.

Also, the git repository is missing the 'upstream' branch used by
git-import-orig.


> In particular, the main issue with this package is that upstream has
> taken the W3C sac/flute library, and modified it extensively for their
> own needs (adding CSS 3 support, among other things). Fortunately they
> have provided the source code for their modifications, and I believe
> there are no licensing issues here, but since I cannot use the Debian
> libflute-java, I've opted to build their modified version during the
> package build, and include it directly in the resulting JAR for
> css2xslfo.
> 
> It is possible that the Debian libsac-java/libflute-java could be
> updated to the css2xslfo versions; the library seems dead upstream
> (last release from W3C was in 2002). On the other hand, I have no idea
> whether any of the css2xslfo modifications have
> backwards-compatibility issues, and css2xslfo upstream is not very
> active themselves (last release in 2010); on top of this, the modified
> libraries are not distributed in a very prominent way.

I think it's better to leave the original sac/flute unchanged. The FTP
masters may not like the archives in the source package though as it's
not the preferred form of modification. Instead of unpacking the sources
at build time I would suggest writing a debian/orig-tar.sh script that
extracts everything before building the upstream tarball.

Emmanuel Bourg