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

[Louis Desjardins]

2009/6/16 Pierre Marchand <pierremarc at oep-h.com>

> Vous avez écrit :
> > 2009/6/15 Pierre Marchand <pierremarc at oep-h.com>
> >
> > > Vous avez écrit :
> > > > As for PDF/X-1a, since this format enforces blind exchange where all
> > > > colors need to be in DeviceCMYK, I have decided to let users export
> to
> > > > PDF/X-1a only if the Color Management is turned *off* in the
> > > > document's setting as opposed to it to be turned on in exporting PDF/
> > > > X3.
> > >
> > > Bad. Having unmanaged (generic in fact) color transformation is not
> > > exactly the first step of a controlled printing process.
> >
> > I am not too sure wether this is good or bad since PDF/X-1a requires
> > explicitely no RGB data but CMYK data. One could assume that the CMYK
> files
> > have been produced in a controlled environment and contain the necessary
> > data.
>
> Here, the "controlled environment" is Scribus itself. If you ask it to
> produce
> a CMYK file, it will convert colors of objects from their declared color
> space
> (either on a per item basis or taking it from document’s settings) to the
> target color space specified for the document. Or, if you disable CM, it
> will
> do the very same conversion but based on an _implicit_ target profile.
> Jean can correct me if i’m wrong or imprecise.


But if we have a CMYK image in, we will have a CMYK image out, without any
conversion, no?

>
>
> >
> > 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
> to
> > 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.

>
>
> >
> > 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.

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.

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?

Cheers!

Louis

Note that when
> we’ll un-mark PDF embedding as experimental, we’ll have to do a lot more
> checks on embedded content streams. Examining both the PDF version, graphic
> state, etc.
>
>
> --
> Pierre Marchand
> http://www.oep-h.com
>
>
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20090616/8a449e4c/attachment.htm>