Hello,

As requested in http://bugzilla.gnome.org/show_bug.cgi?id=382688 I have created a PDF export plugin for GIMP. I need some feedback on it (mainly on it's GUI) so I'm asking for it here. The plugin can be accessed through File->Create->PDF (Both multipage and singlepage options) or through the normal save dialog (single page, simply add the .pdf suffix).
The plugin uses cairo to output the PDF so only features that are available in cairo can be used by the plugin.

It builds on my GIMP 2.6.4 so it should work on later versions, The source can be found on the bug report. To get the compiler flags, use 'pkg-config --cflags --libs gtk+-2.0 cairo-pdf gimp-2.0 gimpui-2.0 gimpthumb-2.0'. The plugin is only one file, so it should be easy to compile.

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

Thanks, ~ LightningIsMyName

Hello martin,

Where should I register the procedure for creating multiple paged PDFs? I switched the plugin to use the gimp_export_dialog as part of the new export api, but I don't know what is the correct place to register a file saver from the menu The problem is that I doubt it's right to have the user choose one of two procedures when saving with a ".pdf" suffix. The multiple paged PDF is some sort of a wizard since the user can configure which images to save and how - and it doesn't relate to just one specific image...

Thank, ~ LightningIsMyName

On Thu, Aug 20, 2009 at 10:47 PM, Martin Nordholts wrote:

On 08/20/2009 06:09 PM, LightningIsMyName wrote:

Hello,

As requested in http://bugzilla.gnome.org/show_bug.cgi?id=382688 I have created a PDF export plugin for GIMP. I need some feedback on it (mainly on it's GUI) so I'm asking for it here. The plugin can be accessed through File->Create->PDF (Both multipage and singlepage options) or through the normal save dialog (single page, simply add the .pdf suffix).

The first thing to do would be to port it to File -> Export... in git master using gimp_export_dialog_new() and gimp_export_dialog_get_content_area(). Look at how the other file plug-ins does it.

BR, Martin

--

My GIMP Blog:
http://www.chromecode.com/

Hello Martin,

The problem is that if I add the multiple paged PDF as an option to the normal sace procedure we will have a problem when running the plugin using GIMP_RUN_WITH_LAST_VALS. Imagine the following Scenario:
* User has images 1 2 3 open
* While image 1 is active, the user now uses the procedure for creating multipage PDFs on images 2 and 3 * The user modifies image 1 again, and wants to export it as a single paged PDF. However he will now have image 2 and 3 and he will have to remove them in order to add image 1. * The user modified image 2 and now we wants to export image 2 and 3 again as a PDF. He will have to add them again.

The problem is that the multipage procedure should be non-related to the single-page save procedure since these are different tasks.

I have only one solution which can solve our problem but I want to hear your opinion about it:
1. Merge the gui both procedures, and make the view of the multipage procedure hidden inside a GtkExpander. 2. Behaviour will be configure like this: a. When the expander is not expanded, only the options for the single page export will be visible, and it will behave as a single page export.
b.When the expander is expanded, it will behave as the multipage export and will export the all the images in the GtkIconView. 3. In case of GIMP_RUN_WITH_LAST_VALS it will be assumed that the expander is hidden and it's a single page export. 4. We should make sure that if the multipage procedure was used the image will still be marked as unsaved somehow (Does the new export api causes images to still be marked as unsaved when using the Export function? If so, this solves our problem :D)

~Barak

On Fri, Aug 21, 2009 at 7:29 PM, Martin Nordholts wrote:

Can't the multi-page variant simply be an option in the File -> Export... dialog somehow? Like, you would specify what additional images to put in the multi-page PDF

Hello Martin

On Fri, Aug 21, 2009 at 10:59 PM, Martin Nordholts wrote:

A more sophisticated solution would be to have per-image export options. Not sure if that is a good idea or not.

I also don't think it's smart - If we do say that the PDF export is a global task ("In both cases the user wants to export a PDF") then it shouldn't be associated with any image.

What d you mean w ith all images in the GtkIconView? Can't we simply let the user pick the images for the multi-page PDF?

The only point is that if we have both procedures merged to one procedure, then the user will have some trouble when handling 2 different PDFs. If the user works on 2 PDFs at the same time, one of images 1 and 2, and another of images 3 and 4 he will be annoyed to set the pages again for every PDF. It shouldn't be a problem with 2 pages but if a user wants to export 50 pages as PDF, it starts to become a problem...

However, now that I think of it, GIMP's product vision doesn't say that it's a page layout program, so maybe we shouldn't really worry about this :-)

In git master, exported dirtiness is separate from saved dirtiness. You should try it out :)

