pdf-devel
[Top][All Lists]
Advanced

[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?





reply via email to

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