Closed star-buck closed 9 years ago
A related bug got filed as a report in Qt: https://bugreports.qt.io/browse/QTBUG-45412
Even though it looks like is should be a simple thing, this is deep in complex font things. I'd like to be able to just close this as "upstream's problem". Choosing a different font could work round it.
@notmart : How about choosing the same font for Breeze password field like Maui SDDM theme, which seems to works fine?
from the Qt report seems to depend from what fonts are installed rather than what fonts are chosen for the particular field?
Fonts installed on the system should be the same, then while Breeze has dots spacing going weird as soon as the entered password is longer than the field, while Maui sddm theme has dots fine for same password... will check again if the field width differs (but both seemed filled out completely).
on devel machine or ubuntu laptop i cannot seem to reproduce, using system fonts both ad oxygen or dejavu. looking at the sources, the difference i see between the maui and breeze seems that maui is using a primitive TextInput element, while our theme uses the qtquickcontrol TextField, both should have echoMode: TextInput.Password and use \u25cf as passwordCharacter
@notmart: Ubuntu Laptop= Kubuntu? For me Kubuntu 15.04 offical release has this weird dot spacing regardless on which machine I install it. I have both fonts here on Netrunner too, so how do you set fonts / test fonts in Breeze sddm theme?
Breeze SDDM Theme in Kubuntu: https://www.dropbox.com/s/0qfa6m7bl88heip/sddm-dots-kubuntu-1504.mkv?dl=0
yeah, straight 15.04. I suspect it's connected to how many DPI in the screen. will try in virtualbox as well like in the video. there i's live or installed? (also virtualbox guest additions installed or not may influence)
@notmart: what dpi did you get this working with? what screen resolution?
15.04 in virtualbox= not installed. Netrunner/kci= always installed on actual machine. several different dpi: netbook with 800x600, mac-hidpi, normal pc with 1920x1080 - over here I never encountered this working properly even once.
got to reproduce: it seems it's renderType: Text.NativeRendering making it use freetype instead of the distance field. the maui sddm theme using TextInput, has the default distance field rendering, but we can't just use that, because on a desktop it looks over the top blurry
if one tries to put in a normal text field a row of the same letter, like MMMMMMMMMMMMMM there will be the same effect of inconsistent spacing. But that's actually the correct behavior, because of truetype hinting: the glyphs are deformed and moved in order to align to the pixel grid, since the choice is either be slightly deformed/mispositioned vs very blurry (there is an age old diatribe between advocates of font rendering between windows and mac about this)
since the password echo is a dot, therefore will be always blurry, we could try to set distance field rendering only on password fields, a possible patch to the plasma style is as following:
should be in the next plasma-framework that gets packaged http://quickgit.kde.org/?p=plasma-framework.git&a=commit&h=ae9cb77838aba7075826a1f444e75b9287ce6e74
lets wait with packaging for plasma5.4.
works as of kci20150807
If the dots fill up more than the initial lenght of the password field, the spacing between each dot changes from evenly to "two dots closer grouped together, then a bigger space before the next 2 dots".