When I compile this code in xelatex
…
documentclass[letterpaper]{texMemo}
usepackage{graphicx}
usepackage{lipsum}
memoto{You}
memofrom{Me}
memodate{today}
memosubject{Some stuff}
logo{includegraphics[width=0.3textwidth]{/Dropbox/foo/bar/baz/my_cool_logo_file.png}}
begin{document}
maketitle
lipsum[1]
end{document}
I get errors about unable to load picture or PDF file
and package graphics Error: division by 0
. I did find this page, which looked promising, but it didn’t solve the problem. I also had a look at the grffile
package, but it didn’t seem to offer anything I could use. How should I fix this problem?
asked Aug 12, 2014 at 17:13
8
The unable to load picture or PDF file
error is a clue that something’s wrong, not on the TeX side but on the filesystem side. Possible causes include a corrupted image file, a permissions-protected image file, or a nonexistent image file. The division by 0
error is secondary to the first: TeX is trying to draw a box without having dimensions to form its corners.
If you can open and view the image with a previewer then it’s likely the problem is not with the file itself (or its permissions, since TeX is running as you). So I guessed the nonexistent file, i.e., bad file name. Knowing that Dropbox usually doesn’t mount at the top level of the file system was another clue that the path was wrong.
cfr’s check that this is the problem is worth repeating.
copy the image file to the working directory, delete the leading parts of the path from the filename in the source, and try compiling.
It’s another example of how simplifying the non-compiling document down to the barest bones can isolate the error.
answered Aug 19, 2014 at 14:54
Matthew LeingangMatthew Leingang
43.7k14 gold badges127 silver badges193 bronze badges
Apart from the excellent inputs by others, another possible issue could be with the filename.
The system photo viewer does not differentiate between Upper and Lower case extensions. That is to say, An image named as IMG.JPG
as well as IMG.jpg
can be opened by system Photo/Image viewer. However, in your .tex file, you should be careful.
includegraphics{IMG.JPG}
is different from includegraphics{IMG.jpg}
answered Mar 29, 2019 at 14:05
user408108user408108
3632 silver badges9 bronze badges
In my case, it was simply a tabular
in a resizebox
, with a missing end{tabular}%
.
Adding the missing end{tabular}
at the end of the resizebox
fixed it.
So, in case this helps anyone, first check that you do not have any missing end{...}
statement somewhere.
answered Jan 18, 2022 at 22:51
1
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
Closed
qwer1304 opened this issue
Oct 5, 2015
· 3 comments
Comments
Hi,
The following command (latest versions):
pandoc.exe -f html —latex-engine=xelatex.exe —verbose -f html -o mll.pdf ml.html > mll.log
On html file http://www.iro.umontreal.ca/~bengioy/dlbook/ml.html pandoc
failed with:
! Package graphics Error: Division by 0.
Tried to attach the log file as txt, log, docx and pdf, but the system wouldn’t let me.
Thanx for your help.
That works for me, amazingly, though the conversion is not perfect (as can only be expected; that HTML is absolutely awful, itself having been generated from a PDF). Check that you’re using the most recent Pandoc (1.15.1.1) and TeX Live 2015.
Thx.
I managed to convert to pdf w/o errors with the setup you’ve described.
Unfortunately, the pdf is not very good.
PS I managed to get a very good result with wkhtmltopdf and small hack of the source. See here.
Glad you managed something. If this particular problem is solved, would you mind closing the issue?
2 participants
fmw42 wrote:identify -verbose says
Image: wizard.jpg
Format: JPEG (Joint Photographic Experts Group JFIF format)
Mime type: image/jpeg
Class: DirectClass
Geometry: 265×352+0+0
Resolution: 118×118
Print size: 2.24576×2.98305
Units: PixelsPerCentimeter
Ummm… I’m not sure how this ‘wizard.jpg’ file now entered the discussion? The filenames I used where only these two (plus the built-in ‘wizard:’):
fmw42 wrote:Image: wiz-300densi.jpg
Format: JPEG (Joint Photographic Experts Group JFIF format)
Mime type: image/jpeg
Class: DirectClass
Geometry: 480×640+0+0
Resolution: 300×300
Print size: 1.6×2.13333
Units: UndefinedImage: wiz-standard.jpg
Format: JPEG (Joint Photographic Experts Group JFIF format)
Mime type: image/jpeg
Class: DirectClass
Geometry: 480×640+0+0
Units: UndefinedNote that for both output images, units get undefine from pixelspercentimeter, which is odd.
As I said: a ‘wizard.jpg’ with defined pixelspercentimeter is not mine and cannot be used as the basis of an argument… However, there are still some weird facts in this story. See my more detailed results further down.
fmw42 wrote:Also the image size (Geometry) gets changed.
No, it doesn’t! Because I never used ‘wizard.jpg’ in this context.
fmw42 wrote:That should not happen, in my opinion. So something is strange here or a bug.
It must be a misunderstanding, somehow. I always used (during these tests) the built-in ‘wizard:’ image as original.
fmw42 wrote:exiftool -s -ee -g1 -u -n -D wizard.jpg
shows— ImageWidth : 265
— ImageHeight : 352
2 ResolutionUnit : 2
3 XResolution : 118
5 YResolution : 118This matches IM
See above about ‘wizard.jpg’…
fmw42 wrote:exiftool -s -ee -g1 -u -n -D wiz-300densi.jpg
— ImageWidth : 480
— ImageHeight : 640
2 ResolutionUnit : 0
3 XResolution : 300
5 YResolution : 300This matches IM
Yes.
fmw42 wrote:exiftool -s -ee -g1 -u -n -D wiz-standard.jpg
shows— ImageWidth : 480
— ImageHeight : 640
2 ResolutionUnit : 1
3 XResolution : 1
5 YResolution : 1This does not match IM. IM identify -verbose is missing the Resolution and undefined units, which should be 0 in exiftool. So this may be where the issue comes from in addition to the size/geometry change.
It matches IM, yes. But please don’t compare to a ‘wizard.jpg’ and conclude a size/geometry change from it — see above about ‘wizard.jpg’…
fmw42 wrote:Perhaps wizard.jpg has erroneous values in it, especially with regard to the image size.
I believe IM convert or wizard.jpg has a bug/problem!
Sorry I do not have LaTex.
I created a table about the results of a series of
Code: Select all
'convert wizard: -density $Xx$Y wiz-$X-$Y.jpg'
with variations of values for X and Y.
But for preparation, I first looked up the JFIF documentation ( http://www.w3.org/Graphics/JPEG/jfif3.pdf ) and found on page 5 the description of these three fields in the header:
- At byte offset `0x0d` the «Units» field. This field has a 1 byte length. It can hold 3 values. The values describe *»Units of the X and Y densities»*.
- `0`, means: «no units, X and Y describe the pixel aspect ratios».
- `1`, means: «X and Y are dots per inch»;
- `2`, means: «X and Y are dots per cm».
- At byte offset `0x0e` the «XDensity» field. This field has 2 bytes length. It describes the «Horizontal pixel density».
- At byte offset `0x10` the «YDensity» field. Its length is 2 bytes. It describes the «Vertical pixel density».
Code: Select all
+---------------+---------+-----------------+---------------------+
| Byte-Offset | 0x0d | 0x0e | 0x10 |
+---------------+---------+-----------------+---------------------+
| Field-Name | "Units" | "XDensity" | "YDensity" |
+---------------+---------+-----------------+---------------------+
| Value/Meaning | 0 | "X and Y describe pixel aspect ratio" |
+---------------+---------+-----------------+---------------------+
| Value/Meaning | 1 | "X and Y are dots per inch" |
+---------------+---------+-----------------+---------------------+
| Value/Meaning | 1 | "X and Y are dots per cm" |
+---------------+---------+-----------------+---------------------+
My tests involved looking at the byte values with a hex editor too, not just relying on `identify -verbose` or `exiftool`. Additionally, I also employed `file` to see what this little tool reported.
So finally, here are the results of my ‘convert wizard: -density $Xx$Y wiz-$X-$Y.jpg’ commands with variations in X and Y values. Note, I also used «odd» and maybe «illegal» values like `000`, `0.2` and `1.5` instead of only «sane» integer numbers for the density (because even for basic testing, it can never be wrong to introduce some fuzzing as well):
These results seem to suggest first of all a potential improvement for the `identify` tool:
- Change the output reported for the «Units:» field.
- Instead of reporting «Undefined» if the JFIF field in fact contains a `0`, it should report something like «0 (means: X and Y Resolution values describe pixel aspect ratio)». See also what the `file` utility reports.
- However, even if developers are not willing to improve identify’s output here and change it: at the same time there is also a bug involved. Because *sometimes* this «Undefined» is wrong: whenever `file` reports «aspect ratio» (that is, the value of JFIF header field «Units» is either `1` {dots per inch} or `2` {dots per cm}).
Some of the other results are also remarkable:
- In every single case my hex editor double checking confirmed that Exiftool’s and `file`‘s reporting and of the values are correct.
- `identify` reported nothing for the «Resolution:» of the results from those `convert` commands where I had used `-density 0.2|0.5|0.8|1.2|000|001` to create the JPEG.
- `convert -density 0.2` created a JPEG where Exiftool and hex editor see a `0x0` resolution with the real meaning of «dots per inch»), while `convert -density 0|000` created a JPEG where the same value becomes `1×1`.
- `convert -density 000` created a JPEG where Exiftool see resolution unit «inches», but for `convert -density 000×000` Exiftool sees resolution unit «None»
You can download the script here:
- https://drive.google.com/file/d/0B-hdTU … sp=sharing
It is only ~60 lines of Bash code. In the tarball included are also the log files of the script (from which I extracted above table). So if you cannot to run it yourself (you may be on Windows), then you can still look at its results.
Heiko Selber
unread,
Jan 3, 1997, 11:00:00 AM1/3/97
to
Hello,
I think I discovered a bug in the graphicx package of LaTeX2e.
when I include a ps file using the graphics package I get an error message in
one case:
includegraphics[angle=270, height=30mm]{overview.ps}
gives me:
! Package graphics Error: Division by 0.
See the graphics package documentation for explanation.
Type H <return> for immediate help.
…
l.181 …phics [angle=270, height=30mm]{overview.ps}
Overfull hbox (403.04594pt too wide) in paragraph at lines 181—182
[][]
And then the ps file is included in its original size.
Every other combination of the keys, i. e.
[angle=270, width=30mm]
[width=30mm, angle=270]
[height=30mm, angle=270]
does what it should.
This applies for all angles between 180 and 270 degrees.
Angles between 0 and 90 degrees are treated correctly,
for angles between 90 and 180 and between 270 and 360 the scaling is wrong.
It seems like there is a division somewhere instead of a multiplication.
Any explanation?
Thanks,
Heiko
PS: I use LaTeX2e <1996/6/1> on a Linux (Debian 1.2) PC
——————————————————————————
Heiko Selber (Fritz-Haber-Institut Berlin) | Vs lbh pna ernq guvf |
http://www.fhi-berlin.mpg.de/~selber | lbh unir jnfgrq lbhe gvzr. |
email: sel…@fhi-berlin.mpg.de | (un un un) |
Phone:+49-30-8413-4574, Fax:+49-30-8413-4686 |____________________________|
Keith Reckdahl
unread,
Jan 3, 1997, 11:00:00 AM1/3/97
to
Heiko Selber <ipse…@sp.zrz.TU-Berlin.DE> wrote:
>I think I discovered a bug in the graphicx package of LaTeX2e.
>when I include a ps file using the graphics package I get an
>error message in one case:
> includegraphics[angle=270, height=30mm]{overview.ps}
>gives me:
> ! Package graphics Error: Division by 0.
> See the graphics package documentation for explanation.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is a feature, not a bug. In latex there is a big
difference between «height» and «totalheight». You
probably want «totalheight» instead.
This is documented in the graphics package documentation,
and the graphics bundle documentation (grfguide). It is
also is covered in
ftp://ftp.tex.ac.uk/tex-archive/info/epslatex.ps
Good luck,
Keith
Robin Fairbairns
unread,
Jan 3, 1997, 11:00:00 AM1/3/97
to
David Carlisle
unread,
Jan 6, 1997, 11:00:00 AM1/6/97
to Heiko Selber
> I think I discovered a bug in the graphicx package of LaTeX2e.
Please see the documentation of the totalheight key
David
Heiko Selber
unread,
Jan 6, 1997, 11:00:00 AM1/6/97
to
Robin Fairbairns (r…@cl.cam.ac.uk) wrote:
: In article <5aj9r4$t…@brachio.zrz.TU-Berlin.DE>,
: Heiko Selber <ipse…@sp.zrz.TU-Berlin.DE> wrote:
: >I think I discovered a bug in the graphicx package of LaTeX2e.
: Also in the updated version of grfguide.tex that went out in September
: which says
:
: item[totalheight]NEWfeature{1995/06/01}
Ah, my version of grfguide.tex is too old. I’ll talk to the debian package
maintainer.
It’s a pity that the height of an object is not its height (a bit
counterintuitive, isn’t it?).
Thanks,
Heiko
——————————————————————————
Heiko Selber (Fritz-Haber-Institut Berlin) | I condem’n the abuse |
http://www.fhi-berlin.mpg.de/~selber | of apostrophe’s. |
email: sel…@fhi-berlin.mpg.de | |
Robin Fairbairns
unread,
Jan 6, 1997, 11:00:00 AM1/6/97
to
In article <5aqmsh$k…@brachio.zrz.TU-Berlin.DE>,
I think they’re looking for a new one (I was approached when I first
asked the Debian guys around here about my first ever Debian install
recently — I thought I ought at least to get used to the system first
;-).
>It’s a pity that the height of an object is not its height (a bit
>counterintuitive, isn’t it?).
The height is the «height above the baseline». If you rotate the
object so that it’s entirely below the baseline, what would you expect
it to be?
I would claim that the name «totalheight» _is_ confusing: what it’s
actually talking about is «sum_of_height_and_depth». OTOH, I would
rather be expected to type «totalheight»…
David Carlisle
unread,
Jan 7, 1997, 11:00:00 AM1/7/97
to Heiko Selber
> It’s a pity that the height of an object is not its height (a bit
> counterintuitive, isn’t it?).
(La)TeX consistently measures `height’ from the baseline so `a’ and
`g’ have the same height (in most fonts) despite the fact that g has a
descender.
David
David Carlisle
unread,
Jan 8, 1997, 11:00:00 AM1/8/97
to
«> «(La)TeX consistently measures `height’ from the baseline so
> This is not perfectly true.
> In cases of minipages, it matters whether they end in
> a descenderless line or not.
It is true if you read it the right way (I think:-) What I meant to
imply was that LaTeX `height’ (ie TeX ht) relates to the height of
the box above the base line.
It is true that the `height’ of a minipage is affected in assorted
unpleasent ways if you end the box with hrule or a vertical space or
whatever, however the position of the baseline is also affected in the
same way, so I claim my statement is still true.
David
Jorg Knappen)
unread,
Jan 8, 1997, 11:00:00 AM1/8/97
to
This is not perfectly true. In cases of minipages, it matters whether they end in
a descenderless line or not. This can be easily demonstrated by usinge a
hrule after the minipage.
I have applied a special command unterlaenge in some work of mine, to
correct such situations.
—J»org Knappen.
«> «
«> «David
«> «