Re: [pdf-devel] Offer a pair of helping hands

[jemarch]

Hi Johannes.

   as I want to give back to the free software community a small fraction
   of what it is giving to me and as I want to learn something new I am 
   searching for a free software project to contribute to. Your project 
   seems to be interesting and challenging, and it seems that it is in 
   need of some helping hands, so I offer mine. Just some words to my 
   skills: in work I'm mostly doing C++ and Python, for personal use I 
   prefer C and Scheme. I am also familiar with Java, JavaScript and 
   POSIX sh scripting. I have not much experience with PDF internals, but 
   I am willing to learn.

That should not be a problem.  Welcome :)

   1) What's the reference for your implementation? I have the PDF 
   reference 1.7 at hand; is it ok to use this? To me it seems that your 
   implementation of the type 4 functions does not comply to the 1.7 
   reference in the regard of the logical operaters (and, xor, not, or). 
   According to the reference they should support the corresponding 
   binary and logical operations, the gnupdf library only supports the 
   binary ones. Is this intented?

No.  It is a bug in the implementation.  Both ISO 32000 and 1.7
mandate overloaded and,or,xor,not operators.

Something like
          
        #define BOOL(elem)   ((elem) == REP_TRUE)
        #define BOOL_P(elem) (((elem) == REP_TRUE) || ((elem) == REP_FALSE))
 
        ... 
 
        case OPC_and:
          if (sp < 1) goto stack_underflow;
          if (INT_P(stack[sp]) && INT_P(stack[sp-1]))
            {
              stack[sp-1] = INT(stack[sp]) & INT(stack[sp-1]);
              sp--;
            }
          else if (BOOL_P(stack[sp]) && BOOL_P(stack[sp-1]))
            {
              stack[sp-1] = (BOOL(stack[sp]) && BOOL(stack[sp-1])) ?
                REP_TRUE : REP_FALSE;
              sp--;
            }
          else
            {
              goto type_error;
            }
          break;

could work, yielding the boolean values in the stack.  But it is not
clear what would happen with a function like:

   { true true and }

With the current implementation and the above hack, the result on the
stack would be something like 1.202057, that is the float
interpretation of the internal representation of 'true'
(PDF_FP_FUNC_TYPE4_TRUE).

On the other hand, the spec is clear in that the range of the pdf
functions is a real interval, so I suppose that the above function
shall be considered invalid.

   2) The current unit tests use predefined pdf type 4 functions. Is it 
   required to use test functions that have a real world use or can I 
   implement unit tests around functions that only make sense for testing 
   purposes?

Actually what we need are systematic tests on every allowed operator.
For each operator, would be good to have:

- A couple of positive tests (with valid values in the domain).
- A couple of negative tests, if applicable (with invalid values in
  the domain).
- A couple of extreme/interesting cases tests, if applicable.

-- 
Jose E. Marchesi  <address@hidden>
                  http://www.jemarch.net
GNU Project       http://www.gnu.org