I have been looking at a user's problems with \includegraphics and it
turned out that the image had a Print Size setting of 12827.0 × 12700.0
millimeters, clearly well beyond TeX's 19ft. Easily fixed in GIMP or
similar, but the problem was that the error is not reported in a way
that would lead the regular user to see the problem:

\documentclass{article}
\usepackage{fontspec,graphicx}
\begin{document}
\includegraphics{filename.jpg}
\end{document}

gives

> ! Dimension too large.
> <argument> \wd \@tempboxa
>
> l.4 \includegraphics{filename.jpg}
>
> Overfull \hbox (16053.9603pt too wide) in paragraph at lines 4--5

It is of course perfectly correct, but when the user checks the
conventional dimensions, they are not in any remote way excessive.

> $ identify filename.jpg
> filename.jpg JPEG 370x500 370x500+0+0 8-bit sRGB 90937B 0.000u 0:00.000

Should graphicx report the fact that it is using Print Size at some
stage, rather than the pixel dimensions that the user is expecting. I'm
not willing to disrupt the work of the graphics bundle team with a
deficiency report unless people think this really is a deficiency.

(And additionally, ImageMagick's 'identify' utility misreports the Print
Size values, which doesn't help :-) GIMP gets them right.

Peter

Le 25/07/2021 à 22:10, Peter Flynn a écrit :
> I have been looking at a user's problems with \includegraphics and it
> turned out that the image had a Print Size setting of 12827.0 × 12700.0
> millimeters, clearly well beyond TeX's 19ft.

For me, the defiency comes from the tool which product such an image
and/or from the user who asks for such an image!

> Easily fixed in GIMP or
> similar, but the problem was that the error is not reported in a way
> that would lead the regular user to see the problem:
>
> \documentclass{article}
> \usepackage{fontspec,graphicx}
> \begin{document}
> \includegraphics{filename.jpg}
> \end{document}
>
> gives
>
>> ! Dimension too large.
>> <argument> \wd \@tempboxa l.4 \includegraphics{filename.jpg}
>> Overfull \hbox (16053.9603pt too wide) in paragraph at lines 4--5
>
> It is of course perfectly correct, but when the user checks the
> conventional dimensions, they are not in any remote way excessive.

16053.9603pt is far beyond a conventional dimensions. Its roudly
equal to 5 meters!

>> $ identify filename.jpg
>> filename.jpg JPEG 370x500 370x500+0+0 8-bit sRGB 90937B 0.000u 0:00.000
>
> Should graphicx report the fact that it is using Print Size at some
> stage, rather than the pixel dimensions that the user is expecting. I'm
> not willing to disrupt the work of the graphics bundle team with a
> deficiency report unless people think this really is a deficiency.
>
> (And additionally, ImageMagick's 'identify' utility misreports the Print
> Size values, which doesn't help :-) GIMP gets them right.

Over the course of my 25 years of (La)TeX, I never encounter a dimen
problem with this outrageous size :-) imho it's not the rôle of graphicx
to inform the user that its image is too large for TeX.

Jean-Côme Charpentier

On 25/07/2021 22:18, Jean-Côme Charpentier wrote:
> Le 25/07/2021 à 22:10, Peter Flynn a écrit :
>> I have been looking at a user's problems with \includegraphics and it
>> turned out that the image had a Print Size setting of 12827.0 ×
>> 12700.0 millimeters, clearly well beyond TeX's 19ft.
>
>   For me, the defiency comes from the tool which product such an image
> and/or from the user who asks for such an image!

The user does not know the origin of the image file. It's possible the
setting was made by someone for a different purpose, rather than being
set arbitrarily by some software.

>   Over the course of my 25 years of (La)TeX, I never encounter a dimen
> problem with this outrageous size :-)

Me neither, although I have used LaTeX for posters where the image size
was in excess of ~10ft (3m).

> imho it's not the rôle of graphicx
> to inform the user that its image is too large for TeX.

