Created attachment 15829 [details] File that block the printer As described in http://lists.cairographics.org/archives/cairo/2008-April/013738.html 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
Created attachment 15830 [details] File that prints
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 vmstatus 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 grestore showpage 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 BT /f-3-0 1 Tf 9.9626 0 0 9.9626 188.390323 447.540186 Tm [<1f08>] TJ ET 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.
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
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?
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. https://bugs.freedesktop.org/show_bug.cgi?id=15348#c13
Current cairo head with your patch fixes printer crashing. All glyphs seem to be on their places. Thanks for your help, Jiri
Fixed with http://gitweb.freedesktop.org/?p=cairo;a=commit;h=c5814d2aa3cb68a13bc9cc8b6a47f660febcad71
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.