xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Art Welch <ar...@EASTPOINT.COM>
Subject RE: FopImage interface - proposal
Date Tue, 19 Dec 2000 19:27:50 GMT
Good! I think that we should evaluate JDK 1.1 support often, because I know
that as soon as I am able to move to 1.2+ I will probably switch to the
"abandon 1.1" camp.

I agree that abandoning 1.1 would make some things easier. However, I am
fairly sure that I (and my customers) are not the only FOP users stuck with
JDK 1.1 (or am I???). As long as I am stuck with JDK 1.1, I will attempt to
maintain as much FOP functionality as possible in that environment. As I
have said in the past - I would not want 1.1 support to be a major hindrance
to FOP.

I strongly suspect that further image support (especially using the Java
image stuff) will not be able to be supported with JDK 1.1 (Like the AWT and
non-BMP image stuff). Would it be possible for the new image stuff to be
contained, so that it could be included or not depending on environment like
we do now with AWT, etc? Could this be a configuration thing?

Art
(What is that writing on the wall?)

-----Original Message-----
From: Eric SCHAEFFER [mailto:ESCHAEFFER@Techmetrix.net]
Sent: Tuesday, December 19, 2000 5:28 AM
To: fop-dev@xml.apache.org
Subject: RE: FopImage interface - proposal


Hum, we're going to discuss about this again ;)

Do we (really) need to maintain JDK1.1 compatibility ? I know you use it,
and can't go on JDK1.2, but I can't work on images with both JDK in mind. I
don't have so much time, I don't understand all the Java image stuff, and
try to make it work with the PDF spec. 
Maybe it's possible to make it work with both JDK, but I can't check. If
someone using JDK1.1 can work on it with me, that would be great.

We really need to use Java native classes (I think), because it makes the
image package independant from PDF stuff, and the other renderers (AWT)
would use it (if the PDFRenderer needs byte array, the AWTRenderer doesn't).
Maybe I'm wrong, and using just an int array would be enougth. But that can
make FopImage classes more difficult to create, and image support more
difficult to implement (ColorSpace, Transparency, etc.).

Eric.

Cordialement,
Eric SCHAEFFER

Consultant TechMetrix Research
http://www.techmetrix.net
Groupe SQLi
http://www.sqli.com
Créateurs de sites intelligents depuis 1995

FOP, the first XSL:FO processor
http://xml.apache.org/fop/ 

> -----Message d'origine-----
> De: Art Welch [mailto:art_w@EASTPOINT.COM]
> Date: lundi 18 décembre 2000 20:35
> À: 'fop-dev@xml.apache.org'
> Objet: RE: FopImage interface - proposal
> 
> 
> I have not looked very closely at the proposal, but I am 
> curious if you
> foresee any problems with maintaining JDK 1.1 support. I know 
> that the Java
> image support was expanded significantly from 1.1 to 1.2. If 
> we use native
> Java classes for image stuff, could this be a problem?
> 
> Just want to know all the implications,
> Art
> 
> P.S. Otherwise it looks good to me so far.
> 
> -----Original Message-----
> From: Eric SCHAEFFER [mailto:ESCHAEFFER@Techmetrix.net]
> Sent: Monday, December 18, 2000 8:47 AM
> To: fop-dev@xml.apache.org
> Subject: FopImage interface - proposal
> 
> 
> Hi,
> 
> Here is my proposal for the image package.
> 
> In fact, I remove dependencies with PDF stuff. The FopImage 
> implementing
> classes return image data as a BufferedImage (I like it 
> because it contains
> everything, but it could be a RenderedImage), and can give 
> access to the
> image InputStream to include the image content "asis".
> The only properties that this interface provides and gives 
> access to is the
> image Mime Type, and the image size (width and height in pixels).
> Maybe we could include properties like dpi, if supported by the image
> type...
> 
> The "filter" support, or the decision to include the image directly
> ("asis"), is delegated to the formatter (PDF, AWT, etc...)
> 
> What do you think about it ? I'm not sure on what Java class to use:
> BufferedImage, RenderedImage, Raster, ...
> 
> 
> package org.apache.fop.image;
> 
> // Java
> import java.io.InputStream;
> import java.net.URL;
> 
> // Java AWT
> import java.awt.image.BufferedImage;
> 
> /**
>  *  Used to manipulate images in FOP. Implementing classes 
> should provide
>  *  constructors: <BR>
>  *  <UL>
>  *    <LI>public FopImage(URL href) throws FopImageException;
>  *    <LI>public FopImage(URL href, ImageReader imgReader) throws
> FopImageException;
>  *  </UL>
>  *
>  * @author     <A href="eschaeffer@emahoo.com">Eric SCHAEFFER</A>
>  * @created    18 décembre 2000
>  */
> public interface FopImage {
> 	/**
> 	 *  Return the URL of the image.
> 	 *
> 	 * @return    The URL of the image
> 	 */
> 	public URL getURL();
> 
> 
> 	/**
> 	 *  Gets the Width of the image.
> 	 *
> 	 * @return                        The image's width
> 	 * @exception  FopImageException  when error occures
> 	 */
> 	public int getWidth() throws FopImageException;
> 
> 
> 	/**
> 	 *  Gets the Height of the image.
> 	 *
> 	 * @return                        The image's height
> 	 * @exception  FopImageException  when error occures
> 	 */
> 	public int getHeight() throws FopImageException;
> 
> 
> 	/**
> 	 *  Gets the Image data, as a BufferedImage.
> 	 *
> 	 * @return                        The Image data
> 	 * @exception  FopImageException  when error occures
> 	 */
> 	public BufferedImage getImage() throws FopImageException;
> 	/*
> 	 * or
> 	 * public RenderedImage getImage() throws FopImageException;
> 	 */
> 
> 	/**
> 	 *  Gets the InputStream used to read the image data.
> 	 *
> 	 * @return                        The InputStream of the image
> 	 * @exception  FopImageException  when error occures
> 	 */
> 	public InputStream getInputStream() throws FopImageException;
> 
> 
> 	/**
> 	 *  Gets the MimeType associated with the image type.
> 	 *
> 	 * @return                        The MimeType of the image
> 	 * @exception  FopImageException  when error occures
> 	 */
> 	public String getMimeType() throws FopImageException;
> }
> 
> Cordialement,
> Eric SCHAEFFER
> 
> Consultant TechMetrix Research
> http://www.techmetrix.net
> Groupe SQLi
> http://www.sqli.com
> Créateurs de sites intelligents depuis 1995
> 
> FOP, the first XSL:FO processor
> http://xml.apache.org/fop/ 
> 

Mime
View raw message