Post by Jan-Ã
ke LarssonHm, OK. Strange. I still cannot reproduce it (although that binary won't
work here, I've only got 32 bit linux available). As far as I can see,
nothing in the code would be able to trigger this. (Being unable to read
the height would return a 400x1 image.)
Could you try the following and report the output
dvipng -D 100 test.dvi -
At the prompt, write
-T 4in,6in <RET>
-pp 1 <RET>
<CTRL>-D
That should report the image size that gets read. Let's see if that is
correct.
Hello,
It's not correct, either with the 32-bit binary nor with the 64-bit
one. A gdb pass tells me that in papersiz.c, the first number is read
both in variables x and y. After reading the first number, the pointer
p should be advanced to read the second one. I don't know how this is
possible in the myatodim function: my intuition would be to add some
"*p=q" at the end. Adding such a line indeed restores correct
behaviour. Am I mistaken by a compiler bug ?
static int32_t myatodim(const char ** p)
{
double tmp; /* double accuracy is enough, I think */
int i=0;
char *q;
tmp = strtod(*p,&q);
while (*q == ' ')
q++;
while (i<8 && (q[0]!=lengthnames[i][0] || q[1]!=lengthnames[i][1]))
i++;
if (i==8 && (q[0]!=lengthnames[i][0] || q[1]!=lengthnames[i][1]))
Warning("unrecognized length unit \"%.2s\", assuming inches",q);
while (*q != ',' && *q !='\0')
q++;
tmp = tmp*lengthsp[i]*dpi/4736286L; /* sp * dots/in / (sp/in),
convert sp to pixels */
return((int32_t) tmp);
}