Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Images Come Out Full Page Instead Of Cropped #24

Closed
herbs opened this issue Jul 14, 2016 · 63 comments
Closed

Images Come Out Full Page Instead Of Cropped #24

herbs opened this issue Jul 14, 2016 · 63 comments

Comments

@herbs
Copy link

herbs commented Jul 14, 2016

Howdy,

With asy 2.38 some of my images in a test file come out full page rather than properly cropped so multiple inages can't appear on a single typeset document. I enclose an example. Running asy on the enclosed asymptotemktest-6.asy (after unzipping) gives me the enclosed pdf file.

asymtotemktest-6.pdf
asymtotemktest-6.asy.zip

@johncbowman
Copy link
Member

What operating system are you using?

@herbs
Copy link
Author

herbs commented Jul 25, 2016

Howdy,

I'm using OS X 10.11.6, El Capitan. I can send you the source file. Strangely some figures are cropped and others not.

Right now I'm at the TUG conference so it might be a sort while before I get it to you.

Good Luck,
Herb Schulz

On Jul 25, 2016, at 5:16 PM, John Bowman notifications@github.com wrote:

What operating system are you using?


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@herbs
Copy link
Author

herbs commented Jul 26, 2016

On Jul 25, 2016, at 5:16 PM, John Bowman notifications@github.com wrote:

What operating system are you using?


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Howdy,

Enclosed is the initial file along with information about compiling it in TeXShop using the pdflatexmk engine. I've also enclosed the sample pdf output that is correct and what I get with asy 2.38

Thanks for any help you can provide and please get in touch with me if you need more information.

PS: I'll note that I'm using the 64bit (x86_64-darwin) version of asy 2.38.

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)

@herbs
Copy link
Author

herbs commented Aug 2, 2016

On Aug 2, 2016, at 8:22 AM, jpellegrini notifications@github.com wrote:

Hello,

I have the same problem -- see this Stackoverflow post.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Howdy,

What OS are you using? What TeX Live and asy versions are you using?

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)

@jpellegrini
Copy link

Hi. I thought I was going to put another test case here, but it's probably not necessary.

Anyway, it's Debian, Asymptote 2.38.

I removed the asymptote package from the OS and installed a git version from today (d76f675) and the problem persists. Also, invoking asy and outputting to png has the same problem (the png is a huge transparent image, with only part of it filled with my figure), so I suppose it's not a LaTeX issue.

Anyway, I have texlive 2016.20160623-1 from Debian sid.

@herbs
Copy link
Author

herbs commented Aug 2, 2016

On Aug 2, 2016, at 8:43 AM, jpellegrini notifications@github.com wrote:

Hi. I thought I was going to put another test case here, but it's probably not necessary.

Anyway, it's Debian, Asymptote 2.38.

I removed the asymptote package from the OS and installed a git version from today (d76f675) and the problem persists. Also, invoking asy and outputting to png has the same problem (the png is a huge transparent image, with only part of it filled with my figure), so I suppose it's not a LaTeX issue.

Anyway, I have texlive 2016.20160623-1 from Debian sid.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Howdy,

It's definitely an asy problem and the folks maintaining it are looking at it. An up-vote with a note that you're using Debian (I use Mac OS X) and asy 2.38 with TeX Live 2016 would at least show that it's not related to one system.

You could crop the bad images using pdfcrop, then rename the -crop output file back to the original name finally running pdflatex again. I consider that a temporary fix until asy is updated properly.

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)

@johncbowman
Copy link
Member

It isn't an Asymptote problem: if I run the intermediate files produced on
affected systems through pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015)
it works just fine. Something appears to be wrong with the TL 2016 version of pdfTeX on certain platforms; I'm still looking in to it.

@herbs
Copy link
Author

herbs commented Aug 2, 2016

On Aug 2, 2016, at 10:07 AM, John Bowman notifications@github.com wrote:

It isn't an Asymptote problem: if I run the intermediate files produced on
affected systems through pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015)
it works just fine. Something appears to be wrong with the TL 2016 version of pdfTeX on certain platforms; I'm still looking in to it.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Howdy,

Wow, that's definitely a surprise.

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)

@johncbowman
Copy link
Member

johncbowman commented Aug 3, 2016

I just installed TeXlive 2016 and can confirm that this is a bug in

pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016)

The problem is that

\pdfpagewidth=113.385827bp
\pdfpageheight=113.385827bp

are ignored when appearing before \begin{document}.
However, I can work around this by moving these commands after \begin{document}.

@johncbowman
Copy link
Member

A workaround for this recent pdflatex bug has been implemented in
61cfa1e

