Re: Another gnumeric printing problem

[Richard Bumby <bumby math rutgers edu>]

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
> http://mail.gnome.org/mailman/listinfo/gnumeric-list
>  
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
 http://www.math.rutgers.edu/~bumby