| Summary: | Form XObject's /BBox may contain reals in exponential format | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | SaGS <sags5495> |
| Component: | PDF Writer | Assignee: | Igor Melichev <igor.melichev> |
| Status: | NOTIFIED FIXED | ||
| Severity: | normal | ||
| Priority: | P2 | ||
| Version: | master | ||
| Hardware: | PC | ||
| OS: | All | ||
| Customer: | Word Size: | --- | |
| Attachments: |
Sample file
Proposed patch. |
||
Created attachment 625 [details]
Sample file
Created attachment 626 [details] Proposed patch. Changes tested with GS8.13, but diffs are relative to HEAD. The proposed patch fixes only this particular bug. After applying it, the attached PostScript converts to a valid PDF but the Form XObjects are still displayed incorrectly. See bug 687430 "Wrong transformation matrix with Form XObjects". Thank you for the patch suggested. I used your information to make a simpler one http://cvs.ghostscript.com/cgi-bin/viewcvs.cgi/gs/src/gdevpdfm.c?r1=1.36&r2=1.37 |
pdfmark_BP() uses sprintf("%g") to create the value of a Form XObject's /BBox. For unexpectedly large values, or values near 0.0 (coming from rounding errors, for example), "%g" outputs the numbers in exponential format, which is not valid in PDFs. Adobe Reader signals an error and does not display the PDF file obtained from the attached sample. The proposed patch also introduces a new utlility function sprintg(), which is more robust than existing code in pprintg1(). The old code may switch to sprintf("%1.1f"); for unexpectedly large numbers this produces hundreds of characters, overflowing the output buffer (for 1e300 it outputs more than 300 chars). sprintg() can also signal an error, by returning NULL.