I disagree. And in this case, the image is NOT too large for TeX (370px
× 500px), it's the bogus Print Size which LaTeX clearly used, and should
have said so. I think graphicx should report on occasions when the size
is too big; but MUCH more importantly, it should obey the optional
parameters, eg width=x,height=y,keepaspectratio and create a condition
which causes TeX to throw an avoidable error.

Peter

On 26.07.21 15:13, Peter Flynn wrote:
> On 25/07/2021 22:18, Jean-Côme Charpentier wrote:
>> Le 25/07/2021 à 22:10, Peter Flynn a écrit :
>>> I have been looking at a user's problems with \includegraphics and it
>>> turned out that the image had a Print Size setting of 12827.0 ×
>>> 12700.0 millimeters, clearly well beyond TeX's 19ft.
>>
>>    For me, the defiency comes from the tool which product such an
>> image and/or from the user who asks for such an image!
>
> The user does not know the origin of the image file. It's possible the
> setting was made by someone for a different purpose, rather than being
> set arbitrarily by some software.
>
>>    Over the course of my 25 years of (La)TeX, I never encounter a
>> dimen problem with this outrageous size :-)
>
> Me neither, although I have used LaTeX for posters where the image size
> was in excess of ~10ft (3m).
>
>> imho it's not the rôle of graphicx to inform the user that its image
>> is too large for TeX.
>
> I disagree. And in this case, the image is NOT too large for TeX (370px
> × 500px), it's the bogus Print Size which LaTeX clearly used, and should
> have said so. I think graphicx should report on occasions when the size
> is too big; but MUCH more importantly, it should obey the optional
> parameters, eg width=x,height=y,keepaspectratio and create a condition
> which causes TeX to throw an avoidable error.

I agree with your disagreement ;-)
As a user I would like useful error messages that help me understand
what the problem is. so that I can fix it. If graphicx where to tell me:
"Your image is waaaay too big", then I would know what to fix.

Sometimes (La)TeX errors are indeed very cryptic.

Andreas

On 26/07/2021 14:29, Andrea Croci wrote:
[...]> As a user I would like useful error messages that help me understand
> what the problem is. so that I can fix it. If graphicx where to
> tell me: "Your image is waaaay too big", then I would know what to
> fix.

Best of all would be "Image size 320px × 450px is being used because
Print Size of 10.7m × 22.4m is too big for graphicx"

Peter

Hello,

is there a test image file available somewhere?

I'm not involved in graphicx development, but my bmpp program converts
PNG/JPEG/NetPBM/TIFF to EPS and PDF, intended for use with (pdf)LaTeX.
I did not know about the 19ft limit for graphics in LaTeX before, so
it's probably a good idea to make bmpp issue a warning if output is too
large for use with LaTeX. And a hint to override resolution manually.

Where can I find a documentation for the 19ft limit?

Best regards,

Dirk

--
Dirk Krause

On 27/07/2021 13:47, Dirk Krause wrote:
> Hello,
>
> is there a test image file available somewhere?

I will ask the original user.

> I'm not involved in graphicx development, but my bmpp program converts
> PNG/JPEG/NetPBM/TIFF to EPS and PDF, intended for use with (pdf)LaTeX.
> I did not know about the 19ft limit for graphics in LaTeX before, so
> it's probably a good idea to make bmpp issue a warning if output is too
> large for use with LaTeX. And a hint to override resolution manually.

The resolution is not the problem, nor the pixel size of the image. It's
the setting labelled "Print Size" in the Image Properties panel in GIMP
was displaying 9398.0 × 12700.0 millimeters when the actual pixel size
of the image was only 370×500px.

LaTeX (well, TeX) has its own warning for an overlong line or overwide
page, so no changes are needed. My suggestion was merely to warn the
user if graphicx used the Print Size values and caused an arithmetic
problem.

> Where can I find a documentation for the 19ft limit?

Any decent book or web site dealing with TeX's dimensions.

The canonical reference is Knuth's _The TeXbook_, Chapter 10
(Dimensions), p.58, last paragraph:

