Fix (pdfwrite) : Properly handle FontMatrix of a Type 3 font.

DETAILS :

Bug 689267 "File converted to PDF displays badly in Acrobat".

Patch from SaGS. His explanation is quoted below.

Part #1: pdfwrite fixes (gdevpdti.c, gdevpdte.c, gdevpdtt.h, gdevpdtt.c :

- Generalize pdfwrite computations for glyph widths and placement,
  which currently assume an [s 0 0 s tx ty]-type original (= ignoring
  changes made by makefont & similar) FontMatrix, to work with an
  arbitrary matrix.

- Fix: the "wy" operand of "d0"/"d1" in Type 3 charproc streams must
  be zero. Note: other parts of the code already consider wy == 0,
  and don't need to be changed.

- Remove font_orig_scale() and pdf_font3_scale(), which are not used
  anymore. Their simple presence is a sign of the assumption that
  font matrices are simple scalings.

- Minor: remove a dead variable ("int code = 0; ... return code;").
  This variable is never changed, because there's another "int code"
  inside the "for", but it is confusing and takes a lot of research
  to figure out the behaviour is OK and no usefull error code is
  lost (it's the 2nd time I stumble against this...)

Notes:
  - All non-Adobe PDF viewers that I tested (Evince/ Fedora 7,
    Foxit Reader 2.0/ Windows, Jaws PDF Editor 3.5/ Windows, and
    Ghostscript -r8204) have problems with "weird" font matrices.
    The bug in ghostscript is addressed below.
  - I do have an alternate patch, which "normalises" the
    FontMatrix, for better viewers compatibility . But this method
    cannot work when fonts are not embedded: cannot "normalize"
    something stored in an external file.

 part #2: PDF interpreter fixes (pdf_font.ps, pdf_ops.ps) :

- Force the "wy" parameter of "d0", not only of "d1", in Type 3
  charproc streams to 0. Comment changed to suggest this is an action
  is expected to be done as part of enforcing the metrics stored in
  the PDF (which always imply wy == 0), and not some strange
  behaviour in Reader.

- A detail in PDF1.7 Ref 5.3.3 "Text Space Details" states that "wy"
  (or "wx" in WMode 1) must be forced to 0 in PDF text space too, not
  only in PDF glyph space. To implement this with non-[s 0 0 s tx ty]
  font matrices, a different method is used: decode "show" strings
  and extract glyph widths with "cshow", put these into an array,
  then render the text with "x/yshow".
  - since "wy/x" = 0 in glyph space, the code does not need to use
    "idtransform", a "div" by "FontMatrix.xx" is sufficient;
  - use a trick (see comment in code) when "FontMatrix.xx" = 0.

CIDFonts are not changed. Those with a "straight" matrix continue to
work, but there's no improvement if they have a weird "/FontMatrix".
I think this would require a radical change, and the result will be
much slower than it is now.

part #3: supplemental ps2write fixes (in opdfread.ps).

- opdfread.ps assumed the FontMatrix is a simple scaling by 0.001;
  generalize the computations to work with an arbitrary matrix.

- Implement a detail of PDF1.7 Ref 5.3.3 "Text Space Details" (nuking
  the "wy" in text space) if a non-[s 0 0 s tx ty] "/FontMatrix".
  Similar to the change in the main PDF interpreter, but shorter
  because opdfread.ps does not handle vertical writing or CID fonts.

Also "wy" in "d0"/"d1" is already 0 (see patch for pdfwrite), so
needs no adjustment.

EXPECTED DIFFERENCES :

pdfwrite :
prfmm.pdf - A 1-pixel shift of 1 glyph, probably due to a different rounding. Mot important.

git-svn-id: http://svn.ghostscript.com/ghostscript/trunk@8217 a1074d23-0009-0410-80fe-cf8c14f379e6

1 files changed, 2 insertions, 2 deletions

diff --git a/gs/src/gdevpdti.c b/gs/src/gdevpdti.c
index 3463b2e7a..88dda741c 100644
--- a/gs/src/gdevpdti.c
+++ b/gs/src/gdevpdti.c
@@ -479,11 +479,11 @@ pdf_set_charproc_attrs(gx_device_pdf *pdev, gs_font *font, const double *pw, int
 	is defined to paint glyphs with the current color."
 	However comparefiles/Bug687044.ps doesn't follow that. */
 	pdev->skip_colors = false; 
-	pprintg2(pdev->strm, "%g %g d0\n", (float)pw[0], (float)pw[1]);
+	pprintg1(pdev->strm, "%g 0 d0\n", (float)pw[0]);
     } else {
 	pdev->skip_colors = true;
 	pprintg6(pdev->strm, "%g %g %g %g %g %g d1\n", 
-	    (float)pw[0], (float)pw[1], (float)pw[2], 
+	    (float)pw[0], (float)0.0, (float)pw[2], 
 	    (float)pw[3], (float)pw[4], (float)pw[5]);
 	pdfont->u.simple.s.type3.cached[ch >> 3] |= 0x80 >> (ch & 7);
     }