Marvin Renich wrote: > * Neil Williams <[EMAIL PROTECTED]> [060814 15:14]: >> I'm downgrading this bug to wishlist because in normal / common >> operation, it's just so unlikely.
> While I agree with your assessment to downgrade the bug, I would prefer > "minor", as it produces a report with missing data. "Missing data" means loss of data from permanent storage, i.e. your gnucash data file. Any data that is hidden from the printed report (remember, the gnucash window display is fine) is retained in the original data file so the report can be regenerated and the workaround below solves the problem for these occasional line wrap problems. There may be missing print characters, but I don't see any missing data. > The behavior that I would like to see is to break inside a long word if > that is necessary to fit the report within the page width. Agreed. Somehow, I don't expect it to be as easy to do in Scheme as it is for any HTML browser. HTML expects lines to be wrapped, I'm not sure it's so simple in the gnucash report engine - after all, the display itself IS fine. It may turn out that this isn't a bug in gnucash at all, it is increasingly likely that this bug is actually in the "hand-off" from the gnucash window to the print engine. At the moment, I'd say it is 60:40 that this bug is not a gnucash bug. I can't say yet if it's a bug in CUPS or in one of the rendering libraries or something in libgtkhtml. The gnucash report is created to fit the available *display* size, gnucash knows nothing about paper sizes. That the display size isn't printable is not really down to gnucash - it is usually the job of a print driver to scale a printout to the available paper size or refuse the print job. You don't set the paper size in gnucash, it's set in the Print dialogue which is raised by CUPS (or whatever else is used). i.e. paper size is printer and printer-driver specific, not determined by gnucash itself. If you could print on A3 (or even A4 landscape), the problem would disappear. If your printer only worked with A5, reports could be unusable but that would be just a bizarre printer. :-) (You might want to try landscape format, see if your printer supports it.) IF gnucash could handle the paper size and orientation itself, reports could be fully paginated - they are not, report lines are commonly split when the printer reaches the bottom end of the printable area. You are seeing the same effect, just on the right margin instead of bottom margin. It's an integral part of printing reports as images (using pretty fonts etc.) compared to the old dot-matrix-style line print from the days before GUI's. It comes down to the fact that gnucash is not a wordprocessor or DTP package. It is unlikely that gnucash is going to support full pagination akin to OOo any time soon. In the meantime, reports will continue to be subject to the whims of CUPS et al with right and bottom margins preventing some content being printed. As above, I'm tempted to consider this as "not the fault of gnucash". Out of interest, if you print to a PDF does the PDF driver shrink the report to a suitable size? I haven't tried, just curious. >> GnuCash does it's best to display your data in the available screen >> space. If you want to print such reports, the easiest solution is to >> export to HTML from the gnucash menu, view the HTML in any-browser and >> print from there. >> > > Thanks, this is a good workaround. > > ...Marvin -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: OpenPGP digital signature