"TeX will not deal with dimensions whose absolute value is 2^{30} sp or
more. In other words, the maximum legal dimension is slightly less than
16384pt. This is a distance of about 18.892 feet (5.7583 meters), so it
won't cramp your style."

Peter

Peter Flynn wrote:
> It's
> the setting labelled "Print Size" in the Image Properties panel in GIMP
> was displaying 9398.0 × 12700.0 millimeters when the actual pixel size
> of the image was only 370×500px.

As far as I understand that's not the setting but calculated from it.
What is actually coded are the "dots per inch". Your example works out
as exactly 1, which is a not unreasonable value for "don't know". That
property can only be defined for paper and is meaningless for e.g.
photographs. Most cameras use an aritrary value of something like 72
here.

But then I often encounter images with no entry whatever for that
variable. LaTeX works fine with those, probably falling back to an
internal default.

--
/¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --

On 27/07/2021 13:47, Dirk Krause wrote:
> Hello,
>
> is there a test image file available somewhere?

He said I can send you the image, so if you could email me your address
off-group I'll send it on.

Peter

On 27/07/2021 22:44, Axel Berger wrote:
> Peter Flynn wrote:
>> It's
>> the setting labelled "Print Size" in the Image Properties panel in GIMP
>> was displaying 9398.0 x 12700.0 millimeters when the actual pixel size
>> of the image was only 370x500px.
>
> As far as I understand that's not the setting but calculated from it.
> What is actually coded are the "dots per inch".

So what you are saying is that its calculated it as 370" x 500", based
on a default value of 1dpi? That fits the data.

> Your example works out
> as exactly 1, which is a not unreasonable value for "don't know".

1dpi is possibly the silliest default value I have ever heard of :-)

> That
> property can only be defined for paper and is meaningless for e.g.
> photographs. Most cameras use an aritrary value of something like 72
> here.

This was a very old picture, scanned possibly a very long time ago, so
it is entirely possible that some ancient softare did this.

Thank you for the information. I need to correct my suggestion to
reflect a bogus dpi value rather than bogus Print Size values.
Unfortunately there is nothing in (eg) identify -verbose to suggest a
DPI of 1, so I'm not sure how it could be identified programmatically.

Peter

> The canonical reference is Knuth's _The TeXbook_, Chapter 10
> (Dimensions), p.58, last paragraph:
>
> "TeX will not deal with dimensions whose absolute value is 2^{30} sp or
> more. In other words, the maximum legal dimension is slightly less than
> 16384pt. This is a distance of about 18.892 feet (5.7583 meters), so it
> won't cramp your style."
>
> Peter

Hello Peter,
thanks for pointing me to the book.
Best Regards,

Dirk

--
Dirk Krause

Am 28.07.21 um 00:32 schrieb Peter Flynn:
> On 27/07/2021 13:47, Dirk Krause wrote:
>> Hello,
>>
>> is there a test image file available somewhere?
>
> He said I can send you the image, so if you could email me your address
> off-group I'll send it on.
>
> Peter

Hello,
thanks for the image.
I modified the bmpp and wxbmpp programs in my dktools package (see below).
For bitmaps resulting in (E)PS or PDF files too large for LaTeX
both programs automatically correct the resolution value to decrease
image size.
Best regards,

Dirk

--
Dirk Krause
http://sourceforge.net/p/dktools/wiki/Home/
http://sourceforge.net/p/gxhints/wiki/Home/
http://sourceforge.net/p/octpgfpl/wiki/Home/

Hello,
In the dktools package I renamed the bmpp program to bitmap2pp to have a
more speaking name and to meet the Debian packaging guidelines which
require a name length of at least 5 characters for new programs to package.
Regards,

Dirk

--
Dirk Krause
http://sourceforge.net/p/dktools/wiki/Home/
http://sourceforge.net/p/gxhints/wiki/Home/
http://sourceforge.net/p/octpgfpl/wiki/Home/