Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-15 Thread David Carlisle
but if you have an up to date system it is in the documented code
(texdoc color.pdf)  I should probably update grfguide at some point.

David


On 15 July 2016 at 09:24, David Carlisle  wrote:
> On 15 July 2016 at 09:17, Philip Taylor  wrote:
>> P.S.  Option "nosetpagesize" does not seem to appear in the PDF output of 
>> "TeXdoc color", for the version of 2016/05/22.
>
> well no, it wouldnt.
>
> 2016-06-02  David Carlisle  
>
> * graphics.dtx, color.dtx, drivers.dtx: add pagesize special
> support to dvips
> option to match pdftex behaviour and add setpagesize and
> nosetpagesize options to color and graphics packages to enable or
> disable this feature for all drivers.
>
>> ** Phil.
>>
>>
>> --
>> Subscriptions, Archive, and List information, etc.:
>>   http://tug.org/mailman/listinfo/xetex


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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-15 Thread Philip Taylor


David Carlisle wrote:
> as stated earlier, if used under latex the specified page size is known and 
> set in the latex allocated registers \paperheight/paperwidth,
Sorry, either messages are arriving out of synch or some are getting lost in 
the post; I don't seem to recall any mention of this, nor of "that will be the 
page size special change mentioned earlier"; could you let me have the 
message-IDs for this so that I can check if I am losing things ?

So is it safe to assume that \paperheight / \paperwidth are normal \dimen 
registers, and I can therefore just add them to my standard prelude in the same 
way that I already set \hoffset / \voffset  \hsize \visze \pdfpagesize / 
\pdfpageheight, etc ?

** Phil.


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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-15 Thread David Carlisle
On 15 July 2016 at 09:17, Philip Taylor  wrote:
> P.S.  Option "nosetpagesize" does not seem to appear in the PDF output of 
> "TeXdoc color", for the version of 2016/05/22.

well no, it wouldnt.

2016-06-02  David Carlisle  

* graphics.dtx, color.dtx, drivers.dtx: add pagesize special
support to dvips
option to match pdftex behaviour and add setpagesize and
nosetpagesize options to color and graphics packages to enable or
disable this feature for all drivers.

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


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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-15 Thread Philip Taylor
P.S.  Option "nosetpagesize" does not seem to appear in the PDF output of 
"TeXdoc color", for the version of 2016/05/22.
** Phil.


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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-15 Thread David Carlisle
Phil,

> And why does :
>
 >\input miniltx
  >   \input color

> /not/ change my page size ?

as stated earlier, if used under latex the specified page size is
known and set in the latex allocated registers
\paperheight/paperwidth, but if used under plain these are not set and
that section of xetex.def is skipped (really if you insist on using
plain you should be prepared to look at the fairly simple tests in
xetex.def) in the eplain/\beginpackages use enough of latex internals
are emulated to send xetex.def down the latex code path.

David


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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-15 Thread Philip Taylor


Ross Moore wrote:
> One of my messages answered this.
> It is so that  \setpagecolor  can work correctly.
> A coloured rectangle is drawn, at the size of the full page.
>  \shipout  is patched to do it on every page.
OK, that makes sense ('though I would argue that it should be the author's 
responsibility to set page size, and the package should assume that the author 
has done so correctly prior to loading the package), but I still do not know 
from where it is taking what it believes (wrongly, in my case) to be the page 
size.  In other words, rather than using :

\input eplain
\beginpackages
\usepackage [nosetpagesize] {color}   
\endpackages

what should I be setting prior to using package {color} in order to communicate 
my intended page size to package {color} ?

And why does :

\input miniltx
\input color

/not/ change my page size ?

** Phil.


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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-15 Thread Ross Moore
Hi Phil.

On Jul 15, 2016, at 5:28 PM, Philip Taylor 
> wrote:

 I am intrigued to know why a package intended to support colour would want to 
set page size, though, and wonder from where it gets its information regarding 
the intended page size,

