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

[Thach Tran]

As I tested the PDF/X-3 and PDF/X-1a files output by Scribus, the  
transparency is in fact *flattened* (I tried the Brochure_1 sample  
shipped with Scribus which contains transparency). Is it because I am  
missing somethings?

Thach
On 15 Jun 2009, at 23:33, Louis Desjardins wrote:

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