Same ol' image pitch again

[PN...@directsourcing.com]

Hi All

A few days ago we(me and Eric) debated on the issue of whether to analyse
the images header for the image type. Now I am sure we need to analyse. I
checked out the latest and greatest code today. Here is a snippet from the
FopImageFactory.java. This code works perfectly as long as the file it
retrieves has an extension with it in its filename. There are two problems
with this approach, what if the image file doesn't have an extension(this
code returns a mime type of application/octet-stream), the second case is a
more problematic one, if the extension given to the file is wrong one e.g. a
jpg is stored as a.gif. I tested this code on the Personal Web Srever. I am
sure other webservers would give the same result.


try {
  URLConnection url_conn = absoluteURL.openConnection();
  contentType = url_conn.getContentType();
} catch (IOException e) 

For the time being this is good, but it's not fool proof :-) Tell me what do
u guys think. I also glanced over PDFBinaryStream . Great thing to put in
fop. I have a small suggestion, the reason we used the HexEncode or
ASCII85Encode in the code was that we were not putting any binary data in
the pdf. But now that we have the ability to put Binary data in the pdf, I
don't think there is a need to HexEncode the image file. We can directly put
the binary data in the pdf.  

Comments any one?


Pankaj Narula
502-326-4426 (Office)