info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
platex producing dvi with wrong bounding box in TexLive 2016 (hagaki.cls)
42 views
Skip to first unread message
Gernot Hassenpflug
Nov 23, 2016, 9:38:18 PM11/23/16
to
In short, I would like to know how I could trace where this problem is
caused, and rectify it if possible.
Note that I posted only here, not in any of the texlive groups, so if
posting there would be better, please advise.
From 2010 until 2015 I have been using the Japanese hagaki.cls class [1]
to create new year cards (physical media height 148mm, width 100mm)
with platex and dvipdfmx (or dvips, but dvipdfmx does a better job of
laying out CJK). For all that time, I have been using Debian unstable
on x86_64 architecture.
The workflow is as follows [2,3], here using an example file name:
1. platex hagaki.tex
2. dvipdfmx -p "100mm,148mm" hagaki.dvi
Unfortunately, this month (November 2016), when preparing the coming
year's cards (always initially a direct copy of the previous year's
directory), I noticed that the DVI file bounding box as shown in xdvi
(actually pxdvi-xaw) is no longer correct (much smaller than it should
be, enough in width, but too short in height by about half), although
when using the zoom function and moving over the display, one can
actually see all the content, so it does not appear to be cut off at
the displayed bounding box.
Converting to PDF however creates a cropped file with the incorrect
bounding box from the DVI file.
Furthermore, recompiling files from the previous year gives the same
incorrect behaviour, thus this problem was clearly introduced during
latex updates sometime between December 2015 and November 2016.
To get around the issue, I managed to compile my files in a virtual
machine running Ubuntu xenial. It turns out (see below) that Ubuntu is
still using TexLive 2015, while my Debian unstable is running the
newer TexLive 2016.
Below, I list compile output, and some version information for Debian
unstable and Ubuntu xenial for the latex installation.
Examining the contents of the incorrect DVI files on Debian, created
with TexLive 2016, with "less" or "cat", shows that it contains the
following string:
The .dvi files contains the string:
"!papersize=365.33351pt,204.29102pt"
This corresponds to 128.88mm,77.07mm, and this seems to be the
displayed box in xdvi (with 128.88mm instead of 100mm, height 77.07mm
instead of 148mm).
This string is not included in DVI files produced with TexLive 2015.
Reading up on e-ptex in Japanese (I did not notice any special mention
of platex in TexLive 2016 release notes), I found a page about
including the DVI "special" called "papersize" [4], which tells
dvipdfmx the paper size to use. I tried to duplicate this in my latex
document, by specifying explicity a special named papersize, with the
size 100mm,148mm.
\AtBeginDvi{\special{papersize=100mm,148mm}}
The special did then appear with those dimentions in the DVI file,
without the "!" though; however, there was no difference in the DVI
bounding box and display with xdvi. So I suspect the explicit
inclusion of this special is not important, and that the size
indicated is a side effect of some other calculation which is the root
cause of the incorrect bounding box.
It does lead me to consider that there might be some incompatibility
in platex independent of the TexLive version, and that the hagaki.cls
class file might need to be changed in some way, but at the present
moment I don't have any clue what to look for.
Any advice, pointers, things to try would be much appreciated. If
necessary, I can provide my files verbatim to anyone that wishes to
compile them (see [1] for the official examples).
Best regards,
Gernot Hassenpflug
References:
[1] hagaki.cls and example hagaki.tex files
http://pub.ks-and-ks.ne.jp/prog/latex2e-lib.html
[2] Example usage (in Japanese)
http://kreisel.fam.cx/webmaster/clog/2008-01-02-1.html
[3] In my latex document, the class is given as follows:
\documentclass[height=14.8cm,topmargin=.58cm,width=10cm,leftmargin=.58cm]{hagaki}
[4] Use of DVI specials in e-ptex
https://texwiki.texjp.org/?special%20%E5%91%BD%E4%BB%A4#dvi-special
Below compile information and software version information.
Numbering is as follows:
1. corresponds to Debian unstable
2. corresponds to Ubuntu xenial
A. Compile information:
1. $ platex ny2016academia.tex
This is e-pTeX, Version 3.14159265-p3.7.1-161114-2.6 (utf8.euc) (TeXLive 2016/Debian) (preloaded format=platex)
restricted \write18 enabled.
entering extended mode
(./ny2016academia.tex
pLaTeX2e <2016/09/08> (based on LaTeX2e <2016/03/31> patch level 3)
Babel <3.9r> and hyphenation patterns for 12 language(s) loaded.
(./hagaki.cls
Document Class: hagaki
(/usr/share/texlive/texmf-dist/tex/platex/base/treport.cls
Document Class: treport 2006/06/27 v1.6 Standard pLaTeX class
(/usr/share/texlive/texmf-dist/tex/platex/base/tsize11.clo)
(/usr/share/texlive/texmf-dist/tex/platex/base/plext.sty)))
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg)
(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/dvips.def)))
(./ny2016academia.aux) 《縦組モード》 [1] [2] [3] [4] [5] (./ny2016academia.aux
) )
Output written on ny2016academia.dvi (5 pages, 5380 bytes).
Transcript written on ny2016academia.log.
2. $ platex ny2016academia.tex
This is e-pTeX, Version 3.14159265-p3.6-141210-2.6 (utf8.euc) (TeX Live 2015/Debian) (preloaded format=platex)
restricted \write18 enabled.
entering extended mode
(./ny2016academia.tex
pLaTeX2e <2006/11/10> (based on LaTeX2e <2016/02/01> patch level 0)
Babel <3.9n> and hyphenation patterns for 13 languages loaded.
(./hagaki.cls
Document Class: hagaki
(/usr/share/texlive/texmf-dist/tex/platex/base/treport.cls
Document Class: treport 2006/06/27 v1.6 Standard pLaTeX class
(/usr/share/texlive/texmf-dist/tex/platex/base/tsize11.clo)
(/usr/share/texlive/texmf-dist/tex/platex/base/plext.sty)))
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty)
(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/graphics.cfg)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/dvips.def)))
(./ny2016academia.aux) 《縦組モード》 [1] [2] [3] [4] [5] (./ny2016academia.aux
) )
Output written on ny2016academia.dvi (5 pages, 5300 bytes).
Transcript written on ny2016academia.log.
B. Version information
ptex-jtex (not needed in Ubuntu, but it seems in Debian it provides platex)
1. Version: 1.7+1-15
2. Version: 1.7+1-15 (same as Debian)
ptex-base (provides platex in Ubuntu, and should provide it in Debian)
1. Version: 1:2.5-2.1
2. Version: 1:2.5-2.1 (same as Debian)
texlive-base (provides dvipdfmx)
1. Version: 2016.20161103-1
2. Version: 2015.20160320-1
texlive-binaries
1. Version: 2016.20160513.41080-8
2. Version: 2015.20160222.37495-1
pxdvi-xaw
1. $ pxdvi-xaw -v
xdvik version 22.87.03 j1.42-debian (Xaw toolkit)
Libraries: kpathsea version 6.2.2, T1lib version 2.6.3, FreeType version 2.11.0
2. $ pxdvi-xaw -v
xdvik version 22.84.16 j1.41-ptexlive (Xaw toolkit)
Libraries: kpathsea version 6.2.1, T1lib version 5.1.2, FreeType version 2.4.8
dvipdfmx
1. $ dvipdfmx --version
This is dvipdfmx Version 20160307 by the DVIPDFMx project team,
modified for TeX Live,
an extended version of dvipdfm-0.13.2c developed by Mark A. Wicks.
/../
2. $ dvipdfmx --version
This is dvipdfmx Version 20150315 by the DVIPDFMx project team,
modified for TeX Live,
an extended version of dvipdfm-0.13.2c developed by Mark A. Wicks.
/../
--
NNTP on Emacs 24.5 from Windows 7
Ulrike Fischer
Nov 24, 2016, 12:47:30 PM11/24/16
to
Am Thu, 24 Nov 2016 11:38:15 +0900 schrieb Gernot Hassenpflug:
> In short, I would like to know how I could trace where this problem is
> caused, and rectify it if possible.
> Note that I posted only here, not in any of the texlive groups, so if
> posting there would be better, please advise.
>
> From 2010 until 2015 I have been using the Japanese hagaki.cls class [1]
> to create new year cards (physical media height 148mm, width 100mm)
> with platex and dvipdfmx (or dvips, but dvipdfmx does a better job of
> laying out CJK). For all that time, I have been using Debian unstable
> on x86_64 architecture.
>
> The workflow is as follows [2,3], here using an example file name:
> 1. platex hagaki.tex
> 2. dvipdfmx -p "100mm,148mm" hagaki.dvi
>
> Unfortunately, this month (November 2016), when preparing the coming
> year's cards (always initially a direct copy of the previous year's
> directory), I noticed that the DVI file bounding box as shown in xdvi
> (actually pxdvi-xaw) is no longer correct.
> In short, I would like to know how I could trace where this problem is
> caused, and rectify it if possible.
> Note that I posted only here, not in any of the texlive groups, so if
> posting there would be better, please advise.
>
> From 2010 until 2015 I have been using the Japanese hagaki.cls class [1]
> to create new year cards (physical media height 148mm, width 100mm)
> with platex and dvipdfmx (or dvips, but dvipdfmx does a better job of
> laying out CJK). For all that time, I have been using Debian unstable
> on x86_64 architecture.
>
> The workflow is as follows [2,3], here using an example file name:
> 1. platex hagaki.tex
> 2. dvipdfmx -p "100mm,148mm" hagaki.dvi
>
> Unfortunately, this month (November 2016), when preparing the coming
> year's cards (always initially a direct copy of the previous year's
> directory), I noticed that the DVI file bounding box as shown in xdvi
You are loading graphicx and in TL2016 graphicx sets (also) for
dvips and dvipdfmx the pdf pagesize.
You could try something like this (I don't have your document so
can't really test, beside this the japanese orientation confuses me)
\PassOptionsToPackage{nosetpagesize,dvipdfmx}{graphicx}
%load the correct driver dvipdfmx if you use dvipdfmx at the end
\documentclass[height=14.8cm,topmargin=.58cm,width=10cm,leftmargin=.58cm]{hagaki}
\RequirePackage{graphics}
\AtBeginDocument{\AtBeginDvi{\special{pdf:pagesize width 170mm
height 148}}}
\begin{document}
blabla bul
\end{document}
Or
\PassOptionsToPackage{dvipdfmx}{graphicx}
\documentclass[height=14.8cm,topmargin=.58cm,width=10cm,leftmargin=.58cm]{hagaki}
\usepackage{graphics}
\paperwidth=100mm
\paperheight=148mm
\begin{document}
blabla bul
\end{document}
both then with a simple dvipdfmx test.dvi call.
--
Ulrike Fischer
http://www.troubleshooting-tex.de/
Gernot Hassenpflug
Dec 2, 2016, 8:57:31 PM12/2/16
to
Ulrike Fischer <ne...@nililand.de> writes:
Hello Ulrike, thank you very much for the helpful reply. Both you
methods I could get to work.
More details (and questions for clarification) below, sorry I
took so long to post a reply, but I found I wanted to get through a lot
of documentation and tests.
It is still pretty unclear to me what is the root cause of the
behavioural differences between Tex Live 2015 and TeX Live 2016 on my
Debian unstable system.
To summarize:
1. original problem: DVI bounding box for hagaki is too small (height
about half-size). PDF file also has same problem.
2. using workarounds 1 and 2 from Ulrike's advice, both DVI file and PDF
file can be displayed correctly.
3. However, leaving out \paperheight and \paperwidth makes DVI file page
size go to A4 (no longer too small though), but PDF size is correct.
4. Furthermore, the workaround only work if the \PassOptionsToPackage is
for graphicx, but the \RequirePackage or \usepackage command is
graphics. In that case dvips.dev is loaded. Using the same name for
the package on each line, or swapping them around, causes
dvipdfmx.def to be loaded instead, and DVI size goes to A4 regardless
of \papersize and \paperwidth.
5. I also note that in TeX Live 2015 there was no dvipdfmx.def
(directory also slightly different), and using the TeX Live 2015
dvips.def (just copied) on my TeX Live 2016 system made no difference
to the (incorrect) behaviour.
6. I put a small sample file at the end, no compile logs for
the various combintions tried, but can be provided.
Compilation:
platex text.tex
dvipdfmx text.dvi (may need option -p "100mm,148mm" depending on workaround used)
> Am Thu, 24 Nov 2016 11:38:15 +0900 schrieb Gernot Hassenpflug:
>
>> In short, I would like to know how I could trace where this problem is
>> caused, and rectify it if possible.
>> Note that I posted only here, not in any of the texlive groups, so if
>> posting there would be better, please advise.
>>
>> From 2010 until 2015 I have been using the Japanese hagaki.cls class [1]
>> to create new year cards (physical media height 148mm, width 100mm)
>> with platex and dvipdfmx (or dvips, but dvipdfmx does a better job of
>> laying out CJK). For all that time, I have been using Debian unstable
>> on x86_64 architecture.
>>
>> The workflow is as follows [2,3], here using an example file name:
>> 1. platex hagaki.tex
>> 2. dvipdfmx -p "100mm,148mm" hagaki.dvi
>>
>> Unfortunately, this month (November 2016), when preparing the coming
>> year's cards (always initially a direct copy of the previous year's
>> directory), I noticed that the DVI file bounding box as shown in xdvi
>> (actually pxdvi-xaw) is no longer correct.
>
> You are loading graphicx and in TL2016 graphicx sets (also) for
> dvips and dvipdfmx the pdf pagesize.
I see. Quite a hurdle for me to understand this, took some time,
sorry. While trying your two methods, I read and re-read the TeX Live
2016 documentation [1], pdfTeX manual [2], LaTeX graphics guide [3], the
epslatex guide [4], among others.
(Aside: I also submitted by email to Tex Live and TUG a set of
documentation bugs, and suggestions for improvement for [1] and [2]).
From grfguide.pdf [3] and epslatex.pdf [4], I now understand that
packages take options as to which driver is used to create output files,
and that there are site defaults set in graphics.cfg, color.cfg, etc.,
as the package may be.
For dvipdfmx, I understand (from 1999 dvipdfm documentation [5]) that
PDF features are activated in the driver via TeX special primitives of
format \special{pdf:...}. There is not much documentation on dvipdfmx,
but the paper included with the package on CTAN [6] mentions the
pagesize special as a way to obtain different page sizes in the same
document. Japanese help on specials included for reference [7]. The
documentation for dvips [8] also mentions insertion of the \papersize
special by packages, for dvips to use. I understand specials without the
above form would be ignored by dvipdfmx.
I am still confused by what driver is being used by default, and why the
behaviour (regarding pagesize of the graphicx/graphics package is
different in TeX Live 2016. From my tests:
(a) without adding any workaround, both TeXLive 2015 and TeXLive 2016
load dvips.def.
(b) with either workaround, if \PassOptionsToPackage{dvipdfx}{graphicx},
but \RequirePackage or \usepackage specifies graphics, then
dvips.def is loaded. And if \paperheight and \paperwidth are set,
then the DVI page size is correct in TeXLive 2016.
If \paperheight and \paperwidth are not set, then the DVI page size
is too small again (i.e., original problem), but PDF page
size is correct.
(Note: using the dvips.def from TeX Live 2015 did not change this
behaviour in TeX Live 2016, so it remains a mystery to me where the
difference in behaviour comes from. I suppose I could experiment
with graphics.cfg also but have no with to revert to an older system
configuration file).
(c) with either workaround, if the same package name (graphicx or
graphics) is used in both the \PassOptionsToPackage and the
\RequirePackage (or \usepackage) commands, then dvipdfmx.def is
loaded in stead of dvips.def.
The same thing occurs if \PassOptionsToPackage uses graphics, and
the later \RequirePackage (or \usepackage) command uses graphicx.
(i.e., only the order in (b) loads devips.def).
In this case, where dvipdfmx.def is loaded, the DVI page size is
always A4, regardless of the use of \paperheight and \paperwidth,
but the PDF page size is always correct also.
(TeXLive 2015 does not have a dvipdfmxdef, only a dvipdf.def, and I
did not experiment to see what happens if I specify a driver for the
graphics/graphicx package).
I remain confused, but happily with options thanks to your help!
From the graphics bundle and epslatex documentation:
If the user wants to use either of these drivers, the driver usually
does not need to be explicitly specified, as the graphics.cfg in most
LATEX distributions is smart enough to specify the correct driver.
If the user needs to specify a driver, it can be specified in one of
three ways:
1. The default can be specified in the graphics.cfg file.
2. Any driver specified as a \documentclass option overrides the
driver specified in graphics.cfg.
3. Any driver specified as an option in \usepackage{graphics}
overrides the drivers specified in the previous two manners.
So it looks to me like graphics.cfg should not have any effct, since it
is being overridden in the workarounds.
> You could try something like this (I don't have your document so
> can't really test, beside this the japanese orientation confuses me)
>
> \PassOptionsToPackage{nosetpagesize,dvipdfmx}{graphicx}
> %load the correct driver dvipdfmx if you use dvipdfmx at the end
> \documentclass[height=14.8cm,topmargin=.58cm,width=10cm,leftmargin=.58cm]{hagaki}
> \RequirePackage{graphics}
> \AtBeginDocument{\AtBeginDvi{\special{pdf:pagesize width 170mm
> height 148mm}}}
insertion of the special from the documentation I had read.
For the DVI file to have the right page size, I also need to add
\paperheight and \paperwidth as for the below workaround.
It seems the nosetpagesize parameter has no effect for me, I get the
same result with or without it.
In the documentation I read I could not discover the necessity of using
\PassOptionsToPackage and \RequirePackage. It looks like the parameters
in \PassOptionsToPackage are ones that would normally be given as
options to the \usepackage command, but I do not know if what you give
above is an alternative form, or a necessary workaround.
> Or
>
> \PassOptionsToPackage{dvipdfmx}{graphicx}
> \documentclass[height=14.8cm,topmargin=.58cm,width=10cm,leftmargin=.58cm]{hagaki}
> \usepackage{graphics}
> \paperwidth=100mm
> \paperheight=148mm
>
> \begin{document}
> blabla bul
> \end{document}
Yes, this works perfectly too both for DVI and for PDF.
Without the \paperheight and paperwidth, both DVI and PDF are too small
(original problem). (Trying with "nosetpagesize" had no effect, must
have those two commands).
Using the above two workarounds, I did not need to specify the PDF paper
size with -p "100mm,148mm" when running dvipdfmx.
I also tried the following successfully:
Specifying the dvipfdmx driver specifically as an option in the
\usepackage command, with the "nosetpagesize" (I could not find it in
the documentation).
\documentclass[height=14.8cm,topmargin=.58cm,width=10cm,leftmargin=.58cm]{hagaki}
\usepackage[nosetpagesize,dvipdfmx]{graphics}
The DVI page size is A4 in this case.
I need "nosetpagesize", else the PDF size is too small (origal problem),
with or without the -p option to dvipdfmx.
When using "nosetpagesize", I still need the -p option with dvipdfmx to
get the correct PDF page size, the option does not work without the
"nosetpagesize" parameter.
> both then with a simple dvipdfmx test.dvi call.
Example TeX file with workaround 1 active:
% workaround 1
%\PassOptionsToPackage{nosetpagesize,dvipdfmx}{graphicx}%no effect
\PassOptionsToPackage{dvipdfmx}{graphicx}
% workaround 2
%\PassOptionsToPackage{dvipdfmx}{graphicx}
% common (hagaki class [9])
\documentclass[height=14.8cm,topmargin=.58cm,width=10cm,leftmargin=.58cm]{hagaki}
% workaround 1
\RequirePackage{graphics}% loads dvips.def if PassOptionsToPackage calls graphicx
\paperwidth=100mm% need for correct DVI bounding box---PDF is fine without it
\paperheight=148mm% need for correct DVI bounding box---PDF is fine without it
\AtBeginDocument{\AtBeginDvi{\special{pdf:pagesize width 100mm height 148mm}}}
% workaround 2
%\usepackage{graphics}% loads dvips.def if PassOptionsToPackage calls graphicx
%\paperwidth=100mm
%\paperheight=148mm
% hagaki data setup
\OurAddress{Addr1 Addr2\par Addr3\rensuji{1}--\rensuji{1}--\rensuji{1}\par Apartment \rensuji{1}}
\OurFamilyName{FamName}
\OurName{MyName}
\OurZip{111-0001}
\Jusho{Omote}
\begin{document}
\omote{Smith}{John & Jill}{111-1111}{Addr1 Addr2 Addr3\rensuji{1}--\rensuji{1}--\rensuji{1}--\rensuji{1}}
\end{document}
Any further tips for trouble-shooting and understanding much
appreciated!
Best regards,
Gernot Hassenpflug
References (on CTAN if no URI given):
[1] The TEX Live Guide—2016 (June 2016)
https://www.tug.org/texlive/doc/texlive-en/texlive-en.pdf
[2] The pdfTEX user manual (May 9, 2016)
pdftex-a.pdf (up to version 1.40.17)
Also: 62 page version (up to version 1.20b):
http://www.pragma-ade.com/pdftex/pdftex-s.pdf
Also: 47 page version (older):
http://vlado.fmf.uni-lj.si/texceh/kako/tex2pdf/ex/pdftex-s.pdf
Also: The pdfTEX user manual TUGboat, Volume 18 (1997), No.4
https://www.tug.org/TUGboat/tb18-4/tb57than.pdf
[3] Guide to graphics in LaTEX (May 2, 2016)
grfguide.pdf
[4] Guide to using Encapsulated PostScript in LaTEX (Jan 12, 2006)
epslatex.pdf
[5] dvipdfm User's Manual (Sep 19, 1999)
http://texdoc.net/texmf-dist/doc/dvipdfm/dvipdfm.pdf
[6] paper on dvipdfmx on CTAN
http://project.ktug.org/dvipdfmx/doc/tug2003.pdf
[7] Japanese TeX Wiki entry for dvipdxmx
https://texwiki.texjp.org/?dvipdfmx
Also: use of specials in dvipdfmx
https://texwiki.texjp.org/?special%20%E5%91%BD%E4%BB%A4#specials-dvipdfmx
[8] Dvips: A DVI-to-PostScript Translator (April 2016)
http://texdoc.net/texmf-dist/doc/dvips/dvips.pdf
[9] hagaki class official site
http://pub.ks-and-ks.ne.jp/prog/latex2e-lib.html
Hello Ulrike, thank you very much for the helpful reply. Both you
methods I could get to work.
More details (and questions for clarification) below, sorry I
took so long to post a reply, but I found I wanted to get through a lot
of documentation and tests.
It is still pretty unclear to me what is the root cause of the
behavioural differences between Tex Live 2015 and TeX Live 2016 on my
Debian unstable system.
To summarize:
1. original problem: DVI bounding box for hagaki is too small (height
about half-size). PDF file also has same problem.
2. using workarounds 1 and 2 from Ulrike's advice, both DVI file and PDF
file can be displayed correctly.
3. However, leaving out \paperheight and \paperwidth makes DVI file page
size go to A4 (no longer too small though), but PDF size is correct.
4. Furthermore, the workaround only work if the \PassOptionsToPackage is
for graphicx, but the \RequirePackage or \usepackage command is
graphics. In that case dvips.dev is loaded. Using the same name for
the package on each line, or swapping them around, causes
dvipdfmx.def to be loaded instead, and DVI size goes to A4 regardless
of \papersize and \paperwidth.
5. I also note that in TeX Live 2015 there was no dvipdfmx.def
(directory also slightly different), and using the TeX Live 2015
dvips.def (just copied) on my TeX Live 2016 system made no difference
to the (incorrect) behaviour.
6. I put a small sample file at the end, no compile logs for
the various combintions tried, but can be provided.
Compilation:
platex text.tex
dvipdfmx text.dvi (may need option -p "100mm,148mm" depending on workaround used)
> Am Thu, 24 Nov 2016 11:38:15 +0900 schrieb Gernot Hassenpflug:
>
>> In short, I would like to know how I could trace where this problem is
>> caused, and rectify it if possible.
>> Note that I posted only here, not in any of the texlive groups, so if
>> posting there would be better, please advise.
>>
>> From 2010 until 2015 I have been using the Japanese hagaki.cls class [1]
>> to create new year cards (physical media height 148mm, width 100mm)
>> with platex and dvipdfmx (or dvips, but dvipdfmx does a better job of
>> laying out CJK). For all that time, I have been using Debian unstable
>> on x86_64 architecture.
>>
>> The workflow is as follows [2,3], here using an example file name:
>> 1. platex hagaki.tex
>> 2. dvipdfmx -p "100mm,148mm" hagaki.dvi
>>
>> Unfortunately, this month (November 2016), when preparing the coming
>> year's cards (always initially a direct copy of the previous year's
>> directory), I noticed that the DVI file bounding box as shown in xdvi
>> (actually pxdvi-xaw) is no longer correct.
>
> You are loading graphicx and in TL2016 graphicx sets (also) for
> dvips and dvipdfmx the pdf pagesize.
sorry. While trying your two methods, I read and re-read the TeX Live
2016 documentation [1], pdfTeX manual [2], LaTeX graphics guide [3], the
epslatex guide [4], among others.
(Aside: I also submitted by email to Tex Live and TUG a set of
documentation bugs, and suggestions for improvement for [1] and [2]).
From grfguide.pdf [3] and epslatex.pdf [4], I now understand that
packages take options as to which driver is used to create output files,
and that there are site defaults set in graphics.cfg, color.cfg, etc.,
as the package may be.
For dvipdfmx, I understand (from 1999 dvipdfm documentation [5]) that
PDF features are activated in the driver via TeX special primitives of
format \special{pdf:...}. There is not much documentation on dvipdfmx,
but the paper included with the package on CTAN [6] mentions the
pagesize special as a way to obtain different page sizes in the same
document. Japanese help on specials included for reference [7]. The
documentation for dvips [8] also mentions insertion of the \papersize
special by packages, for dvips to use. I understand specials without the
above form would be ignored by dvipdfmx.
I am still confused by what driver is being used by default, and why the
behaviour (regarding pagesize of the graphicx/graphics package is
different in TeX Live 2016. From my tests:
(a) without adding any workaround, both TeXLive 2015 and TeXLive 2016
load dvips.def.
(b) with either workaround, if \PassOptionsToPackage{dvipdfx}{graphicx},
but \RequirePackage or \usepackage specifies graphics, then
dvips.def is loaded. And if \paperheight and \paperwidth are set,
then the DVI page size is correct in TeXLive 2016.
If \paperheight and \paperwidth are not set, then the DVI page size
is too small again (i.e., original problem), but PDF page
size is correct.
(Note: using the dvips.def from TeX Live 2015 did not change this
behaviour in TeX Live 2016, so it remains a mystery to me where the
difference in behaviour comes from. I suppose I could experiment
with graphics.cfg also but have no with to revert to an older system
configuration file).
(c) with either workaround, if the same package name (graphicx or
graphics) is used in both the \PassOptionsToPackage and the
\RequirePackage (or \usepackage) commands, then dvipdfmx.def is
loaded in stead of dvips.def.
The same thing occurs if \PassOptionsToPackage uses graphics, and
the later \RequirePackage (or \usepackage) command uses graphicx.
(i.e., only the order in (b) loads devips.def).
In this case, where dvipdfmx.def is loaded, the DVI page size is
always A4, regardless of the use of \paperheight and \paperwidth,
but the PDF page size is always correct also.
(TeXLive 2015 does not have a dvipdfmxdef, only a dvipdf.def, and I
did not experiment to see what happens if I specify a driver for the
graphics/graphicx package).
I remain confused, but happily with options thanks to your help!
From the graphics bundle and epslatex documentation:
If the user wants to use either of these drivers, the driver usually
does not need to be explicitly specified, as the graphics.cfg in most
LATEX distributions is smart enough to specify the correct driver.
If the user needs to specify a driver, it can be specified in one of
three ways:
1. The default can be specified in the graphics.cfg file.
2. Any driver specified as a \documentclass option overrides the
driver specified in graphics.cfg.
3. Any driver specified as an option in \usepackage{graphics}
overrides the drivers specified in the previous two manners.
So it looks to me like graphics.cfg should not have any effct, since it
is being overridden in the workarounds.
> You could try something like this (I don't have your document so
> can't really test, beside this the japanese orientation confuses me)
>
> \PassOptionsToPackage{nosetpagesize,dvipdfmx}{graphicx}
> %load the correct driver dvipdfmx if you use dvipdfmx at the end
> \documentclass[height=14.8cm,topmargin=.58cm,width=10cm,leftmargin=.58cm]{hagaki}
> \RequirePackage{graphics}
> \AtBeginDocument{\AtBeginDvi{\special{pdf:pagesize width 170mm
> \begin{document}
> blabla bul
> \end{document}
Great! This works perfectly for PDF, and I could understand the
> blabla bul
> \end{document}
insertion of the special from the documentation I had read.
For the DVI file to have the right page size, I also need to add
\paperheight and \paperwidth as for the below workaround.
It seems the nosetpagesize parameter has no effect for me, I get the
same result with or without it.
In the documentation I read I could not discover the necessity of using
\PassOptionsToPackage and \RequirePackage. It looks like the parameters
in \PassOptionsToPackage are ones that would normally be given as
options to the \usepackage command, but I do not know if what you give
above is an alternative form, or a necessary workaround.
> Or
>
> \PassOptionsToPackage{dvipdfmx}{graphicx}
> \documentclass[height=14.8cm,topmargin=.58cm,width=10cm,leftmargin=.58cm]{hagaki}
> \usepackage{graphics}
> \paperwidth=100mm
> \paperheight=148mm
>
> \begin{document}
> blabla bul
> \end{document}
Without the \paperheight and paperwidth, both DVI and PDF are too small
(original problem). (Trying with "nosetpagesize" had no effect, must
have those two commands).
Using the above two workarounds, I did not need to specify the PDF paper
size with -p "100mm,148mm" when running dvipdfmx.
I also tried the following successfully:
Specifying the dvipfdmx driver specifically as an option in the
\usepackage command, with the "nosetpagesize" (I could not find it in
the documentation).
\documentclass[height=14.8cm,topmargin=.58cm,width=10cm,leftmargin=.58cm]{hagaki}
\usepackage[nosetpagesize,dvipdfmx]{graphics}
The DVI page size is A4 in this case.
I need "nosetpagesize", else the PDF size is too small (origal problem),
with or without the -p option to dvipdfmx.
When using "nosetpagesize", I still need the -p option with dvipdfmx to
get the correct PDF page size, the option does not work without the
"nosetpagesize" parameter.
> both then with a simple dvipdfmx test.dvi call.
% workaround 1
%\PassOptionsToPackage{nosetpagesize,dvipdfmx}{graphicx}%no effect
\PassOptionsToPackage{dvipdfmx}{graphicx}
% workaround 2
%\PassOptionsToPackage{dvipdfmx}{graphicx}
% common (hagaki class [9])
\documentclass[height=14.8cm,topmargin=.58cm,width=10cm,leftmargin=.58cm]{hagaki}
% workaround 1
\RequirePackage{graphics}% loads dvips.def if PassOptionsToPackage calls graphicx
\paperwidth=100mm% need for correct DVI bounding box---PDF is fine without it
\paperheight=148mm% need for correct DVI bounding box---PDF is fine without it
\AtBeginDocument{\AtBeginDvi{\special{pdf:pagesize width 100mm height 148mm}}}
% workaround 2
%\usepackage{graphics}% loads dvips.def if PassOptionsToPackage calls graphicx
%\paperwidth=100mm
%\paperheight=148mm
% hagaki data setup
\OurAddress{Addr1 Addr2\par Addr3\rensuji{1}--\rensuji{1}--\rensuji{1}\par Apartment \rensuji{1}}
\OurFamilyName{FamName}
\OurName{MyName}
\OurZip{111-0001}
\Jusho{Omote}
\begin{document}
\omote{Smith}{John & Jill}{111-1111}{Addr1 Addr2 Addr3\rensuji{1}--\rensuji{1}--\rensuji{1}--\rensuji{1}}
\end{document}
Any further tips for trouble-shooting and understanding much
appreciated!
Best regards,
Gernot Hassenpflug
References (on CTAN if no URI given):
[1] The TEX Live Guide—2016 (June 2016)
https://www.tug.org/texlive/doc/texlive-en/texlive-en.pdf
[2] The pdfTEX user manual (May 9, 2016)
pdftex-a.pdf (up to version 1.40.17)
Also: 62 page version (up to version 1.20b):
http://www.pragma-ade.com/pdftex/pdftex-s.pdf
Also: 47 page version (older):
http://vlado.fmf.uni-lj.si/texceh/kako/tex2pdf/ex/pdftex-s.pdf
Also: The pdfTEX user manual TUGboat, Volume 18 (1997), No.4
https://www.tug.org/TUGboat/tb18-4/tb57than.pdf
[3] Guide to graphics in LaTEX (May 2, 2016)
grfguide.pdf
[4] Guide to using Encapsulated PostScript in LaTEX (Jan 12, 2006)
epslatex.pdf
[5] dvipdfm User's Manual (Sep 19, 1999)
http://texdoc.net/texmf-dist/doc/dvipdfm/dvipdfm.pdf
[6] paper on dvipdfmx on CTAN
http://project.ktug.org/dvipdfmx/doc/tug2003.pdf
[7] Japanese TeX Wiki entry for dvipdxmx
https://texwiki.texjp.org/?dvipdfmx
Also: use of specials in dvipdfmx
https://texwiki.texjp.org/?special%20%E5%91%BD%E4%BB%A4#specials-dvipdfmx
[8] Dvips: A DVI-to-PostScript Translator (April 2016)
http://texdoc.net/texmf-dist/doc/dvips/dvips.pdf
[9] hagaki class official site
http://pub.ks-and-ks.ne.jp/prog/latex2e-lib.html
0 new messages