On 12 May 2011 19:47, Bill Spitzak <spit...@gmail.com> wrote: > microcai wrote: > >> They can't care how big a windows is in the pixel, but in the inch. >> >> People should have different monitors with different DPI. Windows should >> stay same size regardless the DPI. >> >> Force DPI==96 on every monitor is a stupid idea, and we should avoid it >> on the protocol side. > > The reason this had to be done was due to the incredibly stupid idea that > only *fonts* are measured in points, and every other graphic is measured in > pixels. This strange idea was on both X and Windows, likely due to the > initial programs being terminal emulators where there was no graphics other > than text. What this really means is that there are two different coordinate > systems for all the graphics, and programmers just assumed these two systems > always lined up exactly like they did on their screen. > > After a lot of awful looking output on screens with different DPI, both
That's not really true. Of course, there are things that look awful in different DPI (or because you happen to have slightly different fonts than the author) because they were done by braindead people. This includes but is not limited to - many web sites - (some?) Adobe and HP software - OS X (which actually prevents changing the DPI in the first place leaving you with ridiculous font sizes) Note that very first UIs were virtually bitmap-free and all the WM buttons and borders were vector graphics or generated on the spot from a few user-specified parameters (Windows 3.1, old stuff like mwm, olwm, fvwm, ..) and could be scaled to any size you specified. Then bitmaps were used heavily and made their way to stuff like window borders because the level of complexity people desired for their eye-candy could not be done with simple vector graphics anymore, and complex vector graphics required more power than people were willing to sacrifice for window borders. Still GTK bitmap themes have provisions for scaling the bitmaps to suit any text sizes in window captions and buttons. The button border will be relatively thinner to the text size (or thicker for smaller text) but will still render as intended, and people are free to choose a different theme. Similarly in Windows you can set different border sizes or font sizes if you accept that tons of braindead software breaks (eg. Adobe CS or HP scanner dialogs). Also Windows bitmapped window buttons look terribly on non-default sized borders but vector buttons are still available. The web is a problem because due to the specs being how they are they are not really friendly to people conscious about the look of their sites and many effects can't be achieved in a portable way without setting the element sizes exactly in pixels. You can say it's a defect in the specs or an error on the side of the people who are trying to stretch them to make their sites look flashy at the expense of usability but it's totally offtopic here. > Windows and then X resorted to just forcing the DPI to 96, thus making the > systems obey the programmer's assumptions. Bad DPI settings are still a bug > on X, producing ridiculous large and tiny font sizes unexpectedly, and this > is NEVER wanted. > > The correct solution would have been to specify all coordinates in the same > units, likely 1 unit in the CTM. For practical reasons on current-day > screens this wants to be a pixel by default, but there is no reason a > program can't read the DPI and set the CTM to draw actual-size graphics. Well, they can't on systems where DPI is always forced to be 96 regardless of the actual screen physical properties. Also this is reportedly[1] done so that people don't get ridiculously small text on TVs but it is at the expense of getting ridiculously small DPI on most netbooks and high-end notebooks so this is not really a good tradeoff IMHO. Thanks Michal [1] https://bugs.freedesktop.org/show_bug.cgi?id=23705 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel