2009/6/15 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">> 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>
</div>Bad. Having unmanaged (generic in fact) color transformation is not exactly<br>
the first step of a controlled printing process.</blockquote><div><br>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.<br>
<br>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.<br>
<br>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?<br><br>Louis<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>
> 1. Width information for glyphs is inconsistent: it is required that<br>
> the glyph widths in the font dictionary and the glyph widths in the<br>
> embedded font are consistent.<br>
<br>
</div>As we don’t use widths at all atm, I’ll be curious to investigate this part.<br>
Might be the occasion to finally use TJ operators :)<br>
<div class="im"><br>
> 2. Wrong encoding for non-symbolic TrueType font: it is required that<br>
> non-symbolic TrueType fonts use MacRomanEncoding or WinAnsiEncoding<br>
> without any differences. The output I got from Scribus uses<br>
> Differences dictionary extensively for encoding which causes this<br>
> issue, I guess.<br>
<br>
</div>Here I must say I lack knowledge about PDF/X-4. I see a major rewrite of font<br>
embedding if the work has to be done on the font side -- which is what I<br>
understand has to be done if you want to fit in only 2 encoding schemes.<br>
<div class="im"><br>
><br>
> My guess would be these are just some of the possible issues since<br>
> there can be many more restrictions in the font usage in PDF/X-4 and<br>
> without getting my hand on the full PDF/X-4 spec, fully supporting PDF/<br>
> X-4 export would be quite a challenge. I have tried to google around<br>
> for some more details on PDF/X-4 but no luck so far. Hope you guys<br>
> could help.<br>
<br>
</div>Yes, we’re a bit too short on PDF/X-4 documentation to pretend we can support<br>
it actually. I’ll drop a line on PoDoFo mailing list to know if someone has<br>
more info.<br>
In the meantime, the work on X/1-a should go on. But really I don’t think its<br>
a good idea to do implicit color transformation in this case.<br>
<br>
bon courage<br>
<font color="#888888"><br>
<br>
--<br>
Pierre Marchand<br>
<a href="http://www.oep-h.com" target="_blank">http://www.oep-h.com</a><br>
</font><div><div></div><div class="h5"><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><br><br>