<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dear Ross --<br>
<br>
<div class="moz-cite-prefix">Ross Moore wrote:<br>
</div>
<blockquote
cite="mid:398101B6-03E1-43C9-A9A5-1AFBD5D56428@mq.edu.au"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
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.
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">
</div>
</blockquote>
<div>I note the /almost/. :-)</div>
</div>
</div>
</blockquote>
Well, yes, but far closer than I was 24 hours before !<br>
<blockquote
cite="mid:398101B6-03E1-43C9-A9A5-1AFBD5D56428@mq.edu.au"
type="cite">
<div class="">
<div>Full compliance can be achieved using Adobe Acrobat.
<br class="">
<blockquote type="cite" class="">
<div class="">
</div>
</blockquote>
Of course. Using the “Preflight” utility in modern Acrobat
Pro, you can do just about</div>
<div>anything with PDFs, for standards compliance and
compatibility.<br class="">
<div><br class="">
</div>
<div>The big problem is to do it entirely within TeX-related
software, </div>
<div>*without* using Acrobat Pro, except for checking that
you’ve done it right.</div>
</div>
</div>
</blockquote>
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.<br>
<blockquote
cite="mid:398101B6-03E1-43C9-A9A5-1AFBD5D56428@mq.edu.au"
type="cite">
<div class="">
<div>
<div>In reality, creating PDF/X-compliant documents is
significantly more involved</div>
<div>than what you have achieved so far.</div>
</div>
</div>
</blockquote>
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.<br>
<blockquote
cite="mid:398101B6-03E1-43C9-A9A5-1AFBD5D56428@mq.edu.au"
type="cite">
<div class="">
<div>1. You should drop the /ArtBox completely.
<div> PDF/X allows /ArtBox or /TrimBox but *not both*
(even if they are set to be the same).</div>
<div> Some applications require the /TrimBox, so this
figures to be the best choice.</div>
</div>
</div>
</blockquote>
Thank you, will do.<br>
<blockquote
cite="mid:398101B6-03E1-43C9-A9A5-1AFBD5D56428@mq.edu.au"
type="cite">
<div class="">
<div>
<div><br class="">
</div>
<div>2. PDF/X-1a doesn’t like compressed object streams.</div>
<div> There is a command-line switch: xdvipdfmx -z 0 .</div>
<div> But it results in a much larger file size in a
real-world document.</div>
<div> Besides, with a document based on your example, and
using this switch,</div>
<div> I cannot get Acrobat to stop complaining about
compressed object streams,</div>
<div> even though the page stream is clearly not
compressed:</div>
<div> </div>
<div>
<div style="margin: 0px; font-size: 11px; font-family:
Menlo;" class="">5 0 obj</div>
<div style="margin: 0px; font-size: 11px; font-family:
Menlo;" class=""><</Length 117>></div>
<div style="margin: 0px; font-size: 11px; font-family:
Menlo;" class="">stream</div>
<div style="margin: 0px; font-size: 11px; font-family:
Menlo;" class=""> 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</div>
<div style="margin: 0px; font-size: 11px; font-family:
Menlo; min-height: 13px;" class="">
<br class="">
</div>
<div style="margin: 0px; font-size: 11px; font-family:
Menlo;" class="">endstream</div>
<div class=""><br class="">
</div>
<div class="">Fonts in that PDF do use compression.</div>
<div class="">The only other thing compressed is the XRef
table.</div>
<div class="">When Acrobat is asked to convert to PDF/X the
xref table is uncompressed;</div>
<div class="">so that figures to be the real issue here. <br>
</div>
</div>
</div>
</div>
</blockquote>
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<br>
<blockquote
cite="mid:398101B6-03E1-43C9-A9A5-1AFBD5D56428@mq.edu.au"
type="cite">
<div class="">
<div>
<div>
<div class=""><br class="">
</div>
<div class="">Pity there is no free online PDF/X validator,
like there are for PDF/A, to see what it might say.</div>
<div class="">In any case, we need to be able to stop
xdvipdfmx from producing a compressed XRef table.</div>
<div class=""><br class="">
</div>
</div>
<div><br class="">
</div>
<div>3. Your OutputIntent with /Info(None) and
/OutputConditionIdentifier (Custom) </div>
<div> is of no use to anybody or anything. I’m surprised
Acrobat doesn’t flag this.</div>
</div>
</div>
</blockquote>
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.<br>
<blockquote
cite="mid:398101B6-03E1-43C9-A9A5-1AFBD5D56428@mq.edu.au"
type="cite">
<div class="">
<div>
<div> You need to include a real ICC color profile
(usually CMYK for PDF/X) which is</div>
<div> typically at least .5 MByte in size, often much
larger.</div>
</div>
</div>
</blockquote>
No idea how to include a colour profile, Ross; can you advise,
please ?<br>
<blockquote
cite="mid:398101B6-03E1-43C9-A9A5-1AFBD5D56428@mq.edu.au"
type="cite">
<div class="">
<div>4. The \special {pdf: docinfo << … } while valid,
is *not* the recommended way to
<div> provide Metadata. </div>
<div> The modern way is via XMP which is an XML stream
using uncompressed UTF-8 encoding.</div>
<div> Some docinfo fields can be included also, provided
they agree *exactly* with what</div>
<div> is in the XMP packet. For things like multiple
authors, and more than one Keyword entry,</div>
<div> it is best to put them into the XMP *only*.</div>
<div><br class="">
</div>
<div> Again, with PDF/X-4 and higher, this is flagged as
an issue.</div>
</div>
</div>
</blockquote>
Again, this is Hyperref's default behaviour; Acrobat itself then
adds the XMP stuff when it saves the file.<br>
<blockquote
cite="mid:398101B6-03E1-43C9-A9A5-1AFBD5D56428@mq.edu.au"
type="cite">
<div class="">
<div>
<div>All of these issues are addressed, also for XeLaTeX, in
the latest version (1.5.8) </div>
<div>of the pdfx LaTeX package.<br>
<br>
</div>
<div> <a moz-do-not-send="true"
href="https://www.ctan.org/pkg/pdfx?lang=en" class="">https://www.ctan.org/pkg/pdfx?lang=en</a></div>
<div><br class="">
</div>
<div>The package itself implements everything, (including
ensuring that the correct color spaces are used) </div>
<div>and the documentation explains how to specify the
(external) Metadata that you may wish to provide.</div>
<div>It has a sub-section discussing the limitations when
using XeTeX as engine.</div>
</div>
</div>
</blockquote>
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.<br>
<blockquote
cite="mid:398101B6-03E1-43C9-A9A5-1AFBD5D56428@mq.edu.au"
type="cite">
<div class="">
<div>
<div>Although a LaTeX package, you can check the source coding
to find out how issues</div>
<div>are addressed. Look in particular for \ifxetex
sections.</div>
</div>
</div>
</blockquote>
Thank you, I will.<br>
<blockquote
cite="mid:398101B6-03E1-43C9-A9A5-1AFBD5D56428@mq.edu.au"
type="cite">
<div class="">
<div>(snip)<br>
<blockquote type="cite" class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<ol class="" start="2">
<li class="">the colours will need to be converted to
the desired output profile using Adobe Acrobat;</li>
</ol>
</div>
</div>
</blockquote>
<div>pdfx.sty uses the xcolor package to handle this.</div>
<div> Once a Color Profile is declared (either
CMYK or RGB) the appropriate options</div>
<div> are prepared for xcolor then the package
is loaded with these options.</div>
<div> Internal macros are rigged to stop changes
being made, if the author tries to</div>
<div> load the package separately. Similarly if
color was loaded before pdfx ,</div>
<div> then appropriate coding imposes the
correct color space.</div>
<div><br class="">
</div>
<div> The upshot of this is that whenever a
color is requested by name (‘blue’, ‘red’,</div>
<div> ‘green’, ‘magenta’, etc.) then the
correct color space coordinates are used.</div>
<div> Also, if a new color is declared (say as
RGB) but the color model is CMYK,</div>
<div> then a conversion is done on the
declaration, giving CMYK coords when that</div>
<div> new color is used.</div>
</div>
</div>
</blockquote>
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 ?<br>
<blockquote
cite="mid:398101B6-03E1-43C9-A9A5-1AFBD5D56428@mq.edu.au"
type="cite">
<div class="">
<div>
<div><br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<ol class="" start="3">
<li class="">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;</li>
</ol>
</div>
</div>
</blockquote>
<div> Not sure of the specifics of this.</div>
<div> Can anyone provide example documents?</div>
</div>
</div>
</blockquote>
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.<br>
<blockquote
cite="mid:398101B6-03E1-43C9-A9A5-1AFBD5D56428@mq.edu.au"
type="cite">
<div class="">
<div>(snip)<br class="">
<blockquote type="cite" class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<ol class="" start="4">
<li class="">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;</li>
</ol>
</div>
</div>
</blockquote>
<div> Setting these as a constant for all pages figures to
be OK for most documents.</div>
<div> Even better might be to reset to the size of each
box being shipped-out.</div>
<div> </div>
<div> Since this can actually be done bypassing the
\output routine, then it</div>
<div> requires patching \shipout rather than \makeheader
or similar.</div>
<div> This is certainly an issue for further discussion.</div>
</div>
</div>
</blockquote>
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.<br>
<blockquote
cite="mid:398101B6-03E1-43C9-A9A5-1AFBD5D56428@mq.edu.au"
type="cite">
<div class="">
<div>
(snip)</div>
</div>
</blockquote>
<br>
<blockquote
cite="mid:398101B6-03E1-43C9-A9A5-1AFBD5D56428@mq.edu.au"
type="cite">
<div class="">
<div>
<div>Yes, (w/o /ArtBox ); but if you are hooking into
\shipout ,</div>
<div>why not measure the size of the box being shipped?</div>
<div>Do the conversion into actual points.</div>
<div>Will the bottom-left corner always be at [0 0] ?</div>
<div>Probably need to look also at \hoffset and \voffset .</div>
</div>
</div>
</blockquote>
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. <br>
<tt><br>
\newdimen \innermargin<br>
\newdimen \outermargin<br>
\newdimen \uppermargin<br>
\newdimen \lowermargin<br>
\newdimen \cropwidth<br>
\newdimen \cropheight<br>
\newdimen \cropmark<br>
\newdimen \cropmitre<br>
\newdimen \Knuthoffset<br>
<br>
\innermargin = 0,618 true in<br>
\outermargin = 1,0 true in<br>
\uppermargin = \dimexpr (\innermargin + \outermargin) / 2 \relax<br>
\lowermargin = \uppermargin<br>
\Knuthoffset = 1 in<br>
<br>
\hsize = 176 true mm<br>
\vsize = 250 true mm<br>
\ifcropmarks<br>
\pdfpagewidth = 210 true mm<br>
\pdfpageheight = 297 true mm<br>
\else<br>
\pdfpagewidth = \hsize<br>
\pdfpageheight = \vsize<br>
\fi<br>
\advance \hsize by -1.618 true in<br>
\advance \vsize by -1.618 true in<br>
\parindent = 0 pt<br>
<br>
\advance \hoffset by \dimexpr -0.382 true in / 2 \relax<br>
\advance \voffset by \dimexpr -0.382 true in / 2 \relax<br>
<br>
\ifcropmarks<br>
\advance \hoffset by \dimexpr (210 true mm - 176 true mm) / 2
\relax<br>
\advance \voffset by \dimexpr (297 true mm - 250 true mm) / 2
\relax<br>
\fi<br>
</tt><br>
Anyhow, thank you very much indeed for your most helpful comments
and analysis, which are very much appreciated.<br>
** Phil.<br>
-- <br>
<div class="moz-signature"> <img
src="cid:part2.09000201.04020505@Rhul.Ac.Uk"><br>
Philip Taylor</div>
<br>
<br>
</body>
</html>