@herbs
Copy link
Author

herbs commented Aug 3, 2016

On Aug 2, 2016, at 10:06 PM, John Bowman notifications@github.com wrote:

I just installed TeXlive 2016 and can confirm that this is a bug in

pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016)

The problem is that

\pdfpagewidth=113.385827bp
\pdfpageheight=113.385827bp

are ignored when appearing before \begin{document}.
However, I can work around this by moving these commands until after
\begin{document}.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Howdy,

Thanks for the quick work on this problem. Will this pass through CTAN and TeX Live in the near future?

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)

@mojca
Copy link
Contributor

mojca commented Aug 3, 2016

Unless the TeX Live policy changes, no. It requires a rebuild of asymptote binary and Karl generally opposes rebuilds of binaries. But you can try to ask on the TeX Live mailing list. If this is a bug in a macro package, you should insist in fixing the bug in pdflatex.

@davidcarlisle
Copy link

@kberry, @johncbowman

I tried a latex document in tl2016 that set this before begin docuemnt

\documentclass{article}

\pdfpagewidth=113.385827bp
\pdfpageheight=113.385827bp

\begin{document}
x
\end{document}

the settings had an effect, pdfinfo shows

Creator: TeX

Producer:       pdfTeX-1.40.17
CreationDate:   Wed Aug  3 23:46:04 2016
ModDate:        Wed Aug  3 23:46:04 2016
Tagged:         no
UserProperties: no
Suspects:       no
Form:           none
JavaScript:     no
Pages:          1
Encrypted:      no
Page size:      113.386 x 113.386 pts
Page rot:       0
File size:      8683 bytes
Optimized:      no
PDF version:    1.5

@davidcarlisle
Copy link

oh \usepackage{graphicx}... ah sorry that's probably me...

@davidcarlisle
Copy link

in TL2015 pdftex

\documentclass{article}
\usepackage{graphicx}

\pdfpagewidth=113.385827bp
\pdfpageheight=113.385827bp

\begin{document}
x
\end{document}

is 113 pts square but

\documentclass{article}


\pdfpagewidth=113.385827bp
\pdfpageheight=113.385827bp

\usepackage{graphicx}

\begin{document}
x
\end{document}

is US letter, also other back ends such as dvips didn't set the pdf page size.

in the new graphics-def collection, tried to make dvips,dvipdfmx,luatex and dvips options work in a more or less compatible way (which is tricky as traditionally they were all incompatible...)

so... in texlive 2016 the page size for all the above driver options is set at begin document based on the latex lengths \paperheight and \paperwidth unless the whole feature is turned off with [nosetpagesize] option.

so the advantage is that dependence on order of loading graphicx is avoided but you need to set \paperwidth not \pdfpagewidth or use the [nosetpagesize] option to stop graphicx setting the size.
or you persuade me this is broken and should be reverted (which is not impossible, but currently I still think making the different back ends work in similar ways is the right thing to do...)

So sorry if this broke your code. Please look at the block in pdftex.def starting

