Print Preview Missing in GTK Print Dialog on Fresh Kali Linux — Appears After Installing Evince

Community
1

Hey everyone,

I recently did a fresh install of Kali Linux, and while testing out GTK print functionality (via the GTK widgets demo or my own simple GTK app), I noticed something odd — the Print Preview option is missing from the GTK print dialog.

However, once I install Evince (apt install evince), the Print Preview button suddenly appears and works as expected.

I’m trying to understand:

  • Why does the GTK print dialog lack a preview option by default?
  • What exactly does Evince provide that enables this feature?
  • Is there a specific package or dependency that GTK relies on for print preview functionality?

Any insight into how GTK handles print preview under the hood, or if there’s a more minimal way to enable it without pulling in a full PDF viewer like Evince, would be really helpful.

Thanks in advance!
i attached the pic of print dialog before installing evince and after installing evince

Screenshot_2025-06-23_18_46_32
Screenshot_2025-06-23_18_46_321920×1080 256 KB

Screenshot_2025-06-23_18_47_55
Screenshot_2025-06-23_18_47_551920×1080 266 KB

2

Because the print preview is based on displaying a PS/PDF render, which is generally what will be sent to the printer itself. This would require reading the PS/PDF data and rendering it, and GTK does not depend on a PDF rendering library, which would be a large dependency; additionally, the only PDF rendering library on Linux is Poppler, which is licensed under the terms of the GNU GPL, which would render GTK licensed under the terms of the GNU GPL, which in turn would make all applications using GTK licensed under the terms of the GNU GPL.

Evince is a PDF viewer, and since it’s an external process, it can be licensed under whatever terms it wants without impacting GTK. Evince is used by default on Linux systems.

On other platforms, GTK can use other print previewers. For instance, on macOS GTK will use the Preview application.

It’s also possible to specify a different preview command by using GtkSettings:gtk-print-preview-command.

That’s a question for your Linux distribution.

2 Likes
3

why do we use Evince for previewing PDFs then? Doesn’t GTK have its own default or native PDF viewer that can be used for previewing?
GTK has Cairo built-in, which is used to generate PDFs (for preview purposes). but nothing to preview the pdf.

4

I literally explained it to you.

Correct: Cairo can only generate PDF.

The only free software library that allows that is called Poppler, and since it original comes from a fork of xpdf, it is released under the terms of the GNU General Public License.

1 Like
5

Hi @ebassi ,
I discussed with yash on how we could mordenize GTK’s print dialogue, and the problem of GTK’s and Poppler’s license issue.
I proposed a solution about this:

We’ve seen that the print dialog gets its preview feature when Evince is installed. What if we followed that exact model? We could focus the project on creating a new, separate ‘previewer’ package. This package would use Poppler for rendering, and when installed, it would seamlessly provide the modern print preview to the main GTK print dialog without violating any licenses.

What are your thoughts on this approach?

6

Shouldn’t the printing features (both the setup and preview) be provided by the system, instead of being implemented inside GTK?

On Windows, GTK already delegates the printing setup to the native dialog, I suppose on Linux the Print portal can be used in the same way. So it would be basically a matter of providing a GPL-licensed portal backend for printing.

Edit: there is actually an open issue about that in gnome-portal: Print Preview (#161) · Issues · GNOME / xdg-desktop-portal-gnome · GitLab , sounds actually quite complex…

7

I fail to understand the point. Evince is already there, and in GNOME 49 its place will be taken over by Papers. Just make sure that they are installed in Kali Linux.

If you want to use another print preview command for Kali Linux, build GTK with a different print preview command by changing the PRINT_PREVIEW_COMMAND symbol inside gtksettings.c, or with a global settings file.

8

Sir, I got a GSoC project to modernize the GTK print dialog (like the ones in modern browsers). That’s why I was asking all those questions earlier.

My first idea was to add a “return” button in the preview pane so the print dialog wouldn’t close when the preview opens. But later I realized the preview window comes from an external app, so I can’t modify it directly.

Then I thought of embedding the external preview app inside the GTK window to control it better, but that doesn’t seem technically possible either.

So in my final approach, I used an external PDF rendering library to build a custom GTK print preview, and it worked. But as you mentioned, Poppler might cause license conflicts with GTK, which got me confused.

Regarding this issue, I also talked to you(@ebassi) and Uddhav Pathak sir (@uddhavphatak )to understand the best way forward. Right now, the only solution I see is to explore another PDF library, since GTK doesn’t provide its own rendering.

So I just wanted to ask whether I could go ahead with the approach @uddhavphatak sir suggested, so that the licensing issue doesn’t arise and I can move forward with the project.

9

With the modernization of the print dialog we want to make its operation more intuitive, and the biggest awkwardness in UX is that if you click “Preview” the dialog closes and in the preview you cannot return to the print dialog if you want to change something instead of sending it to the printer.

A preview is to check whether the printout will look like as the user desires. It is natural that often the user sees that it is not what they want and so they want to go back and do changes. This path is missing in the current workflow. The preview has only options to send the job off to the printer or to cancel.

So ideas came up to add a “Back” button to the preview to get back into the print dialog (re-open it), but the previewer being a separate package (due to license reasons) makes the approach difficult.

One quick and easy solution working with any external PDF viewer would be to keep the print dialog open when clicking on “Preview”. The user then does either do changes or prints by the Ui of the still visible print dialog. The print dialog could kill the previewer when it closes, either when the user prints or cancels. Even better would be if the dialog re-sends the PDF to the open PDF viewer when the user makes changes (option settings or destination printer), if the PDF viewer supports it.

The final goal of the modernization project is to get a dialog as we see in Mozilla (Firefox/Thunderbird), Chromium, or LibreOffice. Here the preview is embedded in the main view of the dialog and permanently visible, updated on any option/printer change the user does. This would require a PDF previewer which

  • can be embedded in a GTK app like the GTK print dialog
  • can get sent a new PDF at any time and immediately displays that new PDF without closing and re-opening its window
  • is supplied in a separate package/GitLab repo due to the different license (AFAIK libgtk is LGPL and Poppler-based previewers are GPL)

If it is possible to embed arbitrary desktop apps (also using non-GTK toolkits) in a GTK app (here the print dialog) then the embedding would not be a big problem.

Important is also the updating, that you can send a new PDF to the running previewer and the previewer replaces the PDF which it is currently displaying by the new one immediately, and keeps displaying the page which was selected.

If there is no suitable previewer, we need to write a new one, with GTK as GUI toolkit and Poppler as renderer, which is embeddable and accepts receiving new PDFs. It should have its own repo in the GitLab of GNOME/GTK, published under GPL.

The GTK print dialog should handle the previewer’s absence gracefully, displaying without preview if the previewer is missing but making the user aware that with a PDF previewer they get a preview.

10

The perfect solution would be having a PDF renderer with a permissive license so that libgtk can directly link the renderer library. Therefore I had suggested a GSoC project of creating a PDF renderer based on Michael Sweet’s Apache-licensed PDFio PDF manipulation library.

@uddhavphatak made a proposal for it but we did not get enough contributor slots from Google for including this project in this year’s GSoC.

Great would be if @uddhavphatak would do it voluntarily, or, if it turns out that my suggestion of the previous post does not work out (very low probability), @Yash_kumar_kasaudhan switches to do this project and @uddhavphatak helps him with that …

But I think, the approach of my previous post has the best chances to get completed within this year’s GSoC.

11

Eh, I don’t know. There’s really no need for GTK to do this in process. In fact, we really won’t be doing it in process anymore, since we now use portals.

The print portal runs out-of-process, so we can solve the license issues with Poppler. The portal backend right now is LGPL, but implementing the new design with integrated preview will be a rewrite anyway (since right now we’re just using GTK’s builtin print dialog in the portal backend). Here’s a potential new design:

Potential new design

Or we could just implement this as a portal backend directly in Papers (like we’re doing with Nautilus). This probably makes a lot of sense, considering that Papers already has all the necessary PDF rendering machinery.

Either way, other operating systems provide their own native printing dialogs that we can use instead of the portal there. This way, the state of GTK’s builtin print dialog really doesn’t matter anymore, and it only exists as a fallback

1 Like
12

@adrianvovk thanks for the update.

First, you probably tried to insert a picture in your message, but somehow it does not show for me, only a large empty space. Could you re-insert the picture?

Then, if all GTK/GNOME apps (also if classically installed, no Flatpak or Snap) will use the portal, does it then still make sense to modernize the GTK print dialog? Or should we better invest @Yash_kumar_kasaudhan 's second half of his GSoC time in him working on implementing the new design of the portal backend?

13

The image is https://gitlab.gnome.org/-/project/1206/uploads/a49af26cbdd85fe4359aede47c61a9df/image.png

But note, that this isn’t a final mockup from the design team. Just an example used in some other discussion. So there’d have to be more input from the design team about this.

Then, if all GTK/GNOME apps (also if classically installed, no Flatpak or Snap) will use the portal, does it then still make sense to modernize the GTK print dialog? Or should we better invest @Yash_kumar_kasaudhan 's second half of his GSoC time in him working on implementing the new design of the portal backend?

Great question. I’ll bring it in front of the release team

14

The design is principally what we have in the print dialogs of Mozilla (Firefox, Thunderbird) and Chromium, what I wanted to have my GSoC contributors to do with the dialogs of GTK and Qt, and @Yash_kumar_kasaudhan is doing the GTK task.