Zim

Add printing support

Bug #206168 reported by Jaap Karssenberg
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Zim
Confirmed
Wishlist
Unassigned

Bug Description

Zim does not have printing support. There is a work-around to "print" to a browser, so you can use the browser to do the real printing. This is implemented in the "PrintToBrowser" plugin.

In order to do printing natively we need to use the Gtk printing interface (introduced in Gtk+ 2.10). This involves rendering the contents of the page to a cairo context. Examples can be found on the internet how to do this for text only using Pango. We need a little bit more advanced implementation that also takes care of images.

See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343369

Changed in zim:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Jaap Karssenberg (jaap.karssenberg) wrote :

Demoted to "whish list" since there is a work around and since zim does not focus on visual layout.

Changed in zim:
importance: Medium → Wishlist
Revision history for this message
nomnex (nomnex) wrote :

What about a function to print to PDF? I am commenting on this bug following my issue printing Asian characters with custom font (see bug: 539386)

Agreed with the fact zim does not focus on visual layout, but it needs to print correctly any language and formatting applied in the Zim window (not only western languages). Can you remote the bug or advice. thank you.

Revision history for this message
Jaap Karssenberg (jaap.karssenberg) wrote :

In the Gtk toolkit there is a single interface for printing to paper and printing to PDF. So needs the same amount of work.

Fixing the bug you have with export to HTML is probably much less work than implementing a full printing interface. And we want to fix that one anyway, since export to HTML should also just work.

Revision history for this message
PascalDelcombel (pascal-delcombel) wrote :

[New Feature Request]

Would it be possible to print - ie send to HTML pages, as for any page from within ZIM- the ToDo List, from the todo list addon?

This would be great!

Revision history for this message
Jaap Karssenberg (jaap.karssenberg) wrote :

@pascal: that request is already covered in bug #319976

Revision history for this message
Michael Mulqueen (michael.mulqueen) wrote :

Direct printing in zim could possibly be accomplished like this.

1. Existing process exports to an HTML file in /tmp/
2. Use a tool like html2ps to create a PostScript version
3. Load the Postscript file using the appropriate Cairo backend
4. Use Gtk printing as usual

Of course, even this is going to take quite a bit of work for a real minority of users.

Revision history for this message
nomnex (nomnex) wrote :

Hi Jaap,
I comment on this bug because I need to print out zim page on hard paper. This is the issues I have (Fedora 13/Zim 0.48)

a) The <h>header</h> display green in the browser, but they print purple (someone confirm if it is on my end only, thanks)
b) I use the same headers layout as the page" Zim Manual:Start"

H1 or H2
Line feed
Paragraph
Line feed
H3 or H4 (no line feed between H3 and H4 and the following paragraph)
Text
Line feed
...

The HTML tags <h></h> add a line feed under the header H3 and H4 in the example above. It defeat my layout structure and increase the total length of the documents since I uses headers h3 and h4 to introduce each chapter (often very short--one line or two).

Could it be possible to implement a WYSIWYG printing output as discussed in this bug?

PS: instruct me if issues 'a' is confirmed and should be part of a separated bug report. Regarding issue 'b' user's preference layout (case by case) seems incompatible with a CSS style-sheet (global)?

Revision history for this message
Jaap Karssenberg (jaap.karssenberg) wrote : Re: [Bug 206168] Re: Add printing support

On Thu, Sep 23, 2010 at 2:21 PM, nomnex <email address hidden> wrote:
> PS: instruct me if issues 'a' is confirmed and should be part of a
> separated bug report. Regarding issue 'b' user's preference layout (case
> by case) seems incompatible with a CSS style-sheet (global)?

With respect to 'a', since the actual printing is done by the browser
this is outside of scope for zim. If you use a commonly used browser I
would be *very* surprised if you found a real bug - much more likely
due to printer settings etc.

You can change CSS behavior of the printing by changing the
_Print.html template. If you have some improvements please attach them
here - maybe they can be included in zim as a generic fix.

-- Jaap

Revision history for this message
nomnex (nomnex) wrote :

okay for "a", it must be a printer driver problem. The hex colors render fine in the browser, but the headers print purple and links are flashy green.

I would rather use **BOLD** instead of the H3/H4 than modifying the /usr/share/zim/templates/html/Print.html. I sometimes print man pages using the command man -t (or --troff) command > ~/command.pdf. Couldn't Zim use a similar command to print to PS or PDF in a WYSIWYG manner?

Relying on the browser printing functionality has some downsides:
I use "minium font size" in the browser pref. and large font (DejaVu Sans) for onscreen display. I have to disable the setting and change font/font size anytime I want to print.
The page header/footer are not well positioned on the pages. If I manually change the page margins from the browser page setup. it somewhat conflicts with the CSS margin and the page are truncated when they print.

Revision history for this message
Jaap Karssenberg (jaap.karssenberg) wrote :

On Fri, Sep 24, 2010 at 3:50 AM, nomnex <email address hidden> wrote:
> I sometimes print man pages
> using the command man -t (or --troff) command > ~/command.pdf.  Couldn't
> Zim use a similar command to print to PS or PDF in a WYSIWYG manner?

Uhm yes, but that still means we need code to render a zim page into
PS or PDF. We can do that using latex, but I don't want to have a
dependency on the latex package (which is huge) just or printing.

The new Gtk printing interface is exactly that: an API to render a PS
which is handed to a platform depended printer interface.

> Relying on the browser printing functionality has some downsides:
> I use "minium font size" in the browser pref. and large font (DejaVu Sans) for onscreen display. I have to disable the setting and change font/font size anytime I want to print.
> The page header/footer are not well positioned on the pages. If I manually change the page margins from the browser page setup. it somewhat conflicts with the CSS margin and the page are truncated when they print.

Yes, it is a workaround, direct printing would be better.

-- Jaap

tags: added: integration
tags: added: missing
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.