[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pdf-devel] pdf_get_dict_entry()
From: |
Hardy Falk |
Subject: |
Re: [pdf-devel] pdf_get_dict_entry() |
Date: |
Fri, 14 Sep 2007 22:53:07 +0200 |
User-agent: |
KMail/1.9.5 |
Am Freitag, 14. September 2007 19:49 schrieb address@hidden
> 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.
> 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.
> We could generalize this mechanism in order to use it in
> other parts of the library. We could define the following
> function in `pdf_error.[ch]':
>
> int pdf_check_error (pdf_obj_t obj);
>
> and then:
>
> result = pdf_apply_function (...);
> if (pdf_check_error (result))
> {
> /* Handle the error,
> maybe printing pdf_error_description (result) */
> }
>
> With such schema we could define error conditions (and the
> associated error descriptions) in `pdf_error.h'.
>
> What do you think?
I have mixed feelings about this approach. It is common in
Python, but it doesn't seem to be C. And PDF is not even a
programming language. Greenspuns tenth law is looming :-).