GIMP PDF export plugin

[LightningIsMyName]

Hello,

I began experimenting with cairo to export PDFs of my GIMP images
several weeks ago. Today I saw the GSoC idea in this direction, and I
thought about mailing my thoughts.

I managed to export text while keeping the same appearance that it had
in GIMP using PangoCairo. Exporting images with cairo was also
possible if I saved the images first as PNGs and then used cairo PNG
surfaces to draw them.
Exporting paths is also possible since cairo has full support for bezier curves.
Cairo has the option to create pages in different sizes, using the api
function cairo_pdf_surface_set_size, which means we can also have
different sizes for each page.

The question is, how to build the interface of the plugin. I have no
expirience in GTK+ programming (except for cairo) which means I doubt
I can build an appropriate user interface... In addition, there is
also the question of how will the plugin work - will it export some
sort of defenitions file (XML for example) and then it will call a
process which handles this file, or whether there will be no
sub-export and everything will be done directly.

There are many more questions about this plugin, which I haven't
raised here. Before I continue, I must know whether my direction
sounds OK. Do we want to use Cairo (PDF and PNG), Pango, gimp's png
plugin and so on, or do we want to do it in some other way.
We probably have the option of getting a pixbuf of GIMP's internal
images (using GDK), but I don't like it - I prefer the PNG export.

