2009/6/16 Pierre Marchand <span dir="ltr"><<a href="mailto:pierremarc@oep-h.com">pierremarc@oep-h.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Vous avez écrit :<br>
<div class="im">> 2009/6/15 Pierre Marchand <<a href="mailto:pierremarc@oep-h.com">pierremarc@oep-h.com</a>><br>
><br>
> > Vous avez écrit :<br>
> > > As for PDF/X-1a, since this format enforces blind exchange where all<br>
> > > colors need to be in DeviceCMYK, I have decided to let users export to<br>
> > > PDF/X-1a only if the Color Management is turned *off* in the<br>
> > > document's setting as opposed to it to be turned on in exporting PDF/<br>
> > > X3.<br>
> ><br>
> > Bad. Having unmanaged (generic in fact) color transformation is not<br>
> > exactly the first step of a controlled printing process.<br>
><br>
> I am not too sure wether this is good or bad since PDF/X-1a requires<br>
> explicitely no RGB data but CMYK data. One could assume that the CMYK files<br>
> have been produced in a controlled environment and contain the necessary<br>
> data.<br>
<br>
</div>Here, the "controlled environment" is Scribus itself. If you ask it to produce<br>
a CMYK file, it will convert colors of objects from their declared color space<br>
(either on a per item basis or taking it from document’s settings) to the<br>
target color space specified for the document. Or, if you disable CM, it will<br>
do the very same conversion but based on an _implicit_ target profile.<br>
Jean can correct me if i’m wrong or imprecise.</blockquote><div><br>But if we have a CMYK image in, we will have a CMYK image out, without any conversion, no?<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div class="im"><br>
><br>
> What strikes me more here is the fact that we would claim that Scribus<br>
> supports PDF/X-1a but at the same time the application is, afaik, unable to<br>
> flaten the transparency eventually used in that file. In fact, this will<br>
> make the format unusable for just any Scribus document containing<br>
> transparency.<br>
<br>
</div>Whereas it can’t flatten transparencies, it can, and does, check that no<br>
transparency is used in a document before exporting to PDF1.3.</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="im"><br>
><br>
> I know we have discussed briefly this on IRC and it has been mentionned<br>
> that flatening transparency is a complicated task. But shouldn’t one come<br>
> with the other?<br>
<br>
</div>Not necessiraly. Writing a flatener will/would be a very long run job. And, in<br>
my opinion, it can’t be handled by only one person in one shot. I expect it to<br>
be written little by little, on an incremental basis, as ideas come.<br>
In the meantime (and this kind of can late :-) I think the actual strategy of<br>
checking tranparency in objects before exporting is enough.</blockquote><div><br>I agree checking transparency is a first step. Is it "enough" mostly depends on users needs.<br><br>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.<br>
<br>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.<br>
<br>In the end, I think it is going to be "usable" but we need to clearly warn our users about this limitation.<br><br>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.<br>
<br>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.<br><br>What do you think?<br><br>
Cheers!<br><br>Louis<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Note that when<br>
we’ll un-mark PDF embedding as experimental, we’ll have to do a lot more<br>
checks on embedded content streams. Examining both the PDF version, graphic<br>
state, etc.<br>
<font color="#888888"><br>
<br>
--<br>
</font><div><div></div><div class="h5">Pierre Marchand<br>
<a href="http://www.oep-h.com" target="_blank">http://www.oep-h.com</a><br>
<br>
<br>
<br>
_______________________________________________<br>
scribus-dev mailing list<br>
<a href="mailto:scribus-dev@lists.scribus.info">scribus-dev@lists.scribus.info</a><br>
<a href="http://lists.scribus.info/mailman/listinfo/scribus-dev" target="_blank">http://lists.scribus.info/mailman/listinfo/scribus-dev</a><br>
</div></div></blockquote></div>