Switch printing from reportlab+poppler to cairo

[ockham]

I think we should reorganize the way we print. AFAICS, we're currently using reportlab to create a PDF, render it via poppler to a cairo graphics context (GC), which is then printed via gtk.PrintOperation. This involves relying on two external dependencies, with the additional issue that poppler's Python bindings are not too actively maintained, and only inofficial binaries exist for Windows, where I haven't managed to get printing to work yet -- see issue #337.

I think we could drop both poppler and reportlab dependencies by just using cairo directly to draw to a GC which we can then (again by use of gtk.PrintOperation) either export as PDF, or print.

(BTW, given that most users will consider printing somewhat of a "core" feature, I believe it shouldn't be part of a plugin but part of Gourmet core.)

Update (2014-02-23): Work for a cairo based plugin is underway in the cairo-print branch. Currently, its biggest issues yet to be solved are:

• misplaced recipe image
• incorrect pagination
• no multi-doc export
• ignorance of page layout settings

Alternatively, poppler will become available again once we switch from PyGTK to PyGObject, as it's part of the PyGObject/GTK+3 Windows bundle.

[thinkle]

For what it's worth, the printing actually allows different plugins. It's
possible they're disabled for some reason now, but there used to at least
be a simple "lprprint" that used lpr and printed from text. I also at one
point had written all of the printing in a Gtk print library which the GTK
folks then promptly abandoned, making me hesitant to switch again to a gtk
recommended process.

Reportlab is elegant, well supported, used by lots of web apps and other
third parties and therefore likely to continue existing. Reportlab allows
many nice options as far as layout that are not worth reimplementing with
GTK tools.

So, in short, I would recommend we:

1. Figure out why we stopped supporting simple "lprprint" style simple text
   printing and reimplement if easy.
2. Otherwise, stick to PDF + poppler as a recommended printing method.

That's my 2 cents anyway. I'm hesitant to put a lot of time into rewriting
layout code etc. using GTK code when reportlab already worked -- my memory
of the last time doing this was feeling like I was basically reimplementing
reportlab at a lower level in order to do printing in the correct GTK way.

Tom

On Mon, Mar 11, 2013 at 7:06 PM, Bernhard Reiter
[email protected]:

I think we should reorganize the way we print. AFAICS, we're currently
using reportlab to create a PDF, render it via poppler to a cairo graphics
context (GC), which is then printed via gtk.PrintOperation. This involves
relying on two external dependencies, with the additional issue that
poppler's Python bindings are not too actively maintained, and only
inofficial binaries exist for Windows, where I haven't managed to get
printing to work yet -- see issue #337#337
.

I think we could drop both poppler and reportlab dependencies by just
using cairo directly to draw to a GC which we can then (again by use of
gtk.PrintOperation) either export as PDF, or print.

(BTW, given that most users will consider printing somewhat of a "core"
feature, I believe it shouldn't be part of a plugin but part of Gourmet
core.)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/708
.

[ockham]

I know about the option to have multiple printing plugins. Still, I guess this is something that'd rather confuse the average user who "just wants to print" -- normally rather using a fancy than a simple text layout.

I think I can understand you wouldn't like to give up a convenient and established toolkit such as ReportLab, particulary if this involved redundant re-implementing (though if we did this in cairo, we could maybe re-use e.g. the star drawing code for the rating widget, if we ported that to cairo, too). I also believe that poppler seems quite well maintained, but again, pypoppler unfortunately isn't.

I'm curious about the Gtk print library code you mentioned. Has that ever been part of gourmet? (A quick search for commits containing strings "reportlab" or "PrintOperation" didn't turn up anything.) If you can still find that code, I'd like to at least try out if we can make a reportlab/poppler-free, cairo/pango-only printing plugin as a 3rd alternative, maybe even in a branch for now. TBH, I haven't yet looked into pdf_exporter.py or the reportlab API very deeply, but I think that pango does have some useful high-level typesetting features too, doesn't it?

BTW, just stumbled across WeasyPrint, which seems to use cairo+pango to render HTML+CSS into PDF.

[thinkle]

It looks from the ChangeLog like the move to the current printing setup
happened starting in 10/28 and then was more or less finished in 11/2009.

The printing code used to be in src/lib/exporters/gnomeprinter.py

Here's some info on gnomeprint:
https://developer.gnome.org/platform-overview/2.32/apx-modules-desktop.html.en

Attached are the two gnomeprint-related files from the 0.14.10 release.
You'll see we had to do simple things like paragraphing on our own using
the old gnomeprint API. I assume much of this will translate to GtkPrint --
https://developer.gnome.org/gtk3/stable/Printing.html.

It's beyond my git-foo to recover these files using git, so I just grabbed
the old files from SF.

Tom

On Tue, Mar 12, 2013 at 6:28 AM, Bernhard Reiter
[email protected]:

I know about the option to have multiple printing plugins. Still, I guess
this is something that'd rather confuse the average user who "just wants to
print" -- normally rather using a fancy than a simple text layout.