I'll do some more advanced experimenting, as soon as I get some
working build environment (and libgimp 2.6 for windows which I can't
on  Tor Lillqvist's (tml) page here
http://www.gimp.org/~tml/gimp/win32/downloads.html ).

-- LightningIsMyName
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

Hi,

On Fri, 2009-03-20 at 19:15 +0200, Lightning LIMN wrote:

> I managed to export text while keeping the same appearance that it had
> in GIMP using PangoCairo. Exporting images with cairo was also
> possible if I saved the images first as PNGs and then used cairo PNG
> surfaces to draw them.

Why so complex? You can have a look at the Print plug-in to see how to
transfer the image projection to a Cairo surface without the need to
save as PNG.


Sven


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[LightningIsMyName]

Hello,

On Fri, Mar 20, 2009 at 7:53 PM, Sven Neumann <sven@...> wrote:
> Hi,
>
> On Fri, 2009-03-20 at 19:15 +0200, Lightning LIMN wrote:
>
> Why so complex? You can have a look at the Print plug-in to see how to
> transfer the image projection to a Cairo surface without the need to
> save as PNG.

Thanks Sven, I haven't known that. I found what I needed in
print-preview.c, and I'll try this code out soon.

I should be able to build a small demo that does default printing for
layers and text as one image, however there are several questions we
should consider:

1. How will the user create multi-paged PDFs? Should he choose
different images, one for each page? (This sounds like the most
reasonable way compared to other ways I thought of).
2. PDFs don't have anything such as transperent backgrounds for the
pages. Should we ask the user for a background color for each page, or
should we get the background color from the current gimp context? (Or
mayber we should simply make it white)
3. When drawing paths, how should we ask the user where to draw each
path? Also, how will he tell us how to fill/stroke it?
Abusing the layer names doesn't sound right, and it won't be
user-friendly if he would need to manually relocate his paths inside
the plugin's preview...
The only solution I can see for handling this would be to wait for
vector layers in GIMP, however I haven't heard of any recent progress
in this direction.

-- LightningIsMyName
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

Hi,

On Fri, 2009-03-20 at 22:04 +0200, LightningIsMyName wrote:

> 1. How will the user create multi-paged PDFs? Should he choose
> different images, one for each page? (This sounds like the most
> reasonable way compared to other ways I thought of).

Why would we want to allow the user to create multi-paged PDF files?

Perhaps, before anything else, we need to clearly define what the
purpose of PDF export is. We certainly don't want to provide a tool to
create an illustrated book. That's what page layout applications are
used for.


Sven


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[gg-6]

Sven Neumann wrote:

> Hi,
>
> On Fri, 2009-03-20 at 22:04 +0200, LightningIsMyName wrote:
>
>> 1. How will the user create multi-paged PDFs? Should he choose
>> different images, one for each page? (This sounds like the most
>> reasonable way compared to other ways I thought of).
>
> Why would we want to allow the user to create multi-paged PDF files?
>
> Perhaps, before anything else, we need to clearly define what the
> purpose of PDF export is. We certainly don't want to provide a tool to
> create an illustrated book. That's what page layout applications are
> used for.
>
>
> Sven
>
>

Indeed, what is the advantage of pdf export of a single image?

Despite the current obsession with this format it is pretty clunky and
inflexible. I don't see much point for a single image.

PDF would just be a simple wrapper and this would best be done by and
pdf editor that fully supports all the pdf features. It's unlikely gimp
would want to maintain full functionality just to do this export.

The other question is licensing of pdf. IRCC pdf viewing is allowed in a
fairly liberal sense but creating pdf is what Abode make money on and
retains the rights to.

I could be wrong but that was my recollection.

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[bgw-2]

gg wrote:

> Sven Neumann wrote:
>  
>> Hi,
>>
>> On Fri, 2009-03-20 at 22:04 +0200, LightningIsMyName wrote:
>>
>>    
>>> 1. How will the user create multi-paged PDFs? Should he choose
>>> different images, one for each page? (This sounds like the most
>>> reasonable way compared to other ways I thought of).
>>>      
>> Why would we want to allow the user to create multi-paged PDF files?
>>
>> Perhaps, before anything else, we need to clearly define what the
>> purpose of PDF export is. We certainly don't want to provide a tool to
>> create an illustrated book. That's what page layout applications are
>> used for.
>>
>>
>> Sven
>>
>>
>>    
>
> Indeed, what is the advantage of pdf export of a single image?
>
> Despite the current obsession with this format it is pretty clunky and
> inflexible. I don't see much point for a single image.
>
> PDF would just be a simple wrapper and this would best be done by and
> pdf editor that fully supports all the pdf features. It's unlikely gimp
> would want to maintain full functionality just to do this export.
>
> The other question is licensing of pdf. IRCC pdf viewing is allowed in a
> fairly liberal sense but creating pdf is what Abode make money on and
> retains the rights to.
>
> I could be wrong but that was my recollection.

Maybe. But my OpenOffice has "export as PDF" options in Impress
(PowerPoint-like), Calc (Excel-like) and Writer (Word-like). OpenOffice
is free and available, as we all know, for Windoze, MAC, and *nix.

When I want a multipage PDF of a bunch of images, I write them to jpg,
paste them into a Writer document, then export them to PDF. I know it's
clunky, but it works.

 -- Burnie
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

Hi,

On Sat, 2009-03-21 at 12:41 +0100, gg wrote:

> The other question is licensing of pdf. IRCC pdf viewing is allowed in a
> fairly liberal sense but creating pdf is what Abode make money on and
> retains the rights to.

I am pretty sure that this is not the case. The GIMP Print plug-in
creates PDF files easily and we don't pay Adobe any money for that.


Sven


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

Hi,

On Sat, 2009-03-21 at 12:41 +0100, gg wrote:

> Indeed, what is the advantage of pdf export of a single image?

If it is just a simple PDF, then nothing. But if it includes color
profiles, support for spot colors, resolution-independent text layers,
crop markers etc., then it would be a versatile format for getting your
image printed processionally. But we definitely need someone who has
some experience with using PDF for this purpose to tell us what exactly
is needed.


Sven


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[LightningIsMyName]

Hello again,

On Sat, Mar 21, 2009 at 11:15 AM, Sven Neumann <sven@...> wrote:

> Hi,
>
> On Fri, 2009-03-20 at 22:04 +0200, LightningIsMyName wrote:
>
>> 1. How will the user create multi-paged PDFs? Should he choose
>> different images, one for each page? (This sounds like the most
>> reasonable way compared to other ways I thought of).
>
> Why would we want to allow the user to create multi-paged PDF files?
>
> Perhaps, before anything else, we need to clearly define what the
> purpose of PDF export is. We certainly don't want to provide a tool to
> create an illustrated book. That's what page layout applications are
> used for.

I believe that we should have the option to export multi-paged PDFs,
since we have the option to import them, and to me it makes sense that
we should be able to export what we can import. Gimp may not be a
page-layout program, yet doing multi-paged PDFs isn't too hard, and
won't hurt anyone...

And about what you said on page layout tools, there is some sense in
what you said. Therfore, I think it would be indeed simpler to ignore
paths untill gimp has vector layers, since these aren't the main point
of the PDF plugin. The only feature I believe that is necessary, is to
draw single-colored rectangles as drawing and not as bitmap-images
(Imagine a background layer for a large scale image - a bitmap image
can be a big waist of memory).
However, this can be solved easily by finding all the layers in the
image which have only 1 color (same RGBA values everywhere). I still
need to figure out how to do this (probably using gimp_histogram in
some way).

-- LightningIsMyName
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Alexandre Prokoudine]

On 3/21/09, gg wrote:

> Despite the current obsession with this format it is pretty clunky and
> inflexible. I don't see much point for a single image.

