Comment 5 for bug 657094

This happens because cairo is putting newline "\n" characters into the stream when creating PDF files (before compressing the stream), in an attempt to do word-wrapping to keep the line size short (I think 72 columns?).

PDFs created like this appear ok on screen in evince, ghostscript etc, but some printers don't like this - our institution has big Fuji Xerox machines and these newline characters get turned into several spaces, which screws up the horizontal spacing at what looks like random character positions.

For example, here is an extract of a deflated stream from one such PDF file:

[(M358)-10( )]TJ
-13.196 -1.15 Td
[(The Univ)-6(er)3(s)-4(i)-4(t)-8(y)11( of)-9( W)-3(es)-4(tern Aus)-4(tra\
li)-5(a )]TJ

on screen it looks like
"M358
The University of Western Australia"

but printed it becomes
"M358
The University of Western Austra lia"

The original PDF file doesn't have this, but evince uses libcairo to create the print data, so the file sent to CUPS has the "\\\n" added to the middle of strings in the stream. Printing the original PDF file directly with lpr does not have this problem.

The code that is doing this is the _word_wrap_stream_count_string_up_to() function in src/cairo-pdf-operators.c

            } else if (stream->column > stream->max_column) {
                newline = TRUE;
                break;
            }
...
    if (newline) {
        _cairo_output_stream_printf (stream->output, "\\\n");
        stream->column = 0;
    }

if either of these bits of code is disabled, then the problem is fixed.