> To use the pdf_[i|u](32|64)_t data types instead of int or long would
> help a lot to avoid this kind of problems. Would be possible to make
> the filter to use the fixed-wide data types?
>
I actually think that is the right way of solving the problem. I will
send a patch ASA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
> To use the pdf_[i|u](32|64)_t data types instead of int or long would
> help a lot to avoid this kind of problems. Would be possible to make
> the filter to use the fixed-wide data types?
>
I actually think that is the right way of solving the
> I don't know if you already solved the problem, but after some digging I
> found that the following is happening in the function
> lzw_buffer_get_code in pdf-stm-f-lzw.c
>
> b->valbuf is an unsigned long, and b->valbits seems to assumes this is
> 32 bit in size (from what I ca
I have read the the filters section of the ISO pdf document, and
looked at the source code as well as the gnupdf documentation on
filter streams.
I've listed my findings in brief below (I've also attached a text file
which contains the same info).
Please look at it and let me know if my approach is
Please ignore the question in my email, I am now able to generate a pdf from
the texi document.
-Abhishek
2009/9/20 Abhishek Mishra
> Hello Jose,
>
> Many apologies for such a delayed email.
>
> Due to some personal matters I was unable to work on my task for a long
> time.
> I see that the tas
Hello Jose,
Many apologies for such a delayed email.
Due to some personal matters I was unable to work on my task for a long
time.
I see that the task is assigned to me and I would like to complete it now.
Please let me know if something has changed in the requirements, which I
need to take care
Please ignore the question in my email, I am now able to generate a
pdf from the texi document.
Ok. Note that you can use the build-aux/gendocs.sh script.
--
Jose E. Marchesi
http://www.jemarch.net
GNU Project http://www.gnu.org