\ifGin@setpagesize
\ifx\paperwidth\@undefined\else
\AtBeginDocument{%

If this isn't workable for you, ping me here or in

https://github.com/latex3/graphics-def

@herbs
Copy link
Author

herbs commented Aug 4, 2016

On Aug 3, 2016, at 5:53 PM, David Carlisle notifications@github.com wrote:

oh \usepackage{graphicx}... ah sorry that's probably me...


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Howdy,

My example didn't use the graphicx package so... . The original document (I paired it down a bit to demonstrate the problem) had the preamble and start of document

\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{mathptmx}
\usepackage{asymptote}
\usepackage{subfig}

% test bibliography
\usepackage[numbers]{natbib}
%\usepackage{natbib}
\bibliographystyle{plainnat}
%\bibliographystyle{plain}

\newcommand{\cC}{\mathcal{C}}

\makeatletter
\newsavebox{\sfe@box}
\newenvironment{subfloatenv}[1]{%
\def\sfe@caption{#1}%
\setbox\sfe@box\hbox\bgroup\color@setgroup}%
{\color@endgroup\egroup\subfloat[\sfe@caption]%
{\usebox{\sfe@box}}}
\makeatother

\begin{document}

\begin{asydef}
usepackage("mathptmx");
texpreamble("\newcommand{\cC}{\mathcal{C}}");
\end{asydef}

and then mostly a series of asymptote figures and sub-figures using asymptote with some text, crossreferences, bibliography. It worked fine under TL2015 (with whatever the asy was then) but now fails under TL2016 ans asy 3.28.

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)

@johncbowman
Copy link
Member

johncbowman commented Aug 4, 2016

Herb: Asymptote uses the graphicx package internally.

David: Thank you so much for your prompt response on this issue.
Indeed, as you suggest, a better temporary workaround is for Asymptote to use

\usepackage[nosetpagesize]{graphicx}
rather than moving \pdfpagewidth etc. to after \begin{document}.

However, I think this change to graphicx is unfortunate and should be reverted for the following reasons:

First of all, this could be done without requiring a complete rebuild of the Asymptote and TeXLive binaries. We will also have to update the Asymptote binaries in many other distributions, which will not happen instantly. It is better to fix this problem at the source rather than working around it.

Second, as is evident in this thread, including \usepackage{graphicx} now has suprising side-effects
that one would not normally expect. For the following code to ignore the very clear page size request from the user and still produce US letter size is simply not user friendly:

\documentclass{article}
\usepackage{graphicx}
\pdfpagewidth=113.385827bp
\pdfpageheight=113.385827bp
\begin{document}
x
\end{document}

@johncbowman
Copy link
Member

The nosetpagesize option is not available in TeXLive 2015, so that solution won't work after all:

! LaTeX Error: Unknown option nosetpagesize' for packagegraphics'.

So I will revert the reversion and go back to setting the pagesize after \begin{document}
(which doesn't seem right but it currently seems to be the only alternative).

@davidcarlisle
Copy link

On 4 August 2016 at 04:32, John Bowman notifications@github.com wrote:

Herb: Asymptote uses the graphicx package internally.

David: Thank you so much for your prompt response on this issue.
Indeed, as you suggest, a better temporary workaround is for Asymptote to
use

\usepackage[nosetpagesize]{graphicx}

rather than moving \pdfpagewidth etc. to after \begin{document}.

However, I think this change to graphicx is unfortunate and should be
reverted for the following reasons:

First of all, this could be done without requiring a complete rebuild of
the Asymptote and TeXLive binaries.

perhaps I didn't understand but doesn't the generate code use
asymptote.sty? in which case you'd just need
to change

\RequirePackage{color,graphicx}

to

\RequirePackage[nosetpagesize]{color,graphicx}

around line 34. (I tried running the example in the zip file at top of this
thread, it generated a pdf but is it possible to make it show the
intermediate tex?

this could be easily guarded to work also on older releases.

We will also have to update the Asymptote binaries in many other

distributions, which will not happen instantly. It is better to fix this
problem at the source rather than working around it.

As I say, I'm open to avoid having to make new binaries but not being an
asymptote user I don't have my head around all the parts yet, sorry:-)

Second, as is evident in this thread, including \usepackage{graphicx} now
has suprising side-effects
that one would not normally expect.

No, actually I think in general the new behaviour is less surprising than
the old. Previously the page size was set with
pdftex but not with xetex, or dvips and it would be set differently between

\pdfpagewidth=113.385827bp
\pdfpageheight=113.385827bp
\usepackage{graphicx}

and

\usepackage{graphicx}
\pdfpagewidth=113.385827bp
\pdfpageheight=113.385827bp

and none of the behaviour was documented.

With the new settings pdftex,xetex,dvips,dvipdfmx,luatex
all work the same way, the two examples above work the same way

there is a user option to control things, and the behaviour

is documented.

For the following code to ignore the very clear page size request from the
user and still produce US letter size is simply not user friendly:

\documentclass{article}
\pdfpagewidth=113.385827bp
\pdfpageheight=113.385827bp
\usepackage{graphicx}
\begin{document}
x
\end{document}

As I say it's not so clear
(a) \pdfpagewidth is not defined in classic tex so this has a pdftex
dependency
even before the (implicit) choice of back end by graphics.cfg
(b) if you use the settings after the package load the behaviour was
inexplicably
different.

So despite present issue I think the new behaviour is correct.

If the generated code is using asymptote.sty then I think it is easiest to
fix there
If not I can fix it on pdftex.def as long as there is some hook I can use
to recognise, if you look at the code you'll see it already has some tests
that adjust the default behaviour depending on whether \mag has been set
which was added for compatibility with some Japanese document classes
If necessary i could do something similar for asymptote (but doing it in
asymptote.sty
would be better if it works)

David

@davidcarlisle
Copy link

Ok so I found -k and understand better now...

The generated files don't use any package but inline a lot of low level code, which is perhaps a shame but anyway that's how it is:-)

Does it work for you if pdftex.def (and dvips,luatex,...) change from

% If a package has changed \mag, assume it knows what it is doing
% and leave page size alone
\ifnum\mag=\@m

around line 459 to

% If a package has changed \mag, assume it knows what it is doing
% and leave page size alone, similary leave asymptote generated files
% to do their own thing
\ifnum\ifx\ASYaligned\@undefined\mag\else\@ne\fi=\@m

For the test at top of this thread it changes the page size from us letter to
Page size: 141.732 x 123.341 pts

If \ASYaligned isn't guaranteed to be defined, could you suggest any other way of detecting one of these files.

@johncbowman
Copy link
Member

johncbowman commented Aug 5, 2016

I suggest testing instead for \ASYprefix

For me there are three surprises here. First, in the code

documentclass{article}
\usepackage{graphicx}
\pdfpagewidth=113.385827bp
\pdfpageheight=113.385827bp
\begin{document}
x
\end{document}

I would not expect that loading graphicx should reset the page size.
Second, even if I accept that loading graphicx has this side effect then I would at least expect that I would be allowed to override this decision, as in the above code. But if I accept that even this code doesn't work, then as a user I am even more surprised that the following code does indeed given me the desired result. This is essentially the current Asymptote workaround committed to git. But it seems wrong to adjust the page size after the document has begun!

\documentclass{article}
\usepackage{graphicx}
\begin{document}
\pdfpagewidth=113.385827bp
\pdfpageheight=113.385827bp
x
\end{document}

Most importantly, the new behaviour is backwards incompatible. Sometimes introducing a backwards incompatibility is necessary. But there has to be a strong justification for that and I really don't see it
in this case.

By the way, the bug in graphicx also broke the xelatex engine and the lualatex engine.
The work around currently in git (moving pdfpagewidth etc. to after begin{document}) works for
both pdflatex and xelatex but not for lualatex:

Undefined control sequence.
l.37 \pdfpagewidth
=113.385827bp
! Undefined control sequence.
l.41 \pdfpageheight
=113.385827bp

This isn't the case in TeXLive 2015. Can you please fix this issue too?

@johncbowman johncbowman reopened this Aug 5, 2016
@davidcarlisle
Copy link

On 5 August 2016 at 05:41, John Bowman notifications@github.com wrote:

I suggest testing instead for \ASYprefix

OK, thanks.

For me there are three surprises here. First, in the code

\documentclass{article}
\usepackage{graphicx}
\pdfpagewidth=113.385827bp
\pdfpageheight=113.385827bp
\begin{document}
x
\end{document}

I would not expect that loading graphicx should reset the page size.

It's done this for the pdftex backend since the package was introduced in
1994
so hard to change now.

Second, even if I accept that loading graphicx has this side effect then I
would at least expect that I would be allowed to override this decision,

Well that's why the [nosetpagesize] option was added this time, but since
the usepackage call is embedded in compiled code I'm suggesting putting a
catch for this into the def files.

as in the above code. But if I accept that even this code doesn't work,
then as a user I am even more surprised that the following code does indeed
given me the desired result. This is essentially the current Asymptote
workaround committed to git. But it seems wrong to adjust the page size
after the document has begun!

\documentclass{article}
\usepackage{graphicx}
\begin{document}
\pdfpagewidth=113.385827bp
\pdfpageheight=113.385827bp
x
\end{document}

Yes the page size has to be set by the first page so the package delays it
as long as possible so that any settings (of the documented latex lengths)
in the preamble work. You can set \paperwidth and \paperheight anywhere in
the preamble
before or after loading graphics and the size will be affected.

Most importantly, the new behaviour is backwards incompatible.

Although the exact timing has changed and there s an option not to do this,
pdftex.def has always set \pdfpagewidth/height.

Sometimes introducing a backwards incompatibility is necessary. But there
has to be a strong justification for that and I really don't see it
in this case.

It just became impossible to justify why

\documenclass{article}
\usepackage{graphics}
\begin{document}
x
\end{document}

made a US-letter pdf with pdftex and luatex and an A4 pdf with tex and
xetex. Which was the previous behaviour
(if your tex distribution default was A4)

By the way, the bug in graphicx also broke the xelatex engine and the
lualatex engine.

It is a change not a bug but the bigger change was for xelatatex (and
latex) which now also set the page size to match pdftex and luatex which
have always done so.

The work around currently in git (moving pdfpagewidth etc. to after
begin{document}) works for
both pdflatex and xelatex but not for lualatex:

Undefined control sequence.
l.37 \pdfpagewidth
=113.385827bp
! Undefined control sequence.
l.41 \pdfpageheight
=113.385827bp

This isn't the case in TeXLive 2016. Can you please fix this issue too?

No that's an issue in the document not my code!

as I said originally \pdfpageheight is a pdftex specific command, xetex
also added it but it
is not defined (along with most other \pdfxxx commands such as \pdfoutput)
in current luatex.

If you set \paperheight and \paperwidth then the driver-specific backend
code will do whatever
is needed, setting \pdfpagewidth for pdftex, \special{papersize for dvips,
and setting \pagewidth
and \pageheight (no pdf prefix) for current luatex.

David

@johncbowman
Copy link
Member

Unfortunately \paperwidth and \paperheight are undefined with pdftex and luatex:

This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) (preloaded format=pdftex)
restricted \write18 enabled.
entering extended mode

(./test_.tex
(/usr/local/texlive/2016/texmf-dist/tex/plain/graphics-pln/graphicx.tex
(/usr/local/texlive/2016/texmf-dist/tex/plain/graphics-pln/miniltx.tex)
(/usr/local/texlive/2016/texmf-dist/tex/latex/graphics/graphicx.sty
(/usr/local/texlive/2016/texmf-dist/tex/latex/graphics/keyval.sty)
(/usr/local/texlive/2016/texmf-dist/tex/latex/graphics/graphics.sty
(/usr/local/texlive/2016/texmf-dist/tex/latex/graphics/trig.sty)
(/usr/local/texlive/2016/texmf-dist/tex/latex/graphics-cfg/graphics.cfg)
(/usr/local/texlive/2016/texmf-dist/tex/latex/graphics-def/pdftex.def
(/usr/local/texlive/2016/texmf-dist/tex/generic/oberdiek/infwarerr.sty)
(/usr/local/texlive/2016/texmf-dist/tex/generic/oberdiek/ltxcmds.sty)
(/usr/local/texlive/2016/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
))))) (/usr/local/texlive/2016/texmf-dist/tex/plain/graphics-pln/picture.tex
(/usr/local/texlive/2016/texmf-dist/tex/plain/graphics-pln/miniltx.tex)
(/usr/local/texlive/2016/texmf-dist/tex/plain/graphics-pln/autopict.sty))
! Undefined control sequence.
l.35 \paperwidth
=113.385827bp
! Undefined control sequence.
l.43 \paperheight
=113.385827bp
<test_0.pdf, id=1, 113.81522pt x 113.81522pt> [1{/usr/local/te
xlive/2016/texmf-var/fonts/map/pdftex/updmap/pdftex.map} <./test_0.pdf>] )
(see the transcript file for additional information)</usr/local/texlive/2016/te
xmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></usr/local/texlive/2016/texm
f-dist/fonts/type1/public/amsfonts/cm/cmr12.pfb>
Output written on test_.pdf (1 page, 19970 bytes).
Transcript written on test_.log.

@davidcarlisle
Copy link

Unfortunately \paperwidth and \paperheight are undefined with pdftex and
luatex:

The assumption is that anyone using plain tex is setting these things up
themselves as there are no real conventions in that case there isn't
anything else that can be done really.

they would be defined if you added
\newdimen\paperwidth
\newdimen\paperheight
which is all latex does.

or you could force the .def file to take the nosetpagesize rout via some
combination of

\newif\ifGin@setpagesize

\Gin@setpagesizefalse

depending on exactly what plain tex setup you have.

Or, as I said earlier, if changing your calling code means recompiling the
binaries and we want to avoid that in teh texlive 2016 cycle I can add a
test for \ASYprefix to make it default to \Gin@setpagesizefalse if defined
although longer term that's not such a nice solution.

David

@johncbowman
Copy link
Member

Yes, I had hoped that the temporary \ASYprefix hack you suggested would be in TeXLive 2016 by now but as of yesterday it still isn't there.

In any case we also need a workaround for non-TeXLive distributions (like miktex) that are starting to update pdflatex and other TeX engines. In my tests yesterday, it seemed that I also need \RequirePackage{luatex85} for luatex. It's too bad that we suddenly need so many conditionals to fix simple code that has worked perfectly over the last 13 years.

@davidcarlisle
Copy link

On 23 August 2016 at 15:48, John Bowman notifications@github.com wrote:

Yes, I had hoped that the temporary \ASYprefix hack you suggested would be
in TeXLive 2016 by now but as of yesterday it still isn't there.

I'll try to get something out.

In any case we also need a workaround for non-TeXLive distributions (like
miktex) that are starting to update pdflatex and other TeX engines.

well miktex uses the same def files as texlive so the same fix would cover
both, although if miktex is compiling from source a fixed source at the
asymptote end would be better of course.

In my tests yesterday, it seemed that I also need
\RequirePackage{luatex85} for luatex. It's too bad that we suddenly need so
many conditionals to fix simple code that has worked perfectly over the
last 13 years.

note that luatex85 is only intended as a user-level temporary fix for
packages that have not been updated to work with current luatex. luatex
0.95 as in texlive 2016 is massively incompatible with luatex 0.80 as in
texlive 2015, but it was always flagged as beta software subject to change,
so hard to complain too much (although it has cost us an awful lot of time
to keep the core and contributed latex macros working:-) luatex has
removed all the \pdfxxx... commands and changed much of the lua node
interface. This means that it's no longer ideal to make luatex and pdftex
just use the same back end code. the luatex85 package papers over some
cracks and makes some packages designed for pdftex still work for luatex
but as it doesn't address the changed lua interfaces it can't really be
relied on to make code that worked for luatex 0.80 to work with luatex 0.95
so it's better to do as we've done for graphics/color (and also hyperref)
make luatex have its own (h)luatex.def back end setup.

the luatex issue is not directly related to the page size setting change of
course, however one reason I didn't add a test for \ASYprefix to the def
files the other day was that I wasn't sure what other fixes you needed. If
you are anyway rebuilding to address luatex updates, then you can call
\usepackage[nosetpagesize]{graphics} and I don't need to add a test at all?

David

@johncbowman
Copy link
Member

I think Karl wants to avoid a rebuild. But before adding the \ASYprefix test, I will first try to patch
one of the system *.asy files to invoke nosetpagesize (only for TL2016, of course).

@davidcarlisle
Copy link

On 24 August 2016 at 09:16, John Bowman notifications@github.com wrote:

I think Karl wants to avoid a rebuild.

yes:-)

I can add something to the def files (or perhaps graphics.cfg) to change
the default if ASYprefix
is defined, but if you're anyway going to rebuild to fix for luatex or
something then I'd rather not.
basically let me know...

But before adding the \ASYprefix test, I will first try to patch
one of the system *.asy files to invoke nosetpagesize (only for TL2016, of
course).

OK,

David

@clason
Copy link

clason commented Sep 5, 2016

It does work, but not as expected: with inline, I get an A4 page, not the proper page size for a slide as set by beamer. (To reiterate: The problem is the combination of the inline option and the beamer class.)

What beamer does is to set the page size using the geometry package via

\RequirePackage[%
  papersize={\beamer@paperwidth,\beamer@paperheight},
  hmargin=1cm,%
  vmargin=0cm,%
  head=0.5cm,% might be changed later
  headsep=0pt,%
  foot=0.5cm% might be changed later
  ]{geometry}% http://ctan.org/pkg/geometry

so pdfpagewidth is probably not set. In fact, the problem is with the geometry package; the following code also shows the wrong page size (but not pdf page size!) to be set by asymptote:

\documentclass{article} 
\usepackage[papersize={10cm,10cm}]{geometry}
\usepackage[inline]{asymptote} 

\begin{document}

\begin{asy}
    import geometry;
    size(5cm,0);
    pair A=(0,0),B=(3,1),C=(1,3);
    dot("$A$",A,SW);
    dot("$B$",B,SE);
    dot("$C$",C,NW);
\end{asy}

\end{document}

Changing pdfpagewidth to paperwidth in the updated plain.asy restores the correct behavior in this case (but inserts a spurious blank page without the inline option).

@johncbowman johncbowman reopened this Sep 5, 2016
@johncbowman
Copy link
Member

johncbowman commented Nov 8, 2016

Ok I have finally found a portable way of forcing the nosetpagesize option to the graphicx package,
without tampering with the page size myself. There really should have been an easier way to do this, but given the design constraints of the graphicx package, this is the cleanest portable code I could come up with, now in https://raw.githubusercontent.com/vectorgraphics/asymptote/HEAD/base/plain.asy
Please try your example again with this file and if all is well I will submit this patch soon to TL2016.

if(latex() && pdf()) {
  // Portably force nosetpagesize option to graphicx package.
  texpreamble("\makeatletter\newif\ifGin@setpagesize");
  if(settings.tex == "pdflatex")
    texpreamble("\input pdftex.def");
  else if(settings.tex == "xelatex")
    texpreamble("\input xetex.def");
  else if(settings.tex == "lualatex") {
    texpreamble("\ifx\pdfpagewidth\undefined\let\pdfpagewidth\paperwidth\fi");
    texpreamble("\ifx\pdfpageheight\undefined\let\pdfpageheight\paperheight\fi"
                );
  }
}

if(settings.tex == "luatex")
  texpreamble("\input luatex85.sty");

@clason
Copy link

clason commented Nov 8, 2016

The example now works with inline (but still inserts a spurious blank page without inline). Thanks!

@johncbowman
Copy link
Member

The spurious blank page issue is also fixed; this requires updating
https://raw.githubusercontent.com/vectorgraphics/asymptote/HEAD/base/plain.asy
and generating v1.31 of asymptote.sty from the latest asy-latex.dtx:
https://raw.githubusercontent.com/vectorgraphics/asymptote/HEAD/doc/asy-latex.dtx

@kberry
Copy link

kberry commented Nov 8, 2016

comment #1: for the next full release, i urge you to consider putting all this nontrivial tex code into a file read at runtime, instead of compiled into the binary. it seems improbable to me it will never need to change again. a single tex file can determine the engine it's running under and act accordingly.

comment #2: fyi, akira, david carlisle, and i just concurred on making a change to dvips so that, in the 2017 release, it will act like dvipdmx: the last papersize special will win, instead of the first. i hope that will benefit asy rather than complicate the situation even more.

@johncbowman
Copy link
Member

Hi Karl,
Re: comment #1: There is a misunderstanding here. The above code is already in a text file called plain.asy and it is read at run time. This may look like C++ code but it is actually asy code.
So there is still no need to recompile the asy binaries. Now that it has been thoroughly tested, could you please replace the plain.asy file in TeXLive 2016 with

https://raw.githubusercontent.com/vectorgraphics/asymptote/HEAD/base/plain.asy

Re: comment #2: Yes I agree that the last (not first) papersize should win; that is what people expect. I also think that loading the graphicx package should not have side effects like changing the page size either at load time or worse, as is currently implemented, in the future, at \begin{document}.
In other words, the nosetpagesize option to graphicx should be the default. This would make it easy to write TeX code that works both with TL2016 and TL2015; the situation as it currently stands is not acceptable.

@davidcarlisle
Copy link

In other words, the nosetpagesize option to graphicx should be the
default. This would make it easy to write TeX code
that works both with TL2016 and TL2015; the situation as it currently
stands is not acceptable.

I understand why you take that view but that's not possible sorry. graphics
has set the page size with pdftex since the start. Since that is by far
the most common tex engine, there is no way really to change the default in
that case, even if it was considered a better default. The change to make
graphics+dvips do the same makes things far more consistent.

In an ideal world \documentclass[a4paper]{article} would set the page size
to A4, in fact it sets all the tex typesetting so that it only makes sense
on A4 but (as a conscious decision at the time) it has no knowledge of
driver specific code needed so the final setting of the media size is
delayed until driver-specific code is loaded (typically by graphics package)

David

@kberry
Copy link

kberry commented Nov 12, 2016

sorry, i should have realized that was plain.asy.

updated in tl.

@herbs
Copy link
Author

herbs commented Nov 14, 2016

On Nov 8, 2016, at 11:08 AM, John Bowman notifications@github.com wrote:

Closed #24.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Howdy,

With the latest update the cropping problem is back!

This is typesetting a sample file that comes with asymptote.

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)

@herbs
Copy link
Author

herbs commented Nov 14, 2016

On Nov 14, 2016, at 7:54 AM, Herbert Schulz herbs@wideopenwest.com wrote:

On Nov 8, 2016, at 11:08 AM, John Bowman notifications@github.com wrote:

Closed #24.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Howdy,

With the latest update the cropping problem is back!

This is typesetting a sample file that comes with asymptote.

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)

Howdy,

Just noticed that asymptote.sty is still at 1.30. I'll test with 1.31 as you posted.

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)

@johncbowman
Copy link
Member

Karl: in TL2016 could you also update asy-latex.dtx, which generates version 1.31 of asymptote.sty?

https://raw.githubusercontent.com/vectorgraphics/asymptote/HEAD/doc/asy-latex.dtx

Also, if you change the tex engine within an asy file, you will need to call nosetpagesize() explicitly.
This side-effect of the changes to the graphicx package won't be necessary using the upcoming 2.39 release but it probably won't be fixed in TL2016. Instead one has to do something like this:

if(!pdf()) {settings.tex="pdflatex"; nosetpagesize();}

@herbs
Copy link
Author

herbs commented Nov 14, 2016

On Nov 8, 2016, at 11:08 AM, John Bowman notifications@github.com wrote:

Closed #24.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Howdy,