One of my messages answered this.
It is so that  \setpagecolor  can work correctly.
A coloured rectangle is drawn, at the size of the full page.
 \shipout  is patched to do it on every page.

since by the time that package {color} is loaded I have set all possible page 
dimensions to my intended size (B5, in this case).

Try  \pagecolor{yellow}  or somesuch.
Enjoy.


** Phil.
--

Philip Taylor

Ross


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
M:+61 407 288 255  |  E: 
ross.mo...@mq.edu.au

http://www.maths.mq.edu.au


[cid:image001.png@01D030BE.D37A46F0]


CRICOS Provider Number 2J. Think before you print.
Please consider the environment before printing this email.

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.



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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-15 Thread Philip Taylor


David Carlisle wrote:

> well that'll be the page size special change as mentioned earlier I > assume. 
> what does \usepackage [nosetpagesize]{color} do?

Success :-)  The page reverts to its correct position.  Thank you, David.  But 
when you say "that will be the page size special change mentioned earlier", is 
that "mentioned earlier in this thread", or elsewhere, and do you have a 
message-ID by which I can search for it ?  I am intrigued to know why a package 
intended to support colour would want to set page size, though, and wonder from 
where it gets its information regarding the intended page size, since by the 
time that package {color} is loaded I have set all possible page dimensions to 
my intended size (B5, in this case).

** Phil.
-- 

Philip Taylor




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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-15 Thread Ross Moore
Hi David,

On Jul 15, 2016, at 4:47 PM, David Carlisle 
> wrote:

Is there a mechanism similar to  \hypersetup  that allows the options to be 
changed
*after* the package has been loaded?

Not really, although the actual setting is in \AtBeginDocument{\AtBeginDVI  so 
as long
as you set the relevant registers to the right value it'll get set up (but let 
me know if you need more hooks)

No, I don’t need any more hooks.
A previous message explained why.

There is a very minor issue, as follows.

PDF/X generally requires CMYK color space, whereas PDF/A and PDF/E usually use 
RGB colors.
If one specifies  \pagecolor{yellow}  say, then it will use whatever color 
space was stated
when ‘yellow’ was defined as a color.
This would lead to a validation problem if it wasn’t the same space as the PDF 
type requires.

The “fix” for this is to use the  xcolor  package, and force conversions into 
the right color space.
Thank you for writing this, so many years ago!

Currently  pdfx.sty  force loads  xcolor   for PDF/X.
For some reason the command with PDF/A was commented-out, so that  xcolor would 
be loaded
only if requested by the document author, as per usual.
(I must have been testing something and didn’t uncomment it before releasing 
the package;
or maybe I thought more tests were needed, and just forgot about it.)

I do, however, put in a check that prevents the author from using the wrong 
color space.

The next version of  pdfx.sty  will force loading of  xcolor  in all 
situations, since there’s
no easy way of knowing what or when the author might request colours.


What is the issue?
  xcolor  can be very noisy:
viz.

Package xcolor Warning: Incompatible color definition on input line 3993.

