[Top][All Lists]
[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?