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