SwirlyMyself

2010-11-26T20:33:14+00:00

Screenshots as vector graphics

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).

Comments

Gtk+ 3.0 will use only Cairo for all of its drawing needs. Probably you won't need any hacks to have PDF output.
#1 Felipe Lessa am 2010-11-26T21:42:34+00:00
Well, you still have to convince gtk to use a PDF surface instead of a X11 pixmap, which is probably buried deeply in the code. But you are right: It will be easier and more complete WRT icons and such.
#2 Joachim Breitner (Homepage) am 2010-11-26T21:54:52+00:00
It will be buried deep in the code, but in one place only.

The documentation says each expose event handler needs to create new cairo_t for the window and destroy it again at the end because of double-buffering. So I suppose one could either replace the double-buffer with PDF surface temporarily or replace gdk_cairo_create to use the PDF surface instead of the normal double-buffer and run expose on everything.
#3 Jan Hudec am 2010-11-29T07:29:13+00:00
Why not SVG instead of PDF? It would allow easier user interaction
#4 Anon am 2010-11-28T13:08:08+00:00
Sure, would work equally well. I did it with PDF because I had documentation in mind.
#5 Joachim Breitner (Homepage) am 2010-11-28T13:37:24+00:00

Have something to say? You can post a comment by sending an e-Mail to me at <mail@joachim-breitner.de>, and I will include it here.