I think I forgot to add: Especially PdfRefCountedBuffer could be replaced by a real memory output stream device.
Dom
Am Monday 12 November 2007 schrieb Dominik Seichter:
> 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
**********************************************************************
pgpr49gDDGdDj.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
