pdf-devel
[Top][All Lists]
Advanced

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

Re: [pdf-devel] pdf_get_dict_entry()


From: jemarch
Subject: Re: [pdf-devel] pdf_get_dict_entry()
Date: Fri, 14 Sep 2007 22:28:20 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.1.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI)

   >    Additional questions:
   >    How will function objects be used ( called ) ?
   >    Is pdf_apply_function( const pdf_obj *, int n_in, const
   > double in[] , int n_out, double out[] ) an acceptable
   > signature?
   >
   > After initialized, we will want to call somewhat like:
   >
   >    pdf_obj_t pdf_apply_function (pdf_function_t function,
   > pdf_obj_t inputs);
   >
   > The returned object would be a PDF array with the results.
   > `inputs' would be a PDF array with the actual inputs.
   The spec ( section 3.9 ) says:

        Functions are used in various ways in PDF, including   
   device-dependent rasterization information for high-
   quality printing (halftone spot functions and transfer 
   functions), color transform functions for certain color spaces, 
   and specification of colors as a function of
   position for smooth shadings.

   Function application will occur in the interface to a graphic 
   library, potentially millions of times. Is pdf_obj_t really 
   useful  in this context? The pdf objects are more closely tied 
   to the file format/parser. 

Yes, you are right. pdf_obj doesnt make sense in that context. Your
proposal 

   pdf_apply_function( const pdf_obj *, int n_in, const double in[] ,
                       int n_out, double out[] )

seems ok to me.

   >    How shall errors be reported?
   >
   > If we use a PDF array to report the results, we could return
   > an array such as:
   >
   >    [error ERROR_NUMBER]
   >
   > where `error' is a PDF name and ERROR_NUMBER is a suitable
   > error code.
   Sorry, I was thinking about errors in the constructor while 
   talking about function application. If a required key is 
   missing in a dictionary, or if the stream runs out of data,
   it should return NULL. 

The convention used by far is to return NULL for functions that return
pointers and PDF_ERROR for functions returning integers for the
status.

For now you can return NULL and put an explicative comment. We shall
add a global mechanism to the library in order to communicate specific
errors to callers (ala errno).







reply via email to

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