You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had some issues with creating the pdf. I found those to be caused by the Makefile running dvipdf. When looking into the Makefile, there is:
# these targets are for most common unix systems, but YMMV. Modify if you need
# let the editors know you have a better way for the next ADASS team
# ASP prefers the latex;latex;dvipdfm route
DVIPDF = dvipdf
adding an m at the end makes it work for me. So if ASP prefers that we use dvipdfm, why don't we actually do that in the Makefile?
The text was updated successfully, but these errors were encountered:
the problem for me (or anybody on my team) the dvipdfm didn't work. In fact, even at the ASP machines we had better luck with dvipdf, but the comment is based on an older script from the Sydney proceedings.
Also, at the time I noted that dvipdf took a long time for the book (like 20mins), whereas creating the dvi was fast, so I often used xdvi to preview. The other "working" program (perhaps it was dvipdfm) was superior in speed, but it has issues which I don't remember. Maybe it was badly placed figures or so.
In short, it was a mess.
The mess continues. The 2020 team has issues on the ASP server now with the different version of making pdf's. In some version about a dozen figures are improperly cropped.
I had some issues with creating the pdf. I found those to be caused by the Makefile running dvipdf. When looking into the Makefile, there is:
adding an m at the end makes it work for me. So if ASP prefers that we use dvipdfm, why don't we actually do that in the Makefile?
The text was updated successfully, but these errors were encountered: