Le Jeu 4 janvier 2007 16:17, Adam Jackson a écrit : > You are conflating two different things. > > The "DPI" setting used by Gnome for font sizing is a lie. It has no > actual relation to dots per inch of monitor. The naming is unfortunate, > but every time I ask Gnome people about it, the answer is "oh but people > expect it to be called DPI", which is crap, but oh well. > > It is, in effect, a scale factor passed to Freetype when rendering. That would be great if it was true ; unfortunately that's not a scaling factor but an absolute value, so you get widely different effects depending on the physical pixel density of the screen. This is made clear by the following facts : - no GNOME setup app allows setting Xorg displaysize when it's detected wrong, GNOME dpi is used as an override. If they were actually separate in GNOME people mind they would need separate setting - OLPC has to dynamically adjust GNOME dpi when screen mode switches (but the scaling preferences of the user didn't change!) - as you noted most screens currently on the market actually have a physical dpi value close to the GNOME default *when used at the ideal resolution* - GNOME forces 96 independently of the actual screen resolution, which sort of hides the problem if the user is lucky enough to have a ~96dpi screen. - users spend their time tweaking GNOME dpi when changing hardware, even though their font scaling preferences didn't change. This is a disaster for nfs homes. The "scaling factor" is the excuse GNOME people have found to avoid fixing this. "it's not a real value" => "we don't have to compute it correctly" (its root is in the W3C virtual pixel=angle of view idea. But if you want to pretend you're using virtual pixels, you have to use them both for text and images. We all know GNOME uses actual hardware pixels not angles of view for image sizing) All the feedback I got on the subject before GNOME switched to denial mode was that the "dpi" setting was initially developped as a bandaid because : - xorg displaysize detection is not flawless (esp. then), and was resulting in problems for anaconda, firstboot and gdm (before xorg setup apps are run) - fixing it at the xorg level requires writing xorg.conf as root, writing a gconf key as normal user was easier - when running at suboptimal resolution effective physical dpi is too low to allow correct text rendering - font hinting is optimized for 96dpi, so if you have a close-to-96 hardware dpi pretending to be 96 helps a little Someone then noted setting the wrong dpi value in this gconf key had a scaling side-effect and the bandaid was promoted to inspired feature. Despite the fact it falls appart as soon as the user has a screen with > 100dpi physical density (OLPC...), commutes between screens with different densities (nfs homes, OLPC), uses a mix of GNOME (that use this setting) and non-GNOME (that use xorg dpi) apps, etc Renaming the GNOME key won't fix anything -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