[48]][48

Package xcolor Warning: Incompatible color definition on input line 4027.


Package xcolor Warning: Incompatible color definition on input line 4101.


Package xcolor Warning: Incompatible color definition on input line 4115.

[49]][49

That's 3 warnings per page.
Fortunately the final result is fine, passing validation.

xcolor  has an option  hideerrors  but this doesn’t suppress these warnings.



Cheers

Ross


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
M:+61 407 288 255  |  E: 
ross.mo...@mq.edu.au

http://www.maths.mq.edu.au


[cid:image001.png@01D030BE.D37A46F0]


CRICOS Provider Number 2J. Think before you print.
Please consider the environment before printing this email.

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.



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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-15 Thread David Carlisle
On 15 July 2016 at 00:19, Ross Moore  wrote:

> Hi David,
>
> On Jul 15, 2016, at 8:49 AM, David Carlisle 
> wrote:
>
>
> well that'll be the page size special change as mentioned earlier I assume.
>
>
> Hmm. In which version of  color.sty  was this introduced?
>

pdftex.def (and luatex.def) have _always_ set \pdfpage(height|width) with
no option not to do that,
conversely dvips.def did not by default set \ pagesize \special, which mean
that if you used color or graphics
then the pdf-specified page size either was or was not affected by latex
options such as
\documentclass[a4paper]{article}
depending if you used pdftex or tex+dvips (or luatex or xetex)
as of this year, after some discussion on the texlive list color and
graphics acquired  setpagesize and nosetpagesize options and then
dvips/pdftex/luatex/xetex/dvipdfmx.def either set the page size or not.



> Presumably later than:
>
> Package: color 2016/05/09 v1.1c Standard LaTeX Color (DPC)
>
> There is a potential conflict with  pdfx.sty  setting the  /MediaBox .
>
>
> what does \usepackage [nosetpagesize]{color} do?
>
>
> Is there a mechanism similar to  \hypersetup  that allows the options to
> be changed
> *after* the package has been loaded?
>

Not really, although the actual setting is in \AtBeginDocument{\AtBeginDVI
so as long
as you set the relevant registers to the right value it'll get set up (but
let me know if you need more hooks)


>
> Alternatively, can I detect whether the  pagesize  special has been done
> already?
> Then not repeat specifying  /MediaBox  when setting the other boxes:
>  Bleed/Crop/Trim
> which are required for PDF/X validation.
>
> If not loaded yet, I can do  \PassOptionsToPackage{nosetpagesize}{color} .
> But I’ll want to catch the case also if it is loaded.
>
>
> Cheers
>
> Ross
>


> David
>


>
> * 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.mo...@mq.edu.au 
>
> http://www.maths.mq.edu.au 
>
>
> 
>
>
> CRICOS Provider Number 2J. Think before you print.
> Please consider the environment before printing this email.
> 
>
> 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. 
>
>
>
>
> --
> Subscriptions, Archive, and List information, etc.:
>   http://tug.org/mailman/listinfo/xetex
>
>


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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-14 Thread Ross Moore
Hi again David,

On Jul 15, 2016, at 9:19 AM, Ross Moore 
> wrote:

Hi David,

There is a potential conflict with  pdfx.sty  setting the  /MediaBox .

OK, I see what is going on now.
You are allowing a colored rectangle to be drawn the size of the page,
to support coloured pages, yes?

Nothing to do with the PDF Boxes, except of course you want the sizes
to match; especially when a  \mag  is used.



what does \usepackage [nosetpagesize]{color} do?

Is there a mechanism similar to  \hypersetup  that allows the options to be 
changed
*after* the package has been loaded?

OK; it just sets a boolean flag.


Alternatively, can I detect whether the  pagesize  special has been done 
already?
Then not repeat specifying  /MediaBox  when setting the other boxes:  
Bleed/Crop/Trim
which are required for PDF/X validation.

If not loaded yet, I can do  \PassOptionsToPackage{nosetpagesize}{color} .
But I’ll want to catch the case also if it is loaded.

Looks like this won’t be necessary.
The question now will be how having such colored pages affects validation.
Hopefully not at all, for PDF/X and PDF/A.

Maybe PDF/UA, according to the actual colors, but that would be a visual check 
not automated.


Thanks for a new code-branch to try out.


Cheers

 Ross


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
M:+61 407 288 255  |  E: 
ross.mo...@mq.edu.au

http://www.maths.mq.edu.au


[cid:image001.png@01D030BE.D37A46F0]


CRICOS Provider Number 2J. Think before you print.
Please consider the environment before printing this email.

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.



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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-14 Thread Ross Moore
Hi David,

On Jul 15, 2016, at 8:49 AM, David Carlisle 
> wrote:

well that'll be the page size special change as mentioned earlier I assume.

Hmm. In which version of  color.sty  was this introduced?
Presumably later than:

Package: color 2016/05/09 v1.1c Standard LaTeX Color (DPC)

There is a potential conflict with  pdfx.sty  setting the  /MediaBox .


what does \usepackage [nosetpagesize]{color} do?

Is there a mechanism similar to  \hypersetup  that allows the options to be 
changed
*after* the package has been loaded?

Alternatively, can I detect whether the  pagesize  special has been done 
already?
Then not repeat specifying  /MediaBox  when setting the other boxes:  
Bleed/Crop/Trim
which are required for PDF/X validation.

If not loaded yet, I can do  \PassOptionsToPackage{nosetpagesize}{color} .
But I’ll want to catch the case also if it is loaded.


Cheers

Ross


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
M:+61 407 288 255  |  E: 
ross.mo...@mq.edu.au

http://www.maths.mq.edu.au


[cid:image001.png@01D030BE.D37A46F0]


CRICOS Provider Number 2J. Think before you print.
Please consider the environment before printing this email.

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.



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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-14 Thread David Carlisle
On 14 July 2016 at 23:40, Philip Taylor  wrote:
> It transpires that it is /not/ the PDF/X-1A \specials that are the root cause 
> of the problem.  It is the use of
>
> \input eplain
> \beginpackages
> \usepackage {color}
> \endpackages
>
> If I replace this with what I believe to be the functionally equivalent :
>
> \input miniltx
> \input color
>
> all works as in 2014 !
>
> ** Phil.
>


well that'll be the page size special change as mentioned earlier I assume.

what does \usepackage [nosetpagesize]{color} do?


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


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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-14 Thread Philip Taylor
It transpires that it is /not/ the PDF/X-1A \specials that are the root cause 
of the problem.  It is the use of

\input eplain
\beginpackages
\usepackage {color}   
\endpackages

If I replace this with what I believe to be the functionally equivalent :

\input miniltx
\input color

all works as in 2014 !

** Phil.


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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-14 Thread Ross Moore
Hi Phil,

On Jul 15, 2016, at 6:02 AM, Philip Taylor 
> wrote:

Very happy to believe that, Ross (and will test later) but what I do not 
understand is why things have changed so dramatically in going from TeX Live 
2014 to 2016.  In 2014, adding the PDF/X-1A specials made no difference 
whatsoever to the position of size of the page; in 2016, they cause a vertical 
displacement.

There have been significant changes, at least in  xdvipdfmx  since 2014.

And the interaction with the color package is also inexplicable.  Anyhow, I 
first have to come up with a truly MWE and then I will be in a better position 
to investigate and report back.

Please send me such MWE when you have it.

I’ve been trying a real-world example (Serbian version of TeXLive documentation)
that compiles fine (with one small hiccup that doesn’t seem to affect the 
result)
using 2016’s  xdvipdfmx , but which crashes out almost immediately with 2014 
saying:

SCI:TL-SR16 ross$ /usr/local/texlive/2014/bin/universal-darwin/xdvipdfmx -z 0 
-vv --kpathsea-debug 4095 texlive-sr.xdv
texlive-sr.xdv
 -> texlive-sr.pdf
kdebug:fopen(texlive-sr.xdv, rb) => 0xa0e103ec
DVI ID = 7

xdvipdfmx:fatal: Something is wrong. Are you sure this is a DVI file?

Output file removed.
SCI:TL-SR16 ross$

Note that I have maximum verbosity turned on, as well as a lot of  kpathsea  
tracing.
Yet still it isn’t clear where it is going wrong.

So I’d appreciate your cut-down MWE to test with both versions.
Then we can play with /MediaBox and /CropBox values, to see whether that
is the cause of what you are getting. Or whether it is something else.



** Phil.

Cheers

Ross


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
M:+61 407 288 255  |  E: 
ross.mo...@mq.edu.au

http://www.maths.mq.edu.au


[cid:image001.png@01D030BE.D37A46F0]


CRICOS Provider Number 2J. Think before you print.
Please consider the environment before printing this email.

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.



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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-14 Thread Philip Taylor


Ross Moore wrote:
> I think what you are seeing is due to the  /CropBox settings.
Very happy to believe that, Ross (and will test later) but what I do not 
understand is why things have changed so dramatically in going from TeX Live 
2014 to 2016.  In 2014, adding the PDF/X-1A specials made no difference 
whatsoever to the position of size of the page; in 2016, they cause a vertical 
displacement.  And the interaction with the color package is also inexplicable. 
 Anyhow, I first have to come up with a truly MWE and then I will be in a 
better position to investigate and report back.

** Phil.


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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-14 Thread Ross Moore
Hi Phil,

On Jul 14, 2016, at 10:02 PM, Philip Taylor 
> wrote:


Hallo David, and thank you for your suggestions.  I have now found the 
following :

1) The primary cause of the displacement is the PDF/X-1A:2003 specials -- 
remove these, and the page returns to its normal vertical position, but shifted 
outwards (leftwards) somewhat;
2) The use of \usepackage {color} within e-plain's \beginpackages ... 
\endpackages; in TeX Live 2016, this makes the page size considerably wider, 
IFF the PDF/X-1A specials are not emitted.

