[scribus-dev] GSoC project status: PDF/X export

[Pierre Marchand]

Vous avez écrit :
> But if we have a CMYK image in, we will have a CMYK image out, without any
> conversion, no?

No. If your source image is defined in a color space which does not match the 
target space, it will be transformed. In fact, even if the 2 spaces match, the 
transformation would be an identity but still a transformation :-)

>
> > > What strikes me more here is the fact that we would claim that Scribus
> > > supports PDF/X-1a but at the same time the application is, afaik,
> > > unable  flaten the transparency eventually used in that file. In fact, 
this
> > > will make the format unusable for just any Scribus document containing
> > > transparency.
> >
> > Whereas it can’t flatten transparencies, it can, and does, check that no
> > transparency is used in a document before exporting to PDF1.3.
>
> Yes. This is my point. No transparency allowed for PDF/X-1a. This means
> that any design that includes transparency when done with Scribus will not
> be exportable as a PDF/X-1a with FLOSS tools, correct me if I am wrong. On
> my part, if Scribus can’t do it but another FLOSS can do it, I have no
> problem with that.

It’s not that simple. As you know, when you flatten a document you make 
decision about what you preserve as vector objects and what you rasterize (to 
be very simple). The hard work is exactly to preserve as much vector data as 
you can. Afaik there’s nothing free to do this at the moment. The best you can 
do is to rasterize your documents with Ghostscript.

>
> > > I know we have discussed briefly this on IRC and it has been mentionned
> > > that flatening transparency is a complicated task. But shouldn’t one
> > > come with the other?
> >
> > Not necessiraly. Writing a flatener will/would be a very long run job.
> > And, in
> > my opinion, it can’t be handled by only one person in one shot. I expect
> > it to
> > be written little by little, on an incremental basis, as ideas come.
> > In the meantime (and this kind of can late :-)  I think the actual
> > strategy of
> > checking tranparency in objects before exporting is enough.
>
> I agree checking transparency is a first step. Is it "enough" mostly
> depends on users needs.

 :-)

> When I take the example of the Scribus manual, we learned that the cover
> needed some particular care to be handed as PDF/X-1a to some printers who
> would explicitely and exclusively require this format. Christoph can tell
> us what he had to do to produce this file in the end.
>
> I am not saying that there is no way around. In my shop we can handle PDF
> 1.3 and 1.4 without issues. But we have to aknowledge some workflows
> require PDF/X-1a and if the document includes transparency, Scribus can’t
> export to that format at the moment.
>
> In the end, I think it is going to be "usable" but we need to clearly warn
> our users about this limitation.

You mean "before" they start a job? I do agree.

>
> Plus, I wonder if this should be in the hands of the Scribus team or dealt
> with at another level, by another team? For instance, we would export to
> PDF 1.4, preserving transparency, and then go to that other tool to certify
> the PDF, including flatening it, if necessary, to produce PDF/X-1a or other
> 1.3 based flavors of certified PDF.

Don’t worry that if we hear of someone working on a free flattener we’ll 
immediately borrow his code :-)
Seriously, it’s really hard to rewrite Acrobat. We have some bricks now, I 
would say PoDoFo in first place but really we’re not here today.

>
> I am trying to put myself in the position of a designer who discovers at
> the end of a project that he must hand his job as a PDF/X-1a to a certain
> printer and then the problem starts.
>
> What do you think?

I would not want to be this designer!


-- 
Pierre Marchand
http://www.oep-h.com