I wish I could try the new branch, however I don't have a computer to test it on with administrator rights... I need someone to package GIMP 2.7 as a zip so I can extract and run it (The windows installer requires administrator rights, and installing a package on linux also requires this).
If anyone can package a windows (32 bit)/linux (64 bit) build as a single archive and not as an installer, I'll be very thankful =) Then I'll also be able to test my plugin on GIMP 2.7 (right now, most of my coding for feature releases of GIMP is done "blind" - I test everything I can on the stable version, and when I want to use the new api I read it, write some code and hope for good :D)

~Barak

Hello martin,

You don't need administrator rights to try GIMP git master, just install into a prefix in your home dir

git clone git://git.gnome.org/gimp cd gimp
./autogen.sh --prefix=/home/barak/gimp-2-7 make
make install

the problem is that the linux system I use on the computer labs at doesn't have autogen (and some other tools required for the compilation) installed, and in order to install it to the main directory I need administrator rights. Is there any way to specify other directories for tools such as autogen? I tried extracting it to /vol/scratch (The scratch disk, since the home-folders are very limited in disk space) and then to add it to the PATH but it didn't work. (I'll try it again next time). If the compilation can be done on /vol/scratch I have enough space to install all the missing scripts (such as autogen) on my homefolder. The problem is that I don't know how to do that.
Any tips/help?

~Barak

Hello,

I forgot that there is a tarball (2.7 means a tarball - Yey!) - I'll try it as soon as I can.

Back on topic, I'll submit the modified plugin today (I'll merge both procedures and use 2.8 api) so you can see it.

~Barak

Hello,

I have succesfully compiled GIMP 2.7 (from tarball) on linux, using a terminal access =)
I'll be able to test GIMP itself and the new PDF plugin on Sunday, when I get to the labs to run GIMP with a GUI.

~ Barak

Hello Etienne,

Thanks - I haven't known that. I tried it, but I got an error saying that it's not allowed... =(
Thanks anyway, I learned something new =)

~ Barak

On Tue, Aug 25, 2009 at 4:30 PM, Etienne lepercq wrote:

Notice that if your terminal access is made through ssh, and your ssh-server allows redirecting X, you can launch gui softwares through ssh : ssh -Y -C login@server
then launch your app.

If it can help...

Etienne Lepercq --
Sincerily

Hello,

I tried the new GIMP 2.7 and now I saw what the export feature behaves like. After some thought I reached the conclusion that we should probably merge both procedures (single and multi page) into one procedure for exporting everything.
However I also have 2 new additions: 1. The export parameters (aka the pages and optimization) should be saved for each image individually. If the export is automatically suggested for the same file as last time, we should save the parameters for each file - which means saving the parameters for each image.
2. We should warn the user when he wants to re-export the PDF if one of the images that was a part of the PDF was closed, so he won't overwrite his PDF and loose pages.

For feature 1, we need to make sure the parameters are saved per image but are only relevant for the current session (since the pages are the open images, not images from files). I need some help here on how to do this...
Should I save the parameters to some file instead of adding the to the image? Then I can probabbly use the quit() procedure of the plugin to delete this file. This is the only solution I could think off, and then, should I use the .gimpX.X/tmp/ dir for saving the file?

Waiting for feedback =) ~ Barak

On Fri, Aug 21, 2009 at 10:59 PM, Martin Nordholts wrote:

We can't predict what a user wants to do. We can only give sane defaults, such as the previous export options, and allow the user to change them if they are not right.

A more sophisticated solution would be to have per-image export options. Not sure if that is a good idea or not.

The problem is that the multipage procedure should be non-related to the single-page save procedure since these are different tasks.

I don't see these two as conceptually different tasks. In both cases the user wants to export a PDF.

I have only one solution which can solve our problem but I want to hear your opinion about it:
1. Merge the gui both procedures, and make the view of the multipage procedure hidden inside a GtkExpander. 2. Behaviour will be configure like this: a. When the expander is not expanded, only the options for the single page export will be visible, and it will behave as a single page export.
b.When the expander is expanded, it will behave as the multipage export and will export the all the images in the GtkIconView.

What d you mean w ith all images in the GtkIconView? Can't we simply let the user pick the images for the multi-page PDF?

3. In case of GIMP_RUN_WITH_LAST_VALS it will be assumed that the expander is hidden and it's a single page export.

Wouldn't it make more sense to simply run with last vals? That is, if the user previously exported image 1 2 and 3, invoking 'File->Export to file.pdf' would re-export this multi-page PDF.

4. We should make sure that if the multipage procedure was used the image will still be marked as unsaved somehow (Does the new export api causes images to still be marked as unsaved when using the Export function? If so, this solves our problem :D)

In git master, exported dirtiness is separate from saved dirtiness. You should try it out :)

BR,
Martin