[cairo-bugs] [Bug 89406] New: [fix] word wrapping of pdf stream causes gaps in the middle of text when printing

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Mar 3 01:52:59 PST 2015


            Bug ID: 89406
           Summary: [fix] word wrapping of pdf stream causes gaps in the
                    middle of text when printing
           Product: cairo
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: pdf backend
          Assignee: ajohnson at redneon.com
          Reporter: john.mcpherson at opalle.com
        QA Contact: cairo-bugs at cairographics.org

cairo version 1.13.0

When printing via CUPS (which uses cairo to create pdf files), sometimes
several spaces occur in the middle of words, pushing the rest of the sentence
to the right.

(as reported at https://bugs.launchpad.net/ubuntu/+source/cairo/+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
The University of Western Australia"

but printed it becomes
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;
    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.


ie please don't word wrap if we are inside an open text (...) element.

You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo-bugs/attachments/20150303/a2b20b1d/attachment.html>

More information about the cairo-bugs mailing list