On Sun, 2002-04-28 at 18:08, Drew Varner wrote: > 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 =-) >
*shrugs* discussion is always fine when its intellectual. (We try to avoid the Apache trademark flamefests a bit more around here) > > 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. > Swing still calls X (via AWT). Swing is on top of AWT basically in many respects (yes you don't have the native peers for everything but lots of things in swing just pass through to AWT) > > 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. > Well if there was an HIF for playing with windows-specific-images (seperating the concern of decoding the Image), I'd not really care too much if was tied to X. You'd want to make it as untieable and well encapsulated as possible but what we want to avoid is having HPSF or HSSF or HDF call X but if there was a general port of WMF or DIB or whatever then it could be tied to X. (Or at least until I needed it untied and got around to untying it) > > 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 > Right, and it would be nice to have a library for POI to parse WMF. > > Just Jakarta = Server-side java. > > I agree. See above. > Well the trick here is that a Server might NOT have a GUI. Only really CRAPPY sorry excuses for 32-bit extensions to 16-bit shells for 8 bit operating systems originally written for 4 bit processers by 2 bit company trying to pass themselves off as server operating systems guarantee you a GUI. Granted in 2 years it wont make no nevermind anyhow. (1.4.x) > > 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. > But you need to not import java.awt.** in order to accomplish this. Probably the best thing is to dynamically load YOUR class rather than the AWT class. Better yet have the class available take in the bytestream and create the image. That seems to separate the concerns nicely. > > 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. > eh? > 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? > +/- - What I think would be optimal is having a windows specific image library under POI in its own package. It could be tied to awt until someone scratches the itch. Anyhow, don't tie HPSF/HDF/HSSF/POIFS to AWT and my objections are satisfied. Even if its by providing methods for optionally loading thats fine. Just test and make sure. Thats all I care about. (that and that we don't end up with GUI apps in the mainstream of things). -andy > - Drew > ___________________ > Drew Varner > [EMAIL PROTECTED] -- http://www.superlinksoftware.com http://jakarta.apache.org/poi - port of Excel/Word/OLE 2 Compound Document format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh
