On 19.09.2008 15:38:21 Jean-François El Fouly wrote: > Jeremias Maerki a écrit : > > Right, that's the downside of Image I/O. But then, the XML-based approach > > to metadata is also very powerful. > > > > > I'm not sure I understand. Am I missing something ? > The images I (pre) process will be used by FOP somewhere downstream. > And, as far as I understand, FOP uses the PHYS metadata for its layout.
Indirectly, yes. > That's why I have been through considerable effort to give these > metadata sensible values. Ok, makes sense. Here's an example that uses Image I/O to produce a PNG including resolution information: https://svn.eu.apache.org/viewvc/xmlgraphics/commons/trunk/src/java/org/apache/xmlgraphics/image/writer/imageio/ImageIOImageWriter.java?view=markup Maybe that helps to understand how Image I/O does this. Another alternative: If you only need the resolution right, you can just as well use Common's ImageWriter which is great for just quickly save an image with control over the most important features: https://svn.eu.apache.org/viewvc/xmlgraphics/commons/trunk/examples/java/image/writer/ImageWriterExample1.java?view=markup > > Another option that would give you a lot of control but possibly with a > > simpler API is Apache Sanselan (incubating). > > http://incubator.apache.org/sanselan > > > > > Interesting, did'nt know of this project. > But the project I work on uses and embeds FOP and its dependencies, so I > guess it makes sense to use xmlgraphics-commons whenever possible. Sure, whatever you think works best for you. Just listing alternatives. Jeremias Maerki --------------------------------------------------------------------- Apache XML Graphics Project URL: http://xmlgraphics.apache.org/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
