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

[Philip Taylor]

Ross Moore wrote:
> Hi Phil,
>
>> On Jul 12, 2016, at 7:55 AM, Philip Taylor > > wrote:
>
>>> one can zoom in to examine specific parts. The text is fully mapped
>>> to Unicode, for easy searching and Copy/Paste.
>> What did surprise me is that hyperlinks are not active in the online 
>> version; one has to copy them and paste them into a browser, which is 
>> somewhat counter-intuitive.
>
> Jumping to conclusions again?  :-)
No, tried and no result whatsoever.  I use Adobe Acrobat Pro V7.1, and I 
regularly use it to follow hyperlinks in PDF (e.g., those from the image 
captions in 
"http://rhul.ac.uk/Hellenic-Institute/Research/LPL/Greek-MSS/Catalogue.pdf";) 
but for "http://mirrors.ctan.org/macros/latex/contrib/pdfx/pdfx.pdf"; I saw no 
effect whatsoever -- the text was of a different colour, but completely 
inactive.  However, I now see that I had previously been using Acrobat to edit 
an advertisement, and the currently selected tool was the text touch-up tool 
rather than the select tool, which does indeed explain the apparent 
dysfunctionality of the hyperlinks.  I am happy to confirm that (a 
representative sample of) the hyperlinks in 
"http://mirrors.ctan.org/macros/latex/contrib/pdfx/pdfx.pdf"; do indeed work as 
expected.I have only TeX Live 2014 (I always lag one or two releases) but 
"TeXdoc pdfx" displays the expected document so I may well have them; I will 
check tomorrow.
> Sounds good.
>
> Check that it is for v.1.5.8 with 81 pages incl. source listing in pdfx.pdf .
> The version number is at bottom right, in the footer.
>
> The one for  v.1.5.6 looks similar at the front, but the docs are much 
> shorter.
> (Only 12 pages w/o source listing.)
> Earlier versions have a different color scheme.
Mine is even earlier (only 9 pp); I shall have to install a more recent version.
> BTW, if you are going to work with PDFs into the future,
> invest in the latest Acrobat Pro DC. 
> I don’t know how much it costs for non-academic in the UK,
> but it’ll be the best 100–200 pounds you have ever spent,
> in terms of the time that it will save you.
I still have full academic status (Honorary Research Assistant) so could get it 
at an academic price, but as I wrote previously I unfortunately have no budget 
for such things -- all work that I have done since taking early retirement 
eight years ago has been strictly /pro bono/.  I also find ('though I may be 
wrong in the case of Adobe Acrobat) that modern versions of packages with which 
I am familiar in an older guise tend to have very non-ergonomic and cryptic 
user interfaces as (e.g.,) text labels are phased out in favour of cryptic 
icons and/or tiles.  Looking at Adobe Reader DC, for example, it looks as if it 
is intended for use only on a tablet or similar -- the "Tools" menu uses huge 
tiles and falls off the bottom of my (reasonably large) screen.  Support for 
modern devices may be commendable, but not when it is at the expense of support 
for the traditional keyboard and monitor setup.
-- 

Philip Taylor


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

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

[Philip Taylor]

Ross Moore wrote:
> That document makes no claim to be conformant to any PDF/X standard.
> Instead it is fully conformant with  PDF/A-2u — see image.
OK, then I was confused by its name.
> We supply PDF/A — for an archival version, with RGB monitor intent,
> as this corresponds most appropriately to the purpose of the document.
> It is a manual that will mostly be viewed and read online/onscreen.
> It contains several screen-shots which are best read online where
> one can zoom in to examine specific parts. The text is fully mapped
> to Unicode, for easy searching and Copy/Paste.
What did surprise me is that hyperlinks are not active in the online version; 
one has to copy them and paste them into a browser, which is somewhat 
counter-intuitive.
> I think that you have assumed that it will do what *you* want it
> to do, without having read the supplied documentation.
> That is always a recipe for disappointment.
Sorry, your assumption concerning my assumption is quite correct, but my 
assumption was based on your earlier message.

> The package, once installed, comes with two example documents:
>
>sample.tex
>small2e-pdfx.tex
>
> If you have the most recent TeXLive 2016 installed, 
> you can find them this way:
I have only TeX Live 2014 (I always lag one or two releases) but "TeXdoc pdfx" 
displays the expected document so I may well have them; I will check tomorrow.

Many thanks for your help, Ross; I shall continue tomorrow.
** Phil.
-- 

Philip Taylor


--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

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

[Philip Taylor]

