log scaling fixes in backend_ps.py

Hello, revisions 1.26 and 1.27 introduced some changes

    > into the PS backend which I do not quite understand. The
    > log messages are "some log optimizations" and "more log
    > scaling fixes". What is the problem they try to fix?

    > Most of the changes consist in replacements like

    > def set_linewidth(self, linewidth): if linewidth !=
    > self.linewidth: - self._pswriter.write("%s
    > setlinewidth\n"%_num_to_str(linewidth)) +
    > self._pswriter.write("%1.3f setlinewidth\n"%linewidth)
    > self.linewidth = linewidth

    > with the result that a linewidth of 2 is now emitted as
    > 2.000 instead of 2. Was this done deliberately? I guess
    > that it can result in a significant increase in PostScript
    > file size. It also broke set_linejoin and set_linecap,
    > which expect integer arguments :frowning:

I broke this -- thanks for finding it and fixing it -- too much coffee
I guess. Basically, set_linejoin and set_linewidth happen inside a
very nasty inner loop. In lines.py we do (well, "did" -- see next

    def _draw_plus(self, renderer, gc, xt, yt):
        offset = 0.5*renderer.points_to_pixels(self._markersize)
        for (x,y) in zip(xt, yt):
            renderer.draw_line(gc, x-offset, y, x+offset, y)
            renderer.draw_line(gc, x, y-offset, x, y+offset)

draw_line in backend ps does

    def draw_line(self, gc, x0, y0, x1, y1):
        Draw a single line from x0,y0 to x1,y1
        ps = '%1.3f %1.3f m %1.3f %1.3f l'%(x0, y0, x1, y1)
        self._draw_ps(ps, gc, None, "line")

and the _draw_ps behemoth makes 18 million function calls, including
set_linewidth and friends. To help ease the pain a little, I inlined
_num_to_str, and reduced some of the string processing (eg no
stripping of trailing zeros and '.') . I made a number of changes in
ps along these lines, trading a marginally larger file size for fewer
function calls, but screwed up in the process.

Thanks for covering my back!

See followup post for more on this problem.