[XeTeX] Σχετ: Plain XeTeX, pdftitle, pdfinfo

[Zdenek Wagner]

2016-07-11 10:36 GMT+02:00 Philip Taylor <P.Taylor at rhul.ac.uk>:

> Dear Ross --
>
> Ross Moore wrote:
>
> Just to summarise (for the benefit of archives and posterity), the
> following is /almost/ sufficient to achieve PDF/X-1A:2003 compliance using
> plain XeTeX.
>
> I note the /almost/.   :-)
>
> Well, yes, but far closer than I was 24 hours before !
>
> Full compliance can be achieved using Adobe Acrobat.
>
> Of course. Using the “Preflight” utility in modern Acrobat Pro, you can do
> just about
> anything with PDFs, for standards compliance and compatibility.
>
> The big problem is to do it entirely within TeX-related software,
> *without* using Acrobat Pro, except for checking that you’ve done it right.
>
> Agreed.  I would certainly like to be able to accomplish that, but with a
> 302~pp book waiting to go to press, I have to accept what is possible
> within a very limited time frame.
>

As I found, it is not necessary to be fully PDF/X compliant, in some cases
even PDF 1.5 is acceptable. It is a matter of negotiation with the printer
what they accept and what they do not. The good companies are able to
visualize the output without actually printing it so it is possible to
check. and they can make the proof available on their web and send the
private link to the customer.

> In reality, creating PDF/X-compliant documents is significantly more
> involved
> than what you have achieved so far.
>
> I am more than willing to accept that.  However, Adobe Acrobat 7.1
> pronounces my book "PDF/X-1A:2003" compliant, so I genuinely believed that
> I had achieved my goal.
>
> 1.  You should drop the  /ArtBox  completely.
>       PDF/X allows  /ArtBox  or /TrimBox  but *not both* (even if they are
> set to be the same).
>      Some applications require the /TrimBox, so this figures to be the
> best choice.
>
> Thank you, will do.
>
>
> 2.  PDF/X-1a  doesn’t like compressed object streams.
>      There is a command-line switch:   xdvipdfmx -z 0  .
>      But it results in a much larger file size in a real-world document.
>      Besides, with a document based on your example, and using this switch,
>      I cannot get Acrobat to stop complaining about compressed object
> streams,
>      even though the page stream is clearly not compressed:
>
> 5 0 obj
> <</Length 117>>
> stream
>  q 1 0 0 1 72 769.89 cm BT /F1 9.9626 Tf 19.925 -9.963
> Td[(Hello)-333(W)82(orld!)]TJ 211.584 -654.747 Td[(1)]TJ ET Q
>
> endstream
>
> Fonts in that PDF do use compression.
> The only other thing compressed is the XRef table.
> When Acrobat is asked to convert to PDF/X the  xref table is uncompressed;
> so that figures to be the real issue here.
>
> Interesting.  I get no such complaint for any of the 302 pages, but
> neither am I asking Acrobat to convert the PDF to PDF/X (I would not know
> how to) -- all I am asking Acrobat to do is (a) convert the colour space,
> and (b) reduce the file size while making the PDF Acrobat 4+ compatible.
> At the end of these two processes, Acrobat 7.1 pre-flight tells me the
> result is fully PDF/X-1A:2003 compliant
>
>
> Pity there is no free online PDF/X validator, like there are for PDF/A, to
> see what it might say.
> In any case, we need to be able to stop  xdvipdfmx  from producing a
> compressed XRef table.
>
>
> 3.  Your OutputIntent with  /Info(None)  and  /OutputConditionIdentifier
> (Custom)
>      is of no use to anybody or anything.  I’m surprised Acrobat doesn’t
> flag this.
>
> Ah, these must be the default values output by Hyperref in the absence of
> any other information; I can see I shall have to create a better-specified
> LaTeX source and then re-analyses the \specials that Hyperref emits.
>
>      You need to include a real ICC color profile (usually CMYK for PDF/X)
> which is
>      typically at least .5 MByte in size, often much larger.
>
> No idea how to include a colour profile, Ross; can you advise, please ?
>

pdfx.sty can do it but it makes use of hyperref which I do not like because
it is a big package. My document containing English + Hindi crashed with
one version of hyperref but I was unable to prepare a minimal example in
order to write a useful bug report. It would be nice to have an interface
for preparation PDF/A and PDF/X without Acrobat. Anyway, I never include an
ICC profile. I just convert the colours to CMYK using the right profiles
and the resulting colours are exactly as I wanted.

> 4.  The  \special {pdf: docinfo << … }   while valid, is *not* the
> recommended way to
>      provide Metadata.
>      The modern way is via  XMP which is an XML stream using uncompressed
> UTF-8 encoding.
>      Some  docinfo  fields can be included also, provided they agree
> *exactly* with what
>      is in the XMP packet.  For things like multiple authors, and more
> than one Keyword entry,
>      it is best to put them into the XMP *only*.
>
>      Again, with PDF/X-4 and higher, this is flagged as an issue.
>
> Again, this is Hyperref's default behaviour; Acrobat itself then adds the
> XMP stuff when it saves the file.
>

pdfx.sty can do it

What I dislike is that pdfx has A4 size hard-wired, zwpagelayout.sty
calculates the boxes based upon \paperheight and \paperwidth (without using
eTeX and lua, just the old dimen registers arithmetic).