Ahem, and what is your expertize to make such a bold statement?

> The other question is licensing of pdf. IRCC pdf viewing is allowed in a
> fairly liberal sense but creating pdf is what Abode make money on and
> retains the rights to.

I nearly choked when I read this. The next statement of that kind
would be "GIMP doesn't support CMYK because of patents". I don't
really know what makes you think there is any legal issue regarding
creating PDF files, but rest assured that there is no such issue.

Alexandre
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

Hi,

On Sat, 2009-03-21 at 21:36 +0200, LightningIsMyName wrote:

> I believe that we should have the option to export multi-paged PDFs,
> since we have the option to import them, and to me it makes sense that
> we should be able to export what we can import.

The whole point of calling it "Import" is to make clear that you can't
save this again.

> Gimp may not be a
> page-layout program, yet doing multi-paged PDFs isn't too hard, and
> won't hurt anyone...

Of course it would hurt. It binds development resources for creating and
maintaining it. If a feature does not fit with our product vision, then
we are not going to include it.

Doing multi-page PDF export simply because we can do it is not going to
happen. What we need here is a user story. Without that, it doesn't make
sense to discuss PDF export at all.

> And about what you said on page layout tools, there is some sense in
> what you said. Therfore, I think it would be indeed simpler to ignore
> paths untill gimp has vector layers, since these aren't the main point
> of the PDF plugin. The only feature I believe that is necessary, is to
> draw single-colored rectangles as drawing and not as bitmap-images
> (Imagine a background layer for a large scale image - a bitmap image
> can be a big waist of memory).

I don't understand why that is needed. What is our goal here? To create
PDF files as small as possible? IMO the goal for PDF export should be to
improve support for professional printing. File size is not important
for that. Paths are also not important for that. If people need vector
art, then they should use a vector editor. What matters is color
profiles, CMYK color separation in the export process, support for spot
colors, crop marks, ...

As I said already, we can't discuss the details unless we know what the
goals are. So we need to have one or more user stories for PDF export
first. And we need to check these against our product vision to see if
they are worth supporting.


Sven


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Chris Mohler]

On Sun, Mar 22, 2009 at 6:19 AM, Sven Neumann <sven@...> wrote:
[...]

> I don't understand why that is needed. What is our goal here? To create
> PDF files as small as possible? IMO the goal for PDF export should be to
> improve support for professional printing. File size is not important
> for that. Paths are also not important for that. If people need vector
> art, then they should use a vector editor. What matters is color
> profiles, CMYK color separation in the export process, support for spot
> colors, crop marks, ...
>
> As I said already, we can't discuss the details unless we know what the
> goals are. So we need to have one or more user stories for PDF export
> first. And we need to check these against our product vision to see if
> they are worth supporting.

I see two possible use cases:

1. Proofing artwork - you need to prepare a proof before going to
press.  You send that proof to a client and they print it out and get
a reasonable hard proof.

2. Submission to a printing company - you need to submit hi-res
artwork to a printing company.

For either case to be useful, the PDF export needs to at least
support: CMYK color mode, ICC profiles, spot colors, trim marks, crop
area, and bleed area.  Embedding or outlining (vector) fonts,
registration marks, encryption, and downsampling of image/photo layers
could possibly be useful.

That being said, both use cases would only come about when setting up
a full-color job (CMYK, etc.) - and it is very likely that the
printing company would accept (and perhaps prefer) a hi-res raster
format like TIFF, PNG, or JPEG.  I submit PDFs all of the time for
proofing and printing but 90% are pure vector, 9% are vector with
embedded bitmap images, and only the remaining 1% are completely
raster (I've used at least one printing company that accepts pdf
*only*).

IMHO: Attempting to redraw solid colors as vector would not be a good
idea .  File size is not really a concern - creating PDFs that print
in a reliable manner and are as accurate as possible would be the main
challenge.  If GIMP comes to support vector layers at some point, then
an option to rasterize those layers or keep them as vector should be
presented at the time of PDF export.  Multi-page is not something that
GIMP should worry about at all - there are plenty of tools to join
PDFs already, and multi-page documents are more the domain of page
layout software.

PDF export might be a nice feature, but as a designer I would not use
it very often.  If I did use it, I would expect it to be *extremely*
reliable, and quite verbose about any errors before or during export.

Chris
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Cristian Secară]

On Sun, 22 Mar 2009 09:47:00 -0500, Chris Mohler wrote:

> I see two possible use cases:
>
> 1. Proofing artwork - you need to prepare a proof before going to
> press. [...]
>
> 2. Submission to a printing company - you need to submit hi-res
> artwork to a printing company.
> [...]

