Comment 5 for bug 73269

The normal cause of this sort of problem is wxWidgets/Xaralx incompatibility, or GTK/wxWidgets incompatibility. I doubt it's the latter if it works on autopackage. I suspect that the problem is related to the fact that the autopackage version of wxWIdgets (which is static linked in) is built without libGnomePrint support, whereas the Ubuntu package uses the Ubuntu wxWidgets which is (I believe) built with libGnomePrint on. As Xtreme/Xaralx produces native postscript, it needs to delve into the internals of the wxWidgets printing mechanism in order to use the wx print UI (whether libGnomePrint or native), then use the native printing mechanism whichever is used. Unfortunately it isn't possible (to my knowledge) to persuade wxWidgets /not/ to use libGnomePrint at run time (and anyway, the dialog looks nicer). Therefore there is a slightly different code path when libGnomePrint is used (within Xaralx) to cope with the fact that wxWidgets returns a different type of print object. Now, this should all work (and indeed did under Dapper), so I don't know what has broken it. I don't think many of the wxWidgets developers use libGnomePrint (it's a build flag that defaults off), so it is possible that printing is just broken under wxWidgets on Ubuntu. This could be checked by seeing whether the printing sample works (should be in the wxWidgets source package) and if so whether it uses the right dialog. Sorry not to have time to do this myself.