Version: (using KDE KDE 3.5.0) Installed from: Compiled From Sources Compiler: gcc version 3.3.4 -march=athlon-tbird -Os OS: Linux After nVidia buggered up latest driver that incorrectly set DPI Ref: http://www.nvnews.net/vbulletin/showthread.php?t=61189 I set my correct DPI up in X as per here: http://www.raydreams.com/docs/?f=dpi.html Everything is perfect at 80x80. I was then testing a few things here: http://members.ij.net/mrmazda/auth/dpi-screen-window.html Konq reports incorrect DPI. I mailed the authur, Felix, and he replied: "Depends on your Linux. Which are you on? It works for me unless I'm on some Debian. I've figured out how to force Firefox to obey by using gnome-control-center, but I'm trying to figure out why that's the only way that works there, while on SuSE, Fedora & Mandriva gcc is not necessary. On Xandros 3, my current investigation shows the FF UI obeys X's opinion of DPI if that opinion comes from fontconfig, but the FF viewport seems to obey nothing except the gcc setting if it exists, but stuck on xfs's 75 DPI otherwise (reporting 76 due to Gecko rounding error" He has a page to check this error: http://members.ij.net/mrmazda/tmp/dpi-broken.html On this, Konq fails badly: Undefined DPI Indicated DPI from document.getElementById("inches").offsetWidth It looks like Konq doesn't do what is asked. I do not know if this is by design or otherwise. Thanks, Nick P.S. to get your resolution DPI, run > xdpyinfo | grep -i dots
That's because the image hasn't loaded yet by the time the script is running
OK, so what is wrong - Konq for not loading the image first, or the web page code? It works on Epithany (but not on Konq or Firefox). Nick
http://members.ij.net/mrmazda/tmp/dpi-broken.html and http://members.ij.net/mrmazda/auth/dpi-screen-window.html use different scripts to get DPI. The latter is forced to run after the images the scripts depend on load, while the former is not, leaving it up to the browser to deal with on its own. In Konq 3.4.2 for me none of those scripts ever produce the expected results that Opera accurately does, and Firefox often botches.
OK, I got Firefox to work. In Preferences->Fonts there is a drop down box to select DPI. It was set to 96 (hence why I got 96 DPI!). Setting this to 'system' fixes FF. Using Kong just either reports 96DPI or 'undefined'. Nick
Konqueror always uses DPI as max(96, your X's DPI). In other words, if "xdpyinfo" reports a setting of less than 96 dpi, Konqueror will use that value. I don't agree with that behaviour, but it is used to fix broken websites that expect 96dpi.
Created attachment 13923 [details] screenshot - Konq 3.4.2 @ 168 DPI I see no apparent 96 DPI limit.
It appears Konq limits 96DPI if _under_ that. No way can I get a true DPI on those pages - but Felixs' other `size tests` pages with ruler all work true. Only the DPI detection pages reports incorrect DPI. Nick
Thiago, 96 DPI is _wrong_ as X doesn't set DPI to 96. It depends on drivers and all sorts. Microsoft set DPI to 96... but that isn't relevant here. IMHO it is bad to set a limit on a presumption. Nick
Nick: I know. That's why I disagree with the arbitrary limit the KHTML developers imposed. It is also known to cause problems -- for instance, Kopete's chat window uses KHTML on the top part to display the conversation, while the bottom part is a standard widgets. You may notice how the text is a lot larger on the top part, even if you set the same size in points.
Seems to be a dupe of bug 98583 ("KHTML assumes that vertical DPI is at least 96")
*** This bug has been marked as a duplicate of 98583 ***