GNOME Bugzilla – Bug 350408
Incorrect fonts in reports and their print preview
Last modified: 2018-06-29 21:11:04 UTC
Please describe the problem: The program doesn't respect font choices when printing reports. It substitutes the chosen system font with another, therefore causing the report to look different on the screen and on the print preview/PDF/printout. Steps to reproduce: 1. Create a report. 2. Go to print it. 3. Pick print preview. Actual results: The fonts in print preview are incorrect. Expected results: The fonts should match the ones on the screen. Does this happen every time? Yes. Other information: The screen shot of program look and print preview look will be attached.
Created attachment 70473 [details] Incorrect fonts in print preview On the left is how fonts look in GnuCash reports. On the right is what they look like in print preview or created PDF. BTW, this is on Fedora Core 6 (Development) with Deja Vu fonts.
Same behaviour is displayed on SuSE 10.0 with GnuCash 2.0.1 (self-compiled). The gnome-print version is 0.37-7.
*** Bug 361828 has been marked as a duplicate of this bug. ***
I think this bug can be confirmed as a problem. Three people, including the report, have noted this problem.
Tried it with version 2.0.2 (2.0.2-1.fc6) in FC6 updates-testing. Still the same.
Just upgraded gnucash to version 2.0.0 from 1.8.12 and have the same problem with printing fonts. Thay are HUGE and my customer invoices look goofy. I've tried a manual compile of gnucash 2.0.2 on FC5 and FC6 with the same results. I think it is related to the call to gnome_font_find_closest((guchar *)"Sans Regular", 12) in the print-session.c file.
Just upgraded to gnucash-2.0.4-1.fc6 and the issue is still there.
I'm seeing this problem as well with gnucash-2.0.4-1.fc6. Apparently as a result, the report does not fit on the page and is cut off. This seems fairly critical (at least for me), as there does not appear to be a workaround.
I would have thought that this would have been classed as a fairly serious regression since printing worked fine in 1.8.x and now doesn't work in any useable sense. Maybe the reporter should change the priority and severity to highlight that people expect printing of reports to just work.
(In reply to comment #9) > I would have thought that this would have been classed as a fairly serious > regression since printing worked fine in 1.8.x and now doesn't work in any > useable sense. > > Maybe the reporter should change the priority and severity to highlight that > people expect printing of reports to just work. > My case is anecdotal evidence in support of this. I never thought to test printing of reports before upgrading, until I actually needed it (today). As a follow-up to my earlier comment, I did find a partial workaround, which was to remove some columns from the register report: Num and Balance. This allowed the report to fit on a page without being cut off on the right. It's not a great solution, but maybe better than not printing at all.
Sorry, one more note. I also tried printing in Landscape orientation to get around the horizontal cut-off problem. In that case, multiple lines seemed to be missing in between pages, suggesting that the report was severely cut off (vertically). I haven't had time to pin that down precisely as a bug, but it may be worth noting.
I have the same problem, and so do my clients. If you have too many columns, the page gets clipped on the right. What has worked somewhat is to export as an HTML file and then print the report in a browser (eg firefox). This seems to work fairly well (though I did have some margin problems with at least one report). Incidentally, the title of this page is misleading. It should be something along the line of 'Incorrect printing and preview of reports' or something. gnucash 2.0.2
The situation may improve some when this bug is addressed: http://bugzilla.gnome.org/show_bug.cgi?id=405750 With the current situation, you may be able to use the following workaround: Under Options/Display, uncheck 'Use Full Account Name?' and 'Use Full Other Account Name?'. The report should print properly if you don't use too many columns. For example, having the following columns works properly (at Application Font size 10 and 13 at least): Date Num Description Other Account Name Running Balance Totals However, being able to reduce the font size, or better yet having the report scale automatically to a smaller font size when the width is too large would fully address this issue.
Still the same in gnucash-2.0.5-1.fc6.
Here is my fix for this problem http://members.iinet.com.au/~paulone/gnucash/
Paul's fix in comment #15 worked great for me.
I'd just like to add a "Me too" -- this is a severe bug and has been confirmed many times over (Gnucash 2.0.2 on Ubuntu 7.04, in my case).
Me too, this is very unprofessional, and makes gnucash impossible for people running a business
I'm trying to keep my mouth shut about how bad this is, but seriously we're fast coming up on this bugs first birthday. And it's still unresolved. Or, put another way, it appears that the next stable version of gnucash is nearing completion and for a complete release cycle we haven't been able to do something as simple as print a report without having to export it to html and then print from there (after editing the html so that things are aligned properly).
Yeh try paying a receptionist to go thru and export to HTML, print to PS and convert that PS to PDF, then add that attachment to email, now that this for 300 invoices - this is definately not cool, as well as trying to tout all the benefits of opensource technology...
What is the suggested way to improve this? Interesting the invoice report itself looks really really good, what generates this? can this be converted to postscript (and subsequently to PDF?) Maybe we add another layer where you can see how the current print setup fitswith the report by showing the page width (light blue lines for the border of an A4 behind the report) etc ? I dont mind doing some work on this, but these kinds of issues always come up in gnome applications, what is the gnome's official view of how to handle printable information, do we show the print preview blended in with it?
The issue is known -- due to a bug in libgtkhtml3.8, the printed report uses GnomePrint's default font -- and comment #15 suggests a patch for GnuCash that allows different fonts. So it's just the developers sleeping on the job...?
We really appreciate the work on this software-- the fact that it is so useful is why so many people are relying on it and hope this problem can be fixed. I think the issue is that this bug should be prioritized above any new features. If there are people here with ability to work on this, maybe the developers could outline debugging or coding tasks or an overview of the preferred way to fix this.... (I'm a programmer and willing to try, but I'll be completely new to gnome and printing)
You might start by getting this bug assigned to the correct component (gtkhtml). Please note that the version of gtkthml that gnuchash is built against is also not being actively developed any longer, so don't hold your breath on getting it fixed. See also: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239205 Newer versions of Gnucash/gtkhtml in Fedora rawhide does not exhibit this problem.
Sorry, I'm not following you here. You're saying that a) this is not gnucash's problem and b) there are now newer versions of gtkhtml that fix the problem. So does Gnucash 2.2 -- which I see was released yesterday -- require this newer version of gtkhtml, so distributions will be built correctly and printing will actually work?
I am no expert, but I believe that everything you just said is true. [1] [1] It may not "require" newer gtkhtml, but when built against it, it does seem to fix the problem.
Indeed this works now with GnuCash 2.2.0-1.fc7 (i.e. the system font is obeyed). The produced PDF looks a bit funny with DejaVU LGC fonts (font spacing and kerning is weird - some letters are either too far apart or too close together), but that's probably a different cattle of fish. Also, for whatever reason, my invoices (which fit on one page) now have page 2 which is completely blank.
Yeah, I noticed the same second page issue too (running F7). Also, the items in the various columns don't line up very well. (And certainly aren't wysiwyg).
(In reply to comment #27) > Indeed this works now with GnuCash 2.2.0-1.fc7 (i.e. the system font is > obeyed). > > The produced PDF looks a bit funny with DejaVU LGC fonts (font spacing and > kerning is weird - some letters are either too far apart or too close > together), but that's probably a different cattle of fish. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245852 > Also, for whatever reason, my invoices (which fit on one page) now have page 2 > which is completely blank. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245853
Created attachment 94162 [details] [review] Patch from http://members.iinet.net.au/~paulone/gnucash/print-size-fix.patch
Still the same problem on 2.2.1 using Ubuntu 7.10 with gtkhtml 3.14 installed.
John, does the patch in comment #30 fix it for you?
Derek. No the patch in #30 did not work for me.
I confirm that the problem still exists on 2.2.1 running on Ubuntu 7.10 with gtkhtml 3.14
At this point we still believe the problem is GtkHTML.
What is the bug id for the GtkHTML issue so I can weigh in too? Thanks, Jeff
I'm afraid there isn't a GtkHTML bug # that I know of, as it's only an assumption that it's GtkHTML. Nobody has done any work to track it down or create a test case.
Yeh the problem is that gtkHTML cant be assigned a default style sheet so in the end, nothing lines up, and last i looked at gtkHTML code, it just hard coded these font sizes (complete with #define FONT_SIZE 12!) So the problem is that gnucash needs to use a smarter engine for producing/exporting these reports, or some XSLT type methods for rendering them ?
There's been talk about migrating to GtkMozEmbed or WebKit. But no developer time to actually do the work.
Can we raise a bounty on this?
> Here is my fix for this problem http://members.iinet.com.au/~paulone/gnucash/ I raised the font problem on the GtkHTML mail list (before posting Comment #15) and their responce was that they don't fix old versions and the best course of action was to upgrade to the new version. I was in no situation to test if the new version had fixed it. The easyest fix would be to put my GtkHTML patch in the Ubuntu GtkHTML library.
It never ceases to amaze me how poorly gtk applications integrate into the desktop
Can we get the priority of this one raised? If the accounts are to go to my accountant and get filed with the Powers That Be, they need dead-tree format. And this bug isn't just cosmetic, it causes numbers to fall off the printed page => missing money as far as the government's concerned. This is rather show-stopping IMHO.
I Just compiled gnucash 2.2.5 Still the same problem. Please raise priority! Thanks.
I think I might just start porting the source code for GnuCash over to KDE just to get a properly working print system. The fewer reasons to install Gnome-based libraries, the better. After browsing the bug reports, it looks to me like this bug is a combination of several other bugs in several other libraries. I just compiled 2.2.5 against the default Debian Etch libraries and the bug is identical to the bug I was experiencing with the GnuCash 2.0.* that was installed through apt repositories. As a temporary workaround, I am exporting reports as HTML files and then printing them from Konqueror. This seems to work quite well and gives me more printing options than either GnuCash or Firefox. It also gives me the chance to apply a much nicer CSS style to reports before printing.
(In reply to comment #45) > I think I might just start porting the source code for GnuCash over to KDE just > to get a properly working print system. The fewer reasons to install > Gnome-based libraries, the better. After browsing the bug reports, it looks to > me like this bug is a combination of several other bugs in several other > libraries. > > I just compiled 2.2.5 against the default Debian Etch libraries and the bug is > identical to the bug I was experiencing with the GnuCash 2.0.* that was > installed through apt repositories. > > As a temporary workaround, I am exporting reports as HTML files and then > printing them from Konqueror. This seems to work quite well and gives me more > printing options than either GnuCash or Firefox. It also gives me the chance to > apply a much nicer CSS style to reports before printing. > I completely concur, This is such an old, ugly bug. What do people do with invoices? PRINT THEM. What does gnome fail at? PRINTING. Gnucash is an excellent application, but it is at the mercy of the fundamental issues with the gnome desktop, Printing and Integration (where I may ask, can I get GnuCash to trigger Evolution to re-email all open invoices? Or even 1 invoice?) Plus other yucky bugs, like I've seen people export the invoice as HTML then click "save" from the "File" menu - but this actually saves your GNUCASH DATA as the filename you are asking for - and then email this as an attachment! brilliant! Brice - how much do you think is involved todo this? Is a $200 USD bounty sufficient?
Yeah, currently I'm having to export to HTML. Edit the file to get the address right aligned and then print them from a browser (Firefox). Fortunately, Firefox not prints to PDF, but in the past I had to print to ps and then ps2pdf them. All this so I can send a client a PDF (in an email) that they can read and possibly print. Shame GnuCash!
Brice, Re Comment #45.. "porting" to KDE will probably take you a few man-years of effort. I wish you luck on that. Re comment #46: GnuCash can "print to PDF" and the invoices work fine for me. This is a bug in GtkHTML and it's printing integration. We've been talking about converting out GtkHTML (which SUCKS) to something more modern, like WebKit. But none of the current developers have the cycles to do that work. It would be a decent-sized project but it would also be fairly straightforward to swap GtkHTML -> WebKit-Gtk if someone wanted to take on the task.
I can confirm same problem with version 2.2.5. But the patches at Comment #15 worked for me with a little change for one file that i had to do by hand. You can download the new patch for version 2.2.5 at the same place, Comment #15. I tested them with gnucash version 2.2.5 and gtkhtml version 3.8 (3.10.2).
While I could take the patches and apply them to gnucash, that wont help because you still need changes to GtkHTML. But comment #33 shows that changing GnuCash is not sufficient.
(In reply to comment #15) > Here is my fix for this problem http://members.iinet.com.au/~paulone/gnucash/ > Hi, I am having problems with compiling gnucash2.2.5 (more accurately a bug with guile and slib that has had me banging my head against the screen for a few hours) so am so far unable to install the patch. Unfortunately the older .deb Paul has uploaded that contains the patch and version 2.0. doesn't appear to get on with Ubuntu Hardy Heron. Is there a possibility that a .deb can be compiled of 2.2.5 with the patch included? I have been looking for a solution to this problem for months... clearly looking in the wrong place before! Thanks, Ben
Hi, I've recompiled gnucash 2.2.4 and libgtkhtml3.8 3.13.5 that comes with Ubuntu Hardy 8.04LTS with my patches at http://members.iinet.com.au/~paulone/gnucash/
Paul, have you submitted this patch to the trunk? If so, this bug can be closed out.
Err... is there still a patch waiting to be committed into gnucash (trunk and stable branch)? I didn't understand the discussion here. If there is, I'd like to go ahead committing it in the next days.
I second the nclusion of the patch
Applied the patch to trunk r17727, but with some manual clean-up. The part in report/report-system/html-acct-table.scm was already applied from bug#366934, r16723. The parts in gnome-utils/gnc-html.c is valid only for the part GTKHTML_USES_GTKPRINT is false; i.e. if GtkPrint is active, this patch is not (yet) being executed and an additional patch is necessary.
I am experiencing this issue with v2.3.15 r19580 compiled on Ubuntu 10.04 i am noticing that the font used when printing a report or invoice is different than what is shown on the screen. in fact, it seems, when printing, my system font is used.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=350408. Please update any external references or bookmarks.