> 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
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
Gerardo E. Gidoni has taken ownership of the following task:
FS#87 - Use the disk filesystem in pdf-filter
More information can be found at the following URL:
http://www.gnupdf.org/flyspray/index.php?do=details&task_id=87
You are receiving this messa
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has been changed. The changes are listed below. For full
information about what has changed, visit the URL and click the History tab.
FS#86 - Error management in type 4 functions
User who did this: Gerardo E. Gidoni (gerel)
Assign
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
Gerardo E. Gidoni has taken ownership of the following task:
FS#86 - Error management in type 4 functions
More information can be found at the following URL:
http://www.gnupdf.org/flyspray/index.php?do=details&task_id=86
You are receiving this messag
16 matches
Mail list logo