Dear Ross (copy all) -- OK, I looked at the "pdfx" package and the first thing 
that surprised me was that the documentation file for it 
(http://mirrors.ctan.org/macros/latex/contrib/pdfx/pdfx.pdf), when inspected 
using Adobe Acrobat 7.1, fails the conformity check for PDF/X-1A:2003 on nine 
counts --

 1. Annotation inside page area
 2. Document contains actions
 3. GTS_PDFXVersion key missing
 4. OutputIntent for PDF/X missing
 5. OutputIntent profile not "prtr"
 6. PDF/X label missing or incorrect
 7. TrimBox or ArtBox missing
 8. Uses colour other than 4c or spot
 9. Uses transparency

While some of these are explained by the fact that it is intended for web 
delivery rather than printing, it does not give one enormous confident that the 
package works as intended.  What I would therefore like, if this is possible, 
is for an example LaTeX source file that uses the "pdfx" package and generates 
fully compliant PDF/X-1A:2003 with Xe(La)TeX as  the typesetting engine.  In 
particular I need it to generate OutputIntent with /Info other than (None) and 
OutputConditionIdentifier other than (Custom), so that I can see what a 
fully-compliant PDF/X-1A:2003 has in these metadata fields.  Also one that 
embeds an ICC color profile and XMP metadata.  If you (or any member of this 
list) has such a source file, I would be most grateful for a copy so that I can 
investigate the \specials necessary to accomplish all of these goals.

** Phil.
-- 

Philip Taylor



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

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

[Philip Taylor]

Zdenek Wagner wrote:
> 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.
Yes, that is what they have proposed, but we are asking for a hard-copy proof 
(for which we will be willing to pay, of course).
> Acrobat (at least v9) has even PDF/X profile, you can convert almost any PDF 
> to PDF/X in a single step.
Sadly I have no budget for Acrobat 9, since all work that I have done for the 
last eight years has been /pro bono/.

** Phil.
-- 

Philip Taylor



--
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex

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

[Zdenek Wagner]

2016-07-11 11:37 GMT+02:00 Ross Moore :

> Hi Zdenek,
>
> On Jul 11, 2016, at 7:03 PM, Zdenek Wagner 
> wrote:
>
> 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.
>
>
> Exactly.
> For Phil’s book it would be good to know precisely what the printers have
> requested.
>
> But for general usage into the future, we want the most flexible package
> that
> can be written, to cope with all the identifiable variables.
>
> I would like to have it too. I think it is time to prepare good interface
for package authors and users of all formats and engines.

>
>  even though the page stream is clearly not compressed:
>>
>>
>> 5 0 obj
>> <>
>> 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
>>
>
> OK. But this is after using Acrobat, yes?
> Not before.
>
> I hope that it is the matter of PDF version. If you limit the PDF version,
you will have no compression of streams. The problem is that
\pdfminorversion is understood by pdftex but AFAIK XeTeX does not send it
to xdvipdfmx. You have to use a command line switch.

>
>
> 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.
>
>
> Can you send me any file that shows this?
> I’m not interested in just MWEs, but real-world examples.
>

there was a clash in macros, the document did not compile.

>
> So far I can generate Metadata in Cyrillics, Greek, Armenian, Hebrew as
> well as latin-based languages.
> At some point I plan to tackle Indic scripts as well.
> So English + Hindi is an attractive challenge.
>

I can do it in English + Czech + Hindi + Urdu in XeLaTeX without the
machinery of hyperref but in most cases hyperref works just fine for
documents containing Hindi.

>
>
> 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.
>
>
> It’s not clear to me how important a CMYK profile really is for
> TeX-generated material.
> Mostly the CMYK colors are given algorithmically from RGB coordinates,
> so RGB would probably suffice anyway.
>
> Of course it’s a completely different story for artistic works,
> photographic or otherwise.
>

Yes, photos are my concern. So far I have produced a lot of books,
booklets, and leaflets with colour photographs. A few years ago I did an
extensive test of ICC profiles (the proofs were really printed which cost
me some money) so now I know how to convert the photos using LCMS and get
good result.

>
>
> 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).
>
>
>
> Not in v.1.5.8 — at least not for PDF/X.
> That was a specific request which I responded to.
>
>  pdfx.sty  has no coding about this for  PDF/A, so far as I can see.
> Maybe it’s another of the things that hyperref does, which needs
> to be over-ridden.  I’ll look again more closely tomorrow.
>

OK, I 

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

[Ross Moore]

Hi Zdenek,

On Jul 11, 2016, at 7:03 PM, Zdenek Wagner 
mailto:zdenek.wag...@gmail.com>> wrote:

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.

Exactly.
For Phil’s book it would be good to know precisely what the printers have 
requested.

But for general usage into the future, we want the most flexible package that
can be written, to cope with all the identifiable variables.


 even though the page stream is clearly not compressed:

5 0 obj
<>
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

OK. But this is after using Acrobat, yes?
Not before.



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.

Can you send me any file that shows this?
I’m not interested in just MWEs, but real-world examples.

So far I can generate Metadata in Cyrillics, Greek, Armenian, Hebrew as well as 
latin-based languages.
At some point I plan to tackle Indic scripts as well.
So English + Hindi is an attractive challenge.


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.

It’s not clear to me how important a CMYK profile really is for TeX-generated 
material.
Mostly the CMYK colors are given algorithmically from RGB coordinates,
so RGB would probably suffice anyway.

Of course it’s a completely different story for artistic works, photographic or 
otherwise.


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).


Not in v.1.5.8 — at least not for PDF/X.
That was a specific request which I responded to.

 pdfx.sty  has no coding about this for  PDF/A, so far as I can see.
Maybe it’s another of the things that hyperref does, which needs
to be over-ridden.  I’ll look again more closely tomorrow.

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.

XMP is done via a template file; e.g.  pdfx.xmp  or  pdfa.xmp .
There are many places where i

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

[Zdenek Wagner]

2016-07-11 10:36 GMT+02:00 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.
>

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
> <>
> 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 

Re: [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
> <>
> 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 LaTe