Allow picking specific Monospace font

LinuxOnTheDesktop commented 5 years ago

Summary

It seem to me that, unless I force an override via a global (DE) font setting, KeePass will use fonts that do not clearly distinguish the zero character from the capital 'o' character.

Desired Behavior

'0' and 'O' would be clearly distinguished, ideally via a font that puts a strike through the number.

Possible Solution

The app would have a setting for changing its font and, ideally, to a font that clearly distinguishes 'O' and '0' - and the app would advertise the point of this (that point being, that it is important for a password program so to do - for, sometimes, one will transcribe what one sees in the app - onto, for instance, a different device).

Context

Sometimes I transcribe from one device to another, i.e. from what I see in KeePassXC to e.g. my phone.

phoerious commented 5 years ago

That's hard to do cross-platform. On Windows we already prefer Consolas, but on other platforms the Monospace font could be anything and no specific font is guaranteed to exist.

droidmonkey commented 5 years ago

What OS / Desktop Env are you using? We already implement "Monospace" font family in the password field. There is a known bug on LXDE regarding fonts and Qt. https://github.com/keepassxreboot/keepassxc/issues/1771#issuecomment-375773730

https://github.com/keepassxreboot/keepassxc/blob/develop/src/gui/PasswordEdit.cpp#L34-L37

LinuxOnTheDesktop commented 5 years ago

What OS / Desktop Env are you using?

I should have said: Linux Mint Cinnamon; and Cinnamon uses GTK for preference. I can provide some screenshots of 0s and Os if you like.

Tux commented 5 years ago

I just tried keepassxc today as a possible replacement for keepassx-0.4 and this was the first thing that struck me as "Unusable". openSUSE Tumbleweed and openSUSE Leap 15.0 This tool definitely needs a setting for a selectable font I compiled from git and added

              <property name="font">
                <font>
                  <family>Monospace</family>
                  </font>
                </property>

to <widget class="QWidget" name="entryNotesTab"> in ../src/gui/EntryPreviewWidget.ui Now keepassxc is much better usable for me

phoerious commented 5 years ago

"Monospace" is not a font, it's a fallback name that could be anything. This points to a broken font config on your system and you should configure a different font as your default Monospace font.

KeePassXC respects that setting as long as Qt is made aware of what your Monospace font is:

Tux commented 5 years ago

I did, but I did not want to force my preferences onto the rest. My prefered fixed-width font = DejaVu Sans Mono

rwky commented 4 years ago

I'm using KUbuntu 19.04 and that has the default mono space font of 'Hack' this works fine in the Kate text editor but KeepassXC doesn't pick it up I'm not sure what font it's using see screenshot It makes it difficult to tell the difference between I and l and O and 0

This is what Kate displays

P.S. I have version 2.4.3 using the AppImage

LinuxOnTheDesktop commented 4 years ago

Kate's rendering of the zero seems somewhat strange and ugly but the rendering does satisfy the desideratum here. To wit: enable the user to distinguish the number zero from the letters 'o' and 'O'. Surely enabling the user to make that distinction is a basic prerequisite for a password manager.

droidmonkey commented 4 years ago

Are you using the qt5ct "theme"?

rwky commented 4 years ago

I assume you mean the plasma theme? It's 'Breeze Dark'

droidmonkey commented 4 years ago

This is probably a theme issue not passing the monospace font to Qt correctly. We request a monospace font in the password field.

rwky commented 4 years ago

I've tried this with a few different themes, KeepassXC gets the same font with all of them. Since it works with Kate and Konsole I'd assume the theme is doing it's thing correctly.

droidmonkey commented 4 years ago

Not necessarily. I believe Kate and Konsole request a specific font, not a font family like we do.

rwky commented 4 years ago

Any idea on how to debug further? It wouldn't be a terrible idea if keepassxc had an option to set a specific font.

On Fri, 11 Oct 2019, at 22:26, Jonathan White wrote:

Not necessarily. I believe Kate and Konsole request a specific font, not a font family like we do.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/keepassxreboot/keepassxc/issues/2741?email_source=notifications&email_token=AABFBI4KK5KM5YSKSCTLCLTQODVSBA5CNFSM4G2ECGL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBBIF5Y#issuecomment-541229815, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABFBI67H5PQ4T7Q7GHULETQODVSBANCNFSM4G2ECGLQ.

-- Regards

Rowan Wookey BSc (Hons) Comp, CISMP, MBCS Server Administrator & Programmer

Please add admin@rwky.net to your contacts/email whitelist.

phoerious commented 4 years ago

Which release are you using? AppImage? Snap? PPA? Distribution-native packages (if so, what distribution)?

rwky commented 4 years ago

P.S. I have version 2.4.3 using the AppImage

phoerious commented 4 years ago

The AppImage most likely does not pick up your system theme (which is a limitation of shipping our own Qt, unfortunately). The Snap or a native package should solve the problem. If you want the AppImage to use the correct font, you will have to modify the global fontconfig settings, most likely.

LinuxOnTheDesktop commented 4 years ago

The AppImage most likely does not pick up your system theme (which is a limitation of shipping our own Qt, unfortunately). The Snap or a native package should solve the problem. If you want the AppImage to use the correct font, you will have to modify the global fontconfig settings, most likely.

For my part I don't think I was using the AppImage. I should have recorded whether or not I was in my original report. I cannot easily check now because, whilst keepassxc has its shutdown problem, I'm using KeePass under Wine.

rwky commented 4 years ago

I've tested on another machine and the app image is working fine, oddly enough the snap doesn't pick up the dark theme so doesn't look right but that's a separate issue.

Considering it works fine on one system I'd assume it's some weird problem local to the one machine and not a keepassxc problem.

droidmonkey commented 4 years ago

That's what I've been saying :smirk:

sts10 commented 4 years ago

👋 I'm here because today I mistook an S for a 5 in a password.

Screenshot_20191125_180331

(Screenshot is from v2.5.1, via Snap, Kubuntu 18.04, but I think the 5 vs. S issue was worse on my Mac...)

One idea we might borrow from 1Password that I like is using a slightly different color for numbers -- maybe a green, to match the KeePassXC logo? This would help mitigate/bypass the font availability problem discussed above. Just an idea.

Edit: My particular use-case was reading a password from my laptop to input on a mobile device, something that I admittedly do infrequently.

Debug info in case

KeePassXC - Version 2.5.1 Revision: 0fd8836 Distribution: Snap

Qt 5.9.5 Debugging mode is disabled.

Operating system: Ubuntu Core 18 CPU architecture: x86_64 Kernel: linux 5.3.0-23-generic

Enabled extensions:

Auto-Type
Browser Integration
SSH Agent
KeeShare (signed and unsigned sharing)
YubiKey
Secret Service Integration

Cryptographic libraries: libgcrypt 1.8.1

jimcheetham commented 4 years ago

Using color alone isn't a wonderful differentiator, for accessibility reasons.

Perhaps every glyph/character should have an indicator or some sort, identifying its type (upper/lower case, number, non-"ascii") ... not necessarily all the time, but only when displayed in a context that means its likely the user will be manually retyping the phrase.

Here's an example, with the passphrase on one line and the glyph indicators on a second line, in the limited medium of text in markdown :-) so I get to avoid issues with variable-width glyphs and actual useable UI design ...

1lo0O⚬
NLLNU!

Number one, lower letter L, lower letter L, lower letter O, number zero, upper letter O, pictograph "o"

sts10 commented 4 years ago

Using color alone isn't a wonderful differentiator, for accessibility reasons.

Ugh, sorry, I feel bad for not thinking about this. Thanks for your note.

jimcheetham commented 4 years ago

Absolutely not my intention to make you feel bad - color isn't a bad indicator! Just not on its own, without other elements :-) You could argue in this case that as the color would only be providing a hint, and that we already had the actual content on display, it wouldn't be inappropriate.

ajay-gh commented 4 years ago

Let me add a few observation, simply because I think there is a problem - and it hasn't been fully addressed !

first, a number of older posts on this board show that users with different platforms have run into the very same 'font' problem, and have not been very satisfied with the proposed solutions;
I have had problems with ambiguous passwords (osx), and simply changing a system wide font settings (not a standard option under osx) did not solve the problem;
next, try and edit a new entry in keepassXC, add a user name with ambiguous letters (oO0LliI ...), copy this user name and paste it into the other fields like notes or password. The result: the chars look different in every field, and you still don't know what you read.

