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

[Philip Taylor]

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.
> 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 ?
> 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.
> 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.
> 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)
>>
>>  2. 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 ?
>
>>  3. 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.
> (snip)
>>
>>  4. 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/xetex/attachments/20160711/52c9fd7c/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/52c9fd7c/attachment-0001.jpe>