I am taking up too much mailbox space with my philosophy here, so I'll take it offline for anyone interested in the discussion. The truth is it isn't a big deal. Sorry folks =-)
Quoting "Andrew C. Oliver" <[EMAIL PROTECTED]>: > > <rant> > > Now, passing around a WMF image as a byte[] is really useless. If POI > is "for > > manipulating various file formats based upon Microsoft's OLE 2 > Compound > > Document format using pure Java" (POI Purpose - Web Page), we don't > > allow the > notice this doesn't say "Display" Agreed. I don't think POI is responsible for displaying images. I focus on manipulate. I'd probably return an instance of BufferedImage, which is just an image in memory. Now we have access to all of Java's methods for manipulating images (scaling, transforming to other formats, drawing on, etc.). I only know how to write against AWT, Java2D and Java Advanced Imaging. I have never used Swing in my life, and I am in no hurry to start. > > user to do this with thumbnails. Yes, they can "manipulate" the WMF > image by > > copying it or saving it, but those are not useful manipulations. Wait, > those > > are not manipulations. Seems like keeping a WMF image in a byte[] is > keeping a > > Microsoft file in a format Java can't understand. Isn't the purpose of > POI to > > allow Java to "understand" Microsoft formats? I see some irony here. > We could > > simply pass an Excel file around as a byte[], right? But, that has > already been > > decided, so... > > </rant> > > Well WHAT can you do with the WMF? The POI kind of thing to do with it > would be to read one and provide an API for manipulating it, create one > from scratch and provide an API for manipulating it. But I agree this > seems to be basically a Batik overlap and maybe we can just depend on > Batik for graphic formats and POI can do the specifics for storing it > for a given format. (Storing an image in HSSF is non-trivial). See above for what I think manipulation of an image is (scale, rotate, transform, etc.). Mainly, you should be able convert it to another format, a Java-friendly format. We don't return other properties as ULONGs or *voids. Jakarta has a strong server-based lean. A M$-specific vector-based format doesn't have a role in a server environment. SVG would be a nice fit. However, SVG rendering is via plugin on most browsers. However, Java can write PNGs and JPEGs. It seems to me allowing us to transform WMF into server and Java- friendly images images is good. > POI isn't an API for viewing the formats, its for creating, parsing, > modifying. Go write a Spreadsheet and use POI for the Excel > compatibility for instance. We're not really here to make GUI apps. I agree. However, POI can't parse WMF. It understands nothing about it. We can't modify it (unless we map it to an image). Someone will need this sort of functionality for charting I'd think > Just Jakarta = Server-side java. I agree. See above. > Remember POI's being used by Banks and other folks on servers > that may or may not be graphical in nature. In fact one gentleman is > using it on an AS400 and would have to serial to a PC to call to AWT for > instance. Saying 1.4 will fix it all is a bit well...improper. Most > folks won't be switching (and rightly so) to 1.4 until its had time to > bake (read: they fix all the really STUPID bugs). Just because this is > not a requirement for you doesn't mean its not important. You speak of > reinventing the wheel, I'm willing to reinvent the wheel to be round > instead of square (like the one Sun seems to have invented in this > case). It seems that if I use dynamic class loading in methods with AWT dependencies, the man at the bank will never know the difference. Now, if he calls a method to transform it to a java.awt.BufferedImage, he'll know it. Otherwise, he won't. Should we give him he choice? I generally don't like dynamic class loading, but this seems like a good case for it. > Keep coding and having fun. Chin up > its only life. No problem. It seems by going through this exercise I'll be in a better position to know how to do the conversions anyway. There is no question that "I" can extract thumbnails, modify them, etc. So, the discussion from my point of view is academic. I'd be surprised if anybody accesses a thumbnail via the API. It just seems to go with the "spirit" of the project, though I understand people tend to lose their mind when you break their code, and I can't blame them. In the end, I think the important thing is that a user does not have a dependency against Batik to manipulate thumbnails. I think the best answer is moving it to the Commons. This will allow both projects to use the tool. It'd be useful in many other applications (CAD, drawing, format conversion tools, UML tools etc.) for importing WMFs that might not want to depend on huge JARs for simple image conversion. The solution is probably administrative (talking to Batik folks) rather than coding. And, it doesn't affect me, I just enjoyed the discussion. Now, folks with grand schemes for a Java-based spreadsheet might think more of my theories down the road. Agreed? - Drew ___________________ Drew Varner [EMAIL PROTECTED]
