Off-by-one bug in Content::text_width() when character spacing is non-zero

[gtnuux]

tw_bug.zip
The following applies to both PDF::API2 and PDF::Builder.

The definition of the text_width() sub takes character spacing into account on
line 2466 of Content.pm:

$width += $opts{'charspace'} * ($char_count - 1);

On the one hand, a string of n characters does have n-1 inter-character
positions, so this would seem to make common sense. On the other hand, the
pdf spec was written by Adobe :-). But, actually, implementing character
spacing in this way would be a problem when a line is formed by multiple
writes (Tj or TJ). When a subsequent string is written to the same line, you
would need to also add (or subtract) space before typesetting the second
string. This would be ambiguous if Tc was changed between the two writes.
The pdf spec says:

When the glyph for each character in the string is rendered, Tc is
added to the horizontal or vertical component of the glyph’s displacement,
depending on the writing mode.

This is really the only reasonable way to do things. Since text_width() is
used by PDF::API2 to keep track of the current position, the values returned
by position() are wrong when Tc is non-zero. The line simply needs to be
changed to

$width += $opts{'charspace'} * $char_count;

I discovered this while creating a custom ellipsis by decreasing the spacing
between the characters of "...". A unicode ellipsis in a mono-spaced font
like Courier or NimbusMono does not work well b/c it is only one character
wide. The attached zip has as short script (and it's output) that illustrates
the issue more dramatically by double-spacing the characters of a string.

Thanks!
-Jeff Norden