Am Thursday 28 June 2007 schrieben Sie: > Dominik Seichter wrote: > > Totally makes sense! Now I wonder way I overlooked this issue all the > > time :) Thanks for pointing it out. > > Some of the rest of the PoDoFo code assumes that documents can support > operations that may not be possible with all kinds of documents. > > This makes it less than trivial to abstract the two document types. It > doesn't help that PdfStreamedDocument seems to be a partial wrapper > around PdfDocument that only exposes some methods. Intentionally? Or are > they just things added to PdfDocument after PdfStreamedDocument was > created, or stuff you didn't need and didn't get around to? Some of them > are obvious (LoadDocument doesn't make sense with a PdfStreamedDocument > for example) but many missing ones are not. I think most of them have been forgot. Other's like direct access to the PagesTree do not make much sense for a streamed document. But this is right now IMHO the biggest problem of the currect architecture: It is very hard to keep PdfDocument and PdfStreamedDocument in sync as methods are usually added to PdfDocument and forgotten in PdfStreamedDocument. PdfDocument::Append for example would also make sense in a PdfDocument in my opinion.
So a common interface would make sense to keep both classes in sync for the
PoDoFo developers and application developers could work with both classes not
caring which one they use for real.
PdfStreamedDocument in its current shape is my fault. I started it to
implement the immediate writing out of streams while reworking the filter
architecture. This parts works quite well, I think, but I did not get to all
the other stuff.
Some methods like ::Append could even be implemented in the high-level
PdfDocument other might need an implementation in PdfMemDocument and
PdfStreamedDocument. I think a common base class (i.e. something more than an
interface, but still with some pure virtual methods) should be doable. So
your approach for fundamental refactoring sounds good to me. But it might
require some major changes to PdfDocument (= PdfMemDocument) itself.
PdfElements do not work at the moment (apart from images which work as far as
I know). The only reason that they do not work is that appropriate
constructors are missing for PdfStreamedDocument. A common base class should
fix this problem. As all PdfElements operate directly on PdfObjects there
should be no technical reasons why they should not work on
PdfStreamedDocuments. I added support for PdfFields together with
PdfStreamedDocuments a minute ago, hope this is helpful to you.
Well this is going to become a major change. What do you think: Fix it now and
include it into the 0.5 release or do a release now and fix it afterwards.
As you are porting to Scribus right now, I leave this up to your decision. In
my opinion the fixed PdfDocument issue, and the fixed memory issues would
make up a nice 0.6 release.
But getting Scribus to use PoDoFo would be the killer-app for PoDoFo. So I
will support you in any way while doing the port
best regards,
Dom
> It's not immediately clear what is and is safe or possible with a
> PdfStreamedDocument as compared to an ordinary PdfDocument. I'm also not
> really sure it makes sense to implement PdfStreamedDocument using
> PdfMemDocument; maybe they need to be more fundamentally refactored:
>
> - Rename PdfDocument to PdfMemDocument
> - Put methods and data members that are common between, and make sense
> for both of, PdfMemDocument and PdfStreamedDocument into `PdfDocument'
> - remove the dependency of PdfStreamedDocument on PdfMemDocument and
> make it inherit PdfDocument instead.
>
> Unfortunately, this is quite a bit more work and more importantly will
> require a bunch of analysis of the code for me to figure out how
> streamed documents are supposed to work, what's possible and what's not,
> etc.
>
> Also, right now it looks like few if any PdfElement based tools will
> work on them, meaning streamed documents cannot be used if the
> application writer wants to use any of PoDoFo's higher level features.
> Have I understood that correctly? If so, any ideas on how it might be
> possible to fix that problem?
>
> Some general information on what can and cannot be done with streamed
> documents vs memory documents would be extremely useful. Right now it's
> pretty confusing for me as I try to use PoDoFo to re-implement PDF
> export in Scribus - and I've been working on the library for a while.
> Streamed output support is there, but seems highly impractical to use
> for non-trivial cases.
>
> --
> Craig Ringer
--
**********************************************************************
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
**********************************************************************
pgpFymsl6Cuay.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
_______________________________________________ Podofo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/podofo-users
