From 9f656faebac150c6aceca16c5ef6a78b92b6da43 Mon Sep 17 00:00:00 2001 From: Ken Sharp Date: Fri, 25 May 2012 14:08:52 +0100 Subject: 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 --- gs/base/gdevpdtc.c | 23 +++++++++++++++++++---- 1 file 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); } -- cgit v1.2.3