dvipdfm graphics problem
Laurent S.
*** dvipdfm graphics problem
Hi dvipdfm bitmap users,
It appears I have encountered a bug in dvipdfm that
bites when a *big b/w bitmap* is included as an eps file
using say epsf.tex of Rokicki --- which uses specials like
\special
{fig2-ab.eps llx=0 lly=0 urx=3609 ury=4076
rwi=2949.76936 rhi=3331.46576}
Only a modest rectangle at the lowerleft of the bitmap is
included. I have dvipdfm version 0.13.2c under linux 386.
Since dvipdf (which is a script that pipes dvips to gs) works
OK here, I conclude this is a dvipdfm bug. But I want to
exploit other features of dvipdfm, so I want to work around
this bug.
Demos illustrating the problem are posted temporarily at
http://topo.math.u-psud.fr/~slc/dvipdfm_puzzle
The archive "simple_tst.zip" serves to check normal operation
of eps inclusion.
The archive "fig2-ab_tst.zip" serves to exhibit the bug.
Suggestions? Diagnoses?
Cheers
Laurent S.
Robin Fairbairns
>Hi dvipdfm bitmap users,
>
> It appears I have encountered a bug in dvipdfm that
>bites when a *big b/w bitmap* is included as an eps file
>using say epsf.tex of Rokicki --- which uses specials like
>
>\special
> {fig2-ab.eps llx=0 lly=0 urx=3609 ury=4076
> rwi=2949.76936 rhi=3331.46576}
what makes you imagine that dvipdfm uses dvips \specials unmodified?
it may do, but i see no more than hints in the manual.
if you want to use epsf, i suggest you need to make a modified version
for your bitmaps, using \special{pdf:image ...} -- that takes image
types jpg, png and pdf(?!).
needless to say, the latex graphics bundle (available to eplain users,
and to plain tex users who care to use it via the macros at ctan
macros/plain/graphics) has a dvipdfm driver that will auto-detect
which file type is being requested (under the "proper" circumstances).
--
Robin Fairbairns, Cambridge
George N. White III
> pos...@topo.math.u-psud.fr (Laurent S.) writes:
>> Hi dvipdfm bitmap users,
>>
>> It appears I have encountered a bug in dvipdfm that
>> bites when a *big b/w bitmap* is included as an eps file
>> using say epsf.tex of Rokicki --- which uses specials like
>>
>> \special
>> {fig2-ab.eps llx=0 lly=0 urx=3609 ury=4076
>> rwi=2949.76936 rhi=3331.46576}
>
> what makes you imagine that dvipdfm uses dvips \specials unmodified?
> it may do, but i see no more than hints in the manual.
The OP's imagination works just like that of many, many other TeX users.
This is probably the most common "mistake" I see among experienced
LaTeX users switching to a new TeX system or trying to co-author with
someone using a different system. Kpathsea needs a way to recognize
"system dependent" files and require an explicit override
(\yesreallyinput) to load such files from a user directory.
--
George N. White III <aa...@chebucto.ns.ca>
Robin Fairbairns
note that laurent is a *very* long-time (and experienced) _plain_ tex
user. i wouldn't have responded that way to someone who (for all i
know) couldn't have known better.
--
Robin Fairbairns, Cambridge
Laurent S.
Perhaps the following 'primitive' Plain TeX file
will help someone explain the dvipdfm
"eps integration bug" that I am curious about:
%-------- cut
%%% fig2-ab_ptest.tex, needs fig2-ab.eps
%% use Plain TeX; then process the ".dvi" output with dvipdfm
%% or compatible extension (such as dvipdfmx ?)
\output{\shipout\box255}
\noindent\null
\vfill
\hrule\vskip 408.6pt
\special
{PSfile=fig2-ab.eps llx=0 lly=0 urx=3609 ury=4076
rhi=4076}
\hrule\vfill
\eject
\end
%-------- cut
The wanted result is the one produced by dvipdf under linux.
This bug is only in my dvipdfm under linux so far.
The file "fig2-ab.eps" (a big b/w bitmap really) is available in
http://topo.math.u-psud.fr/~slc/dvipdfm_puzzle/fig2-ab_tst.zip
Robin, when your favorite macros integrate
fig2-ab.eps for dvipdfm, do they use/avoid
\special {PSfile=...} in the dvi file?
Do they succeed?
(Apologies for omitting "PSfile=" in my first posting.)
Cheers
Laurent
Heiko Oberdiek
> %% use Plain TeX; then process the ".dvi" output with dvipdfm
> \special
> {PSfile=fig2-ab.eps llx=0 lly=0 urx=3609 ury=4076
> rhi=4076}
> This bug is only in my dvipdfm under linux so far.
I only have an old version of dvipdfm (0.13.2c). Here
dvipdfm calls Ghostscript with option
-sPAPERSIZE=a0
But your image is larger, therefore you get clipping.
Dvipdfm has a configuration file where you can change
the Ghostscript call.
Or you can convert the EPS file to PDF using epstopdf
or "gs -dEPSCrop". Then include the PDF file. This
also saves time, because the conversion don't need
to be repeated each call of dvipdfm.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Robin Fairbairns
fwiw, loading your .eps into my ghostscript caused it to hang!
far, far, better (imo) to convert the original tiff to png, and use
that instead. (among other things, the .png file will be a lot
smaller than your .eps; pdf incorporates .png files rather
efficiently.)
--
Robin Fairbairns, Cambridge
Heiko Oberdiek
> fwiw, loading your .eps into my ghostscript caused it to hang!
AFPL Ghostscript 8.50 works fine here, although it takes some time
for loading the image and without options it also prints a warning:
*** Warning: Some of the BoundingBox for the EPS file will be clipped.
Use -dEPSCrop or -dEPSFitPage to avoid clipping.
Either option or a larger setting of PAPERSIZE help to display
the figure. Otherwise the empty lower left area is displayed.
Also ESP Ghostscript 7.07 with -dPAPERSIZE=a0 shows the left
part of the figure and doesn't hang.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Dan Luecking
wrote:
> pos...@topo.math.u-psud.fr (Laurent S.) writes:
>>Hi dvipdfm bitmap users,
>>
>> It appears I have encountered a bug in dvipdfm that
>>bites when a *big b/w bitmap* is included as an eps file
>>using say epsf.tex of Rokicki --- which uses specials like
>>
>>\special
>> {fig2-ab.eps llx=0 lly=0 urx=3609 ury=4076
>> rwi=2949.76936 rhi=3331.46576}
>
>what makes you imagine that dvipdfm uses dvips \specials unmodified?
>it may do, but i see no more than hints in the manual.
I asked some years ago why there were two dvipdfm.def's and what
was the difference. One was labeled "hand-edited" in the comments,
the other was generated by unpacking the latex graphics package.
Mark Wicks said something to the effect that the hand-edited one
was part of an attempt to converge toward the dvips syntax. That
file now includes:
\special{PSfile="#1"\space
llx=\Gin@llx\space
lly=\Gin@lly\space
urx=\Gin@urx\space
ury=\Gin@ury\space
\ifx\Gin@scalex\@tempa\else rwi=\number\dimen@\space\fi
\ifx\Gin@scaley\@tempa\else rhi=\number\@tempdima\space\fi
\ifGin@clip clip\fi}
which is definitely a dvips syntax, though not the one Laurent
showed in his post. This may have led to the assumption that dvips
specials can be used. Also the fact that they sometimes
"just work" with dvipdfm.
>if you want to use epsf, i suggest you need to make a modified version
>for your bitmaps, using \special{pdf:image ...} -- that takes image
>types jpg, png and pdf(?!).
>
>needless to say, the latex graphics bundle (available to eplain users,
>and to plain tex users who care to use it via the macros at ctan
>macros/plain/graphics) has a dvipdfm driver that will auto-detect
>which file type is being requested (under the "proper" circumstances).
One may need a hand-edited version of graphicx.tex (preferably
renamed) which sets the name of the driver to "dvipdfm" in place
of the hard-wired "dvips". I am not sure if eplain overcomes this
in its code.
The plain graphics package includes a file named miniltx.tex which
defines enough latex code to let graphicx.tex input graphicx.sty
and dvips.def. It used to cause a bit of trouble if one needed
pdftex.def, but code was added so that that now works. But it is
not clear if dvipdfm.def will necessarily work. Still, it is
what I would _start_ with.
If that doesn't work, I would almost certainly try conversion. Since
this is a bitmap eps, conversion to png or jpeg (depending on the
type of bitmap) seems best.
Dan
To reply by email, change LookInSig to luecking
*** Posted via a free Usenet account from http://www.teranews.com ***
Robin Fairbairns
>I asked some years ago why there were two dvipdfm.def's and what
>was the difference. One was labeled "hand-edited" in the comments,
>the other was generated by unpacking the latex graphics package.
the graphics package no longer provides a copy of dvipdfm, but that
version isn't in any linux distribution yet.
>Mark Wicks said something to the effect that the hand-edited one
>was part of an attempt to converge toward the dvips syntax. That
>file now includes:
> \special{PSfile="#1"\space
> llx=\Gin@llx\space
> lly=\Gin@lly\space
> urx=\Gin@urx\space
> ury=\Gin@ury\space
> \ifx\Gin@scalex\@tempa\else rwi=\number\dimen@\space\fi
> \ifx\Gin@scaley\@tempa\else rhi=\number\@tempdima\space\fi
> \ifGin@clip clip\fi}
>which is definitely a dvips syntax, though not the one Laurent
>showed in his post. This may have led to the assumption that dvips
>specials can be used. Also the fact that they sometimes
>"just work" with dvipdfm.
you think laurent looked at some ***latex*** code to ensure that epsf
would work? seems pretty improbably.
--
Robin Fairbairns, Cambridge
Laurent S.
*** Re: dvipdfm graphics problem
Hello Heiko,
Heiko> I only have an old version of dvipdfm
> (0.13.2c). Here dvipdfm calls Ghostscript
> with option
> -sPAPERSIZE=a0 But your image is larger,
> therefore you get clipping.
>
> Dvipdfm has a configuration file where you
> can change the Ghostscript call.
>
> Or you can convert the EPS file to PDF
> using epstopdf or "gs -dEPSCrop". Then
> include the PDF file. This also saves
> time, because the conversion don't need to
> be repeated each call of dvipdfm.
Heiko> AFPL Ghostscript 8.50 works fine here,
> although it takes some time for loading the
> image and without options it also prints a
> warning:
>
> *** Warning: Some of the BoundingBox for
> the EPS file will be clipped.
>
> Use -dEPSCrop or -dEPSFitPage to avoid
> clipping.
>
> Either option or a larger setting of
> PAPERSIZE help to display the figure.
> Otherwise the empty lower left area is
> displayed.
>
> Also ESP Ghostscript 7.07 with -dPAPERSIZE=a0
> shows the left part of the figure and doesn't
> hang.
Your diagnosis of the bug seems right to me. If gs
evolves the eps file to a buffer bitmap of fixed (say a0
size = 1189mm * 841mm) at the conventional resolution of
72 pixels per inch -- amputating the overflow over top
and right edges of that rectangle, Then, in the case of a
sufficiently big bitmap like my fig2-ab.eps example, one
expects to see an image clipped on the right and top
rectangle with the \sqrt 2 aspect ratio of the a-series
papersizes. And that is what I observe.
Since dvipdfm delegates the ".eps" ==> ".pdf" conversion
via a configuration file, we can hope that the fix will
consist in modifying that file in one of the three ways
you suggest above.
Could you guess where/how I should look for that
configuration file on an institutional linux machine with
the following implementations?
--- TeX, Version 3.14159 (Web2C 7.4.5) --- dvipdfm,
version 0.13.2c, Copyright (C) 1998, 1999 by Mark A.Wicks
--- GNU Ghostscript 7.07 (2003-05-17)
Copyright (C) 2003 artofcode LLC, Benicia, CA.
Thanks for your help!
Laurent S.
Sanjoy Mahajan
> Could you guess where/how I should look for that configuration file
> on an institutional linux machine
I use 'locate' in such circumstances:
$ locate dvipdfm
[produces hundreds of files from /home/sanjoy/admin/tex/dvipdfmx-20050831/,
from when I built dvipdfmx]
So restrict the search to /usr (or somehow exclude /home, perhaps with
grep -v):
$ locate '/usr*dvipdfm*'
/usr/bin/dvipdfm
/usr/share/doc/texmf/help/Catalogue/entries/dvipdfm.html
/usr/share/doc/texmf/help/faq/uktug-faq/FAQ-dvipdfmgraphics.html
/usr/share/doc/texmf/latex/pgf/version-for-dvipdfm
/usr/share/doc/texmf/latex/pgf/version-for-dvipdfm/en
/usr/share/doc/texmf/latex/pgf/version-for-dvipdfm/en/pgfmanual.tex
/usr/share/doc/texmf/latex/pgf/version-for-dvipdfm/en/Makefile
/usr/share/doc/texmf/latex/pgf/version-for-dvipdfm/pgfmanual-dvipdfm.cfg
/usr/share/doc/texmf/programs/dvipdfm.dvi.gz
/usr/share/doc/texmf/programs/dvipdfm.pdf.gz
/usr/share/man/man1/dvipdfm.1.gz
/usr/share/texmf/tex/generic/pgf/systemlayer/pgfsys-dvipdfm.def
/usr/share/tex-common/50dvipdfmx.cnf
/usr/share/rubber/rubber/rules/latex/dvipdfm.py
/usr/share/rubber/rubber/rules/latex/dvipdfm.pyo
/usr/share/rubber/rubber/rules/latex/dvipdfm.pyc
/usr/share/texmf-tetex/dvipdfm
/usr/share/texmf-tetex/dvipdfm/config
/usr/share/texmf-tetex/dvipdfm/config/README.config
/usr/share/texmf-tetex/dvipdfm/config/config
/usr/share/texmf-tetex/fonts/map/dvips/tetex/dvipdfm35.map
/usr/share/texmf-tetex/fonts/map/dvipdfm
/usr/share/texmf-tetex/fonts/map/dvipdfm/tetex
/usr/share/texmf-tetex/fonts/map/dvipdfm/tetex/cm-dvipdfm-fix.map
/usr/share/texmf-tetex/tex/latex/dvipdfm
/usr/share/texmf-tetex/tex/latex/dvipdfm/dvipdfm.def
/usr/share/texmf-tetex/tex/latex/hyperref/hdvipdfm.def
/usr/share/texmf-tetex/tex/latex/pict2e/p2e-dvipdfm.def
Ah, ha, some of the files look likely, especially
/usr/share/texmf-tetex/dvipdfm/config/config
If I'm feeling really lucky, or the list is too long, I do:
$ locate dvipdfm | egrep 'conf|cnf|cfg' | grep -v dvipdfmx | grep /usr
/usr/share/doc/texmf/latex/pgf/version-for-dvipdfm/pgfmanual-dvipdfm.cfg
/usr/share/texmf-tetex/dvipdfm/config
/usr/share/texmf-tetex/dvipdfm/config/README.config
/usr/share/texmf-tetex/dvipdfm/config/config
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
Dan Luecking
wrote:
> Dan Luecking <Look...@uark.edu> writes:
You know laurent better than I do.
But I didn't think that. I did't even say it. He _could_ have
observed the response from MW I mentioned above. He _could_ have
accidentally found out that it sometimes "just works". In fact,
after his correction, it seems he used a syntax that would normally
work.
Or he could have scoured many files (perhaps even dvipdfm.def)
for evidence. I will accept your estimate of that as "pretty
improbable", but it's something I might have done.
Laurent S.
*** Re: dvipdfm graphics problem
Hi dvipdfm users,
The bug I have been hunting is a system-specific dvipdfm
implementation bug -- of teTeX in my case -- rather than one
that concerns dvipdfm itself. I suspects it bites teTeX users of
dvipdfm for all sufficiently big eps objects.
Of the 3 suggested fixes the replacement of "-sPAPERSIZE=a0"
by "-dEPSCrop" is the only right one I believe.
Here is my revised "config" file for dvipdfm.
%%% ----------cut
% "config" file for dvipdfm, prepared for teTeX by Thomas Esser.
% For more info, read the dvipdfm manual (texdoc dvipdfm) and
% the original file which is provided as README.config.
% Distiller config. Uses ghostscript and works on compressed and
% uncompressed files.
% D "zcat -f %i | gs -q -sPAPERSIZE=a0 -sDEVICE=pdfwrite -dCompatibilityLevel=1.2 -dUseFlateCompression=true -dSAFER -sOutputFile=%o - -c quit"
%%%%%%%%%%%%%% begin bug comment
% Laurent S. & Heiko Oberdiek bugfix of May 2006 on comp.text.tex:
% Any fixed papersize as in above line will cause unwanted clipping of very big objects,
% so -- following a (version 8.50) gs log suggestion spotted by Heiko Oberdiek
% -- use "-dEPSCrop" instead of "-sPAPERSIZE=a0".
% The other gs suggestion "-dEPSFitPage" causes unwanted downscaling. Here is the revised line:
%%%%%%%%%%%%%% end bug comment
D "zcat -f %i | gs -q -sDEVICE=pdfwrite -dEPSCrop -dCompatibilityLevel=1.2 -dUseFlateCompression=true -dSAFER -sOutputFile=%o - -c quit"
% Set default paper size here
p letter
% The "g" option specifies the amount to "grow" annotations by
% Many TeX macro pages set the annotation bounding box equal
% to the TeX box that encloses the material. That's not always
% what you want
g 1
% PDF version stamp to use in output file and max version of files
% allowed to be included (2 for 1.2, 3 for 1.3)
V 2
% Font map files; maintained by updmap(1)
f dvipdfm.map
%%% ----------cut
On my institutional linux machine I can simply place the above
patched config file in the same directory as the dvi files for
processing by dvipdfm.
Here is my current TeX test file.
%%%%------cut
%%% fig2-ab_ptest.tex, needs fig2-ab.eps
%%% use Plain TeX; then process the ".dvi" output with dvipdfm
%% or compatible extension (such as dvipdfmx ?)
\output{\shipout\box255}
\noindent\null
\vfill
\hrule
\vskip 3pt
\hrule
\vbox to 407.6bp
{
\vfill
\hrule width \hsize
\vskip 3pt
\hrule
\vfill
}
\special
{PSfile=fig2-ab.eps llx=0 lly=0 urx=3609 ury=4076
rhi=4076}
\hrule
\vskip 3pt
\hrule
\vfill
\eject
\end
%%%%------cut
The complete example is posted at:
http://topo.math.u-psud.fr/~slc/dvipdfm_puzzle
My sincereest thanks to Heiko Oberdiek and Sanjoy Mahajan
for the key suggestions.
Which implementations of dvipdfm are affected by this bug?
Cheers,
Laurent S.
Heiko Oberdiek
> Of the 3 suggested fixes the replacement of "-sPAPERSIZE=a0"
> by "-dEPSCrop" is the only right one I believe.
> \special
> {PSfile=fig2-ab.eps llx=0 lly=0 urx=3609 ury=4076
> rhi=4076}
However, here I expect problems if llx \neq 0 or lly \neq 0.
Yours sincerely
Heiko <ober...@uni-freiburg.de>
Laurent S.
Heiko> However, here I expect problems if
> llx \neq 0 or lly \neq 0.
Yes. Bad news except for the common
case llx = 0 or lly = 0, which fortunately
is the only one I use.
A perl script could reduce to that case.
Perhaps dvipdfm support programmers would do
as much thereby protecting poor B.L.User
from such horrors.
Better ideas?
Other hiccups?
Laurent S.