Tested the new plain.asy (installed this AM via a TeX Live update) with version 1.31 of asymptote.sty (NOT installed at the same time) and all seems to be fine.

So version 1.31 of asymptote.sty needs to be installed ASAP.

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)

@herbs
Copy link
Author

herbs commented Nov 14, 2016

On Nov 14, 2016, at 10:03 AM, Herbert Schulz herbs@wideopenwest.com wrote:

On Nov 8, 2016, at 11:08 AM, John Bowman notifications@github.com wrote:

Closed #24.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Howdy,

Tested the new plain.asy (installed this AM via a TeX Live update) with version 1.31 of asymptote.sty (NOT installed at the same time) and all seems to be fine.

So version 1.31 of asymptote.sty needs to be installed ASAP.

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)

Howdy,

Sigh... asymptote.sty 1.31 with the updated plain.asy seems to work just fine when I process with pdflatex but I have the same cropping problem if I use xelatex. Am I missing some information? (I'm not changing processing in the middle of anything.)

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)

@johncbowman
Copy link
Member

Hi Herb,
Sorry about that oversight. This is now fixed in version 1.32 of asymptote.sty.
This new version of asy-latex.dtx should be installed in TL 2016.

@herbs
Copy link
Author

herbs commented Nov 14, 2016

On Nov 14, 2016, at 12:55 PM, John Bowman notifications@github.com wrote:

