pdf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pdf-devel] Streams solution proposal


From: jemarch
Subject: Re: [pdf-devel] Streams solution proposal
Date: Sat, 04 Oct 2008 20:18:06 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

   Done, patch attached. I also fixed a bug un pdf_stm_read that lead to an
   infinite loop on small cache sizes (and deleted the buggy
   pdf_stm_filter_set_be statment in pdf_filter_file_new).

Many thanks. I just applied the patch to the trunk. pdf-filter is now
much better!

   There is another issue that I did not change but I think that should be
   changed. pdf_flush (stm, PDF_TRUE) is called from pdf_stm_destroy. I
   think that that behaviour is wrong, because twoo many ending characters
   are printed if the user manually calls pdf_flush (stm, PDF_TRUE).

Hmm. AFAIK the implementation should not emit more characters in that
case. If it does that then it is a bug.

For me it makes sense to call flush into pdf_stm_destroy: it is
what you get when you call fclose, for example.


   Instead, I think that we can automatically force a FINISH on
   EOF. That would also allow printing the trailing characters when playing
   on read mode -I think that the current behaviour of never finishing on
   read mode is quite wrong).

Hmm. Consider that you want to ahex encode 20mb of data. You want to
do it in chunks of 4k, so you call pdf_stm_write (my_buf, 4k). The
internal filter chain will consume any output from 'my_buf' until it
generates an EOF condition, but we certainly dont want to finish the
filters at that point...

I am not sure if I am understanding you. What EOF are you talking
about?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]