Hi, I think the problem is fixed by your patch you sent later in this thread. I commited it for this reason.
Some time ago, I tried to fix PdfOutputDevice and PdfInputDevice. Currently it
is sometimes really hard to even say what is expected behaviour and what is
not. For this reason it is really hard to fix both classes and create for
example an PdfIODevice from which we can read and write to at the same time.
To clarify, I hope you meant this two classes when talking about replacing
them by a mature "streams" framework, because I think PdfInputStream and
PdfOutputStream subclasses are quite fine for their purpose. Pdf*Stream is
usually only a small wrapper around a real API or PdfInputDevice or
PdfOutputDevice. So I hope we can keep theese and you agree they are fine.
We are writing a PDF library here and as you told before we're reinventing the
wheel with our input and output devices. As it is my aim to write a PDF
library and not to reinvent wheels I do not think we should fix
PdfOutputDevice and PdfInputDevice. It would be a waste of time.
Ok, so we are going to replace two core classes of PoDoFo. I think this should
be done in a branch first so that we do not break anything. Especially if
other people would like to work on other stuff (rendering? :) ).
With what are we going to replace them. Well, Qt has nice IO classes but it is
not an option for PoDoFo in any way. So from what I see boost remains as the
only option. I only had a quick look at the boost.IOStreams classes and they
look nice from what we need. (I am eager to see if memory mapped IO could
increase PDF parsing performance!)
From what I see we would get another library as dependency from using boost
streams. Right? Well, I am not a friend of yet another dependency and one
Company at which I am currently integrating PoDoFo into a new product would
not be happy either (they were not too happy that PoDoFo brought this strange
new dependency STL with it .... so well .... I do not think we should care).
But better a new dependency than wasting our time.
To sum up: I think we should try replacing PdfInputStream and PdfOutputStream
with classes from boost in a new branch. I am not yet sure wether we should
wrap them in a PdfIOStream class or use them directly? From a Software
Engineering point of view, wrapping them sounds like a good idea. This way we
could support different output stream libraries and keep boost maybe as an
optional dependency.
What do the others think? Does this all make sense?
best regards,
Dom
PS: My girlfriend would be angry at you if she knew ... I am about to meet her
in cinema in a few minutes and all I will think about is the PoDoFo IO
Streams implementation. Beeing a geek can be hard at times :)
Am Monday 12 November 2007 schrieb Craig Ringer:
> Hi
>
> The test fail in DeviceTest is caused by PdfOutputBuffer starting
> writing at the beginning of a PdfRefCountedBuffer that already contains
> data, where DeviceTest assumes it'll begin appending at the end of the
> data that's already there.
>
> Any idea which the rest of the code expects? Which do you think is best?
> The existing behaviour (open existing and clobber) or the tested-for
> behaviour (open existing for append)?
>
> I would really like to look at a mature "streams" framework like the
> Boost one, because we're doing a lot of wheel reinventing in this area.
>
> --
> Craig Ringer
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Podofo-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/podofo-users
--
**********************************************************************
Dominik Seichter - [EMAIL PROTECTED]
KRename - http://www.krename.net - Powerful batch renamer for KDE
KBarcode - http://www.kbarcode.net - Barcode and label printing
PoDoFo - http://podofo.sf.net - PDF generation and parsing library
SchafKopf - http://schafkopf.berlios.de - Schafkopf, a card game, for KDE
Alan - http://alan.sf.net - A Turing Machine in Java
**********************************************************************
pgpJfdOmEexmN.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ Podofo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/podofo-users
