Point sizes: are they reliable?
-
Does anyone with experience across multiple devices know how reliable physical measurements are? I'd like to know if someone with experience has encountered devices where using a point size doesn't work as expected, and if we can safely ignore these devices.
My assumption is that most devices follow VESA standards (EDID), and so we are able to get accurate physical display sizes most of the time. Using point sizes (or other real-world measurement units) then seems like the way to go for device-independent app development.
I'd like to gauge how reliable this fact is.
-
We discussed in some topics where I contribute, and the results was that point size is not reliable at all, because any platform has a different interpretation of how big is a point size in real dimensions.
The conclusion was that the most reliable approach is to use pixel size and use the information about physical density from QScreen generating a value that correspond to 1 mm (or 1 inch ) in term of pixel and use it. -
Ah, thanks, @Gianluca. I just found this "thread in the development list":http://comments.gmane.org/gmane.comp.lib.qt.devel/6807. The very last email suggests exactly what I think would be necessary: introducing logical versus physical measurements.
Currently, the issue in developing a QML app is this: I can only choose a pixelSize or pointSize for the font of my app, while with other components like rectangle. Pixels are obviously not device-independent, and if point sizes are not reliable, then there is currently no truly device-independent way to develop with QML out of the box.
What you've suggested @Gianluca, is to essentially calculate my own real-world sizes (e.g. pt, mm, etc), which was my original idea, but then I decided to research on what a point size means in Qt. The "docs":http://qt-project.org/doc/qt-5/qml-qtquick-text.html#font.pixelSize-prop say that using point sizes is "device-independent" so I thought I'd research on how accurate that is, which you've said isn't.
Based on your suggestion, the truly most cross-platform way to develop a QML app would be to use Screen.pixelDensity to calculate physical measurements, assuming that Screen.pixelDensity gives us the physical pixel density of the display, not the logical density of an OS that has scaling applied (e.g. OS X with Retina: x2).
So, one question is: does "Screen.pixelDensity":http://qt-project.org/doc/qt-5/qml-qtquick-window-screen.html#pixelDensity-prop give you the physical density of the display as read from the VESA-standard DDC (EDID) data? If not, then perhaps Screen should be more on par with QScreen and have both Screen.physicalPixelDensity and Screen.logicalPixelDensity. EDIT: Aha! The answer to this question is yes. The docs are outdated and do not mention that Screen also has a property called "logicalPixelDensity":https://qt.gitorious.org/qt/qtdeclarative/source/fc76abfa52be058e Am I reading the most recent docs?items/qquickscreen.cpp#L130. pixelDensity is physical, while logicalPixelDensity is... logical, and each one is calculated from QScreen's physicalDotsPerInch and logicalDotsPerInch, respectively.
Another issue is that component measurements in QML (e.g. an Item's width, or a Rectangle's border.width) are in pixels. There's seems to be no way to specify a point size, as far as I can tell, for a Rectangle's width or a Rectangle's border.width. It seems that only a Text component has a pointSize.
So here's another question: If I were to use a pointSize for the base font size of my app, how would I set some other Rectangle's height to that same pointSize? EDIT: if I do myText.height, that doesn't give me the value I'm looking for because it includes pixels for the spacing above and below the actual text of the Text component. myText.pixelSize doesn't give me the value I want because it's undefined since I've only set pointSize.
-
Good points.
Others followed your reasoning, but at the end me and others decided to ignore completely the point sizes because if you do some real testing you'll see that 1pt is converted in different real dimensions depending on which platforms you are (iOS, Mac, Windows or Linux) and you don't have any way to get that real dimension from the Qt API.
While, with pixel size you can use QScreen (and Screen) to calculate the exact dimension in the real word. -
I've run into some of the issues you mentioned while working on a kind of graphical editor that can show both text, primitive shapes, pictures, etc.
The users want to select the point size for their text, because this is what they are used to. But when you then resize a rectangle next to the text to match it's height, and transfer the result to a different computer with a different DPI setting, the heights won't match anymore.
I ended up doing fonts in "point size at 96 dpi", regardless of the system's dpi setting. That way, pixel and font sizes always match.
In your case, I guess you'll want to go the opposite way, which means you need to find out the system's dpi setting, and calculate your pixel size for a certain point size. Basically your formula would be
@pixelSize = (fontPointSize * systemDpi) / 72.0@ -
Thanks Gianluca and Asperamanca. What I ended up deciding to do is ignore the system dpi of all devices (because the system's dpi is not always the hardware dpi) and use real-world measurements (i.e. 1pt shall always be 1/72nd of a real-world inch no matter what device I'm on, and 1 inch always 1 inch, etc) like this:
@var mm_per_cm = 10;
var cm_per_in = 2.54;
var pixelsPerInch = Screen.pixelDensity * mm_per_cm * cm_per_in;
function pointsToPixels(pointValue) {
return Math.floor((pixelsPerInch*pointValue)/72);
}console.log("logical density (ppmm): "+Screen.logicalPixelDensity);
console.log("physical density (ppmm): "+Screen.pixelDensity);
console.log("logical density (ppi): "+Screen.logicalPixelDensity * mm_per_cm * cm_per_in);
console.log("physical density (ppi): "+Screen.pixelDensity * mm_per_cm * cm_per_in);
console.log("16pt is "+pointsToPixels(16)+"px on this device.");@Then, based on the device size, I'll be able to pick a layout and font size. For example, mobile phones might all have a 10 point font, tablets a 12-14 point font, and laptops and desktop a 14-16 point font, all depending on the chosen font. My aim is to have it be inherently the same app regardless of the size and resolution of the devices. Some things, like column widths, might vary from device to device and be percentage based (or one column fixed-width and the other column filling the remainder of a 2 column layout), while things like buttons and tabs might always have the same physical height.
This should work assuming that most devices conform to the VESA standards.
-
Revisiting this after some time, and having spent some time in the world of web where nice things like pixelDensity and logicalPixelDensity are never exposed, I wonder if I can expose these values into my web app so that I can at least have these nice values for web development when I package my web apps for mobile with Qt WebEngine.
On another related topic, and due to being tired of web development in Chrome, Firefox, and IE with no access to such vital information, I think it's about time someone (or some organization) made a browser for browsing both QML-based and HTML-based sites. That'd be revolutionary.
Imagine pointing your web browser to http://some-domain.com and it's pure awesome because it's QML-based. It'd be amazing.
-
Revisiting this after some time, and having spent some time in the world of web where nice things like pixelDensity and logicalPixelDensity are never exposed, I wonder if I can expose these values into my web app so that I can at least have these nice values for web development when I package my web apps for mobile with Qt WebEngine.
On another related topic, and due to being tired of web development in Chrome, Firefox, and IE with no access to such vital information, I think it's about time someone (or some organization) made a browser for browsing both QML-based and HTML-based sites. That'd be revolutionary.
Imagine pointing your web browser to http://some-domain.com and it's pure awesome because it's QML-based. It'd be amazing.
