You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Eric SCHAEFFER <es...@posterconseil.com> on 2000/05/04 10:46:44 UTC
Image Support : need help
Ok, after a short discussion with Pankaj, here is the result.
But there's still some problems, and I don't have a clear vision on what to
do.
Let's explain :
- We need to know the real image size while creating the area tree, to handle
width and height fo properties. The only way we found is to load the image
data.
- If we load image data while creating the area tree (before writing the PDF
stream), should we keep this data in memory or should we reload this data
later when needed ?
- If we keep image data in memory, we should compress it. But then, in the PDF
stream, the data are written compressed too. Should the FOPImage objects
return compressed data, or should the PDF stream writer handle compression ?
The PDF compression filters are PNG and JPEG (and 3 others that I don't
understand: LZW, CCITTFax, RunLength). That's a bit short, and maybe doesn't
cover all needs. Thus, it seems better that FOPImage objects return
uncompressed data, and that the stream writer compresses it if needed and
using a compression filter adapted.
Problem: compression -> decompression -> compression, and what compression
filter to use (JPEG has loss quality: it's better to use it if the image was a
JPEG file, but then why so much compressions and decompressions). On the other
hand, if FOPImage objects return compressed data, the compression filter must
be understandable by PDF readers...
- Maybe we should use Java image classes. I don't know them enougth ot see
what class can be used, and what would be the benefits.
If you have suggestions...
Proposed FOPImage interface:
public interface FOPImage {
// init and load the image data
public FOPImage(URL href) throws FOPImageException;
// get image general properties
public int getWidth() throws UninitializedImageException;
public int getHeight() throws UninitializedImageException;
public String getURL() throws UninitializedImageException;
// get the image bytes, and bytes properties
// get compressed image bytes
public byte[] getCompressedImageBytes() throws UninitializedImageException;
public int getCompressedImageSize() throws UninitializedImageException;
public int getCompressionFilter() throws UninitializedImageException;
// get uncompressed image bytes
public byte[] getImageBytes() throws UninitializedImageException;
public int getImageSize() throws UninitializedImageException;
// to change the compression filter
public void compressImageBytes(int compressionFilter) throws
UnsupportedFilterException, UninitializedImageException;
// ? : the ColorSpace doesn't imply the bits per pixels ?
public int getBitsPerPixel() throws UninitializedImageException;
// DeviceGray, DeviceRGB, or DeviceCMYK
public ColorSpace getColorSpace() throws UninitializedImageException;
// For transparent images
boolean isTransparent() throws UninitializedImageException;
PDFColor getTransparentColor() throws UninitializedImageException;
// release memory
public void close();
}
_______________________________________
Eric SCHAEFFER
eschaeffer@posterconseil.com
POSTER CONSEIL
118 rue de Tocqueville
75017 PARIS
FRANCE
Tel. : 33-140541058
Fax : 33-140541059
_______________________________________
-------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com --------------------
Re: Image Support : need help
Posted by Sebastian Rahtz <se...@computing-services.oxford.ac.uk>.
> Yes, we need to know the aspect ratio. And I'd like to have the ability to
> only specify one size property in the XSL file (only width or only height).
> Maybe we could add a "keep aspect ratio" property, no ?
have you checked the FO spec? this is all there already
scaling="uniform"
is the default. the author can use
scaling="non-uniform"
to specify that the aspect ratio can be destroyed. the
"scaling-method" property will also be relevant to you, probably (I
cant find any way to implement it in my stuff)
Sebastian
Re: Image Support : need help
Posted by Eric SCHAEFFER <es...@posterconseil.com>.
----- Original Message -----
From: Stefano Mazzocchi <st...@apache.org>
To: <fo...@xml.apache.org>
Sent: Thursday, May 04, 2000 2:12 PM
Subject: Re: Image Support : need help
> Eric SCHAEFFER wrote:
> >
> > Ok, after a short discussion with Pankaj, here is the result.
> > But there's still some problems, and I don't have a clear vision on what
to
> > do.
> > Let's explain :
> >
> > - We need to know the real image size while creating the area tree, to
handle
> > width and height fo properties. The only way we found is to load the image
> > data.
>
> Agreed.
>
Yes, we need to know the aspect ratio. And I'd like to have the ability to
only specify one size property in the XSL file (only width or only height).
Maybe we could add a "keep aspect ratio" property, no ?
> > - If we load image data while creating the area tree (before writing the
PDF
> > stream), should we keep this data in memory or should we reload this data
> > later when needed ?
>
> I say, reloading later. Why? you don't need to read the whole image to
> get its properties. Most image formats I know store that property in the
> first chunk. So, in theory, just reading a few Kb is enough for every
> image.
>
Wasn't you that said "don't reinvent the wheel" ? :-)
Sure, it would be the best solution. But if we want to use image libraries
(Jimi, JAI, or others), I think we can't do that: image libraries need to load
the entiere image before knowing it's size.
shit :-(
> > - If we keep image data in memory, we should compress it. But then, in the
PDF
> > stream, the data are written compressed too. Should the FOPImage objects
> > return compressed data, or should the PDF stream writer handle compression
?
>
> The PDF should handle compression, IMO.
>
I was sure you would answer this...
> > The PDF compression filters are PNG and JPEG (and 3 others that I don't
> > understand: LZW, CCITTFax, RunLength).
>
> LZW is Lempel Ziv Welsh, the algorithm used by GIFs and patented by
> Unisys. Until 2003 we can't use this without paying. Cancel this out.
>
> CCITTFax is the algorithm used for duotone images (mostly faxes)...
> since it's almost useless on the web, I say we forget about it.
>
> RunLenght is the compression used in PCX image formats (for example) and
> uses the most trivial compression algorithm ever: instead of writing
> "AAAAAA" write "A6". It works great with flat colored bitmaps (great
> when computer displays had 16 colors or less), on true-color images it
> normally doubles the image size after compression. Result: ignore it.
>
> > That's a bit short, and maybe doesn't
> > cover all needs. Thus, it seems better that FOPImage objects return
> > uncompressed data, and that the stream writer compresses it if needed and
> > using a compression filter adapted.
>
> +1
>
> > Problem: compression -> decompression -> compression, and what compression
> > filter to use (JPEG has loss quality: it's better to use it if the image
was a
> > JPEG file, but then why so much compressions and decompressions).
>
> Note, JPEG is lossy on first pass, it's not a continously degradative
> filter. I mean: when you pass an image thru JPEG compression, it's
> evidently lossy (unless 100% quality is used and the loss-less algorithm
> is kicked in), but if you decompress it and compress it again (with the
> exact same code and parameters), it doesn't loose any more information.
>
> It is the equivalent of rounding a double to a float: first time you
> might loose information, but if you go back to double and back to float,
> you still have the same information.
>
Ok, but we should be able to avoid all this steps if it's not necessary.
But, this problem was raised by the need to keep data in memory...
> > On the other
> > hand, if FOPImage objects return compressed data, the compression filter
must
> > be understandable by PDF readers...
>
> This is why we should avoid this.
>
> > - Maybe we should use Java image classes. I don't know them enougth ot see
> > what class can be used, and what would be the benefits.
>
> I don't either :(
I find Java image API (awt, Jimi, JAI) a bit complicated...
>
> > If you have suggestions...
> >
> > Proposed FOPImage interface:
> >
> > public interface FOPImage {
> > // init and load the image data
> > public FOPImage(URL href) throws FOPImageException;
> >
> > // get image general properties
> > public int getWidth() throws UninitializedImageException;
> > public int getHeight() throws UninitializedImageException;
> > public String getURL() throws UninitializedImageException;
> >
> > // get the image bytes, and bytes properties
> >
> > // get compressed image bytes
> > public byte[] getCompressedImageBytes() throws
UninitializedImageException;
> > public int getCompressedImageSize() throws UninitializedImageException;
> > public int getCompressionFilter() throws UninitializedImageException;
> >
> > // get uncompressed image bytes
> > public byte[] getImageBytes() throws UninitializedImageException;
> > public int getImageSize() throws UninitializedImageException;
> >
> > // to change the compression filter
> > public void compressImageBytes(int compressionFilter) throws
> > UnsupportedFilterException, UninitializedImageException;
> >
> > // ? : the ColorSpace doesn't imply the bits per pixels ?
> > public int getBitsPerPixel() throws UninitializedImageException;
> >
> > // DeviceGray, DeviceRGB, or DeviceCMYK
> > public ColorSpace getColorSpace() throws UninitializedImageException;
> >
> > // For transparent images
> > boolean isTransparent() throws UninitializedImageException;
> > PDFColor getTransparentColor() throws UninitializedImageException;
> >
> > // release memory
> > public void close();
> > }
>
> Sounds good to me on first pass, but I should play around with it on
> real life to get a true impression... unfortunately I don't have time
> for that. :/
>
If we don't keep data in memory, we don't need neither the "close()" method
nor the "UninitializedImageException". We would just have to recover image
properties when creating the FOPImage object (width, height, color space,
transparency).
Maybe the best solution would be to be able to return the binary image data
(the real file content, without any transformation) and the uncompressed image
data (the bitmap).
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
> Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------
>
>
Re: Image Support : need help
Posted by Stefano Mazzocchi <st...@apache.org>.
Eric SCHAEFFER wrote:
>
> Ok, after a short discussion with Pankaj, here is the result.
> But there's still some problems, and I don't have a clear vision on what to
> do.
> Let's explain :
>
> - We need to know the real image size while creating the area tree, to handle
> width and height fo properties. The only way we found is to load the image
> data.
Agreed.
> - If we load image data while creating the area tree (before writing the PDF
> stream), should we keep this data in memory or should we reload this data
> later when needed ?
I say, reloading later. Why? you don't need to read the whole image to
get its properties. Most image formats I know store that property in the
first chunk. So, in theory, just reading a few Kb is enough for every
image.
> - If we keep image data in memory, we should compress it. But then, in the PDF
> stream, the data are written compressed too. Should the FOPImage objects
> return compressed data, or should the PDF stream writer handle compression ?
The PDF should handle compression, IMO.
> The PDF compression filters are PNG and JPEG (and 3 others that I don't
> understand: LZW, CCITTFax, RunLength).
LZW is Lempel Ziv Welsh, the algorithm used by GIFs and patented by
Unisys. Until 2003 we can't use this without paying. Cancel this out.
CCITTFax is the algorithm used for duotone images (mostly faxes)...
since it's almost useless on the web, I say we forget about it.
RunLenght is the compression used in PCX image formats (for example) and
uses the most trivial compression algorithm ever: instead of writing
"AAAAAA" write "A6". It works great with flat colored bitmaps (great
when computer displays had 16 colors or less), on true-color images it
normally doubles the image size after compression. Result: ignore it.
> That's a bit short, and maybe doesn't
> cover all needs. Thus, it seems better that FOPImage objects return
> uncompressed data, and that the stream writer compresses it if needed and
> using a compression filter adapted.
+1
> Problem: compression -> decompression -> compression, and what compression
> filter to use (JPEG has loss quality: it's better to use it if the image was a
> JPEG file, but then why so much compressions and decompressions).
Note, JPEG is lossy on first pass, it's not a continously degradative
filter. I mean: when you pass an image thru JPEG compression, it's
evidently lossy (unless 100% quality is used and the loss-less algorithm
is kicked in), but if you decompress it and compress it again (with the
exact same code and parameters), it doesn't loose any more information.
It is the equivalent of rounding a double to a float: first time you
might loose information, but if you go back to double and back to float,
you still have the same information.
> On the other
> hand, if FOPImage objects return compressed data, the compression filter must
> be understandable by PDF readers...
This is why we should avoid this.
> - Maybe we should use Java image classes. I don't know them enougth ot see
> what class can be used, and what would be the benefits.
I don't either :(
> If you have suggestions...
>
> Proposed FOPImage interface:
>
> public interface FOPImage {
> // init and load the image data
> public FOPImage(URL href) throws FOPImageException;
>
> // get image general properties
> public int getWidth() throws UninitializedImageException;
> public int getHeight() throws UninitializedImageException;
> public String getURL() throws UninitializedImageException;
>
> // get the image bytes, and bytes properties
>
> // get compressed image bytes
> public byte[] getCompressedImageBytes() throws UninitializedImageException;
> public int getCompressedImageSize() throws UninitializedImageException;
> public int getCompressionFilter() throws UninitializedImageException;
>
> // get uncompressed image bytes
> public byte[] getImageBytes() throws UninitializedImageException;
> public int getImageSize() throws UninitializedImageException;
>
> // to change the compression filter
> public void compressImageBytes(int compressionFilter) throws
> UnsupportedFilterException, UninitializedImageException;
>
> // ? : the ColorSpace doesn't imply the bits per pixels ?
> public int getBitsPerPixel() throws UninitializedImageException;
>
> // DeviceGray, DeviceRGB, or DeviceCMYK
> public ColorSpace getColorSpace() throws UninitializedImageException;
>
> // For transparent images
> boolean isTransparent() throws UninitializedImageException;
> PDFColor getTransparentColor() throws UninitializedImageException;
>
> // release memory
> public void close();
> }
Sounds good to me on first pass, but I should play around with it on
real life to get a true impression... unfortunately I don't have time
for that. :/
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------