Ok, this is loosely related to bug #9466 and #8854, and one of the reasons I've passed xkb work lately (the others being end-of-year work pike + christmas shopping hell + vacations) The current nobreakspace handling in French is not too satisfactory. Due to POSIX/SUS whatever shells do not treat nobreakspace characters as spacing characters. So if they are too easy to type many users complain of broken CLI. OTOH they are extensively used in normal typography, so if they are too difficult to access other users complain (bug #9466 is an example, I've just received another mail about this today) To compound this we actually need both nobreakspace and narrow nobreakspace (the reference typography book I've been waiting for confirms this : — narrow nobreakspace is used before ;!? — nobreakspace before :» and after « So now I'm leaning towards defining a spacebar with: – shift+iso_level3 → nobreakspace – shift+iso_level5 → narrow nobreakspace – everything else → space Questions: 1. is it possible to sanely do this without the rest of the keymap being 5-level (I don't want to kill users right ctrl for this) 2. what is the right type to use there 3. are spacebars modularised somewhere so I can add this as an option (the others being old-style fr-latin9 handling and current fr(oss) handling)
There are other problems: * Do fonts provide glyphs and metrics for narrow spaces? This question sounds quite silly, but most programs replace unknown characters by question signs or a boxed sign (like Firefox, for instance) which look very ugly. * Are narrow spaces really suited for French typography? IMO no, no-break property is much more important than width property, so we need a no-break narrow space. And in fact we need more different widths for French typography, IIRC my TeXperiments a long time ago. In other words, the first step is IMO to check which Unicode codepoints we want for French typography and if they are well supported by common fonts and applications.
Err, I should have read your bug report more carefully, my second point does not make sense, sorry. Anyway my first point still stands, can you please check how 202F is supported by fonts and applications? I checked one year ago when a similar issue had been discussed at http://lists.debian.org/debian-l10n-french/2005/12/msg00350.html (I do not remember why I did not consider 202F at that time), and decided to keep 00A0 because support of other spacing characters were too poor, but maybe this situation has changed.
(In reply to comment #1) > There are other problems: > * Do fonts provide glyphs and metrics for narrow spaces? Dejavu which is becoming the standard font of every major distro has working normal & narrow nobreakspaces for months (years?) > * Are narrow spaces really suited for French typography? page 149 of http://www.amazon.fr/Lexique-r%C3%A8gles-typographiques-limprimerie-nationale/dp/2743304820 is very clear on the subject (I explicitely didn't want to touch this before having this reference book on hand, it arrived this week) > IMO no, > no-break property is much more important than width property, > so we need a no-break narrow space. Note : there I'm talking about U+202F which has both the nobreak & narrow properties Also do remember making a glyph accessible in no way forces people to use it.
(In reply to comment #3) > (In reply to comment #1) > > * Are narrow spaces really suited for French typography? > > page 149 of > http://www.amazon.fr/Lexique-r%C3%A8gles-typographiques-limprimerie-nationale/dp/2743304820 > > is very clear on the subject (I explicitely didn't want to touch this before > having this reference book on hand, it arrived this week) To be 100% transparent the Imprimerie Nationale only identifies three different spaces in French typography : – « espace justifiante » → normal space – « espace mots insécable » → nobreakspace — « espace fine insécable » → narrow nobreakspace (translation from French to english unicode naming mine, but self‑evident IMHO)
Not sure if I understand your initial questions, but let me try: 1. You can specify a type for a given key, see symbols/nbsp for instance 2. I would say EIGHT_LEVEL, defined in types/level5 3. Space bar is modularized into symbols/nbsp; maybe this file should have been named symbols/space instead? Anyway you can add your own option there for now. Putting it all together, I would try (not tested): key <SPCE> { type[Group1]="EIGHT_LEVEL", symbols[Group1]= [ space, space, space, nobreakspace, space, 0x100202f, space, space ] };
(In reply to comment #5) > 3. Space bar is modularized into symbols/nbsp; maybe this file should have > been named symbols/space instead? IMHO (but my naming skills are overrated) space or spacebar would be more appropriate, esp. for nontechnical non-english-speaking users
Created attachment 8296 [details] [review] Proposed patch How about this patch?
Nicolas, this patch looks quite ok to me. Going to commit it.
updated rules/base.o_s.part, committed.
(In reply to comment #8) > Nicolas, this patch looks quite ok to me. Going to commit it. svu, thanks a lot but I just noticed the 8-level spacebar kills right-ctrl on my box (ie it can not be used to do ctrl+c ctrl+v anymore for example) Is there a way to restrict right-ctrl = iso-level5 to the space key ? The alternative as I see it is forget about using the existing EIGHT_LEVEL type but that : 1. would require creating a new type (I know you don't like it) 2. would hardcode right-ctrl as accessor, which is not too good either Am I missing something?
Nicolas, why just don't you drop level5(rctrl_switch) from your variant? You can leave it to the user - choosing level5 modifier. Or use some other level5 switcher (well, you have to create it - at the moment only rctrl_switch is available).
The problem is not so much the key used for level5, but that once it's declared for spacebar it's lost to users for the rest of the layout right-ctrl is perfectly fine as default level5 for French users on the spacebar what's not fine is once you've declared it as level5 key there it does not behave anymore as ctrl for the rest of the keyboard (which is 4-level only) I guess I'll end-up defining a new level3+right-ctrl+shift type if I can't isolate right-ctrl=level5 to the spacebar
> The problem is not so much the key used for level5, but that once it's declared > for spacebar it's lost to users for the rest of the layout Yes, it is true. If some key (or combination!) is used for level5 - it is used for level5 only. So what?:) > what's not fine is once you've declared it as level5 key there it does not > behave anymore as ctrl for the rest of the keyboard (which is 4-level only) Yes, I see. You want to have it as usual good old rctrl for all keys having 4- levels. > I guess I'll end-up defining a new level3+right-ctrl+shift type if I can't > isolate right-ctrl=level5 to the spacebar Ghm. Sounds suspicious. Let's see...
(In reply to comment #13) > > I guess I'll end-up defining a new level3+right-ctrl+shift type if I can't > > isolate right-ctrl=level5 to the spacebar > Ghm. Sounds suspicious. Let's see... Hi Sergey, did you have the time too look at this or should I go along and rework the layout to not use iso-level5 but hartcoded right-ctrl?
> Hi Sergey, did you have the time too look at this or should I go along and > rework the layout to not use iso-level5 but hartcoded right-ctrl? Nicolas, I actually do not know what would be the right solution. Well, work away on the new type - while I am not excited about that idea, it looks like a bad hack to me, so I reserve the right to decline the whole thing at the end, ok? Or may be we'll finally create "contrib" subdirectory for bad hacks like this.
Bugzilla Upgrade Mass Bug Change NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO. - benjsc fd.o Wrangler
I post here because the bug seems to be related to this topic. In the current oss_latin9 layout, the right control is completely broken. It seems related to your "level5(rctrl_switch)" modification.
If I've correctly understand the syntax, you should remove include "level5(rctrl_switch)" from the fr oss layout and then include include "level5(rctrl_switch)" in the "level4n" of nbsp file to make things work correctly. BTW I'm not sure that Shift+level5+space is more easier than level3+v.
> I post here because the bug seems to be related to this topic. > In the current oss_latin9 layout, the right control is completely broken. It > seems related to your "level5(rctrl_switch)" modification. How do you mean "completely broken"? What is expected/actual behaviour?
I mean the Right Control works great for accessing iso_level_5, but does not behave as a control key anymore : i can't use it for copy/paste, etc… See comment #10 : « I just noticed the 8-level spacebar kills right-ctrl on my box (ie it can not be used to do ctrl+c ctrl+v anymore for example) »
> I mean the Right Control works great for accessing iso_level_5, but does not > behave as a control key anymore : i can't use it for copy/paste, etc… Of course it does not work as Control any more! For example, I am using RCtrl to switch between groups - and it does not work as Control for me. I am using LCtrl instead. You cannot have RCtrl as switcher to level 5 and Control at the same time. RCtrl is used to switch to level5 in all layouts which have levels 5+ - so effectively they all disable its function as Control.
Ok, but it seems that it is not the behavior expected by Nicolas Mailhot, and this is very disturbing for normal users who don't understand why their right control does not work anymore. This should not be set as the default behavior.
> Ok, but it seems that it is not the behavior expected by Nicolas Mailhot, and > this is very disturbing for normal users who don't understand why their right > control does not work anymore. This should not be set as the default behavior. What would you offer as standard switcher for 5th level? RAlt is already taken for switching to the 3rd level (BTW why noone complains that it does not work as Alt when used as switcher?)
LAlt is not used as a switcher by *default*. RAlt is used for third level but this is the way it is expected to behave on a french keyboard AFAIK (I mean french keyboard does not have a RAlt key but a AltGr key instead). 5th level is *only* used for the space key (the nbsp problem) on the french layout. To solve this, we should : - provide a way to define the 5th level key (as for the 3rd level) - « a way to restrict right-ctrl = iso-level5 to the space key » as Nicolas Mailhot said before. Thanks.
> LAlt is not used as a switcher by *default*. RAlt is used for third level but > this is the way it is expected to behave on a french keyboard AFAIK (I mean > french keyboard does not have a RAlt key but a AltGr key instead). You see, this is the problem with expectations actually;) Once we make people expect RCtrl to be a switcher for any configuration with levels 5+ - we're ok;) > 5th level is *only* used for the space key (the nbsp problem) on the french > layout. To solve this, we should : > - provide a way to define the 5th level key (as for the 3rd level) No problem at all. But there should be some default switcher anyway. All keyboards having levels 3 and 4 have RAlt as switcher by default. > - « a way to restrict right-ctrl = iso-level5 to the space key » as > Nicolas Mailhot said before. Well, if he manages to invent special type for space which would not break other things - he's mostly welcome!
Created attachment 16056 [details] [review] Proposed patch to avoid using level5 Here is
Created attachment 16057 [details] [review] Proposed patch to avoid using level5 Here is a proof-of-concept patch on how to avoid using iso-level-5 in fr(oss), make French users happy, and close this bug The good part is it seems to apply without making xkb go bang (you won't believe how long it took to get to this state) The bad part is rctrl+shift+space is not doing what I want it to do. So obviously I'm still missing something. xkb experts please review
Created attachment 16060 [details] xkbcomp :0 -o xkb.out output with patch #16057
Created attachment 16061 [details] [review] Proposed patch to avoid using level5 Ok, it seems that despite RControl being used in some types it's not enabled by default. Since enabling RControl as separate modifier is likely to have side-effects somewhere, here is a version that uses plain Control instead That means control+space shortcuts will be disabled for fr(oss). I don't see how I could make it better short-term. People are encouraged to make RControl a first-class modifier if they want something less heavy-handed
The patch is ok. But could you come up with some less techy description? People without XKB knowledge would be frustrated...
How about: Space key outputs non-breakable space character at fourth level, thin non-breakable space character at sixth level. Sixth level is acceded with Ctrl+Shift, and can not be reconfigured. However Ctrl is left unchanged for the rest of the layout. (Brought to you by hotel wifi)
OMG. This is real War and Piece. Is it possible to come up with something SHORT?:)
I take it I now officially suck at descriptions (that's ok, I've been sucking at it unofficially for quite a long time). Here is my last attempt: "Space key outputs non-breakable space character at fourth level, thin non-breakable space character at sixth level (via Ctrl+Shift)" But the descriptions should really be done by someone with more taste than me.
Ok, I'll commit this one. Thanks a bunch:)
Nicolas, could you please have a look at #15804 ? Thanks
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.