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 _______________________________________________ Dvipng mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/dvipng
