[gs-commits] rev 11815 - trunk/gs/base

ken at ghostscript.com ken at ghostscript.com
Fri Oct 15 14:21:52 UTC 2010


Author: ken
Date: 2010-10-15 14:21:51 +0000 (Fri, 15 Oct 2010)
New Revision: 11815

Modified:
   trunk/gs/base/gdevpdfd.c
Log:
Fix (pdfwrite) : Properly scale co-ordinates into Acrobat's range

When emitting various co-ordinates pdfwrite is careful to stay within +/- 32,767 in
order to ensure all versions of Acrobat can properly deal with them. To achieve this it
emits a matrix which scales values up, and then writes the co-ordinates scaled down
by this factor. Thus ensuring that they stay within permitted values, but are still
correct.

However, when emitting a rectangular fill, the scale was applied backwards, the 
co-ordinates were scaled *up* instead of down by the scale factor. This led to wildly
incorrect values being written for rectangular paths.

No differences expected with this in the test suite, however it forms part of the fix
for type 3 fonts which will follow and does rely on this change.


Modified: trunk/gs/base/gdevpdfd.c
===================================================================
--- trunk/gs/base/gdevpdfd.c	2010-10-15 12:48:50 UTC (rev 11814)
+++ trunk/gs/base/gdevpdfd.c	2010-10-15 14:21:51 UTC (rev 11815)
@@ -1392,8 +1392,8 @@
 	    psmat = &smat;
 	}
 	pprintg4(pdev->strm, "%g %g %g %g re f\n",
-		fixed2float(box1.p.x) * scale, fixed2float(box1.p.y) * scale,
-		fixed2float(box1.q.x - box1.p.x) * scale, fixed2float(box1.q.y - box1.p.y) * scale);
+		fixed2float(box1.p.x) / scale, fixed2float(box1.p.y) / scale,
+		fixed2float(box1.q.x - box1.p.x) / scale, fixed2float(box1.q.y - box1.p.y) / scale);
 	if (psmat)
 	    stream_puts(pdev->strm, "Q\n");
 	return 0;



More information about the gs-commits mailing list