pdfwrite - address problems with stringwidth and composite fonts

Bug #693059 "Asian fonts placed badly with pdfwrite output"

The problem here was caused by the way that pdf_process_string deals with 'widths'
when responding to a strginwidth operation versus a regular show.

When handling stringwidth the width of each glyph is added to the enumerator
'returned.total_width'. However, when handling a regular show, the width of
the glyphs are simply stored directly into 'returned.total_width'.

To handle the latter case the higher level code maintains its own total width
but that was getting confused when a stringwidth was used.

Ideally we would fix pdf_process_string to behave the same whether in response
to a stringwidht or a show, but that routine is called from other places and
making it coherent looks difficult. Instead we now process stringwidth
differently form show, and don't accuulate wodths when we have a steingwidth
operation in the higher level composite font code routines.

No differences expected

1 files changed, 19 insertions, 4 deletions

diff --git a/gs/base/gdevpdtc.c b/gs/base/gdevpdtc.c
index 4c3682643..c737bf678 100644
--- a/gs/base/gdevpdtc.c
+++ b/gs/base/gdevpdtc.c
@@ -153,10 +153,25 @@ process_composite_text(gs_text_enum_t *pte, void *vbuf, uint bsize)
             }
             pte->xy_index = out.xy_index;
             if (return_width) {
-                pte->returned.total_width.x = total_width.x +=
-                    out.returned.total_width.x;
-                pte->returned.total_width.y = total_width.y +=
-                    out.returned.total_width.y;
+                /* This is silly, but its a consequence of the way pdf_process_string
+                 * works. When we have TEXT_DO_NONE (stringwidth) we add the width of the
+                 * glyph(s) to the enumerator 'returned.total_width' so we keep track
+                 * of the total width as we go. However when we are returning the width
+                 * but its NOT for a stringwidth, we set the enumerator 'retuerned'
+                 * value to just the width of the glyph(s) processed. So when we are *not*
+                 * handling a stringwidth we need to keep track of the total width
+                 * ourselves. I'd have preferred to alter pdf_process_string, but that
+                 * is used in many other places, and those places rely on this behaviour.
+                 */
+                if (pte->text.operation & TEXT_DO_NONE) {
+                    pte->returned.total_width.x = total_width.x = out.returned.total_width.x;
+                    pte->returned.total_width.y = total_width.y = out.returned.total_width.y;
+                } else {
+                    pte->returned.total_width.x = total_width.x +=
+                        out.returned.total_width.x;
+                    pte->returned.total_width.y = total_width.y +=
+                        out.returned.total_width.y;
+                }
             }
             pdf_text_release_cgp(penum);
         }