J.Pietschmann wrote: > The problem is that some stock image readers only accept a > stream with the pointer at the begin of the content, and if > the stream pointer can't be reset (e.g. if the analyser > needed so much info that the underlying implementation > already discarded buffers), then the stream has to be reopened. > > If you want to donate an intelligent buffering system....
BufferedInputStream (and all InputStreams) have mark() and reset() functions which should work for this. I rather thought that the developer maybe didn't want to leave the stream open in between layout and rendering, but I don't know. WRT "intelligent" buffering system, I wrote one for my font work, based on java.io.RandomAccessFile with a wrapper of my own that allows you to read in bigger chunks at a time with a kind of window that slides back and forth over the file contents. I haven't looked at the ImageReader subclasses to know whether they really need a random-ish approach or whether resetting the Stream would be sufficient. If you are interested, the source is here (the inner class ByteSearcher is where the sliding window is managed): http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-common/src/java/org/ foray/common/RandomReader.java?view=markup I don't really have a good feel for how efficiently this works. It seems to work pretty well, but I haven't profiled it. Of course, FOP is always welcome to this code. Also, if Irv does donate some other intelligent buffering system, he needs to understand that the FOP developers won't use it unless it is written for the head/trunk. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