> All of these issues are addressed, also for XeLaTeX, in the latest version
> (1.5.8)
> of the  pdfx  LaTeX package.
>
>          https://www.ctan.org/pkg/pdfx?lang=en
>
> The package itself implements everything, (including ensuring that the
> correct color spaces are used)
> and the documentation explains how to specify the (external) Metadata that
> you may wish to provide.
> It has a sub-section discussing the limitations when using XeTeX as engine.
>
> Hmmm.  Past experience suggests that LaTeX packages are no easy to get to
> work in a Plain context, but if I look at the \specials emitted that may
> well provide key information.  I know that this particular stable door was
> closed over 20 years ago, but I still wish that LaTeX were far far more
> modular than it actually is.  If only one could have a trivial wrapper such
> as Miniltx and then /any/ package could be used from within a Plain
> framerwork, how wonderful life would be.
>

Especially this one, it depends on a lot of files. I wanted to extract
ideas how to build the XMP, how to include the ICC but I gave up.

> Although a LaTeX package, you can check the source coding to find out how
> issues
> are addressed. Look in particular for  \ifxetex  sections.
>
> Thank you, I will.
>
> (snip)
>
>
>    1. the colours will need to be converted to the desired output profile
>    using Adobe Acrobat;
>
> pdfx.sty  uses the  xcolor  package to handle this.
>                Once a Color Profile is declared (either CMYK or RGB) the
> appropriate options
>                are prepared for  xcolor  then the package is loaded with
> these options.
>                Internal macros are rigged to stop changes being made, if
> the author tries to
>                load the package separately. Similarly if  color  was
> loaded before  pdfx ,
>                then appropriate coding imposes the correct color space.
>
>                The upshot of this is that whenever a color is requested by
> name (‘blue’, ‘red’,
>                 ‘green’, ‘magenta’, etc.) then the correct color space
> coordinates are used.
>                 Also, if a new color is declared (say as RGB) but the
> color model is CMYK,
>                 then a conversion is done on the declaration, giving CMYK
> coords when that
>                 new color is used.
>
> OK, but I am not using named colours; I have using 3 hex pairs following
> the font name in XeTeX's \font specifier.  An earlier query on this list
> suggested that this was hard-wired to RGB -- if indeed that is the case,
> how does pdfx.sty get around that ?
>
>
>
>    1. the file will need to be reduced in size with Acrobat 4+
>    compatibility but with no image compression in order to convert it to PDF
>    1.3;
>
>      Not sure of the specifics of this.
>      Can anyone provide example documents?
>
> Well, I can :-)  By default, XeTeX generates PDF 1.6;  by loading the
> document into Adobe Acrobat and telling the latter to "Reduce file size",
> one is given the option of specifying the earliest release of Acrobat with
> which the resultant PDF is to be compatible, and if Acrobat 4 is selected,
> then the resultant PDF is PDF 1.3.  Inhibiting image compression is just a
> question of adjusting the settings in Acrobat's PDF Optimiser.
>

Acrobat (at least v9) has even PDF/X profile, you can convert almost any
PDF to PDF/X in a single step.

> (snip)
>
>
>    1. the dimensions of the bounding boxes are for B5 in so-called "big
>    points" (Postscript points) and will need to be amended for other page
>    sizes;
>
>      Setting these as a constant for all pages figures to be OK for most
> documents.
>      Even better might be to reset to the size of each box being
> shipped-out.
>
>      Since this can actually be done bypassing the \output  routine, then
> it
>      requires patching  \shipout  rather than \makeheader  or similar.
>      This is certainly an issue for further discussion.
>
> True, but my challenge was to achieve PDF/X-1A:2003 compliance for a
> single book, in which I can be confident that \shipout is not called other
> than through \output {}; a general solution, would, of course, be
> considerably more complex.
>
> (snip)
>
>
> Yes, (w/o /ArtBox ); but if you are hooking into  \shipout ,
> why not measure the size of the box being shipped?
> Do the conversion into actual points.
> Will the bottom-left corner always be at  [0 0] ?
> Probably need to look also at  \hoffset  and  \voffset .
>
> IMHO, the default values of \hoffset and \voffset are INSANE.  I can use
> no milder word.  Every TeX project that I have ever undertaken is forced to
> reset these, along the lines of the following.
>
> \newdimen \innermargin
> \newdimen \outermargin
> \newdimen \uppermargin
> \newdimen \lowermargin
> \newdimen \cropwidth
> \newdimen \cropheight
> \newdimen \cropmark
> \newdimen \cropmitre
> \newdimen \Knuthoffset
>
> \innermargin = 0,618 true in
> \outermargin = 1,0 true in
> \uppermargin = \dimexpr (\innermargin + \outermargin) / 2 \relax
> \lowermargin = \uppermargin
> \Knuthoffset = 1 in
>
> \hsize = 176 true mm
> \vsize = 250 true mm
> \ifcropmarks
>     \pdfpagewidth = 210 true mm
>     \pdfpageheight = 297 true mm
> \else
>     \pdfpagewidth = \hsize
>     \pdfpageheight = \vsize
> \fi
> \advance \hsize by -1.618 true in
> \advance \vsize by -1.618 true in
> \parindent = 0 pt
>
> \advance \hoffset by \dimexpr -0.382 true in / 2 \relax
> \advance \voffset by \dimexpr -0.382 true in / 2 \relax
>
> \ifcropmarks
>     \advance \hoffset by \dimexpr (210 true mm - 176 true mm) / 2 \relax
>     \advance \voffset by \dimexpr (297 true mm - 250 true mm) / 2 \relax
> \fi
>
> Anyhow, thank you very much indeed for your most helpful comments and
> analysis, which are very much appreciated.
> ** Phil.
> --
>
> Philip Taylor
>
>
>
>
>
> --------------------------------------------------
> Subscriptions, Archive, and List information, etc.:
>   http://tug.org/mailman/listinfo/xetex
>
>

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/xetex/attachments/20160711/df880f53/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 12104 bytes
Desc: not available
URL: <http://tug.org/pipermail/xetex/attachments/20160711/df880f53/attachment-0001.jpe>