I think I can understand you wouldn't like to give up a convenient and
established toolkit such as ReportLab, particulary if this involved
redundant re-implementing (though if we did this in cairo, we could maybe
re-use e.g. the star drawing code for the rating widget, if we ported that
to cairo, too). I also believe that poppler seems quite well maintained,
but again, pypoppler unfortunately isn't.

I'm curious about the Gtk print library code you mentioned. Has that ever
been part of gourmet? (A quick search for commits containing strings
"reportlab" or "PrintOperation" didn't turn up anything.) If you can still
find that code, I'd like to at least try out if we can make a
reportlab/poppler-free, cairo/pango-only printing plugin as a 3rd
alternative, maybe even in a branch for now. TBH, I haven't yet looked into
pdf_exporter.py or the reportlab API very deeply, but I think that pango
does have some useful high-level typesetting features too, doesn't it?

BTW, just stumbled across WeasyPrint http://weasyprint.org/, which
seems to use cairo+pango to render HTML+CSS into PDF.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/708#issuecomment-14767961
.

[ockham]

Another source on this topic:
http://lethalman.blogspot.co.at/2009/05/render-tables-with-pangocairo-like.html

[ockham]

Thanks! I'll take a look at it.

FYI, I managed to restore src/lib/exporters/gnomeprinter.py from git by searching the string "gnomeprint" in the git log, locating the commit where src/lib/exporters/gnomeprinter.py had been deleted, and then checking out that file from that commit's predecessor, by

git log -Sgnomeprint
git checkout 64fdb^ -- src/lib/exporters/gnomeprinter.py

[ockham]

FWIW, cairo doesn't produce hyperlinks in PDF (yet), but we could use https://github.com/Kozea/WeasyPrint/blob/master/weasyprint/pdf.py to post-process the cairo-generated PDF.

[thinkle]

Just caught onto this thread.

I would hesitate to rewrite printing to depend on Cairo, partly because I
already implemented GTK-supported printing once via the gnomeprint
library, and then the GTK folks unceremoniously abandoned that library and
left us stranded, which is why I moved to the ReportLab + Poppler solution.

Also, ReportLab is really very nice and makes it trivial to do multiple
columns, recipe cards, font-sizes, and so forth. I'd much rather see energy
go into improving existing printing than re-writing from scratch at a lower
level of abstraction. It seems to me that the folks who make ReportLab will
do a much better job than us fixing and maintaining a decent
printing-to-PDF solution. I also have more faith that ReportLab will
continue to offer that functionality than I do in cairo or anything related
to the GTK stack, truth be told.

If there's an issue with dependencies, maybe that's a packaging bug rather
than a programming one.

My 2 cents.

Tom

On Sun, Sep 1, 2013 at 3:21 AM, Bernhard Reiter [email protected]:

FWIW, cairo doesn't produce hyperlinks in PDF (yet), but we could use
https://github.com/Kozea/WeasyPrint/blob/master/weasyprint/pdf.py to
post-process the cairo-generated PDF.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/708#issuecomment-23620219
.

[ockham]

(FWIW, I started porting the old gnomeprinter.py exporter to the new plugin interface and Gtk.PrintOperation a couple of days ago in a local branch. So far, I can print the recipe image and need to investigate printing text paragraphs next.)

I'm okay with considering this a packaging bug, but then again, as far as Windows is concerned, we're our own packagers, so we're the ones who're supposed to fix it. (Printing on Windows to me seems to be one of the most requested features that people are currently missing, see recent questions on Launchpad.)

I tried to build pypoppler Windows binaries a while ago already and failed. There hasn't been any pypoppler release in almost 4 years.

So to me, it seems logical to resort to Gtk (which includes Cairo) as we're depending on it already. Conceptually, I think this is somewhat equivalent to resuscitating lprprinter, which AFAIK also doesn't require any extra dependencies, but IIRC can only offer much less appealing layout. I wouldn't really want that to be the only printing option for Windows users. I also think that cairo and pango are at least somewhat more advanced than gnomeprint was -- dealing with font settings seems to be something that pango nowadays can do quite well, but admittedly, it's the first time I'm using it in a software project.

So what's your stance on this question -- how do we enable our Windows users to print their recipes?

[ockham]

Just found pypdflib, which seems to be some sort of high-level abstraction layer based on cairo and pango. We might want to give it a try -- the last commit to their git repo was in 2012.

(edit: 2012, not 2010)

[thinkle]

Fair enough. I haven't tried building popler on Windows, so perhaps I
should back down. On a practical level, I wonder how terrible it would be
to just export a PDF and open it on Windows -- or if there's a commandline
switch on windows to print the file (something that might be used from a
browser, e.g.).

Tom

On Sun, Sep 1, 2013 at 6:16 PM, Bernhard Reiter [email protected]:

Just found pypdflib https://savannah.nongnu.org/projects/pypdflib,
which seems to be some sort of high-level abstraction layer based on cairo
and pango. We might want to try this -- unfortunately, it seems the last
commit to their git repo was in 2010 :-/

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/708#issuecomment-23634414
.

[thinkle]

Sent from Windows Mail