Bug 89406 - [fix] word wrapping of pdf stream causes gaps in the middle of text when printing
Summary: [fix] word wrapping of pdf stream causes gaps in the middle of text when prin...
Status: RESOLVED DUPLICATE of bug 85662
Alias: None
Product: cairo
Classification: Unclassified
Component: pdf backend (show other bugs)
Version: unspecified
Hardware: All All
: medium normal
Assignee: Adrian Johnson
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-03 09:52 UTC by john.mcpherson
Modified: 2015-03-03 19:58 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description john.mcpherson 2015-03-03 09:52:59 UTC
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
"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.

######

ie please don't word wrap if we are inside an open text (...) element.
Comment 1 Adrian Johnson 2015-03-03 19:58:58 UTC
Has been fixed in master.

*** This bug has been marked as a duplicate of bug 85662 ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.