Hi Manuel,
Manuel Mall wrote:
[...] In addition TIFF is currently supported through BatikImage.
I don't think once Batik has the inputstream decoded, e.g. read
the TIFF directory, I have access to the raw data required for
the CCFFilter.
So I suggest the following. We provide two TIFF image
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, J
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
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
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 image
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 ana
On Fri, 12 Aug 2005 06:48 pm, Jeremias Maerki wrote:
> 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
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
>
On Fri, 12 Aug 2005 06:00 pm, Thomas DeWeese wrote:
> Jeremias Maerki wrote:
> 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
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 full
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.
Of
I was looking at issues related to images not being displayed with their
correct resolution. As far as I understand all image formats apart from
GIF (which defaults to 72dpi) do carry resolution information. However,
it only works for JPEG at the moment. I managed to fix it for BMP
images by re
12 matches
Mail list logo
