[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[pdf-devel] Re: GNU PDF functions
From: |
jemarch |
Subject: |
[pdf-devel] Re: GNU PDF functions |
Date: |
Mon, 04 Aug 2008 21:23:16 +0200 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) |
Hello Hardy.
(Note that I added a CC to the development mailing list, since you
arise some interesting questions in this email and the other people
may provide ideas)
> Ok. Will you want to work in the interpolation functions only or also
> in the other aspects of the floating point module?
Much of my work in Nov 2007 does not belong to the base layer proper.
Multilinear and cubic interpolation functions may be rewritten in the
base layer, they can do with only base types in their API.
Ok, superb.
The matrix functions are even simpler. I can include them for
completeness .Most graphics libraries provide highly optimized
versions of these functions, so I don't think they'll be much used.
That is an interesting point. If we are going to use libcairo as the
graphics library to render the pages of the documents then we could
rely in its implementation of matrices,
> The constructor of pdf_func_t instances will decompose its
> stream/dictionary object argument. Shall it go to the object layer
> for this reason? This would expose the complex innards of
> pdf_func_t to a function implemented in another layer.
>
> The idea is to have the pdf_interp_XXX functions in the floating point
> module (in the base layer) operating in pdf_real_t values (an alias
> for 'double').
This leaves me in the cold.
Pdf functions, as described in the reference documentation, may have
wildly varying nested structures, e.g. a function dictionary for a
stitching function with several other function dictionaries.
OTOH, function application looks the same for every function:
an input vector pdf_real_t in[N] is mapped to pdf_real_t out[M].
There seems to be a gap between pdf_obj_t , streams, and
dictionaries and the low level data structures ( for example the
interpreter for postscript functions ) needed for actual function
application.
The code filling this gap certainly does not belong to pdf-fp.c.
Ok, besides the interpolation functions, what more do we need?
- Streams (containing the samples or the postscript function
definitions) will be provided in the second layer of the library
(the object layer).
- The dictionary structure containing the function attributes will
also be provided in the object layer.
- The interpreter for postscript functions.. well, AFAIK the pdf
functions are the unique part of the codebase where that facility is
used. Then we could implement it in the document layer where the
notion of "pdf function" is introduced.
What do you think?
- [pdf-devel] Re: GNU PDF functions,
jemarch <=