Bug #657094 “Evince when printing a pdf creates strange gapping....” : Bugs : cairo package : Ubuntu

Revision history for this message

Fritz Scholz (fw-scholz) wrote on 2010-10-08:

#1

output.pdf Edit (102.2 KiB, application/pdf)

Revision history for this message

madbiologist (me-again) wrote on 2010-10-09:

#2

Thankyou for providing the result of printing to pdf with Evince. Could you also please attach the original PDF file.

Ubuntu 10.10 "Maverick Meerkat" is released tomorrow. Please test and let us know if the problem still occurs.

Changed in cairo (Ubuntu):
status:	New → Incomplete

Revision history for this message

Fritz Scholz (fw-scholz) wrote on 2010-10-09: Re: [Bug 657094] Re: Evince when printing a pdf creates strange gapping.

#3

test.pdf Edit (24.9 KiB, application/pdf; name="test.pdf")
testBAD.pdf Edit (11.5 KiB, application/pdf; name="testBAD.pdf")
testGOOD.pdf Edit (11.2 KiB, application/pdf; name="testGOOD.pdf")

Thanks for your fast reply. I will attach 3 files, test.pdf, testBAD.pdf
and testGOOD.pdf.

test.pdf is produced by my LaTex run within Texmaker, which
also opens up Evince Document Viewer 2.30.3. When I print that file
from there to PDF I get the bad version testBAD.pdf with the gapping.
When I open up test.pdf with Acrobat Reader 9, version 9.3.4 and
print from there to a file I get testGOOD.pdf, without the gapping.
This gapping also showed up when I print to a printer from within
Evince.
It seems that the issue lies within Evince.
At this point I am a bit leery to change to an even newer version of
Ubuntu, since this issue cropped up because I upgraded to Ubuntu 10.04.

Any help in resolving this will be much appreciated.

Fritz

On Sat, 2010-10-09 at 03:12 +0000, madbiologist wrote:
> Thankyou for providing the result of printing to pdf with Evince. Could
> you also please attach the original PDF file.
>
> Ubuntu 10.10 "Maverick Meerkat" is released tomorrow. Please test and
> let us know if the problem still occurs.
>
> ** Changed in: cairo (Ubuntu)
> Status: New => Incomplete
>

Till Kamppeter (till-kamppeter) on 2010-12-07

Changed in cairo (Ubuntu):
importance:	Undecided → High

madbiologist (me-again) on 2010-12-11

Changed in cairo (Ubuntu):
status:	Incomplete → New
status:	New → Confirmed

Revision history for this message

madbiologist (me-again) wrote on 2010-12-11:

#4

I can reproduce this on Ubuntu 10.10 "Maverick Meerkat" using the test.pdf file attached to comment #3.

Package versions:
evince 2.32.0-0ubuntu1
poppler 0.14.3-0ubuntu1.1
libcairo2 1.10.0-1ubuntu3

Revision history for this message

John McPherson (john-mcpherson) wrote on 2014-10-23:

#5

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.

Revision history for this message

John McPherson (john-mcpherson) wrote on 2014-10-23:

#6

I should have mentioned that this was happening for me on Ubuntu 14.04, with libcairo2_1.13.0~20140204-0ubuntu1

Revision history for this message

Sebastien Bacher (seb128) wrote on 2014-10-28:

#7

@John, thanks for the debugging work, do you think you could report that to upstream on https://bugs.freedesktop.org/enter_bug.cgi?product=cairo ?

Revision history for this message

Fritz Scholz (fw-scholz) wrote on 2014-10-30:

#8

Thanks John for throwing light on this and providing a solution.
Will try to fix it and play with it.

Sorry for the delay in my response. I had major computer problems and
was updating to Ubuntu 14.04 on 3 machines.

Best regards,

Fritz

-----Original Message-----
From: John McPherson
Sent: Thursday, October 23, 2014 1:17 AM
To: <email address hidden>
Subject: [Bug 657094] Re: Evince when printing a pdf creates strange
gapping.

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.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/657094

Title:
Evince when printing a pdf creates strange gapping.

Status in “cairo” package in Ubuntu:
Confirmed

Bug description:
  When trying to print a pdf file with Evince Document Viewer 2.30.3 in
Ubuntu 10.04 it creates strange gapping that seems to be due to Courier
font.
  These gaps show up when I print this file to pdf. Example file is
attached.
  They do not show when I print to pdf from within Acrobat Reader.
  I never had this problem before, but I recently upgraded to Ubuntu 10.04
from 8.04, and I can't recall which version
  of Evince I was using before.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/657094/+subscriptions

Thanks John for throwing light on this and providing a solution.
Will try to fix it and play with it.

Sorry for the delay in my response. I had major computer problems and
was updating to Ubuntu 14.04 on 3 machines.

Best regards,

