> The more I think about
> moving the tokeniser to the base layer the more convinced I am in that
> it is a good idea:
>
> - We could use it in the type 4 functions parser in the fp module.
>
> - We could let the user of the library to use the tokeniser,
> publishing it
On Fri, Jan 23, 2009 at 23:54:58 +0100, jema...@gnu.org wrote:
>For the basic type, something like pdf_obj_t is needed by the tokeniser
>anyway even if it's never exported publically.
>
> Could we use something like 'pdf_token_t'?
Sure, and parts of the pdf_obj code could be used for that
> It is a pity that you dedicated all that time working on that
> obsolete pdf_obj* code: quite probably we wont use it at all.
For the basic type, something like pdf_obj_t is needed by the tokeniser
anyway even if it's never exported publically.
Could we use something like 'pdf_toke
> gnulib is not a shared library. The files are designed to be copied
> directly into programs -- so if a programmer decides they don't want to
> abort on OOM conditions, they can avoid or fix those modules. But GNU
> PDF will usually be loaded dynamically, which means the same bin
> Date: Fri, 23 Jan 2009 00:53:39 +0100
> From: jema...@gnu.org
>
> > > Gerel, what do you think about this? We would of course loose the
> > > benefits of the opaque pointers in this case, but
> 'pdf_obj_equal_p'
> > > throwing PDF_ENOMEM sounds quite weird, and I
> Date: Thu, 22 Jan 2009 18:28:47 -0500
> From: Michael Gold
> Content-Disposition: inline
>
> > If we publish the iterator structure and allocate it from the stack, we a=
> lso
> > need to make public the gl_list_* structures which was in first place som=
> ething
> > we didn't want. Co
On Fri, Jan 23, 2009 at 00:11:43 +0100, jema...@gnu.org wrote:
>> can we use
>> the same data type (pdf_obj_t) for both the public interface and
>> to be used by the parser?, etc.
>
>It's obvious to me that we should, since many of the type (like strings)
>would end
> > Gerel, what do you think about this? We would of course loose the
> > benefits of the opaque pointers in this case, but 'pdf_obj_equal_p'
> > throwing PDF_ENOMEM sounds quite weird, and I think that we could
make an
> > exception and publish the iterator struct
On Thu, Jan 22, 2009 at 14:03:42 -0800, ge...@gnu.org wrote:
> >One annoying thing I noticed was that pdf_list_t needs a heap allocation
> >to use an iterator, which means that pdf_obj_equal_p could fail with an
> >ENOMEM error (but currently has no way to return that error). It woul
> Date: Fri, 23 Jan 2009 00:27:43 +0100
> From: jema...@gnu.org
>
> > Date: Thu, 22 Jan 2009 20:48:24 +0100
> > From: jema...@gnu.org
> >
> > Gerel, what do you think about this? We would of course loose the
> > benefits of the opaque pointers in this case, but 'pdf_ob
> Date: Thu, 22 Jan 2009 20:48:24 +0100
> From: jema...@gnu.org
>
> Gerel, what do you think about this? We would of course loose the
> benefits of the opaque pointers in this case, but 'pdf_obj_equal_p'
> throwing PDF_ENOMEM sounds quite weird, and I think that we could
Hi gerel.
> Gerel, what do you think about this? We would of course loose the
> benefits of the opaque pointers in this case, but 'pdf_obj_equal_p'
> throwing PDF_ENOMEM sounds quite weird, and I think that we could make an
> exception and publish the iterator structure.
Well,
>The next component to add would be a reader that can read
>the xref table and resolve indirect object references.
>
> Before to proceed with the implementation of code pertaining to the
> object layer, we need to complete other activities.
Some parts of the code won't
> Date: Thu, 22 Jan 2009 20:48:24 +0100
> From: jema...@gnu.org
>
> Gerel, what do you think about this? We would of course loose the
> benefits of the opaque pointers in this case, but 'pdf_obj_equal_p'
> throwing PDF_ENOMEM sounds quite weird, and I think that we could make an
> exceptio
> Date: Thu, 22 Jan 2009 20:48:24 +0100
> From: jema...@gnu.org
>
>One annoying thing I noticed was that pdf_list_t needs a heap allocation
>to use an iterator, which means that pdf_obj_equal_p could fail with an
>ENOMEM error (but currently has no way to return that error). It w
On Thu, Jan 22, 2009 at 20:48:24 +0100, jema...@gnu.org wrote:
>The next component to add would be a reader that can read
>the xref table and resolve indirect object references.
>
> Before to proceed with the implementation of code pertaining to the
> object layer, we need to complete othe
Hi Michael.
Here's an updated version of my previous patch, which adds a parser in
addition to the tokeniser, and also makes major changes to pdf-obj.[ch].
There's still some incomplete stuff (like the pdf_obj_dict_ functions)
but it would probably be OK to merge once I complete the
17 matches
Mail list logo
