dvipng
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: jfbu
Subject: Re: [Dvipng] does dvipng include the dpi information in its output?
Date: Mon, 15 Oct 2012 14:23:27 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc13 Thunderbird/3.1.10

le 15/10/2012 12:59 selon Jan-Åke Larsson:
> jfbu skrev 10/15/2012 08:56 AM:
>> 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!
> 


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!

> 
>> 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. From what I can gather (use the source, Luke!) the
> currently alpha version 2.1.0 of libgd will support this. I will make
> sure that dvipng uses this too, if I only can figure out how to enable
> it. libgd.org is currently down, so I don't have easily accessible docs
> just now (on my lunch hour).
> 

dear Jan-Åke I am very grateful to your willingness to look into
this, but do take your (deserved) time!

>> 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)
> 
> I'd expect that. But not quite as good, and not nearly as fast. :)


I am a big fan of dvipng! Thanks a lot! 
> /JÅ

PS: maybe the reason why AUCTeX/Preview displays images in my
emacs buffer on my 135dpi macbook which do not fit with the
surrounding text is to be found into these murky waters of
having png files with no indication of the real physical size?

best wishes, thanks again
Jean-François




reply via email to

[Prev in Thread] Current Thread [Next in Thread]