Comments below. -----Original Message----- From: Joerg Pietschmann [mailto:[EMAIL PROTECTED]] Sent: March 18, 2002 12:09 PM To: FOP Dev Subject: URI resolving
[ SNIP ] The fo:externalGraphics handling code would somehow have to decide whether the graphics is XML and invoke theXMLURIResolver.resolve(), otherwise call theBinaryStreamURIResolver.resolve() directly. (It may be an idea to provide an additional layer for character sources like PostScript) I'm not quite sure how FOP decides how to handle a certain input for an external-graphic, i have faint memories that it first looks at the content-type attribute and if there is none, it tries to guess a content type from the URL. It may be an idea to give the user hooks for this two mappings as well (content-type -> content handler and URL -> content type). [ SNIP ] -----End of Original Message----- Hi, Joerg I snipped out the part that dealt with URI resolution; this is obviously important, but since we have a 2-part problem - WHERE is the image and WHAT is it - I'd rather deal with the WHAT first. Which is why I presently addressing the above comments of yours. However FOP does it now, all I know is that I personally distrust external information - content-types and what have you. Let's keep in mind that although we are using URI terminology a lot of these are going to be file: URLs and the path of the file is going to be just about all we have to work with. The file extension is reliable enough that it can be used for a first guess but that is about it. But my current thought process is that FOP doesn't worry about the WHAT at all - that's what the image library is for. I came across this excellent list that Marco Schmidt has created: http://www.geocities.com/marcoschmidt.geo/java-image-coding.html. Seems to me that with this embarrassment of image-library riches all we should have to do is define a simple interface that image readers must follow, and that we then can write adapters that target some of the more useful libraries, as required. From my viewpoint we'd be doing a good job if we can write FOP-side code that doesn't even know what a JPEG or PNG or WMF or anything else is. If the library of choice can't tell us that much, nor tell us about the basic geometry that we need for layout, then what good is it? This may turn out to be too simplistic and naive but I hold it up as a desirable target. I have to research libraries that are available, and do some coding and testing, to see if I am just talking through my hat, but I'd sure like to see a situation where format-specific FOP classes disappear. URI resolution is another matter. I haven't put any thought into it, other than having read your comments. The one thing I'd mention right now is that we need to look at how the available libraries expect to see image input. Again, if most of the otherwise useful ones tend to fall short in this area then we can always write adapters - which can be the same classes as the adapters mentioned above. Regards, Arved Sandstrom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
