On Sun, 14 Aug 2005 09:14 pm, Jeremias Maerki wrote:
Oh, right, looks like the CCFFilter needs to be ported from the
maintenance branch to the trunk. I didn't remember that one. The
Batik codecs are actually not so much involved in this case, since
the TIFF doesn't have to be fully decoded.
I haven't looked into it in detail but what you say makes sense. If
possible I'd try to use loadOriginalData() as much as possible even if
I needed to stretch the meaning a bit. I'm sure you'll figure out the
right way.
On 15.08.2005 16:04:00 Manuel Mall wrote:
On Sun, 14 Aug 2005 09:14 pm,
Oh, right, looks like the CCFFilter needs to be ported from the
maintenance branch to the trunk. I didn't remember that one. The Batik
codecs are actually not so much involved in this case, since the TIFF
doesn't have to be fully decoded. Have a look at how JPEG is handled.
The JPEGs are simply
On Aug 12, 2005, at 2:27 AM, Jeremias Maerki wrote:
Ideally, the *Reader implementations (analyser package) for each format
should actually read the extents and the bitmap resolution already. It
should not be deferred to the actual codec, if possible. That makes it
possible to work with the
AFAIK, the codecs themselves are not affected by the headless issue.
They are simply code to decode and encode the TIFF and PNG formats.
Furthermore, Batik maintains JDK 1.3 compatibility so no worries here,
either. The codecs will probably be moved into XML Graphics Commons
anyway, so no point in
Ideally, the *Reader implementations (analyser package) for each format
should actually read the extents and the bitmap resolution already. It
should not be deferred to the actual codec, if possible. That makes it
possible to work with the image (during layout) without fully loading it
already.
Jeremias Maerki wrote:
Ideally, the *Reader implementations (analyser package) for each format
should actually read the extents and the bitmap resolution already. It
should not be deferred to the actual codec, if possible. That makes it
possible to work with the image (during layout) without
On Fri, 12 Aug 2005 06:00 pm, Thomas DeWeese wrote:
Jeremias Maerki wrote:
snip/
Yes it does. It uses the 'properties' interface to expose this
(and lots of other) information. The properties in question are
x_pixels_per_unit, y_pixels_per_unit pixel_units.
The TIFF reader exposes
On 12.08.2005 12:00:05 Thomas DeWeese wrote:
Jeremias Maerki wrote:
Ideally, the *Reader implementations (analyser package) for each format
should actually read the extents and the bitmap resolution already. It
should not be deferred to the actual codec, if possible. That makes it
