[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pdf-devel] Offer a pair of helping hands
From: |
jemarch |
Subject: |
Re: [pdf-devel] Offer a pair of helping hands |
Date: |
Wed, 06 Jan 2010 23:04:07 +0100 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/23.1.91 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) |
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