GNOME Bugzilla – Bug 502206
Helvetica does not print
Last modified: 2007-12-12 00:57:17 UTC
The attached Excel 95 file was originally made by gnumeric, and updated by several versions of gnumeric. The current version was written by 1.7.90. Printing direct to a postscript printer fails. The printer aborts the job with an error message. Printing to pdf results in a bogus pdf file where most of the content is missing. (gtk version is 2.12.2 - Debian version 2.12.2-1. cairo version is 1.4.10 - Debian version 1.4.10-1). Reading the file into Excel and printing from Excel results in the correct output, but followed by 1891 blank pages. I guess we aren't maintaining Excel 95 output so well these days. In that case, may be we should make it harder to select it. One thing I notice in the file is Print_Area Alt!IV65536:$A$1. Looks strange. Is it? The sheet has max col 10, max row 30, but a style region covering rows 22:65535.
Created attachment 100476 [details] Spreadsheet
Created attachment 100477 [details] PDF file
When I open the file in gnumeric svn I notice 2 things: it uses a font (helvetica) that doesn't print on my system even with a completely fresh file. the print area is set to A2:$A$1, so without asking it to print while ignoring the print area it really shouldn't print anything. so I don't see anything specific to this file or even the XL import. What does XL think the print area is? You mention that you are seing the printarea Print_Area Alt!IV65536:$A$1. Where are you seeing that?
In the gnumeric file which results from running the file through ssconvert.
hmm, why would that differ from the PrintArea one sees when one opens the file in Gnumeric?
Now I see: since it is relative it looks different in the define-name dialog depending on the currently selected cell. Of course Print_Area should really always be absolute. When we print we clearly use the absolute version. When we are printing we are limiting ourselves to the extent rather than printing the whole print area (which XL apparently does). So XL prints 1891 blank pages. We don't. I am not sure I would want XL's behaviour. So the real problem is font related then? Jon-Kare: if you change the font to a font that you know prints on your set-up, are you still getting errors or strange behaviour?
To be clearer: there are still issues with the Print_Area, since we see to get confused by the fact that the area is not normalized. I'll have a look at that.
The printer is postscript, and has Helvetica. I'm at the office right now, with a different computer and printer. I get nothing if I print the sheet unchanged, and the output I expect if I clear the print area first. It isn't necessary to change the font. The print area was probably set by an export bug in gnumeric. The oldest version I've seen of this file is from 2002. Looks like we have to work around unreasonable print areas. I'll look for clues in the older versions of the file when I get home.
We can forget all about old excel versions and import of print area. I can reproduce by just doing this: New gnumeric A1: 0 select A1 Font: Helvetica Print Printing to postscript printer gives error. Printing to pdf gives blank grid (header/footer are visible). Ironically, the printer does have Helvetica built in.
Jon-Kare: I knew the problem with some fonts (see my comment #3). This doesn't mean that there is no print area problem. With your file, if you change the font to a font that prints in a clean file, you still don't get any output. (At least I don't get any.)
Created attachment 100670 [details] [review] patch for the printarea issue This patch fixes the print area problem. If you view a preview now, you may in fact see a few characters since there is some sans on the page. If you change the font for the whole sheet to a font that normally prints for you, then this patch should make the file printable, please review.
Looks OK, and fixes the print area problem here.
so the print area part is fixed and committed. We are left with the helvetica font not printing.
I have filed the helvetica font issue separately (which also affects Times and various other "well known" fonts.) *** This bug has been marked as a duplicate of 503162 ***