Font in Terminal is incorrectly massive since recent update

Conformed on krillin rc-proposed 167

from debug we were doing last week, I logged this bug 1513816
we are seeing that the terminal app font is not following the grid units - but it should ?

FWIW, this affects the Logviewer app in the store too.

Here's the line of code in the logviewer app that is responsible for it:

http://bazaar.launchpad.net/~vtuson/logviewer/trunk/view/head:/app/ui/LogPage.qml#L183

Indeed, it does hardcode the font size to a pixel value. So while I confirm something has changed recently, it seems to reveal improper use of components in apps instead of real breakage in the system.

Here's the terminal app:

http://bazaar.launchpad.net/~ubuntu-terminal-dev/ubuntu-terminal-app/reboot/view/head:/src/plugin/qmltermwidget/lib/qtermwidget.cpp#L281

One thing that I've overlooked in the previous comment is that it uses "font.pointSize", not font.pixelSize. Same for the terminal app. That should indeed be correct.

So seems to be an issue in the calculation of font's pointSize after all.Sorry for the wrong assessment in the previous comment.

Status changed to 'Confirmed' because the bug affects multiple users.

If we're sure the regression is in that landing https://code.launchpad.net/~osomon/qtubuntu/ubuntuscreen-physicalsize/+merge/273965 seems to be one possible candidate for font size changes.

Status changed to 'Confirmed' because the bug affects multiple users.

I'd need to dig, but I'd guess the DPI value in the QPA is now being correctly calculated, since we've wired up the physical size, qt can calculate a DPI. But we also live in the X world where DPI is nearly always 96.

So need to figure out the right thing to do...

http://bazaar.launchpad.net/~mir-team/qtmir/trunk/view/head:/src/platforms/mirserver/screencontroller.cpp#L157 is the relevant line of code. This triggers after compositor start, to match mir DisplayBuffers with Qt Screens. I've designed it under the assumption that each Mir Display will always have a DisplayBuffer on compositor start.

oops wrong bug, please ignore above

Browser is affected too

Yes, this is caused by the recent qtubuntu change where we now correctly provide the QScreen physical size.

But the font size is correct. I just measured it with a ruler on my Nexus 4. I set the terminal font size to 10 (via the apps configuration GUI) and the text height is around 3 mm. Which matches with my expectation if the size is being set in points.

One point is ~ 0.35mm. So a 10 points font would have text of height around 3.5 mm.

Before that change, QScreen was defaulting to 100 dpi when calculating its physical size, which is way lower than the 318 of Nexus 4. So yes, I would expect text sizes in points (as opposed to pixels) to get 3 times bigger after that qtubuntu fix.

So the fix for this bug is to have ubuntu-terminal-app to size its VT font in pixels and to factor in grid units when doing to. The whole UI is measured in grid units and ubuntu-terminal-app's VT font should be not exception to that.

But if you do insist in having the VT font size in a physical unit (ie, point size) then please do provide a broader range of values in that slider.

Closing C.S.I. task, each application has to be fixed.

marking fixed for the terminal which is pre-installed for some images

Fix committed into lp:ubuntu-terminal-app at revision 142, scheduled for release in ubuntu-terminal-app, milestone 2014-12-11