Re: Another gnumeric printing problem

Dave Feustel wrote:

On Thursday 09 June 2005 02:55 pm, Morten Welinder wrote:
To reiterate, the entire gnumeric print dialog is buggy,
buggy, buggy. The rest of gnumeric is working well for me.
That is what you say.  And say again.  And again.  It is not useful!
I really wish you would back it up with a coherent statement as to
what is wrong.

I believe, on the basis of the various print problems I see, that qa testing
on the print dialogs is either not done at all or else done minimally. Prove me wrong by pointing me to a url where the print test procedures are that
are used to test the gnumeric print functions so I can convince myself
that the feature testing is comprehensive. Try doing a print to pdf file
twice in a row without changing the output file name and see if gnumeric
crashes when you do so. IT does 100% of the time on my system.

Having said that, I concur that filing bugzilla reports is the best way to
get the bugs fixed. My problem is that I don't have time to  file (much less
learn how to file) bug reports while I am trying to work around print problems
as I attempt to meet real-time report deadlines. I would prefer to upgrade
to the most recent gnumeric and see if the print problems go away.
The question is how to do that without changing operating systems since
one of the disadvantages of using OpenBSD is that the packages are almost
always out-of-date.
gnumeric-list mailing list
gnumeric-list gnome org
I selected this message from a rather long thread to automatically include some background.

By now other postings in this thread have settled that gnumeric relies on gnomeprint for printing, so that difficulties in printing may not be symptoms of problems in gnumeric itself. It may be that something in the data is incorrectly processed in preparation for printing, but that can't be settled without an example of a worksheet that causes difficulty in printing.

I have no problems with the print dialogs, except when I hit the "print" button before making sure that I have made the correct selection of all options. The "print preview" (which worked well in release 1.0.8, which is still running on my office machine, and continues to be useful on other releases that I have used) is very useful in getting the intended result.

Working around printing problems on a spreadsheet is easy. You can use a separate area of the sheet too copy just what you want to print together with extra markup information and copy this area into an editor instead of using an export utility included in gnumeric. Although I was led to this by problems with gnomeprint, I find it useful in cases where most of the changes in what I want to print are in headers and footers. Instead of navigating the dialogs, these changes can be made in the TeX file that controls the typesetting of files that are otherwise fairly static and obtained by extracting a small selection from the workbook (they are signin sheets that I circulate in to take attendance in my classes).

I did an experiment in which I took a page of one of my gnumeric worksheets and printed to pdf using the version 1.2.x that was included in Fedora Core 3. I was able to view and print the result from Acroread with no difficulty. I did not try printing directly with the CUPS system on my system since I have not yet checked the setup of that system to see if it had a reasonable filter for printing pdf files. However, I did view the pdf file in an editor. There were no syntactical flaws: all objects made sense and were cross-referenced in a sensible manner. DOS line-endings were used throughout. This made viewing in emacs on a linux system awkward because of all the "^M" clutter, but it is robust on all systems, and the standard "binary second line" to warn file transfer programs that the file should be transferred in binary mode was present. However, there were some curious features. The page content was not compressed (most programs writing pdf usually compress pages), so I could easily see the printing instructions. A great deal of effort was spent outlining each cell of the sheet before inserting its contents, so the actual content, including line feeds and tabbing, was between 1/3 and 1/2 of the file. A lot could go wrong with things that you would never see. However, the use of the font was efficient. Compression was used for much of the font data and the font was excerpted with only the characters actually appearing in the document included, and a special encoding vector was created to list these. This is unusual and may have confused the pdf filter in your print system.

I also did not try writing to an existing pdf file. The crash that this causes on your system may be extremely system dependent, but the gnomeprint folks should be encouraged to look at it. Almost everything that I have created in pdfTeX has written to the same file many times, usually while Acroread was viewing the existing version. However, evidence suggests that Acroread was not keeping the file open while viewing it. If something was using your file, it may have reacted badly to another program trying to write the file.

Since ghostscript and one of its various viewers should be available for your platform, I repeat my suggestion that printing to PS instead of PDF is likely to be better behaved.

--RT Bumby
 Rutgers Mathematics Department

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]