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

Zdenek Wagner zdenek.wagner at gmail.com
Mon Jul 11 11:59:11 CEST 2016 

2016-07-11 11:37 GMT+02:00 Ross Moore <ross.moore at mq.edu.au>:

> Hi Zdenek,
>
> On Jul 11, 2016, at 7:03 PM, Zdenek Wagner <zdenek.wagner at 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.
>
> 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
>> <</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
>>
>
> 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 wrote zwpagelayout.sty 9 years ago, the boxes were added to it in
2010. I have not examined pdfx.sty since.

>
> 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 information can be supplied, via macros
> such as  \xmp at Subject  and  \xmp at Author .
> Much of the  pdfx  package is about supplying values for these, in UTF8
> encoding.
>
>
> I know, writing XMP is easy, I do not know how to include it. I do not
like to use hyperref for a document that will only be pronted and never
will be online.

>
> Zdeněk Wagner
> http://ttsm.icpf.cas.cz/team/wagner.shtml
> http://icebearsoft.euweb.cz
>
>
>
> Cheers
>
> Ross
>
>

Zdeněk Wagner
http://ttsm.icpf.cas.cz/team/wagner.shtml
http://icebearsoft.euweb.cz



>
> * Dr Ross Moore*
>
> *Mathematics Dept **|* Level 2, S2.638 AHH
> Macquarie University, NSW 2109, Australia
>
> *T:* +61 2 9850 *8955  |  F:* +61 2 9850 8114 <%2B61%202%209850%209695>
> *M:*+61 407 288 255 <%2B61%20409%20125%20670>*  |  *E:
> ross.moore at mq.edu.au <rick.minter at mq.edu.au>
>
> http://www.maths.mq.edu.au <http://mq.edu.au/>
>
>
> <http://mq.edu.au/>
>
>
> CRICOS Provider Number 00002J. Think before you print.
> Please consider the environment before printing this email.
> <http://mq.edu.au/>
>
> This message is intended for the addressee named and may
> contain confidential information. If you are not the intended
> recipient, please delete it and notify the sender. Views expressed
> in this message are those of the individual sender, and are not
> necessarily the views of Macquarie University. <http://mq.edu.au/>
>
>
>
>
> --------------------------------------------------
> Subscriptions, Archive, and List information, etc.:
>   http://tug.org/mailman/listinfo/xetex
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/xetex/attachments/20160711/f50cb69d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4605 bytes
Desc: not available
URL: <http://tug.org/pipermail/xetex/attachments/20160711/f50cb69d/attachment-0001.png>

More information about the XeTeX mailing list