Le 06/10/2015 18:38, Guillaume Munch a écrit :
I'm trying to come up with examples where do we actually "need"
unicode in the interface. The ellipsis case seems to be trivial
indeed.
Is it trivial? On my ubuntu libreoffice (where I can write the same
string to compare), I would say that what is used is three dots and not
ellipsis. I failed to find documentation on the subject, except:
http://stackoverflow.com/questions/3777072/in-menus-for-should-one-use-ellipsis-sign-or-just-three-dots
After more looking around, I see that Apple recommends the ellispsis
character:
https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//apple_ref/doc/uid/20000957-CH15-SW3
Gnome seems to prefer ellipsis character too:
https://developer.gnome.org/hig/stable/writing-style.html.en#ellipses
Microsoft does not say anything, but their examples use ...:
https://msdn.microsoft.com/en-us/library/dn742392.aspx
Seriously, I think this is just going to annoy our translators.
Seriously, who knows how to get an ellipsis on his/her keyboard?
I could propose to hack it into the menu code...
I general, our source code is already UTF8 (in particular author names
in .cpp files), but I am not sure that adding weird characters in the
source is always helpful. I would not swear that there only one
character looking like an ellipsis in unicode standard.
> Properly formatted text in general, not just proper ellipses…
> A revamped IPA toolbar?
> The math toolbar?
> See also src/frontends/qt4/ui/HSpaceUi.ui in the patch.
Please note that we have to be very careful with unicode characters. At
some times I advocated using the proper unicode visible space character
in our documentation, but it turned out that several windows font did
not have that. You do not want to force users to use such or such font
in their text editor.
Of all programs, if LyX does not need an Unicode interface, which
program does? I am sure you will be able to come up with creative uses.
LyX needs an interface that blends well with the environment where it runs.
LyX already uses a ton of Unicode chars, defined by hand with their code
point. This patch makes it easier to use Unicode in the source, and
enables special chars in translation strings as well.
Code point is more precise than trying to recognize a character in a
unicode table. I am sure that emacs can tell me what is the code point
at cursor position, but life is to short to try to find it.
And the patch is free.
:)
For the docstring part of the code, I am not sure what code like the
following do:
- LASSERT(static_cast<unsigned char>(*c) < 0x80, return l);
- s.push_back(*c);
+ if (static_cast<unsigned char>(*c) < 0x80)
+ s.push_back(*c);
+ else
+ return s += from_utf8(string(c));
There is nothing magic about from_utf8(string(c)), right? This is just
accepting latin1 characters, or am I blind?
JMarc