What would be the advantage of handling a .pdf generation at
application level instead of at operating system level ?
(i.e. via print command)

Cristi
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Alexandre Prokoudine]

2009/3/22 Cristian Secară wrote:

> What would be the advantage of handling a .pdf generation at
> application level instead of at operating system level ?
> (i.e. via print command)

Far more features supported.

Install Scribus, go to File - Export - Save as PDF, then visit Fonts,
Security, Color (make sure you choose "Output intended for: Printer"
and enable "Use custom rendering settings" checkbox) and Pre-Press
tabs.

Alexandre
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

Hi,

On Sun, 2009-03-22 at 09:47 -0500, Chris Mohler wrote:

> I see two possible use cases:
>
> 1. Proofing artwork - you need to prepare a proof before going to
> press.  You send that proof to a client and they print it out and get
> a reasonable hard proof.
>
> 2. Submission to a printing company - you need to submit hi-res
> artwork to a printing company.
>
> For either case to be useful, the PDF export needs to at least
> support: CMYK color mode, ICC profiles, spot colors, trim marks, crop
> area, and bleed area.  Embedding or outlining (vector) fonts,
> registration marks, encryption, and downsampling of image/photo layers
> could possibly be useful.
>
> That being said, both use cases would only come about when setting up
> a full-color job (CMYK, etc.) - and it is very likely that the
> printing company would accept (and perhaps prefer) a hi-res raster
> format like TIFF, PNG, or JPEG.

Thanks a lot for your input. That was very useful.

So would you say that it makes more sense to spend time improving the
TIFF save plug-in or would it be a better idea to invest that
development into a powerful PDF export? My experience with TIFF is that
it is an extremely difficult format as most of the important features
are implemented as some sort of extension that is not part of the TIFF
6.0 specification. I would hope PDF to be better specified.


Sven


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[peter sikking]

Sven wrote:

> So would you say that it makes more sense to spend time improving the
> TIFF save plug-in or would it be a better idea to invest that
> development into a powerful PDF export? My experience with TIFF is  
> that
> it is an extremely difficult format as most of the important features
> are implemented as some sort of extension that is not part of the TIFF
> 6.0 specification. I would hope PDF to be better specified.


bummer about the non-standard, but would industrial-strength TIFF
in and export not be significantly more in line with our product
vision than industrial-strength pdf in and export?

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture



_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Cristian Secară]

On Sun, 22 Mar 2009 21:23:24 +0300, Alexandre Prokoudine wrote:

> Far more features supported.
>
> Install Scribus, go to File - Export - Save as PDF, then visit Fonts,
> Security, Color [...]

I assume it all depends on the application used for .pdf generation.
Adobe Distiller (& Acrobat) has a comprehensive set of options.
Not 100% sure, but perhaps Ghostscript based applications too, except
that the user has to know the Ghostscript parameters (i.e. hard to use
for more than basic .pdf generation, but possible).

Cristi
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

Hi,

On Sun, 2009-03-22 at 19:33 +0100, peter sikking wrote:

> bummer about the non-standard, but would industrial-strength TIFF
> in and export not be significantly more in line with our product
> vision than industrial-strength pdf in and export?

Depends on what gets used nowadays. If professionals are turning away
from TIFF and start to adopt PDF instead, then PDF support would be more
in line with our product vision.


Sven


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[peter sikking]

Sven wrote:

>> bummer about the non-standard, but would industrial-strength TIFF
>> in and export not be significantly more in line with our product
>> vision than industrial-strength pdf in and export?
>
> Depends on what gets used nowadays. If professionals are turning away
> from TIFF and start to adopt PDF instead, then PDF support would be  
> more
> in line with our product vision.


when I wrote the previous message I already knew that this is the
only counter-argument that I was going to accept.

so now we really need some trend spotting from those in our community
who deal with serious printing jobs.

and when then moving forward with pdf, we should keep in mind
what a GIMP document actually is: a single canvas/image
(please do not mention the animation hacks we have...)

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture



_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Filipe Soares Dilly]

Just my two cents;

TIFF is more important to GIMP because TIFF is widely used on printing and CG works. Its a common practice to use TIFF images in professional page layout programs like Scribus and Adode InDesign for example. And some 3d programs (like zbrush) use TIFF for export texture maps (in high bit dephs).

A better TIFF support would be more in sync with GIMP, me thinks.

PS: sorry for any English mistakes. =/

--
Filipe Soares Dilly
dilly.carbonmade.com/

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer