Bug 15445 - cairo generated postscript blocks Dell 5100cn
Summary: cairo generated postscript blocks Dell 5100cn
Alias: None
Product: cairo
Classification: Unclassified
Component: postscript backend (show other bugs)
Version: 1.5.20
Hardware: x86 (IA32) Linux (All)
: medium major
Assignee: Adrian Johnson
QA Contact: cairo-bugs mailing list
Depends on:
Reported: 2008-04-11 00:47 UTC by Jiri Cerny
Modified: 2008-04-11 06:09 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

File that block the printer (98.85 KB, application/postscript)
2008-04-11 00:47 UTC, Jiri Cerny
File that prints (92.79 KB, application/postscript)
2008-04-11 00:49 UTC, Jiri Cerny

Description Jiri Cerny 2008-04-11 00:47:36 UTC
Created attachment 15829 [details]
File that block the printer

As described in 


some postscript files generated by cairo completely blocks the Dell 5100cn printer.

It seems that offending commit is 6f9d71c10bf3e38c88378950037d1c81a2413617.

I attach to this message two files, one that prints (07g.ps) and one that not (06b.ps). 07g is a subset of 06b, both are trimmed versions of the same file generated by cairo. They do not seem to be very different to me, only one is longer (the difference is 400 lines ~ 100 characters). And both are pretty boring .... 

One remark, the version of cairo that I used to produce the original file is not 1.5.20, but 1.5.9 just after the commit that create problems. But cairo 1.5.20 produced files have the same issue. 

This bug seems to be similar to bug 15348
Comment 1 Jiri Cerny 2008-04-11 00:49:13 UTC
Created attachment 15830 [details]
File that prints
Comment 2 Adrian Johnson 2008-04-11 01:55:57 UTC
Thanks for the test files. This narrows it down a bit.

The only difference between 07g.ps and 06b.ps is more of the same text operators. I am wondering if these operators are somehow using up too much memory.

To check on the memory usage you can paste the following PS code into one of the PS files and print it:

/Helvetica findfont 
12 scalefont setfont
50 50 moveto (VM max: ) show
20 string cvs show
( bytes    VM Used: ) show
20 string cvs show
( bytes   Save Level: ) show
20 string cvs show 

I suggest placing just before the


near the end of the file. You can change the "50 50 moveto" if you want to print to a different location on the page. It would be interesting to see how the available memory changes as the blocks of:
  0 g
  /f-3-0 1 Tf
  9.9626 0 0 9.9626 188.390323 447.540186 Tm
  [<1f08>] TJ

type code are added or removed.

The text is sometimes displayed with the "Tj" operator with a hex string eg
<12> Tj

and sometimes displayed with the "TJ" operator which takes an array of strings, each string separated by a horizontal position adjustment eg
[<05> -1.031738 <0c>] TJ

It would be interesting to see if only using one or the other in the file makes a difference.

Looking at the other operators:

"0 g" sets the color to black

"BT" and "ET" do nothing and are there for PDF compatibility.

/f-3-0 1 Tf   stores the font name "f-3-0" for later use by the "Tm" operator.

a b c d e f Tm   is the most interesting operator in this file and is where I suspect the problem may be. It creates a new font with the font matrix specified by the 6 numbers.
Comment 3 Adrian Johnson 2008-04-11 02:30:35 UTC
Here's an alternative definition of the "Tm" operator the makes it more like the PostScript that was used before the switch to PDF operators.

In the prolog section at the beginning of the file, replace the old Tm definition

/Tm { 6 array astore cairo_font exch selectfont 0 0 moveto } bind def

with this

/Tm { 6 2 roll 0 0 6 array astore cairo_font exch selectfont moveto } bind def

Comment 4 Jiri Cerny 2008-04-11 03:38:24 UTC
Re #2. Adrian, thanks for the hits. I pasted the code to 06b and 07g just before the grestore. 

07g gives VM max: 27949440 bytes VM Used: 82488 bytes Save Level:2

06b gives VM Used: 89982 bytes

So memory does not seem to be an issue. 

Yes, 06b printed this time. So I tried to send another file, 05b (which is a slightly longer version of 06b, 500 lines more) to the printer just after 06b and it blocked the printer. I restarted the printer, sent there 05b again and it blocks again.

I am sure that 06b blocked the printer at least twice. I went through the sheets I printed today and I realised that 05b was also once successfully printed.  
So, there is something non reproducible.

Re #3. I changed the definition of /Tm operator. 05b prints. So I changed the definition of /Tm also in the original file produced by cairo, and it prints now.
So it seems to solve the problem.

Can you explain me why? 
Comment 5 Adrian Johnson 2008-04-11 05:19:23 UTC
I've attached a patch for cairo 1.6.0 to bug 15348. Please test and confirm that it fixes the crash without introducing any regressions.


Comment 6 Jiri Cerny 2008-04-11 06:00:23 UTC
Current cairo head with your patch fixes printer crashing. All glyphs seem to be on their places.

Thanks for your help, Jiri

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.