The displacement is visible both in TeXworks viewer and in Adobe Acrobat.


I think what you are seeing is due to the  /CropBox settings.
A PDF viewer shows the contents of the cropped area,
scaling to fill either the width or height or both.

There are 2 kinds of test that you can do.

1.  Print a few pages of your document, once with the \specials, once without.
Is there any difference in the position of your content on the printed page?

2. Vary the numbers in  /CropBox [ a b c d ] ;
such that (a,b) is bottom-left  and  (c,d)  is top-right corners of a 
rectangle.
Values such as  [ 200 200 300 300 ] should crop to a small-ish portion of a 
page,
which is then scaled up to fit your window-size.
   Observe the value of your browser’s scaling factor.

   With different values of [ a b c d ] you can simulate vertical and 
horizontal shifts,
to a small extent, according to how much smaller the /CropBox is, compared to
the /MediaBox.

Does this interpretation agree with what you observe?



A4 is indeed the default in both, and the difference between A4 and letter is 
only 3/4", whereas it appears to require a 1" correction ...

** Phil.


Cheers,

Ross


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
M:+61 407 288 255  |  E: 
ross.mo...@mq.edu.au

http://www.maths.mq.edu.au


[cid:image001.png@01D030BE.D37A46F0]


CRICOS Provider Number 2J. Think before you print.
Please consider the environment before printing this email.

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.



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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-14 Thread David Carlisle
On 12 July 2016 at 16:17, Philip Taylor  wrote:



 > \advance \voffset by 1 true in % REQUIRED ONLY FOR TL 2016

If it's really a difference in texlive check that you specified the same
default driver page size (presumably A4)
in both installations, not A4 in one and letter in the other


or it may be a change in the driver files that now use a pagestyle special
by default but it wouldn't do that unless the latex \paperwidth register is
set (look at the end of xetex.def)

although neither of these would have the effect of exactly 1in shift.

David


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


Re: [XeTeX] [tex-live] Seemingly inexplicable shift in page origin between TL 2014 and TL 2016

2016-07-13 Thread Philip Taylor


Bruno Le Floch wrote:
> ! Undefined control sequence. l.29 \ifcropmarks ? 
Ah, yes, sorry about that Bruno.  I thought I had stripped out all external 
dependencies, but clearly I had not.  The "cropmarks.tex" is my own, written 
over 20 years ago for Kaveh and/or Dominik -- somewhere on CTAN, but I no 
longer remember where.  Anyhow, I have (sort of) tracked down the issue -- two 
things are affecting the displacements (both vertical /and/ horizontal, as it 
turned out) :

1) The PDF/X-1A specials;
2) The \usepackage {color} within an Eplain \beginpackages ... \endpackages 
sequence.

More research needed on my part to identify the exact cause in both cases.
** Phil.
-- 

Philip Taylor


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