On 20.12.2007 22:40:54 J.Pietschmann wrote:
Jeremias Maerki wrote:
image loading and processing library in Java
Can you give some of the more promising links? I have taken a look
myself and haven't found anything closely resembling what we have now.
Most only seem to support bitmap
Andreas,
what I was talking about was exlusively logging targeted at the developer,
not the user. User feedback is a different topic, one that I want to
address early next year for FOP (see [1]), but I've mentioned that
before.
[1] http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback
I
On Dec 17, 2007, at 10:48, Jeremias Maerki wrote:
Andreas,
what I was talking about was exlusively logging targeted at the
developer,
not the user. User feedback is a different topic, one that I want to
address early next year for FOP (see [1]), but I've mentioned that
before.
OK, just
On 18.12.2007 02:21:38 thomas.deweese wrote:
Hi Cameron, Jeremias,
This is written pretty quickly just to get potential ideas comments
out.
The Image package sounds nice in general.
Jeremias Maerki:
I could move the new image package from org.apache.fop.image2 [2] (in
the
Hi,
On Dec 13, 2007 6:21 PM, Jeremias Maerki [EMAIL PROTECTED] wrote:
H. What with the people who prefer Log4J and want everything logged
there? Commons Logging at least provides a switching central to route
the log traffic where you want it. I don't think that's so easy (and
readily
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
15 matches
Mail list logo