| Summary: | cairo generated postscript blocks Dell 5100cn | ||
|---|---|---|---|
| Product: | cairo | Reporter: | Jiri Cerny <ji.cerny> |
| Component: | postscript backend | Assignee: | Adrian Johnson <ajohnson> |
| Status: | RESOLVED FIXED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
| Severity: | major | ||
| Priority: | medium | ||
| Version: | 1.5.20 | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
File that block the printer
File that prints |
||
|
Description
Jiri Cerny
2008-04-11 00:47:36 UTC
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 |
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.