GNOME Bugzilla – Bug 120103
Enlarging documents (i.e. printing 1 page enlarged and split onto 2 pages)
Last modified: 2006-10-30 10:17:33 UTC
I'd like to have the ability to print one page enlarged and split onto several others. For example, I would like to print 1 image onto 4 * 4 pages in order to get a big poster after gluing those pages together. I already implemented that for EOG (including margins, overlapping, cutting helpers, etc.), but I'd like to put that feature into libgnomeprint so that all programs that use libgnomeprint can offer that feature. I've already done some work on this by enhancing gnome-print-meta and writing a class gnome-print-meta-zoom.c. You do something like /* Create the zoom print context */ zoom = gnome_print_meta_zoom_new (); g_object_set (G_OBJECT (zoom), "center_x", TRUE, "center_y", TRUE, "zoom", 2.0, NULL); /* Print onto the zoom context */ (...) /* Render it onto the final print context */ pc = gnome_print_job_get_context (job); gnome_print_meta_zoom_render (zoom, pc); As of now, it works for lines. I started with images, too, but libgnomeprint internals aren't fun to work with and I don't want to lose time with suggestions that don't get included into libgnomeprint (like my feature request 113956 including patch which remains unanswered since nearly 3 months...) Therefore my question: Would you accept patches that add the zoom feature into libgnomeprint?
Considering that the gnumeric mainatainers seem to have taken open maintainership of libgnomeprint you may find them quite willing to include useful features into gnome-print.
We would consider patches implementing this. Some restrictions: This has to be transparent to the application using libgnomeprint. So we would need some additions to the standard print dialog that stores appropriate info in the print_config. When finally printing gnomeprint would then use those specifications. Will you be submitting such a patch?
Created attachment 22579 [details] Proof of concept
Hi! I just attached a draft of a possible patch. I ran into problems implementing the zooming of images - libart_lgpl has (0,0) in the top left corner, libgnomeprint has it in the bottom left corner. And unfortunately, there's not much left from my math knowledge on affine transformations. But I think with the help of someone else knowing a bit of math and libart, implementation shouldn't be too difficult. The zooming code comes into action if you do for example a g_object_set (pc, "center_x", TRUE, "center_y", TRUE, "zoom", 1.5, NULL); The page should then be displayed enlarged by 50% centered on 4 pages. I suggest setting up the basic structure in CVS (i.e. the skeleton of gnome-print-meta-zoom) that handles zoom = 1.0 and adding the implementation of individual functions stepwise (i.e. gnome_print_meta_zoom_clip, gnome_print_meta_zoom_image_transform).
Created attachment 22626 [details] Proposal for GUI for access to the zoom feature
Created attachment 22627 [details] Patch that adds a new tab 'Size' to the GnomePrintDialog (see related screenshot)
Why are your patches always trying to remove GNOME_COMPILE_WARNINGS(maximum) from configure.in ?
It looks like applying both patches is not sufficient to have a working model of your changes: [aguelzow@kirkman ~/cvs/libgnomeprintui/tests]$ ./test-dialog ** (lt-test-dialog:15619): CRITICAL **: file gpa-spinbutton.c: line 217 (gpa_spinbutton_new): assertion `gpa_node_lookup ( GNOME_PRINT_CONFIG_NODE (config), path) != NULL' failed Segmentation fault
Created attachment 22658 [details] [review] Latest patch for libgnomeprint
Created attachment 22659 [details] [review] Latest patch for libgnomeprintui
Created attachment 22660 [details] Screenshot showing the output of libgnomeprintui/tests/test-dialog
As you can see, I attached two somewhat functional patches - one for libgnomeprint and one for libgnomeprintui. As of now, only the zooming of simple lines (gnome_print_stroke_bpath) is implemented. The other operations would be implemented the same way. The patches are quite huge and address several issues at once. If you want me to split them into small patches (i.e. one for libgnomeprint/data/globals.xml, another for libgnomeprintui/gpaui/gpa-spinbutton.[c,h], etc.), please tell.
Created attachment 22751 [details] [review] Updated patch (now implementing fill_bpath_rule)
Created attachment 22757 [details] [review] Updated patch (now implementing clip_bpath, setlinewidth, setdash)
Created attachment 22821 [details] [review] Updated patch for libgnomeprint (implementing everything)
Created attachment 22822 [details] Screenshot showing the testpage zoomed and spread over 4 pages
With classes starting this week, I may not get to reviewing this patch until the week thereafter. I did notice that you may want to align the 2 overlap percentage spin button. Similarly the size spinbutton should not be aligned and not as incorporated into sentences. This may cause translation problems. Since the number of pages apparently needs to be a square I am wondering whetehr the spin button could be coerced to just scroll through the squares: 1, 4, 9, 16, 25, 36, ...
After applying the patches, my first observation is that the margin spin buttons are messed up now. The margin amount shown is not the margin amount previously set. If a margin was set to 2 cm it appears in future as 0.99 cm. If the margin is 1.5 in it is 0.15 in next time, etc. Printing by existing applications fails horribly since the margin information they receive seems to be completely wrong (i.e the margin info they retrieve appears to be much larger than expected.) I don't see why you touched any of the margin code.
I touched the margin code because (1) I implemented the gda_spinbutton and tried to convert the existing setup to use it (2) I assumed that margins relate to the page itself and not the contents, i.e. margins don't get zoomed, only the stuff between. But this needs to be defined. If you want to, I can change the behaviour and zoom everything, including margins. Anyways, I need to admit that I haven't verified the margin code. I will do it next week.
The current patch breaks printing on all applications that allow the margin to be set (gedit, gnumeric,...) so I can't even test the patch appropriately.
Created attachment 22974 [details] [review] Updated patch for libgnomeprint
Created attachment 22975 [details] [review] Updated patch for libgnomeprintui
I tried to fix the margin code. Please see updated patch. If gnumeric/gedit still fails, please have at least a look at libgnomeprintui/tests/test-dialog to see what I would like to reach.
Created attachment 23038 [details] gnumeric using my patch
Created attachment 23039 [details] [review] Updated patch for libgnomeprint
Created attachment 23040 [details] Updated patch for libgnomeprintui
Patches read as utter garbage (binary looking) for me.
patches are zipped collections of additional files an a proper patch...
The patches that will shortly follow implement the concept of filters. You can design your own filter network that will be applied to the print context. The printing dialog supplies some stock filter networks like 'even', 'odd', '1 to 4', '4 to 1' or 'all to 1', but users are free to define their own ones. The filter networks are a lot more flexible than GnomePrintMultipage (i.e. I can use them to enlarge something onto several pages - that's what this feature request is all about). Comments are welcome! If you like the idea, I'll add the possibility to save and load filters.
Created attachment 25000 [details] [review] Updated patch for libgnomeprint
Created attachment 25001 [details] [review] Updated patch for libgnomeprintui
Created attachment 25002 [details] Updated screenshot
Created attachment 29210 [details] [review] Updated patch The amount of new files (see libgnomeprint/filters) and changes is quite high - it has been easier to zip the whole thing. Patches on request.
Created attachment 29214 [details] Screenshot Screenshot showing some files that have been generated using the filters "all to 1", "upside down", "4 to 1", "even".
Created attachment 29218 [details] [review] Complete works (libgnomeprintui) The amount of new files (see libgnomeprintui/filters) and changes is quite large - it has been easier to zip the whole thing. Patches on request.
Ping
The patch is still sitting on my machine (this is not the only one regarding libgnomeprint).
Any point in having this open still? Did the patches land in CVS or are they not going in after all?
It looks like work on printing continues outside libgnomeprint. Therefore, this bug can be closed.
Ok. Closing. We will still apply bugfixes to these modules though.