GNOME Bugzilla – Bug 382688
Export layers as pages to PDF file
Last modified: 2017-06-19 20:17:20 UTC
Hello, first thanks for GIMP which is a great software. I often use the TWAIN interface for my scanner. to send paper documents for many people Unfortunately most people don't know GIMP. And I consider that I can't urge them to use it even if it's a free software (both as speech and as beer) The easiest way for this people to see my document is to export them as a PDF file (because Adobe Reader is very used and the PDF file format is well documented so other reader software exists) Now, I save my file as file.xcf Open a console and strike $ convert file.xcf file.pdf (convert is part of the ImageMagick package) As you can see that's not very difficult but it's quite long to do it So, could you add such a feature into the next GIMP release (thanks a lot !) I think you should use the "convert" line command for this. Regards
I see that you change What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Component|General |Plugins Ever Confirmed|0 |1 Making a plugin (or a script-fu) for this could be very usefull Unfortunately I don't know Scheme/Lisp at all Moreover even if a script-fu is made for this, it should be made available as a export filter in the save-as menu (and not as part of the script-fu menu) Regards
The most common method to create PDF nowadays is to use a PDF printer. Do we really need a PDF export plug-in?
I think it would be useful to have one, yes. Even if exporting to PDF is already easily available by printing to a PDF printer. A lot of users expect to be able to save as PDF. And in the long run we could improve the PDF export to include text layers as PDF text objects.
Yes, that's a good idea. The first PDF export filter could be just a little hack... after... it will be possible to improve it. About PDF printers... I 'm running GIMP on Mac OS X, on Windows and of course on Linux. You must admit that the print function it not fully implemented on the 3 OS. Moreover the way of making a PDF printer is totaly different... so having a native PDF export will simplify this. Regards
http://libharu.sourceforge.net/ This seems to be a reasonably licensed library which we can use. Or do we use GtkPrintOperation and print to PDF, while showing an "Export to PDF" UI? gtk_print_operation_set_export_filename () seems to be geared towards this exact use-case.
Providing a better PDF export feature could also allow people to save multi-page PDFs, which might be useful if people want to re-save an imported multi-page PDF for some strange reason.
The discussion about this in the mailing list was intterupted by various arguments about CMYK support and several other features. So, I'm continuing this discussion here. I already have a working version of a PDF export plugin with RGB support and text layer support (however it still has no GUI). Adding support for multiple pages will be done as soon as I (or someone which is better than me in GTK programming) will create a GUI. Multiple pages will be implemented by selecting several images. The output itself is done by Cairo (which is a part of the official GIMP distribution) using it's PDF backend. For that reason, the output is RGB (and I see no reason to find anyway to get CMYK support before gimp has CMYK support - so at least for the near future this should be OK) Should I attach the source of this version here to the bug report? I do want to see it as a part of GIMP 2.8, even if it will only have basic features right now.
Created attachment 133601 [details] [review] A simple version of a pdf export plugin Here is my self-written pdf export plugin. It uses Cairo for the pdf output and PangoCairo for rendering the text to the pdf documents. This plugin works! All it's dependencies already come with GIMP, so no additional resources are needed. Right now, it simply exports the images in the default resolution (72 pixels per inch) without any special optimizations. Things that can be added: - Better support for indexed images (GRAY, GRAYA, INDEXED, INDEXEDA) - Choosing a resolution - Multiple pages (by selecting multiple image) - Support for layer masks - Replacing single-coloured layers (bitmaps) with colored rectangles (vectors) to optimize the file
Thanks a lot :) However the code doesn't use GIMP's coding style. Please look at any file in app/ to see how it's supposed to be indented and functions headers should be formatted. Also, there is no need to implement "choosing a resolution" because images already have a resolution, just use gimp_image_get_resolution().
Created attachment 134111 [details] [review] A fixed version of the pdf export plugin Here is my second version of the plugin. It's now useable (as far as I know), and I did my best to fix every potential bug I can think of: * Added handling for image resolutions, and fixed the behaviour of getting font sizes (previously, getting the size of the font didn't check the unit). * Added optimization (solid rectangles instead of bitmaps wherever possible, layers with 0 opacity are not included) as a macro flag. Now, all we need is a GUI to replace this ugly macro. * Added checking for layer visibility. Hidden layers are not included. * Added handling for layer masks. As a part of this, drawables with one channel are now saved in CAIRO_FORMAT_A8 instead of CAIRO_FORMAT_RGB24. * Indexed layers are now handled correctly, without need to convert to RGB images. * Switched to GNU coding stlye. This uses api which is currently in the SVN (GIMP 2.8 api). The remaining part is to add a User Interface that allows to: 1. Toggle optimization on and off 2. Allow to select multiple images to create multiple paged PDF's 3. (Optional) Choose whether to apply layer masks before exporting to PDF, or whther to export with the masks (This is the default right now , however the files will be larger).
Comment on attachment 134111 [details] [review] A fixed version of the pdf export plugin I forgot to mention this is a patch (although it's not a diff file, it's still a code fix) so the bugzilla didn't mark it as having a possible patch...
Please provide this as a git commit that also changes the build system to include this plug-in.
We should definitely try to get this into 2.8.
Hello, First of all, I'm glad to see that you wish to see it inside the 2.8. I have a more recent version of this plugin on my computer, and this one already has a working User Interface. It has 2 different procedures - one for saving a single image as a pdf (as a normal file saving plugin), and another one which opens a user interface with more options, to create a multiple paged PDF (I seperated them, since I believe the second one shouldn't be a normal file-save plugin). The problems are that: 1. I'm having trouble with exporting the multiple paged plugin's API for GIMP. For some reason, I get an array of images but my user interface doesn't load it very well... Don't understand me wrong, the multiple page option still works, but it doesn't care which parameters it is given - it always pops it's user interface with the default options, no matter what parameters were passed for file-pdf-save-multi-page. 2. I still haven't allowed the parameters of the plugin to be saved (Trivial to fix). 3. Although the user can select in the user interface which optimizations does he want, It's still not implemented inside the code (again, Trivial to fix). Right now I'm a busy in university, which means that I only have free time on weekends. I don't know if I'll have the time to finish this plugin before mid-August. There are 2 options: 1. I'll provide the single paged export only (I can have this done with complete working user interface and parameter saving this weekend). 2. I'll also provide the multiplae page export, warning however that it's still buggy if you try to invoke it using file-pdf-save-multi and not directly from GIMP's user interface. If I'll know how much time do I have untill 2.8, I'll be able to estimate which options can be finished until then.
We can live with minor issues and deal with those separately as long as the core functionality (exporting as a PDF) is there. It is impossible to say when GIMP 2.8 will be released, but if we ignore that, I would guess that GIMP 2.8 will be released around the end of 2009 or early 2010.
In that case, I will definetly finish it before 2.8. Even though I'm busy, I should easily be able to finish it until in a month or two. I'll submit the current code of the plugin somewhere this weekend for people to able to see and comment, and I'll keep updating the code here, each time with it's current status.
Some things that need fixing: please keep query() and run() at the beginning of the file, just as in all other plugins. RGBAcolor -> please get rid of that and use GimpRGB from libgimpcolor // foo -> /* foo */ if (!foo) -> if (! foo) if { -> if\n{ i=0 -> i = 0 foo;bar -> foo; bar foo(bar) -> foo (bar) But it looks very good apart from these minor stylistic issues.
Progress update: I have finished the GUI of the plugin including the parameter saving (Finally!). Right now I have a GUI which does nothing, and a PDF plugin with no gui (Used the script-fu console to test it) that works. The only remaining part is to connect them, and this should happen very soon
Created attachment 140954 [details] [review] The PDF plugin Finally - It's done. The code attached here is a version that still uses GIMP 2.6 API and it works against my GIMP 2.6.4 on windows XP. I'll port the API usage (especially the text API) to the one of GIMP 2.8 as soon as I get feedback on this plugin. There are 2 ways to acces the plugin: 1. Simply save an image with the extension of .pdf (Single page PDF) 2. File->Create->PDF->Multiple Paged PDF (multiple paged PDF) Known Issues: 1. Grayscale layers are inverted (although layer masks which are not grayscale, are not inverted) 2. Exporting some fonts doesn't work since gimp_text_layer_get_font Returns a font which is sometimes incompatiable with pango_font_description_from_string (gimp_text_layer_get_font sometimes returns suffixes such as "semi-expanded" to the font's name although the GIMP's font selection dialog shows the don'ts name normally - This should be checked again in GIMP 2.7) 3. Indexed layers can't be optimized yet (Since gimp_histogram won't work on indexed layers) Waiting for Comments/Suggestions =)
p.s. Apperantly there is a typo in the plugin which prevents it from compiling... in file-pdf-save line 60 "GimpRunMod" should be "GimpRunMode". I'll fix it when I upload the version using the 2.8 api.
Created attachment 141452 [details] A new patch using the 2.8 api Changes in this patch (as requested in the mailing list): Fixed a typo that prevented the plugin from compiling... A migration to the new GIMP 2.8 api, which includes: - Now using gimp_export_dialog_new - Using gimp_text_layer_get_hint_style (2.8) instead of the depreceated gimp_text_layer_get_hinting (2.6). The two procedures (the multipage and single page) weren't merged yet as discussed here http://www.nabble.com/Need-feedback-for-the-new-PDF-plugin-td25065097.html The reason is that I still haven't got a working 2.7 build to test if this will be the right behaviour. Other people are welcome to test the plugin and see if merging the procedures will indeed be right. If no one else does this before me, I'll get to it next week.
Hello, I'm giving a little progress update: 1. I have a setup of weekly GIMP builds, so I can now continue 2. I'll probably have time to work on it in this month (or the following month if any problem occures) 3. Can I migrate the plugin to GtkBuilder, as we did for the file-png-save? I haven't understood from the mailing list if we do want to use GtkBuilder or not...
Thanks for the update! Use GtkBuilder for now.
*** Bug 609595 has been marked as a duplicate of this bug. ***
Any update on this LightningIsMyName? What is left to do on the patch?
Hello Martin, We talked on IRC and it was decided that for compatability with feature versions of GIMP, the plugin should move to use some sort of GEGL text operation of GIMP, so that when the upcoming changes to the text core will come, the plugin won't have to be re-written. To tell the truth, I don't have an idea where to begin... I tried to take a look here http://gegl.org/operations.html#op_gegl:text but it doesn't seem to give us any advanced options for rendering more then just basic text. As far as I know, GIMP still uses PangoCairo to render it's text - http://git.gnome.org/browse/gimp/tree/app/text/gimptextlayout-render.c So I have no idea which GEGL action/operation/etc should be used to render with GIMP's current layout. (the plugin worked, but now since text layers can have decoration styles like bold, and can have more than one font, the plugin won't work as the user would expect it). I can catch up on #gimp IRC at tuesday 14:00-21:00 (GMT+2).
Comment on attachment 141452 [details] A new patch using the 2.8 api Setting to non-patch since there is work left to do and bugzilla chokes on non unified diff files. When creating the new version of the patch, please use git format-patch and concatenate the patches into one file. Thanks!
If we want this into GIMP 2.8, we can't wait for a GEGL text operation. LightningIsMyName: Will you go for a 2.8 version of the plug-in, or we move this to the 2.10 (3.0) milestone?
The group api is making some of the delay - I need a way to access layers inside layer groups. Otherwise text which is inside a layer group will be lost, and this will ruin the point of the plugin (preserving everything, including text). Also, I'm waiting for some promised changes in the text core (someone said something about different line spacing and some other stuff). If I'm supposed to ignore this, I should be able to finalize the plugin soon (2.8 is scheduled. The current delay was because of the GimpItem api changes and since I still heard some rumours about more upcoming changes to the text core... Could be easily finished even before 2.8 to have a testing period (if the schedule is still to do the release at the end of 2010)
The new pdf export plugin is now committed. It requires some work, but it mostly works. commit 6f8c412735637403063dfb929c3626d4d506d8d4 Author: Barak Itkin <lightningismyname@gmail.com> Date: Fri Aug 27 23:22:10 2010 +0300 plug-ins: add the new file-pdf-save plugin (Bug #382688)
Thanks! It's pretty neat! But as you say, it can be improved: * Text layers inside groups are exported as bitmaps, not text, like toplevel text layers * The checkboxes should not be questions * Why do we need the "Apply layer masks before saving" option at all? If someone don't want the layer masks applied, he would have disabled them before exporting, wouldn't he? * Why do we need the "Don't save layers which are hidden or have 0% opacity" option at all? * Instead of "Convert bitmaps to vector where possible?" I suggest "Decrease file size by converting solid colored layers to filled polygons" * The padding between the last checkbox and the buttons is too small, compare with e.g. the PNG export plugin dialog But again, thanks for getting us as far as you have :) Would you mind if we reopened this until the above have been fixed? I'm asking because it can be offensive to reopen a bug report someone has put a lot of effort in fixing.
Oh I see now that you mentioned the text layer in group exporting problem in the comment before.
Re-Opening untill the bugs will be fixed (this will be easier than opening a new bug) * About the "Apply layer masks before saving" option - we can either apply the masks to modify the layers alpha channel and then save, or save both the original alpha and the mask (and the mask will be applied at view time). This does need a better description * About the "Don't save layers which are hidden or have 0% opacity" option - for example, layers which have their opacity set to 0% may still contain data. This may be needed as some intermidiate step (so that people who read the pdf as is won't see some data, but it will be possible to retrieve it later by editing). I think that this can also be useful for truly hidden watermarks to keep such layers. The option to discard these layers is given to the user as a part of the optimization process. * UI still needs some love =) The current UI is only so that people will be actually able to test the plugin, it probably should be changed so thanks for pointing this out. I'm also attaching the list of other known issues that should still be fixed: * Fix some coding style issues (trivial) * Need to add support for i18n (trivial) * Grayscale layers are inverted (although layer masks which are not grayscale, are not inverted) * Exporting some fonts did't work since gimp_text_layer_get_font returned a font which is sometimes incompatiable with pango_font_description_from_string (gimp_text_layer_get_font sometimes returns suffixes such as "semi-expanded" to the font's name although the GIMP's font selection dialog shows the don'ts name normally). This should be checked again in 2.7 as this originally happened only sometimes in 2.6 * Indexed layers can't be optimized yet (Since gimp_histogram won't work on indexed layers) * Rendering the pango layout requires multiplying the size in PANGO_SCALE. This means we need to do some hacking on the markup returned from GIMP or to find some other fix. * When accessing the contents of layer groups is supported, we should do use it (since this plugin should preserve layers and most importantly text layers). Also, there are 2 things which we should warn the user about: * Cairo does not support bitmap masks for text. * Currently layer modes are ignored. We do support layers, including transparency and opacity, but layer modes are not supported. So warn the user if any mode other than Normal is used. Also - the plugin supports exporting multiple paged PDFs. Although this does not seem match the product vision, I still think this feature should be kept (It's currently under "<Image>/File/Create/PDF/Create multiple paged PDF..." which is clearly a bad place). I would really like to find a suitable place for it in the UI, but if needed I'll remove it from the UI (I'll still keep the procedure though). Note to the future: when vector layers get integrated into GIMP (somewhere in the future) this plugin should be updated.
The basic functionality is in, we don't need to spend more time on this for 2.8
Created attachment 219786 [details] [review] export layers as pages I'd like to push this plugin in a somewhat different direction. What I am sorely missing is the ability to export layers from one image as a multipage PDF. I have experimented with the plugin to that effect (and in the process dumped the existing but unused multipage capabilities and the other options as well because they kept getting in the way) and the result works nicely for what I need, and also preserves text layers in layer groups, at the cost of ignoring potential layer group attributes. Since I heavily modified the existing plugin I'm not sure how useful the patch is as-is but I wanted to throw it out there for some feedback at least.
Created attachment 226402 [details] [review] slightly updated patch that optimizes the groups-without-text path a bit Any comments on this?
I think the only one who can properly comment here is LightningIsMyName.
Created attachment 230306 [details] [review] minimally invasive git-formatted patch This is largely the same as the previous patch except it doesn't rip out any existing functionality and tries to touch as little as possible.
Thanks, that looks much better :)
Hi, I have not tested the patch, but the description of the commit looks appealing, since just today I had the case where I needed to import a pdf document, draw on it, and re-export as multi-paged pdf. Well the import worked fine, but I was not able to export, so had to export individual pages and use `convert`. This patch would have save some time. Now the second improvement that is really missing is quality control. Are we currently directly drawing in the pdf pages, without any loss? (no idea if the pdf format allows this, but a fast look at the code, it looks something like this) Because that makes very heavy pdf. In my today use case for instance, I had to produce a pdf of maximum 700ko, for upload on a website (format and max size were imposed by this website). Well when I saw that the pdf for a single of my pages produced by GIMP was more than 3Mo, that would have been impossible, even with the multi-page export. My only control over file size was resolution, but getting a resolution small enough was getting me a pdf totally unreadable. On the other hand, when exporting each page as jpg, and subsequently making a multi-page pdf with `convert` (which I guess simply embeds the jpg images into pdf pages), I got a very small file with a pretty fair and readable quality. Would be awesome if GIMP was able to do this all by a simple export, preventing me the multi-step procedure. :-)
An option for exporting multi-page pdf (each layer a page) is definitely missing. It should be obvious, just like when you export a gif and you have the option to save each layer as a frame.
For information, even though it is still cool if we can improve PDF support on GIMP, I now have a different point of view on the topic as I did a year ago. Basically if you want to make very cool PDF with advanced features and such, don't use GIMP. There are software much more adapted and made for this. In particular, my advice is: use Scribus. It is very good, has very advanced features for making PDF, and they even just released a new dev version. So such bug report can stay open, but I consider this low priority. This said, if we have a quality working patch for this, that's cool and should be included in the tree.
LMAO "advanced features and stuff"
> LMAO "advanced features and stuff" ? Well that's still a lot more than what you get in GIMP. But suit yourself.
What I meant was that, given that the option to export a PDF exists, having each layer exported as a page is not some "advanced feature", it's among the most basic options that one would expect from a program that offers the ability to export a pdf in the first place, just like when you export a GIF you have the option to export each layer to a frame.
This is currently on the 2.10 milestone, so we have to decide whether to land it or move it to a future one.
The patch does not apply on master anymore and I don't have enough interest in this specific feature to afford the time to fix it. I'm sorry all for the long time without proper review. Could anyone who is interested in this patch try and fix it? If at least the patch applies cleanly and work, I will at least make the time to review it and push the commit if it looks good (the cleaner and simpler code the better!). Thanks.
*** Bug 663404 has been marked as a duplicate of this bug. ***
Adding newcomers keyword.
Comment on attachment 230306 [details] [review] minimally invasive git-formatted patch Per comment 47.
*** Bug 780182 has been marked as a duplicate of this bug. ***
In our current effort to get a 2.10 release, I am bumping this non-blocker report to 3.0 milestone. It can still make it to 2.10 if someone provides an updated patch before the release. Also with our new release policy, the feature will be allowed to be released in a minor 2.10.x version as well.
Created attachment 353702 [details] [review] Export Layers as Pages Here's my attempt to add "Export Layers as Pages" when exporting into pdf.
Review of attachment 353702 [details] [review]: 1/ There are quite a bit of trailing whitespaces to clean out. 2/ There is a deprecated function warning, but from before the patch, so that's ok. 3/ > if ((gimp_item_get_visible (layer_ID) && > (! optimize.ignore_hidden || > (optimize.ignore_hidden && opacity > 0.0))) || > (optimize.layers_as_pages && ! gimp_item_get_visible (layer_ID))) You don't need to retest gimp_item_get_visible. That's redundant. :-) Also the layers as pages should also follow the ignore_hidden option. So if the "Ignore Hidden layers" option is checked, the export should not generate a patch for it. Apart from these, that's nice!
Ok so I had a closer look at this if. It is completely broken. Just replace it with: > if ((gimp_item_get_visible (layer_ID) || opacity == 0.0) || > ! optimize.ignore_hidden) This is the proper test. And enter: > if (optimize.layers_as_pages) > cairo_show_page (cr); Inside the previous if block.
Let's put this back to 2.10. :-)
Created attachment 353739 [details] [review] Updated Export Layers as Pages I updated the patch considering Jehan's comments 54 & 55. The code still needs some cleanup, there are unused parts that should be removed. I will take a look at it.
I will review soon. Thanks!
Review of attachment 353739 [details] [review]: The if test I gave in comment 55 was wrong, sorry for this. I took on me to fix it directly in your patch. My bad. Apart from this, I realize we cannot just update the signature of a procedure published in the pdb. It would create any existing script. We need to stay compatible so I just created a file-pdf-save2 (we will be able to break compatibility in GIMP 3. Maybe then, file-pdf-save2 can replace file-pdf-save). For the same reason, let's not touch file-pdf-save-multi. I did a separate commit for these. I also did a commit so that the default values are taken into account in the GUI. ignore-hidden should indeed be TRUE by default, but it wasn't because we were always checking parameters even in interactive mode.
All pushed to master. Comparing to previous proposed patches, I realize they were proposing one more option: reverse-order. This would reverse the order of layers/pages. Of course such option should be grayed-out when layers-as-pages is not checked. Lionel> Should we just forget about this option and close, or do you want to implement this too? commit d03de527a5c383725af21958bdf5c561dbd30e83 Author: Lionel N <lionel@libreart.info> Date: Tue Jun 13 20:45:09 2017 +0200 Bug 382688 - Export layers as pages to PDF file Add feature to export multiple layers to multiple pages. Fixed the deprecated functions. Fixed how transparent/invisible layers are handled. plug-ins/common/file-pdf-save.c | 100 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------- 1 file changed, 63 insertions(+), 37 deletions(-) commit c08cf41113a62b4fcf7a78da9534ec8240fa1926 Author: Jehan <jehan@girinstud.io> Date: Wed Jun 14 23:27:31 2017 +0200 plug-ins: only check non-defaut parameters in non-interactive mode. Otherwise default values are not taken into account in interactive mode. In particular, we want ignore-hidden to be checked (TRUE) by default, because this is the most obvious behavior (WYSIWYG). plug-ins/common/file-pdf-save.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) commit c8550c95819007d7475a4340dd54242dfa64c07e Author: Jehan <jehan@girinstud.io> Date: Thu Jun 15 00:22:25 2017 +0200 plug-ins: create file-pdf-save2 with the additional parameter. And revert file-pdf-save to its previous signature before commit d03de52. For compatibility reason, we can't change the signature of a procedure available in previous stable releases. Also revert file-pdf-save-multi for the same reason. I don't create a file-pdf-save-multi2 though even though layers-as-pages could still be meaningful there (creating a multi-page PDF from several multi-layers images) but that's likely a special case which can be dealt with later. Obviously the interactive export will use file-pdf-save2. plug-ins/common/file-pdf-save.c | 71 +++++++++++++++++++++++++++++++++++++++++++++-------------------------- 1 file changed, 45 insertions(+), 26 deletions(-)
Also probably layers-as-pages should also be grayed out when the image has a single layer (similarly to the fact we gray-out animation feature on git/webm in similar cases).
Created attachment 353924 [details] [review] Reverse pages order As suggested by Jehan in his comments 60 & 61, I added a "Reverse pages order" option and greyed out the "Layers as pages" option if the image has only 1 layer.
Review of attachment 353924 [details] [review]: Looks pretty good. I will test tomorrow just to be double sure but it looks like it will get in as-is.
With reverse ordering, any of the previous patches are obsolete now, it seems.
(In reply to Michael Schumacher from comment #64) > With reverse ordering, any of the previous patches are obsolete now, it > seems. Indeed. I tested. As expected, it works well. I just amended with minor cleanups (trailing spaces and mis-alignments). commit 4a05ddebabe0c3b7564d60330d586ccf3fe4f105 Author: Lionel N <lionel@libreart.info> Date: Fri Jun 16 23:36:03 2017 +0200 Export layers as pages to pdf / Reverse pages order Added a "Reverse Order" option when "Layers as pages" is checked. "Layers as pages" option is greyed out if the image has only 1 layer. plug-ins/common/file-pdf-save.c | 41 +++++++++++++++++++++++++++++++++++++---- 1 file changed, 37 insertions(+), 4 deletions(-)
Review of attachment 353924 [details] [review]: Pushed. Cf. previous comment.