Summary: | Konq reports incorrect DPI | ||
---|---|---|---|
Product: | [Applications] konqueror | Reporter: | Nick Warne <nick> |
Component: | khtml | Assignee: | Konqueror Developers <konq-bugs> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | mrmazda |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | screenshot - Konq 3.4.2 @ 168 DPI |
Description
Nick Warne
2005-12-13 22:38:15 UTC
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 *** |