JUN
29
2008

KDE with high DPI

As I mentioned in my previous blog entry, I'm working on making KDE and plasma behave better on systems that are quite different from 'normal' computers, specificaly small devices. As currently the only physical device I have access to for this project is a Neo1973 Openmoko phone, most of my initial work will be for that device.

In these images of plasma running on this device several problems are immediately visible, the most important being the somewhat large text that does not realy fit in the size reserved for it. This happens because default sizes of stuff in KDE is not all stored in the same unit; fonts have a default size specified in points (and thus should have the same physical size no matter the DPI of the screen KDE is running on), but lots of other things (most importantle widgets like scrollbars and the default panel size) have sizes specified in pixels. This doesn't cause any big problems when every user has more or less the same DPI, but one of the interesting things of this device is that it has a screen of approx. 280 DPI, which is a lot higher than many normal screens. At such a DPI the so called 'smallest readable font' of 8 points becomes a (quite large) 31 pixel font, which no longer really fits on a 38 pixel panel. After changing the default font sizes to somehwat smaller fonts (which I admit is not really a solution, but more a quick hack to make things look better on this one specific device) it already looks a lot more reasonable as you can see. A real solution would probably involve defining default sizes in some mix of points an pixels (while a 4 point font might be perfectly readable with good eyes on a 280DPI screen, it is impossible to read on a 72DPI screen, so having all default sizes strictly in points won't work), but I think some people would also not be very happy if for example the default panel size would be purely point-based, as chances are very low the actual resulting size would result in non-scaled icons, which apparently some people really want. I'm not sure what the perfect solution would be, but the current situation is far from perfect.

Some more screenshots of the current state: (with even kwin running on this device):

Comments

KDE should move towards using point-based measurements everywhere, rather than some weird hodgepodge combination of points and pixels.

The difference between readability on a 72DPI screen versus 280DPI screen is a good and valid point. Unfortunately though the reality is that no matter what unit of measurement you choose, you can't create default settings that will work everywhere.

After all, DPI and point sizes are only two variables in an altogether very complex issue. To create functional defaults across all devices you'd also have to take into account the distance between the display device and the user's eyes, stability of the display device, ambient lighting, etc, etc

So rather than searching for some magic formula of points, pixels and DPI, I'd suggest that KDE moves to a single, clearly defined real-world unit of measurement (such as the point).

Different device categories could then be addressed with separate default settings.


By jannu at Sun, 06/29/2008 - 21:40

Wasn't KDE4 supposed to have svg icons all the way, or did I miss something?


By jannu at Sun, 06/29/2008 - 21:45

I'm not convinced its the best solution, but I think it is certainly worth looking into;
Microsoft uses something they call "dialog units" if you google you will find the definition. The point is that if you know the actual size of the dialog (or, indeed, the whole device) you can make a metric to scale your fonts and other sizes to a more usable size.

In my mind just having a higher resolution (DPI) does not mean the fonts can be smaller. I'd like my newspaper of the future to still be readable in the bus. But the total size of the device determines how far from my face I will keep the device, and this in turn determines how big I want my fonts to be.

Anyway, just a thought ;)


By Thomas Zander at Sun, 06/29/2008 - 21:46

I case you're not on the x-org-list, there was/is a long
thread about resolution independence that might be of interest
to you:

Resolution indpendence


By bakterie at Mon, 06/30/2008 - 08:02

I like the CSS idea of "reference pixel"

