The customer reports: As you will see in the screenshot 56957_gs_div_0.png of the attached 56957.zip there is a floating point division by 0 (because alp->diff.x is 0) when the 56957.pdf is ripped at 7 dpi in order to get a thumbnail. When gsdll32.dll is used with Delphi's standard control word register contents of 0x1372, i.e. extended precision and only some exceptions masked, the shown error occurs. However if the exceptions division by 0 and invalid operation are masked with e.g. 0x127f GS happily renders the file. Changing the precision makes no visible difference. Is this the intended behaviour? Should I really circumvent the problem?
Is the customer using the absolute latest code ? I ask because I think Chris did recently fix a GPF caused by very small point sizes. Also I am unable to reproduce a crash/SEGV/any problem at all with this file at resolutions down to 2 dpi (-r1 gives a rangecheck in setscreen while starting up). At 2 dpi the text makes no marks. If you can give me a command line which exhibits the problem I'll be happy to look further. I don't have, and wouldn't know how to use, Delphi but I assume the problem ought to emerge with the standard GS implementation using the DLL.
I've contacted the customer asking for confirmation of the command line and the version used. BTW, I wasn't able to get it to crash under Linux x86_64, but assumed it was a Windows and/or 32 bit issue.
In the latest version of ghostscript, we use freetype to do font rendering by default; as such the code in gxfdrop.c is not called, hence the problem cannot easily be reproduced. Dropping back to use gs8.71 with the supplied file (that I will attach to this bug in a moment), with the following command line: debugbin\gswin32c.exe -P- -dBATCH -dNOPAUSE -Z: -r7.2483221x7.2483221 -sOUTPUTFILE=$.tif -sDEVICE=tiff24nc -dDEVICEWIDTH=240 -dDEVICEHEIGHT=180 -dFirstPage=1 -dLastPage=1 -dUseCropBox -d.IgnoreNumCopies=true -c (56957.pdf) run we do indeed get a division by 0 at line 279 of gxfdrop.c in the Y_AT_X macro. In normal use it seems that the division by zero is ignored and the program continues regardless. It seems the margin_boundary code can be called with alp being a vertical line, hence alp->diff.x == 0. The attempt to calculate Y_AT_X therefore fails. The customer has suggested a fix for this whereby we detect alp->diff.x == 0 and drop out of this routine. That certainly works, and has the benefit of simplicity. It is interesting to note that the code can be called with 'alp == 0' (indicating that the line is horizontal), and that the loop is at pains to cope with this. For symmetry, should we be handling vertical lines in the same way? If so, the correct fix would be to alter the conditional setting of y in the loop so that the Y_AT_X macro is not called in the case when alp.diff.x == 0.
Created attachment 6445 [details] 56957.pdf Example file to show problem.
Changing customer bugs that have been resolved more than a year ago to closed.