Re: PDF library refactoring
Then, I guess, you'll be happy now after the patch this morning. :-) On 28.03.2003 20:45:57 J.Pietschmann wrote: > Jeremias Maerki wrote: > >>I noticed that the default filter is now no filter. > > > > Was it different before??? > Yes, if no filter was defined in config.xml, flate was used > (hardcoded). I found this annoying while debugging, because > there were no noop-filter. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF library refactoring
Jeremias Maerki wrote: I noticed that the default filter is now no filter. Was it different before??? Yes, if no filter was defined in config.xml, flate was used (hardcoded). I found this annoying while debugging, because there were no noop-filter. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF library refactoring
On 28.03.2003 04:19:30 Keiron Liddle wrote: > > These changes are in CVS (redesign) now. > > > > I've also introduced a dependency on Jakarta Commons IO, mainly because > > of the CountingOutputStream needed for on-the-fly stream output. It also > > contains several utility methods (such as for stream copy) that also > > exist in out codebase. I'd like to remove ours over time. Help is > > welcome. I hope you guys don't mind that I have done this. I will revert > > if anyone objects, but I think it makes sense to use the Commons classes. > > I still need to update the build to create that all-in-one PDF > > transcoder. > > I seems to be working well. Good stuff. > I noticed that the default filter is now no filter. Is that intended? The FOP and > the > PDF transcoder will probably want to set at least flate compression. Was it different before??? I always had no filter as default. Anyway, it wasn't intended. Just still on the todo list. :-) I'll do that today. > > I've also updated the Gump descriptor for the new dependency. I hope it > > works. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF library refactoring
> These changes are in CVS (redesign) now. > > I've also introduced a dependency on Jakarta Commons IO, mainly because > of the CountingOutputStream needed for on-the-fly stream output. It also > contains several utility methods (such as for stream copy) that also > exist in out codebase. I'd like to remove ours over time. Help is > welcome. I hope you guys don't mind that I have done this. I will revert > if anyone objects, but I think it makes sense to use the Commons classes. > I still need to update the build to create that all-in-one PDF > transcoder. I seems to be working well. Good stuff. I noticed that the default filter is now no filter. Is that intended? The FOP and the PDF transcoder will probably want to set at least flate compression. > I've also updated the Gump descriptor for the new dependency. I hope it > works. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: PDF library refactoring
These changes are in CVS (redesign) now. I've also introduced a dependency on Jakarta Commons IO, mainly because of the CountingOutputStream needed for on-the-fly stream output. It also contains several utility methods (such as for stream copy) that also exist in out codebase. I'd like to remove ours over time. Help is welcome. I hope you guys don't mind that I have done this. I will revert if anyone objects, but I think it makes sense to use the Commons classes. I still need to update the build to create that all-in-one PDF transcoder. I've also updated the Gump descriptor for the new dependency. I hope it works. On 19.03.2003 21:42:48 Jeremias Maerki wrote: > A little heads up: As I've announced I did some refactoring on the PDF > library. As life goes it got pretty extensive. I've cleaned a lot of > stuff, more centralized und uniform behaviour, improved logging > (PDFDocument makes the logger available to all child objects) etc. I > also hope that my changes are somewhat preparatory for the "parse PDF" > task. > > The refactoring allows me now to easily implement on-the-fly stream > encoding. That means the stream doesn't have to be encoded from a > StreamCache (byte buffer) to another byte buffer. That was previously > necessary to calculate the length of the encoded stream. This value was > included in the object's dictionary (/Length). By using an indirect > object (4.10 in the PDF 1.3 specs) I can encode the raw stream on-the-fly > using a chain of FilteredOutputStreams to the PDF file. The length is > later added as a separate PDFNumber object. > > I quickly tested the new runtime behaviour and I got from 4350KB down to > 2277KB (Total memory used as calculated in the LayoutHandler) on a 1.1MB, > two-page PDF (image-intensive). Time used went up from average 2.5sec to > 3.1sec, but when I used a BufferedOutputStream it was around 2.4sec. > (Disclaimer: I didn't account for JVM warm-up! It was just a quick test.) > > Theoretically, it would now also be possible to pipe a (JPEG image) > stream right through FOP without having to buffer the raw stream in > memory or in a temp file. But doing that is not on my todo list right > now. > > I still need to tackle the last few methods. Then it's testing time. And > when I'm done that'll be a rather big commit. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
