Most of you may know that I'm working on a new image loading package for
FOP. FOP needs to load all sorts of different image (bitmap, EPS, SVG,
MathML and others we don't even need to know about). I'm soon finished
with it so it can be merged into FOP Trunk (it's currently in a branch
at [1]). The
Thanks for your feedback!
Passing additional information to an image converter (like font info) is
not a problem. This is already available in the package by passing a Map
of key/value pairs through the image pipeline. But carrying the font
information from the FO stage all the way to the
Jeremias,
IMO XMLGraphics is definitely the place to be. I would very much like to
see the API here, as it should be generic - in this case the
jeuclid-fop-plugin would become a jeuclid-xmlgraphics-plugin (which
would allow us to mix svg / mathml, an interesting thought).
However, this would
Another important point to consider here:
The image package currently makes extensive use of Apache Commons
Logging like the rest of FOP. XML Graphics Commons still doesn't use
Commons Logging. With the migration of the PDF and EPS transcoders to
Batik a lot more code with references to Commons
Jeremias Maerki wrote:
Another important point to consider here:
The image package currently makes extensive use of Apache Commons
Logging like the rest of FOP. XML Graphics Commons still doesn't use
Commons Logging. With the migration of the PDF and EPS transcoders to
Batik a lot more code
On 12.12.2007 16:45:13 Chris Bowditch wrote:
Jeremias Maerki wrote:
Another important point to consider here:
The image package currently makes extensive use of Apache Commons
Logging like the rest of FOP. XML Graphics Commons still doesn't use
Commons Logging. With the migration of the
Jeremias Maerki wrote:
Most of you may know that I'm working on a new image loading package for
FOP.
[snip]
Good work BTW. I'm quite impressed.
A month ago, I told Tonny Kohar of Kiyut about the new package, after
I've seen their Ekspos Image Viewer [3]. He showed quite some interest
and now
Jeremias Maerki:
Another important point to consider here:
The image package currently makes extensive use of Apache Commons
Logging like the rest of FOP. XML Graphics Commons still doesn't use
Commons Logging. With the migration of the PDF and EPS transcoders to
Batik a lot more code with
J.Pietschmann:
I'm all for re-use of code solving common problems. Moving the image
loading package into a position more neutral than the FOP project is
certainly a good idea. I hope the font related code can be shared
with Batik also.
Yes, I’d like to re-work the font handling after the 1.7
Hi,
On Dec 12, 2007 5:41 PM, Max Berger [EMAIL PROTECTED] wrote:
If the size is an issue: Maybe the xmlgraphics commons can be split up
into multiple jars? this could be done depending on the actual use, e.g.
what batik actually uses and what fop uses.
Yup, agree with Max regarding using
10 matches
Mail list logo
