Bug 239205

Created attachment 154216 [details]
print preview of how fonts should look from gnucash

Created attachment 154217 [details]
example pdf before the patch is applied (wrong fonts)

Created attachment 154218 [details]
example pdf after the patch is applied (matches print preview)

Created attachment 154219 [details]
capture of the actual report in gnucash

I mean to say that the print preview doesn't match the fonts either.  That was
a typo.

This is the capture of how the fonts should look.

Thanks for the detailed bug report!

I'm changing the version from 'fc6' to 'devel' since it's too late to really do
anything about this in Fedora Core 6 and the problem still exists in even the
latest revision of the upstream source code repository.

The patch looks reasonable but as Paul mentioned, as of version 3.14 GtkHtml is
using GtkPrint rather than GnomePrint.  So I'll have to re-evaluate it.

It just so happens that I'm planning on ripping into GtkHtml's printing API
(again) to better integrate with GtkPrint's approach to pagination.  As it
stands now, the API makes it very difficult to honor user selected page ranges
when printing.

I'll make sure to expose the default font in the API, as Paul suggests.

Also happens in F7 as gnucash relies on gtkhtml38.

Given the small number of applications that are even using gtkhtml38, don't you
think it would be safe to apply this patch and push to F-7 updates & rawhide?

(this is on F-7)
repoquery --all --whatrequires libgtkhtml-3.8.so.15
gnotime-0:2.2.2-7.fc6.i386
gtkhtml38-devel-0:3.12.3-4.fc7.i386
gnucash-0:2.0.5-3.fc7.i386
gtkhtml38-0:3.12.3-4.fc7.i386
gnomesword-0:2.2.3-1.fc7.i386

As it's changing the code in a non-upstream way... not really. Matt, as
upstream, what's your opinions on changing the dead-end code in this way?

I haven't tested the patch at all, but it looks reasonable and doesn't break any
interfaces.  Might be worth trying it out in Rawhide.  If it works that could
increase its chances of a version of the patch that works with GtkPrint getting
accepted upstream.  I'd be leery of putting it in Fedora 7.

Heh. Of course, in the near future gnucash will probably get upgraded in rawhide
to a version that uses the current gtkhtml. 

Added in -5.

(In reply to comment #9)
> I'd be leery of putting it in Fedora 7.

Looking at the two other programs that actually depend on gtkhtml38... Neither
of them has printing capabilities.  If the patch only affects printing, I don't
see how this is even risky. (Maybe the patch affects things other than printing?)

The patch modifies htmltext.c, which may affect general rendering of HTML and
not just printing.  But probably in a good way.

You might also be interested in the GtkHtml printing work I'm currently
targeting for the next GNOME release.  It extends GtkHtml's printing API to
allow for printing individual pages or custom page ranges, among other things. 
See [1].

[1] http://bugzilla.gnome.org/show_bug.cgi?id=446894

(In reply to comment #10)
> Heh. Of course, in the near future gnucash will probably get upgraded in rawhide
> to a version that uses the current gtkhtml. 

Doesn't seem to affect the gnucash/gtkhtml combo in rawhide.

Oops, if you've upgraded to 2.1.4, you're using gtkhtml-3.14.

(In reply to comment #14)
> Oops, if you've upgraded to 2.1.4, you're using gtkhtml-3.14.

Yeah, which was my point.  gnucash-2.1.4/gtkhtml-current doesn't seem to carry
this particular bug.

Oh, I thought you meant the *change* didn't fix it. If it's working now, I'll
close this.

Let me be more clear:

This bug does not exist with gnucash-2.1.4/gtkhtml-current in rawhide.

:)

Sorry for the terseness I sometimes exhibit!