Created attachment 194539 [details] Screenshot of the issue This is a followup to bug 50400 1. Open a new document 2. File - Export As - Export As PDF 3. Go to the Security tab, press the Set Password button 4. Type some non-ASCII character into the Password field -> at the bottom of the dialog the warning "Only Basic Latin characters can be entered" appears. This was added in bug 50400 User feedback is that this wording is equally cryptic as just saying ASCII, also does not indicate whether special characters such as $, %, &, are exempt or not. Wording needs to be improved, maybe by listing "everything" allowed. Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: f6ea343e6fb2dc3539823dee60c9c6f96fc16275 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: hu-HU (hu_HU.UTF-8); UI: en-US Calc: threaded
asking for UX input as well
"Basic Latin" is the name of the code block, https://codepoints.net/basic_latin?lang=en. Not necessarily wrong if you want to avoid the term ASCII or "A..Z,[,{...". "Plain Latin characters" could be an alternative but I wonder if users understand that it includes brackets, for example.
Yes, "Basic Latin" is correct in the sense that it's the official name of the Unicode block. But if you don't know it's a name of a Unicode block (and I think most users don't), there's a lot of room for confusion. "ASCII" is most likely a better known term, because it's been around for longer, but the users who understand it might still be in the minority. Possible solutions could be the following: * "Only characters in Basic Latin Unicode block can be entered" The average user would be none the wiser, but at least interested users could search for "Basic Latin Unicode block" on the internet and discover what it contains. * "Only ASCII character can be entered" This would be clear for the more technically oriented users, but not so much for the rest. * "Only characters A-Z, a-z, 0-9 and the most common punctuation marks can be entered" Not an exact definition, but would give the right idea to most users, perhaps? * ""Only Basic Latin (a.k.a. ASCII) characters (A-Z, a-z, 0-9 and the most common punctuation marks) can be entered" Something for everyone?
Unlike the Unicode 'Basic Latin' block, referring to ASCII is a problem as non-standard Extended-ASCII and localized 8-bit character mappings remain prevalent. And also utf-8 is broken for password entry as noted in bug 50400--that our SfxPasswordDialog::AllowAsciiOnly() used in pw dialogs exclusively validates the 7-bit 128 character ASCII code set. That is what needs to be conveyed. (In reply to Tuomas Hietala from comment #3) >... > * ""Only Basic Latin (a.k.a. ASCII) characters (A-Z, a-z, 0-9 and the most > common punctuation marks) can be entered" > Something for everyone? Make that "Only Unicode 'Basic Latin' (a.k.a ASCII) characters (A-Z, a-z, 0-9 and the most common punctuation marks) can be entered"
If we end up in a verbose label, I suggest to keep a short label and have the explanatory text in a tooltip. ("aka" might become a migraine for l10n)
(In reply to V Stuart Foote from comment #4) > Unlike the Unicode 'Basic Latin' block, referring to ASCII is a problem as > non-standard Extended-ASCII and localized 8-bit character mappings remain > prevalent. > > And also utf-8 is broken for password entry as noted in bug 50400--that our > SfxPasswordDialog::AllowAsciiOnly() used in pw dialogs exclusively validates > the 7-bit 128 character ASCII code set. > > That is what needs to be conveyed. > > (In reply to Tuomas Hietala from comment #3) > >... > > * ""Only Basic Latin (a.k.a. ASCII) characters (A-Z, a-z, 0-9 and the most > > common punctuation marks) can be entered" > > Something for everyone? > > Make that "Only Unicode 'Basic Latin' (a.k.a ASCII) characters (A-Z, a-z, > 0-9 and the most common punctuation marks) can be entered" Yes, that would be even more complete.
(In reply to Heiko Tietze from comment #5) > If we end up in a verbose label, I suggest to keep a short label and have > the explanatory text in a tooltip. > > ("aka" might become a migraine for l10n) Not sure about the migraine, but of course if we put it in a tooltip, we could as well write "also known as" as we wouldn't be running out of space anyway. So perhaps something like this: "Only Unicode 'Basic Latin' characters can be entered" And the tooltip/explanation: "Characters in the Unicode 'Basic Latin' block (also known as ASCII) include the letters A-Z, a-z, numbers 0-9 and the most common punctuation marks."
We discussed the topic in the design meeting. Ideas are + "Only Unicode 'Basic Latin' characters can be entered" with tooltip "Characters in the Unicode 'Basic Latin' block (also known as ASCII) including the letters A-Z, a-z, numbers 0-9 and the most common punctuation marks." + "Character not allowed. Read the help page for a list of allowed characters." + "Character not allowed, only basic Latin alphabets, numbers and punctuations can be used." + "Character not accepted" (essentially forwarding to a more explanatory help page) Code pointer: sfx2/uiconfig/ui/password.ui
Balazs Varga committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/89c00618b9cee6e786fd11a7fdbf7aaf24e4fbb7 tdf#161411 - UI: Add Better wording for ASCII-only characters It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
There is Help system suitable for the verbose listing. I do not see why would we want to fit everything into the UI - was Help deprecated for some reason? If users do not understand what is included into the "Unicode 'Basic Latin'" (as worded now), they are welcome to press Help button.
(In reply to Mike Kaganski from comment #10) > If users do not understand ... "Unicode 'Basic Latin'" It's always a balance act between tooltips explaining a function and the help going into the detail. This is an example where the tip satisfactorily explains the wording with low costs ie. acceptable length of text.
Gabor Kelemen committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/542ec4ede3c0d1ce2ffc99e41762d85b5a5d14a2 tdf#161411 Add detailed list of allowed PDF password characters
(In reply to Heiko Tietze from comment #11) There is never such "balance". Tooltip is never a substitution for good help; if the information is *not* in help, it must be added there. People may disable tooltips, and still be able to find the relevant data. So adding it to the tooltip does *not* fix the problem of people not able to discover what is the character repertoire here.
Created attachment 198509 [details] The dialog in current nightly Checked in current nightly, looks okay: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e146f49704ef535c9ddd74338783e7c38390bf59 CPU threads: 14; OS: Windows 10 X86_64 (build 19045); UI render: default; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: threaded maybe some line breaks could be introduced into the tooltip.
(In reply to Gabor Kelemen (allotropia) from comment #14) > maybe some line breaks could be introduced into the tooltip. Depends on the VCL whether it auto breaks or not. Kf6 does it right. Thought we have a ticket on this but don't find any.
(In reply to Heiko Tietze from comment #15) > (In reply to Gabor Kelemen (allotropia) from comment #14) > > maybe some line breaks could be introduced into the tooltip. > Depends on the VCL whether it auto breaks or not. Kf6 does it right. Thought > we have a ticket on this but don't find any. Very interesting, under Windows if the Extended help option is disabled, it is not broken into multiple lines, but if it is enabled, the same text is wrapped. Seems to be independent from this issue. Marking as fixed for now.