[Dvipng] does dvipng include the dpi information in its output?

[jfbu]

I am using dvipng from the TeX Live 2012 distribution,

This is dvipng 1.14 Copyright 2002-2010 Jan-Ake Larsson

on a mac os x 10.8.2

The installed gs is GPL Ghostscript 9.05 (2012-02-08)

When I use dvipng, the produced images are at 96dpi.

However when I open them in Preview.app (Mac OS X) it tells
me they are at 72dpi.

If instead I do dvipng -D144 for example, then again Preview.app
tells me that the image(s) are at 72dpi.

Hence if I ask preview to display at 100% (with the option,
«natural size as will be printed», I don't know the English version)
the displayed image doubles in size, because the number of
pixels per inch is doubled in each direction.

It is only with dvipng -D72 that the produced image, when
viewed in Preview at its "real size" is indeed on screen with
the dimensions of the original dvi (or cropped dvi, because I use
the -Ttight option, but I tried with and without)

It is as if the png file was missing the "real" dimensions
information, so Preview just applies its default setting of 72dpi
having as its disposal solely the number of pixels information.

I looked through the documentation and found no hint.

I must be missing the obvious or perhaps this is a problem with Preview?

If I use gs on a pdf files, the behavior is absolutely coherent. The
-r option of gs does influence the dots per inch, and this info is
correctly displayed in Preview. The natural size of the image remains
invariant but its number of pixels per inch changes.

But with dvipng I get the behavior I have described: the natural size
rather than remaining invariant changes with the setting of the -D
option.

Any help?

Jean-Francois

[Jan-Åke Larsson]

Post by jfbu
But with dvipng I get the behavior I have described: the natural size
rather than remaining invariant changes with the setting of the -D
option.

Yes, this is what I would suspect. dvipng uses the Graphics Draw library
(libgd), and there was no way to include this kind of information in a
saved PNG back when I wrote dvipng. Perhaps there is now, I'll need to
check.

The -D switch does select the resolution in "natural" units, relative to
the TeX dimensions, so it would be the correct thing to do.

/JÅ

[jfbu]

Post by jfbu
But with dvipng I get the behavior I have described: the natural size
rather than remaining invariant changes with the setting of the -D
option.

Yes, this is what I would suspect. dvipng uses the Graphics Draw library (libgd), and there was no way to include this kind of information in a saved PNG back when I wrote dvipng. Perhaps there is now, I'll need to check.
The -D switch does select the resolution in "natural" units, relative to the TeX dimensions, so it would be the correct thing to do.
/JÅ

Thanks for your reply: the png images I produced were for
inclusion in a web page and as far as I could determine firefox
displays the png images with the correspondence 1 image pixel
equals 1 screen pixel, thus does not take into account the
(possible) information of the real dpi used in the image.
Hence it is the number of pixels in the image which decides
of its size on screen. By experiments I understood that to
produce with gs some images (from pdf) that would display in
a coherent manner in firefox alongside the images obtained
via dvipng, I add to use gs -r96, or equivalent, to get 96dpi.
If I use another dpi the size in firefox changes accordingly.
I went through a confusing stage because Preview.app confirmed
that the gs produced images were at 96dpi, but kept telling
me that the older dvipng images had been at 72dpi. In fact these images
were also at 96dpi but that information is either not in the file
or not understood by Preview.

gs has a useful option -dDownScaleFactor so that for example
gs -r480 -dDownScaleFactor=5
produces images at 96dpi that are internally treated at 480dpi
hence the final result is far better than with gs -r96.
(I am talking about images containing only text and math formulas)

The quality and the number of kilobytes
is then about comparable to the quality and size of the dvipng
produced images, in my experiments, (I did not try to see if 4 or 6
were better than 5)

thanks again, best wishes
Jean-François

[Jan-Åke Larsson]

Post by jfbu
Thanks for your reply: the png images I produced were for
inclusion in a web page and as far as I could determine firefox
displays the png images with the correspondence 1 image pixel
equals 1 screen pixel, thus does not take into account the
(possible) information of the real dpi used in the image.
Hence it is the number of pixels in the image which decides
of its size on screen.

You *have* read the documentation that comes with dvipng, no? It reads:

‘-D num’

Set the output resolution, both horizontal and vertical, to num dpi
(dots per inch).
One may want to adjust this to fit a certain text font size (e.g.,
on a web page), and for a text font height of font_px pixels (in
Mozilla) the correct formula is

dpi = font_px * 72.27 / 10 [px * TeXpt/in / TeXpt]

The last division by ten is due to the standard font height 10pt in
your document, if you use 12pt, divide by 12. Unfortunately, some
proprietary browsers have font height in pt (points), not pixels. You
have to rescale that to pixels, using the screen resolution (default is
usually 96 dpi) which means the formula is

font_px = font_pt * 96 / 72 [pt * px/in / (pt/in)]

On some high-res screens, the value is instead 120 dpi. Good luck!

Post by jfbu
By experiments I understood that to
produce with gs some images (from pdf) that would display in
a coherent manner in firefox alongside the images obtained
via dvipng, I add to use gs -r96, or equivalent, to get 96dpi.
If I use another dpi the size in firefox changes accordingly.
I went through a confusing stage because Preview.app confirmed
that the gs produced images were at 96dpi, but kept telling
me that the older dvipng images had been at 72dpi. In fact these images
were also at 96dpi but that information is either not in the file
or not understood by Preview.

Not in the file.

[jfbu]

Post by Jan-Åke Larsson

Post by jfbu
Thanks for your reply: the png images I produced were for
inclusion in a web page and as far as I could determine firefox
displays the png images with the correspondence 1 image pixel
equals 1 screen pixel, thus does not take into account the
(possible) information of the real dpi used in the image.
Hence it is the number of pixels in the image which decides
of its size on screen.

‘-D num’
Set the output resolution, both horizontal and vertical, to num dpi
(dots per inch).
One may want to adjust this to fit a certain text font size (e.g.,
on a web page), and for a text font height of font_px pixels (in
Mozilla) the correct formula is
dpi = font_px * 72.27 / 10 [px * TeXpt/in / TeXpt]
The last division by ten is due to the standard font height 10pt in
your document, if you use 12pt, divide by 12. Unfortunately, some
proprietary browsers have font height in pt (points), not pixels. You
have to rescale that to pixels, using the screen resolution (default is
usually 96 dpi) which means the formula is
font_px = font_pt * 96 / 72 [pt * px/in / (pt/in)]
On some high-res screens, the value is instead 120 dpi. Good luck!

well yes I had read it! but to say I understood would be daring.

for example, how could I imagine what must be the obvious certainly
to anyone involved in web design,
that browsers would use pixels so
that if your device has say a res of 135dpi then everything (text and
images) is almost twice smaller than on an 72dpi screen!

one could imagine another world where the browser queries the OS
about the device resolution and takes it into account...

[for example in Adobe Acrobat, there is such a setting, where you
can either use or by-pass the device resolution]

but no, because at some point the industry decided that graphics elements
on a computer screen were counted in pixels, so for example on
my 135dpi macbook the physical appearance of everything, the icons,
the borders of the windows, the size of text in menus, everything
is physically smaller than on a 96dpi device. I am indeed old enough
to have designed pixel by pixel some 8x8 icon on a Mac SE!

but now that computers are powerful enough for everything to be
potentially given in outlines, if I forget about my old age
and wake up today, I could imagine that all elements of the GUI
could be done in scalable outlines, so that each device to
display them at a given absolute size, and working on a 135dpi
device would just mean having a smoother GUI, but of the *same*
size.

if a pt (as in your text above) is indeed the absolute measure
1/72.27 of an inch then I am more on the side of browsers who
use points rather than pixels! if that means that they take
into accoung the device dpi in order to display a 12pt font
as really a 12 true points on screen, with whatever pixels
this requires!

Post by Jan-Åke Larsson

Post by jfbu
By experiments I understood that to
produce with gs some images (from pdf) that would display in
a coherent manner in firefox alongside the images obtained
via dvipng, I add to use gs -r96, or equivalent, to get 96dpi.
If I use another dpi the size in firefox changes accordingly.
I went through a confusing stage because Preview.app confirmed
that the gs produced images were at 96dpi, but kept telling
me that the older dvipng images had been at 72dpi. In fact these images
were also at 96dpi but that information is either not in the file
or not understood by Preview.

Not in the file.

[Marc Culler]

Post by jfbu
if a pt (as in your text above) is indeed the absolute measure
1/72.27 of an inch then I am more on the side of browsers who
use points rather than pixels! if that means that they take
into accoung the device dpi in order to display a 12pt font
as really a 12 true points on screen, with whatever pixels
this requires!

If only it were that simple. For *typesetting* a point is 1/72.27
inches, but on the web a point is defined by the CSS specification
to be 1/72 inches. To convert points to pixels, according to CSS,
a browser is supposed to assume that the size of a pixel is equal
to the size of a "reference pixel". The definition of a
reference pixel is

"The reference pixel is the visual angle of one pixel on a device
with a pixel density of 96dpi and a distance from the reader of an
arm's length. For a nominal arm's length of 28 inches, the visual
angle is therefore about 0.0213 degrees. For reading at arm's
length, 1px thus corresponds to about 0.26 mm (1/96 inch)."

[ http://www.w3.org/TR/css3-values/#absolute-lengths ]

But of course the size of a reference pixel is configurable by the
user. The Ctrl-+ and Ctrl-- keys change the size of a reference
pixel, and the ability to do that is a key component of web
accessibility. The bottom line is that browsers can display 12 point
type at pretty much any size. Certainly, as a web designer, you
cannot assume anything about the size at which a 12 point font will
be rendered on a screen.

- Marc

[Jan-Åke Larsson]

Post by Marc Culler
But of course the size of a reference pixel is configurable by the
user. The Ctrl-+ and Ctrl-- keys change the size of a reference
pixel, and the ability to do that is a key component of web
accessibility. The bottom line is that browsers can display 12 point
type at pretty much any size. Certainly, as a web designer, you
cannot assume anything about the size at which a 12 point font will
be rendered on a screen.

Exactly. And if you ask nicely (say in javascript) what size is used by
the browser, mozilla answers in pixels, while IE answers in screen
points. To convert that to pixels, you need to ask IE again what the
screen dpi is. If you're really really lucky you will get an accurate
answer (and not some irrelevant default).

You need to load different images for different sizes used by the browser.

Now all you have to handle is the vertical alignment. Last I looked this
was different in IE, mozilla and probably opera and safari... It was
also broken, in different ways in different versions of the browsers.
There is a good reason for the wish for good luck in the manual.

Have you looked at mathjax?
/JÅ

[jfbu]

Post by Marc Culler
"The reference pixel is the visual angle of one pixel on a device
with a pixel density of 96dpi and a distance from the reader of an
arm's length. For a nominal arm's length of 28 inches, the visual
angle is therefore about 0.0213 degrees. For reading at arm's
length, 1px thus corresponds to about 0.26 mm (1/96 inch)."
[ http://www.w3.org/TR/css3-values/#absolute-lengths ]

So a pixel is a solid angle, what a completely abysmal definition!

my computer tells me its screen has W times H pixels and these
are not solid angles!

http://en.wikipedia.org/wiki/Display_resolution

... hard for me to understand the motivations behind that
amazing CSS3 definition!

thanks for the info! this opens the veil for me on the
wild world of web design; which after all is know dominated
by money and not by the spirit of the metric system from
the French Revolution!

best regards,

Jean-François

[jfbu]

Post by Jan-Åke Larsson

Post by jfbu
me that the older dvipng images had been at 72dpi. In fact these images

Post by jfbu
were also at 96dpi but that information is either not in the file
or not understood by Preview.

Not in the file.

[jfbu]

Post by jfbu
In fact these images
were also at 96dpi but that information is either not in the file
or not understood by Preview.

just for the sake of precision, now that I re-look more precisely
at these images
were produced by dvipng at rather something like 100dpi, not 96dpi


(498 pixels in width for some tight image of text produced with
\usepackage[hscale=0.6,a4paper]{geometry} so that the actual
width is circa 12,6cm. 498 pixels =12,6cm iff 100,4 pixels =1 in,
and I checked with images as displayed in firefox, physically
measuring their sizes and comparing to their number of pixels
with due account of the screen resolution)

and about an app querying the system

1) on my macbook air, Acrobat says that the system resolution is at 133dpi
whereas it is more like 135,5 dpi [confirmed with actually measuring on
the screen that a a4 page has truly 21cm of width]

2) on a Dell ultrasharp display at my office on a Fedora 13 linux,
Acrobat says that the system resolution is at 97dpi whereas physically
measuring it I obtain 86dpi [and again this is then confirmed by
displaying at its natural size an a4 page in Acrobat, and also I
checked on images displayed in firefox]


best wishes
Jean-François