Fritz

-----Original Message----- 
From: John McPherson
Sent: Thursday, October 23, 2014 1:17 AM
To: fw.scholz@comcast.net
Subject: [Bug 657094] Re: Evince when printing a pdf creates strange 
gapping.

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.

-- 
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/657094

Title:
  Evince when printing a pdf creates strange gapping.

Status in “cairo” package in Ubuntu:
  Confirmed

Bug description:
  When trying to print a pdf file with Evince Document Viewer 2.30.3 in 
Ubuntu 10.04 it creates strange gapping that seems to be due to Courier 
font.
  These gaps show up when I print this file to pdf. Example file is 
attached.
  They do not show when I print to pdf from within Acrobat Reader.
  I never had this problem before, but I recently upgraded to Ubuntu 10.04 
from 8.04, and I can't recall which version
  of Evince I was using before.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/657094/+subscriptions

Revision history for this message

In freedesktop.org Bugzilla #85662, Alex Korobkin (korobkin) wrote on 2014-10-30:

#15

This patch [1] breaks PostScript printing with pdftocairo to Ricoh printers: only the last line of the sequence is printed.

For example, if you have this in your .ps file,
(aaa)
(bbb)
(cc)
only "cc" will appear on the page.

PostScript viewers also fail to parse it: neither GhostScript nor Evince are able display these lines.

Please revert or fix the patch?

1. http://cgit.freedesktop.org/cairo/commit/?id=ab2a7b61d59258b71e1c3256edf2f42ea6cc1eb2

Revision history for this message

In freedesktop.org Bugzilla #85662, B-harrington (b-harrington) wrote on 2014-10-30:

#16

I've reverted the problematic patch in trunk.

I'm hopeful that a better fix can be found for the original issue, and am CCing Adrian.

This (or a better fix) is a candidate for 1.14.2

Revision history for this message

In freedesktop.org Bugzilla #85662, Adrian Johnson (ajohnson-redneon) wrote on 2014-10-30:

#17

Created attachment 108707
patch

Please attach a pdf for reproducing the problem and your ps output. It works fine for me with ghostscript 9.06.

Please try the attached patch.

Revision history for this message

In freedesktop.org Bugzilla #85662, Adrian Johnson (ajohnson-redneon) wrote on 2014-10-30:

#18

(In reply to Bryce Harrington from comment #1)
> I've reverted the problematic patch in trunk.
>
> I'm hopeful that a better fix can be found for the original issue, and am
> CCing Adrian.
>
> This (or a better fix) is a candidate for 1.14.2

I'm sure we can find a better fix since reverting it breaks printing on my printer. I'll work on analyzing this problem but don't expect an immediate response. I've been sleeping for the last 8 hours.

Revision history for this message

In freedesktop.org Bugzilla #85662, Adrian Johnson (ajohnson-redneon) wrote on 2014-10-31:

#19

I've pushed a fix for this.

Revision history for this message

In freedesktop.org Bugzilla #85662, Alex Korobkin (korobkin) wrote on 2014-10-31:

#20

Created attachment 108728
cafe2.pdf

Revision history for this message

In freedesktop.org Bugzilla #85662, Alex Korobkin (korobkin) wrote on 2014-10-31:

#21

Created attachment 108729
cafe2.ps

Here is a resulting file with broken lines.

I tested the suggested patch. Looks like it makes one long line (aaabbbcccc) instead of
(aaa)
(bbb)
(cccc)

This works with my Evince, GS, and my printers, though I'm not sure what is the limit of length for such a line.

Revision history for this message

Sebastien Bacher (seb128) wrote on 2015-02-23:

#9

@John, did you ever try to upstream your finding from here?

Revision history for this message

John McPherson (john-mcpherson) wrote on 2015-02-23:

#10

Hi,

No sorry, I forgot about this. I'll report it upstream later this week when I'm back from overseas leave. Thanks for the reminder.

John

> On 23 Feb 2015, at 8:35 pm, Sebastien Bacher <email address hidden> wrote:
>
> @John, did you ever try to upstream your finding from here?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/657094
>
> Title:
> Evince when printing a pdf creates strange gapping.
>
> Status in cairo package in Ubuntu:
> Confirmed
>
> Bug description:
> When trying to print a pdf file with Evince Document Viewer 2.30.3 in Ubuntu 10.04 it creates strange gapping that seems to be due to Courier font.
> These gaps show up when I print this file to pdf. Example file is attached.
> They do not show when I print to pdf from within Acrobat Reader.
> I never had this problem before, but I recently upgraded to Ubuntu 10.04 from 8.04, and I can't recall which version
> of Evince I was using before.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/657094/+subscriptions

Revision history for this message

In freedesktop.org Bugzilla #89406, John McPherson (john-mcpherson) wrote on 2015-03-03:

#13

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):

######