[gs-cvs] rev 8571 - trunk/gs/src

[ken at ghostscript.com]

Author: ken
Date: 2008-03-01 02:15:02 -0800 (Sat, 01 Mar 2008)
New Revision: 8571

Modified:
   trunk/gs/src/gdevpdfd.c
Log:
Fix (pdfwrite): problems with type 3 fonts executing 'show'.

Details:
Bug #689687 "Regression: pdfwrite DEVICE produces bad text".

The File is from Quark XPress and contains a type 3 font which
executes a 'show' and a 'charpath stroke' with a glyph from a type
1 font.

The code for revision 8265 converts these into a '2 Tr' in the
PDF file. However, I missed the case of this occuring inside a font,
resulting in much too large a strokewidth being set. This code takes
account of the font matrix.

NB there is still a potential problem. There is no way currently to tell
the difference between a charproc which explicitly sets a stroke width
and one which inherits it from the prevailing graphics state. Currently
we will write a font which always emits the stroke width at the time
the font was first used. There is no simple way to address this, we
could set the stroke width to an invalid value during the course of a type
3 glyph, and check it before emitting the stroke, but this is dangerous.

However, this seems unlikely to be a real problem in practice, since altering
the stroke width outside the font might result in unpredictable widths
dependent on the point size. I have chosen not to open a bug for the
possible condition at this time.

(gdevpdfd.c) gdev_pdf_stroke_path, if we are converting to a PDF text
rendering mode, and are inside a type 3 font glyph description, take the
font matrix into account when calculating the strokewidth.

EXPECTED DIFFERENCES:
None.


Modified: trunk/gs/src/gdevpdfd.c
===================================================================
--- trunk/gs/src/gdevpdfd.c	2008-03-01 06:56:10 UTC (rev 8570)
+++ trunk/gs/src/gdevpdfd.c	2008-03-01 10:15:02 UTC (rev 8571)
@@ -1224,13 +1224,29 @@
 	    /* Set the colour for the stroke */
 	    code = pdf_reset_color(pdev, pis_for_hl_color, pdcolor, &pdev->saved_stroke_color, 
 			&pdev->stroke_used_process_color, &psdf_set_stroke_color_commands);
-	    if(code == 0) {
+	    if (code == 0) {
 		s = pdev->strm;
 		/* Text is emitted scaled so that the CTM is an identity matrix, the line width 
 		 * needs to be scaled to match otherwise we will get the default, or the current
 		 * width scaled by the CTM before the text, either of which would be wrong.
 		 */
-		pprintg1(s, "%g w\n", (pis->line_params.half_width * 2));
+		if (pdev->font3 != 0) {
+		    double det, scale;
+
+		    /* Since font matrix may have different scaling effect by
+		       different directions, we need to average them into
+		       a single scaling factor. A right way is to use
+		       the geometric average of the 2 eigenvalues of the 2x2 matrix,
+		       which appears equal to sqrt(abs(det(M)) where M
+		       is the font matrix with no translation.  */
+		    det = ((double)fixed2float(pdev->charproc_ctm.xx) * fixed2float(pdev->charproc_ctm.yy)) - 
+			((double)fixed2float(pdev->charproc_ctm.xy) * fixed2float(pdev->charproc_ctm.yx));
+		    scale = fabs(sqrt(det));
+		    scale *= 72 / pdev->HWResolution[0];
+		    pprintg1(s, "%g w\n", (pis->line_params.half_width * 2) * (float)scale);
+		} else {
+		    pprintg1(s, "%g w\n", (pis->line_params.half_width * 2));
+		}
 		/* Some trickery here. We have altered the colour, text render mode and linewidth,
 		 * we don't want those to persist. By switching to a stream context we will flush the 
 		 * pending text. This has the beneficial side effect of executing a grestore. So