[remark: the "monospace" setting in general settings changes sth, but it doesn't solve the problem]

For any user who cannot use autotyping or who's got to enter some passwords manually into his DB which where generated by another system (e.g. Apple's Timemachine) this is quite unsatisfactory. Best Regards

felix-otto commented 1 year ago

While trying out KeePassXC I missed the option to customize the font used for displaying the password(s). It's a feature I know from KeePass 2 (see screenshot below). Tools => Options => Interface (2) KeePass2_OptionsFonts

Source Code Pro helps me to distinguish look-alike characters in passwords. KeePass2_SourceCodePro In other situations/environments I prefer different (mono space) fonts.

Setup: KeePassXC 2.7.4 and KeePass 2.52 on Windows 10 22H2

droidmonkey commented 1 year ago

You can change the default monospace font on windows in the registry: https://superuser.com/a/1567627 The font selection is a feature we are interested in adding though

felix-otto commented 1 year ago

The font selection is a feature we are interested in adding though

👍

I didn't find such a clear statement in the existing issues (so far it was rather about mono space in general or font size). Looking forward to see this in one of the future releases.

michaelk83 commented 1 year ago

Source Code Pro helps me to distinguish look-alike characters in passwords.

You can use colored passwords for that since 2.7.2.

haarp commented 1 year ago

I'm seconding (tenthing?) this request. I understand that there are bugs that can prevent KXC from picking up the system's monospace font. But why use the system font to begin with? There's no guarantee that it has distinguishable characters.

IMO it's in a password manager's interest to either provide a good font, and/or allow the user to override it. It shouldn't depend on the system to provide it with a suitable font.

Thanks!

christakahashi commented 1 year ago

Just to add to this as I don't think my issue is a full "new" issue. the upper case i and lower case L look exactly the same in windows when you click to reveal the password on the entry edit screen. the font is good from the normal view, just not the edit view.

NomarCub commented 1 year ago

I don't care about picking my own monospace font, just for consistency in the editing view password field too. Like mentioned above, on Windows it's not monospace. Is there a separate issue for that?

Is this it? https://github.com/keepassxreboot/keepassxc/issues/7337 There looks to be a lot of confusion in both issue discussions.

jmbreuer commented 5 months ago

For me, the issue is similar but different (#10277).

On my system, KeePassXC chooses a particularly badly readable font for monospace, with apparently no current workaround either for font type or size. OK possibly I could track down that offensive font and uninstall it or something.

On that note, it seems that KeePassXC, on my system, simply picks the first mono font from an alphabetic list of system font types. ...

droidmonkey commented 5 months ago

That would be a Qt problem in your case since we simply ask Qt for the preferred monospace font.

jmbreuer commented 5 months ago

That would be a Qt problem in your case since we simply ask Qt for the preferred monospace font.

Your comment got me thinking, and I dug into this.

It turns out that KeePassXC overrides the size of the monospace font requested from Qt with the size of the (non-monospace) system default font:

https://github.com/jmbreuer/keepassxc/blob/a472ef8a931dd64990d7f735394e949638e880d5/src/gui/Font.cpp#L46

At least in my case, that leads to a monospace font rendering noticably smaller, and apparently with somewhat bad scaling artifacts on top.

In the specific case of Windows with Consolas, a similar issue is already being compensated:

https://github.com/jmbreuer/keepassxc/blob/85751e4ad2d918464b23ea88c8ac11390244194d/src/gui/Font.cpp#L38

(At least) on platforms where UI fonts can be completely arbitrarily chosen (e.g. Linux/KDE), such fudging/compensation attempts make no sense to me at all. Rather, it leads to much less 'surprise' to use the configured fonts as-is, which conveniently also enables existing mechanisms to override/configure those for specific, individual applications (which was my issue in #10277), e.g. via ~/.config/keepassxcrc:

[General]
fixed=Droid Sans Mono Dotted,11,-1,5,50,0,0,0,0,0,Regular

I've drawn up the appropriate (trivial) patch, see the PR above.

keepassxreboot / keepassxc