Hi Herb,
Sorry about that oversight. This is now fixed in version 1.32 of asymptote.sty.
This new version of asy-latex.dtx should be installed in TL 2016.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Howdy,

Works fine with both pdflatex and xelatex with asymptote.sty 1.32. Haven't tried to use lualatex, etc.

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)

@kberry
Copy link

kberry commented Nov 14, 2016

ran tex asy-latex.dtx, installed resulting asymptote.sty in TL for tonight's build. (also install asy-latex.dtx in the Build tree for completeness)

@herbs
Copy link
Author

herbs commented Nov 14, 2016

On Nov 14, 2016, at 4:38 PM, kberry notifications@github.com wrote:

ran tex asy-latex.dtx, installed resulting asymptote.sty in TL for tonight's build. (also install asy-latex.dtx in the Build tree for completeness)


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Howdy,

Karl, make sure you've got asymptote.sty 1.32 since it was updated from 1.31 today.

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)

@johncbowman
Copy link
Member

It turns out that the previous workaround for the graphicx bug was incompatible with Asymptote's 3D
label generation. A simpler and more robust workaround is here:

https://raw.githubusercontent.com/vectorgraphics/asymptote/HEAD/base/plain.asy

This also removes the requirement to call nosetpagesize() if you change the tex engine within an asy file.

