Open the report options and change style sheet to "CSS" (I think that's what it's called).  Then, you can use the menu entry Edit->Stylesheets, select Default-CSS and Edit, and then change the fonts.

Using Edit->Stylesheets, you can create stylesheets based on the base template, so you can have multiple stylesheets, each with different fonts.

Not all reports use the fonts correctly, but a lot/most do.

Does this fix the problem?

Created attachment 141110 [details]
Example Report Printout

I have the same problem.  This is the first time I have ever installed gnucash.   All of the reports do the same thing.  The output (see attachment) is in minuscule font in the top, left, inch or so of the page.

Changing fonts in the Default-CSS setup does not affect the report.

You also need to change the stylesheet to "Default-CSS" in the report options (General page, I think).

Changing from default to default-css caused a change in the display of the report (on screen) but when you hit file, print - you get the same result.

bump

bump bump

(In reply to comment #6)
> bump

Are you also on Windows?

Sorry for the delay - yes, WinXP.  I can export the report as HTML and it will print properly from Firefox 3.5.2.

PS - I updated to gnuCash 2.3.4 and see the same behavior.

FWIW, I have a Brother 5350 and the PDF's that I sent were printed directly using PDFCreator, but both appeared the exact same, so I don't think it is a printer issue.

I'm on WinXP - GnuCash 2.3.4 - Report printing to pdf file using any of the stylesheets under Options still results in small print.  I export the report to a file and then open with MS Excel and print from there.  If I open with MS Word, some of the numbers split/wrap to a new line.

Work Around - As you said, Eric.... The only work around I have found is to export the report (I used HTML).  Then print from Firefox (or Excel in your case).

The problem looks like a decimal issue when calculating printer page size.  But that is just my uninformed guess.

We're using an older version of the webkit html engine on windows built by someone else because I have not been able to build one due to problems with its dependencies.  Maybe I need to try again.  I don't see the problem on linux, but maybe the version we're using doesn't interact with the windows print system properly.

For now, use the workaround.

Just to clarify - the HTML export (and apparently the Excel export) works fine, I think that this is just a scaling issue as you can zoom in on the report and all is good.

FYI: The problem continues in v2.3.5

TESTED- Clean install of v2.3.7 on Fresh Install of Windows 7 Pro (RTM) - Printing problem continues.

Same Problem on our Vista Home 32-bit where we started using GNUCash 2.3.3 for our organization's 2010 books with live data.

I installed 2.3.8 over 2.3.3 on my Windows 7 Home Premius desktop today to see if the printing is still the same tiny font.  It is.

(In reply to comment #17)
> Same Problem on our Vista Home 32-bit where we started using GNUCash 2.3.3 for
> our organization's 2010 books with live data.
> 
> I installed 2.3.8 over 2.3.3 on my Windows 7 Home Premius desktop today to see
> if the printing is still the same tiny font.  It is.

An off-topic remark for this issue but important anyway:
Let me remind you that the 2.3.x series is the UNSTABLE development version of GnuCash. Bugs in this version may cause unexpected data loss or corruption. I would not recommend using it for live data yet.

Removing target of 2.3.X since we will be sticking with gtkhtml on windows and this is webkit-related.

Not a critical bug. Lowering severity to major (IMHO it is still normal).

I have switched the windows build to use gtkhtml until webkit is fixed.

See also bug #610051.

My attempt to switch to GtkHtml was not successful. With GtkHtml as backend, gnucash on Windows crashes whenever a report is opened.

So the report printing problem is currently not solved:
- Webkit produces fonts that are too small
- GtkHtml crashes.

So either this bug or bug #610051 will have to be resolved before 2.4.

Just to be sure this isn't forgotten, I will add target 2.3.x to both reports. Only one has to be resolved before 2.4.

The PDF in comment 2 is about 8 times smaller than it should be. One possible cause of this bug is if gtk_print_operation_set_unit (op, GTK_UNIT_POINTS) is not called. gtkprint defaults to GTK_UNIT_PIXEL - a useless unit to be using with printers.

On Linux GTK_UNIT_PIXEL units are 1 unit = 1/72 inch (the same as GTK_UNIT_POINTS as well as PostScript and PDF units). On Windows GTK_UNIT_PIXEL units are the GDI device units which for printers is the dpi resolution. So for a 600dpi printer 1 unit is 1/600".

If the application was developed on Linux and assumes the default gtkprint units are always 1/72" inch the output on Windows using a 600dpi printer will be 72/600 = 0.12 of the size (or approximately 1/8 of the size).

PDF Creator was used to create the PDF in comment 2. PDF Creator has a default printer resolution of 600dpi. This can be changed in printer properties. A workaround would be to change the PDF Creator printer resolution to 72dpi.

(In reply to comment #23)
> One possible cause of this bug is if 
> gtk_print_operation_set_unit (op, GTK_UNIT_POINTS) is not called.

Does that mean we should call this function somewhere in our "Print" button callback?

Fixed in r18720

*** Bug 611395 has been marked as a duplicate of this bug. ***

*** Bug 615249 has been marked as a duplicate of this bug. ***

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=591177. Please update any external references or bookmarks.