Basically the reference pixel is the viewing angle of a pixel on a nominal monitor (96 dpi) at a nominal arms length (28") distance, and is what the CSS "px" value should be treated as (though a "px" value may be treated as a device pixel instead). The CSS specification only mentions printers as an example of where treating px as a device pixel is unsuitable, but I do think mobile phones would qualify.

So guestimating that you are reading a mobile phone at a distance of 9" (= 228.6 mm) that would make a reference pixel ~ 0.085 mm, which for a 280dpi device (Neo 1972 or FreeRunner) would be ~ 1.07 device pixels.

According to the CSS spec, the "pt" value is 1/72 of an inch (~ 0.35 mm), and should only be used if you know exactly what output medium (eg. screen, mobile phone or printed copy) is used. Unfortunately most people use "pt" for fonts even when they don't know the output medium. I'm not quite sure, but it's probably because that's the default in CSS, or becouse all DTP software and word processors works in pt.

Anyway, because pt generally has become the defacto standard for fonts in a px based environment, I would redefine the "pt" value based on the reference pixel, while giving an identical output on the nominal monitor. Thus a pt would be 96/72 px (~ 1.33 px), which on the Neo 1972 or FreeRunner would be 1.42 device pixels (~ 0.13 mm).

Thus my recommendation would thus be to either make Qt be reference pixel aware (which would require qt-config to allow you to change reading distance) and redefine pt according to above (or just hack it to make a px 1.07 device pixels and one pt to be 1.42 device pixels in the OpenMonko stack). That should make all Qt-based application, including plasma, to behave much nicer on mobile devices such as Neo 1972 or FreeRunner.


By jonno at Wed, 07/02/2008 - 12:53

Yes, some sort of angular size unit (i.e. a unit that accounts for both the real-world size of the UI element as well as the viewing distance) would be great. The only question is, where do you get the information necessary to define such a unit for all display devices.

DPI (and thus the real-world size of UI elements) is usually known, but the viewing distance isn't.

As far as I can see, the only practical solution to getting the viewing distance is to define certain display medium categories (e.g. paper, computer screen, handheld device, TV/projector, etc.) and questimate a reference value for each of them. This way the UI will behave the same way across all devices in a given category, thus giving you consistency and predictability.

But if you go with that approach, you might as well use pt units and define different default sizes for each of the categories (or one default pt size and category-specific scaling factors). And as an added bonus, you'd get to use a well-defined and well-understood measurement unit (which is IMHO a pretty important point, considering how fundamental a choice a measurement unit is).

P.S., for any web designers reading this, the Correct Way(tm) to define font and element sizes is to use em or percentage values only. That's because that is the only approach which will honour both the DPI value of the user's display device as well as the font size setting of the user's web browser. And as an added bonus, defining all element sizes (including images) in em:s or percentages means that the whole page scales with the fonts thus preserving your precious layout.


By jannu at Wed, 07/02/2008 - 13:38

Yup, the Qt/Embedded team hit this issue too - and proposed a similar solution. Don't use points or pixels - use radians:

http://tomcooksey.livejournal.com/662.html

In the mean time, we just "adjusted" the reported physical size of the screen so the effective DPI would be calculated to ~100.

BTW: Do you know of anyone working on porting KDE4 to Qt/Embedded?


By tomcooksey at Tue, 07/15/2008 - 12:45

Well, a 8pt (pt being 1/72 in, if we’re talking about PostScript measures) font is the same size regardless of the DPI — uses more pixels, but if you measure it with a ruler it should be (should be!) exactly as big as it was on a 72 DPI screen (PPI, if we’re really trying to split hairs). It’s a wholly different issue that you only have 480 pixels width (or however many) to use and therefore you have to specify font sizes that use less pixels :)

I think that what X does — getting PPI from the display’s resolution and physical size and setting that as the “DPI” of whatever gets displayed — is the least wrong thing to do on a screen. Lying to the world like Windows does (96 or 120 dpi forced) is kinda... odd.

A solution would be that display-oriented font sizes (such as those for the GUI), could be specified in pixels, rather than in points. It too doesn’t take into account the “visible size of a pixel on the screen” (i.e. the pixels physical size and the viewer’s distance), but you can’t really do that anyway. This way though, what’s specified to take 16 pixels for an em, will. Kinda the same effect as cheating with the DPI setting (as done according to your latest post), but at least when it comes to displaying things that “should” be displayed as big as they should be, it will be easy (since having the proper PPI/DPI setting ensures that a centimetre looks quite like a centimetre) — not that anyone would ever use a Maemo for desktop publishing :D

As an aside, what I’ve missed a few times already in many OSes and DEs is the possibility to specify non-integer point sizes.


By ralesk at Sat, 07/05/2008 - 01:43