Joachim Breitner's Homepage

Recently, I was considering the following set of statements: Vector graphics are great, especially in print. Program documentation needs screenshots. Usual screenshots are not bitmaps. Some programs use gtk. Gtk uses Cairo to render most of its display. Cairo can generate PDF. PDF is a vector graphics format.

And while I was doing so, for some reason, I thought: Wouldn’t it be great if I my gtk programs could generate vector PDF files of their screen content? And after some experimentation, I was able to extract this PDF file from the buttonbox example program.

This works without any modification to the original program. Instead, I am loading some code using LD_PRELOAD that overrides the cairo_xlib_surface_create function and creates a PDF surface instead. It also monitors calls to XCopyArea to observe where on the window gtk (gdk actually) paints the resulting image. Then I combine these PDF files (6 in this example, theoretically a lot more) using a latex document and I must say, the result is pretty good for a start: All lines are vector lines, the text really is text (and not just rendered pixels), so you can actually copy’n’paste from it.

Of course this is but a proof of concept and has several problems:

• You can not use the program with my library loaded, as all output is redirected. A solution would be to create a proxy cairo surface that renders both on-screen and to the PDF file, or to make the library react to a signal and only start intercepting the calls when the image has arrived.
• You need a gtk theme with a cairo-using engine such as Murrina, because
  
  
• any drawing done directly with gdk is lost. This includes icons, but also the clearing of parts of the screen. At the moment, all is just put on top of each other.
• It is not a turn-key tool.

I don’t think I’ll fix that myself, as I had my fun. But maybe it can inspire a more useful tool exploiting this idea, and maybe there are cleaner approaches (for example special gtk theme engines, or by patching gtk).