@johncbowman
Copy link
Member

Karl: could you please update plain.asy in TL 2016 one more time? I've also updated asy-latex.dtx (which generates asymptote.sty) to version 1.33 although version 1.30-version 1.32 should work equally well. Thanks!

@herbs
Copy link
Author

herbs commented Nov 26, 2016 via email

@kberry
Copy link

kberry commented Nov 26, 2016

sure, updated plain.asy in tl. did not do asy-latex, but no problem to do that too if it becomes necessary ...

@raw915
Copy link

raw915 commented Jan 14, 2017

A few days ago (January 6, 2017) I did a full upgrade to TexLive 2016 on my MacBook Pro running OSX 10.10.5. I found asymptote.sty file version [2016/02/09 v1.30 Asymptote style file for LaTeX] at /usr/local/texlive/2016/texmf-dist/tex/latex/asymptote. Based on the above discussions I expected to find v1.33. I found v1.33 of asymptote.sty on the Internet and replaced v1.30 at /usr/local/texlive/2016/texmf-dist/tex/latex/asymptote/asymptote.sty Was that correct or should I have put this version in /usr/local/texlive/texmf-local? If two versions (1.30 and 1.33) are found, will the latest version be used?

@johncbowman
Copy link
Member

Asymptote 1.30 and 1.33 are in fact identical. As long as you have the latest version of plain.asy:

https://raw.githubusercontent.com/vectorgraphics/asymptote/HEAD/base/plain.asy

you should be fine.

jjgod pushed a commit to jjgod/texlive that referenced this issue Jun 11, 2017
git-svn-id: svn://tug.org/texlive/trunk/Build/source@41935 c570f23f-e606-0410-a88d-b1316a301751
jjgod pushed a commit to jjgod/texlive that referenced this issue Jun 11, 2017
git-svn-id: svn://tug.org/texlive/trunk/Build/source@41994 c570f23f-e606-0410-a88d-b1316a301751
jjgod pushed a commit to jjgod/texlive that referenced this issue Jun 11, 2017
git-svn-id: svn://tug.org/texlive/trunk/Build/source@42511 c570f23f-e606-0410-a88d-b1316a301751
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants