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

[Louis Desjardins]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20090615/45ee86eb/attachment-0001.htm>