GNOME Bugzilla – Bug 554116
XLS : explicit PRINT_AREA should imply print-content-only
Last modified: 2009-03-05 04:09:03 UTC
Please describe the problem: Gnumeric 1.9.3 for Windows 2000. Printing to either Adobe PDF or to Adobe distiller doesn't print the area specified. Printing to Adobe PDF creates crazy characters. Printing to other printers such as Snagit 8 printer or HP8250 also shows the same defect. Adobe Distiller version 8.1.2 for Windows Adobe Acrobat 8 Standard version 8.1.2 for Windows Steps to reproduce: 1. Select a print area of more than 65 spreadsheet rows. 2. Set page setup to either fixed scaling sufficiently small, or automatic scaling to fit on one page. 3. Print. In case of Distiller, import the postscript file to Distiller and create a pdf. Actual results: The print area is truncated to 65 lines (or maybe 66, I'm not sure) Expected results: The full print area would be printed Does this happen every time? Yes Other information: I will attempt to upload an input file and the results to bugzilla.
Created attachment 119502 [details] Gnumeric spreadsheet and outputs zipped Gnumeric spreadsheet, Adobe PDF output (Gnumeric Spreadsheet job #2.pdf), and Adobe Distiller output after converting ps file (test.pdf)
Your sheet content ends at 65 lines so the print area is _supposed_ to be truncated there. If you want to include the additional lines that contain only styles, you need to check "styles with no content " on the "sheeet" tab of the Page setup dialog.
It sounds like you are reporting 2 distinct issues here 1) you expect PRINT_AREA to override the size of the sheet content and print blank areas. - We can discuss this from a compatibility perspective. As Andreas points out the impact of our 'styles with no content' flag changes things. However, this does seem like a bug on some level. Importing a book with an explicit print area should print that area. Perhaps we should set the no-content flag on import if there is a print-area ? 2) The pdf we generate via cairo makes adobe's distiller unhappy. This is out of our hands on several levels. a) cairo is generating the pdf, and it appears viable for standard display. b) We don't have access to distiller to find out what it does not like about the pdf. The test.pdf appears reasonable in acroread, and evince. Can you file a bug with adobe on distiller to get more detail ?
Jody: regarding your item 1: Currently there is _always_ a printarea set, frequently it is the whole sheet. If it is smaller its effect is to exclude a region from being considered for printing.
Jody: the subject line you set seems to contradict your comment above.
Firstly, I would like to say that checking the box mentioned by Andreas does fix the problem on my system, in windows. Thanks for information. However, the pdf output with the box unchecked actually does not include the portion of the print area which has what I think of as data. The pdf cuts off after row 64, but there is color and a double line boundary down to the bottom of row 67. I think of cell color and borders as content, but that such things as numeric styles such as number of decimal digits, since they don't appear if no data is in the cell, shouldn't get printed in the case of an empty cell--I guess the developers of Gnumeric haven't thought of "styles" in this way. I agree with Jody that everything visible within a print area should be automatically printed--it shouldn't be necessary to hunt around for a check box to turn on printing of certain elements within the print area. (In this connection, but admittedly perhaps the opposite situation, I was trying to use OpenOffice Writer to create a document and was extremely frustrated by automatic bullets and paragraph numbering that I couldn't see how to turn off. Eventually, at http://www.oooforum.org/forum/viewtopic.phtml?t=69739 I located a discussion about how to turn this off, and how many people thought this shouldn't happen automatically.) Regarding Jody's point 2. Actually Distiller works fine, it is the direct creation of a pdf from the Adobe pdf printer that doesn't work. The test.pdf is the one that is ok in respect to the characters, it is the one called "Gnumeric Spreadsheet job #2.pdf" which has crazy characters. But I take your point that you can't really fix a problem with the Adobe pdf printer software, and since the Snagit 8 printer and the HP8250 work correctly, this is more likely a bug in Adobe's software anyway, and not worth Gnumeric developers' time.
Andreas : The subject presumes that the solution is to set the style-only flag on xls import if a PRINT_AREA is defined. However, as you point currently we always define it, which makes a hash of that solution. There is a question of whether or not we should be defining it automatically. Paul : colour and border and part of styles in gnumeric parlance. To count them as content would render the entire style-only flag useless. What would remain as a style that wasn't content ? The goal of this is to allow people to format an entire col/row without forcing them to print the entire thing.
Jody: I still don't understand how this relates to xls import/export.
I have changed gnumeric's behaviour. If the print area is set to anything but the whole sheet, exactly the printarea will be printed (unless the user chooses "ignore printarea"). This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.