I'm sorry of the name mistake in this mail (it's corrected below) and got aware of a number of problems with sending secreenshots. As I just learned that links are preferred for images, I posted them on Postimage.
On Tue, Jun 30, 2015, Khaled Hosny wrote: > On Tue, Jun 30, 2015 at 11:02:18AM +0200, Marcel Schneider wrote: > > On Sun, Jun 28, 2015, Peter Constable > > wrote: > > > > > Marcel: Can you please clarify in what way Windows 7 is not supporting > > > U+2060. > > > > On my netbook, which is running Windows 7 Starter, U+2060 is not a > > part of any of the shipped fonts. > > It is a control character, it does not need to have a glyph in the font > to be properly supported. As Doug explained us, this is true and false because there are three fonts shipped with Windows' full version where U+2060 is a part of, and all other fonts are bugging about U+2060. However, that too is only an application issue, and Khaled's advice is true for OpenOffice and LibreOffice, if my test results are accurate (please refer to the e-mail I sent just before). The issue about WORD JOINER vs ZWNBSP is resolved in conformance with Unicode recommendations at the condition that the preferred word processor is LibreOffice Writer, or OpenOffice Writer, but not Microsoft Offfice Word. This results from three facts: 1 The WJ is displayed with zero width and with a visible mark (resembling to that of NBSP) in OpenOffice/LibreOffice: http://s24.postimg.org/5ujkak28l/screen_m_2015_07_02_04_08.jpg 2 The WJ works with whatever font is selected (here, Aharoni). 3 No format character is destroyed by OpenOffice/LibreOffice at conversion to plain text (pasting into a text editor). This is why, actually, users must switch between applications depending on the actual task and the characters used. Sticking with an application we are used to, would then be a counter-productive error. If you wish to view some more screenshots, I'd like to provide these (I switched the UI to English if possible, eventually in LibreOffice Writer): http://s6.postimg.org/mfn27wthd/screen_m_2015_07_02_04_19.jpg http://s6.postimg.org/6wpmasl6p/screen_m_2015_07_02_04_32.png http://s6.postimg.org/bz6y5kugx/screen_m_2015_07_02_04_42.jpg About the WJ being a control character, I would add that it is of general category Cf, which in actual terms is Other (Format), while control characters belong to Cc, named Other (Control). The difference may be slight and a mere terminology topic, but given the bad handling of some format characters by the world's most used word processors, I guess there must be something to be changed. Perhaps the WJ has been forgotten, on the idea that it's only a control. In the case that the WJ has purposely been poorly implemented on Word, that may be to prevent people from using Word for what they should use Publisher. However, I believe that WJs being a part of plain text, they should be properly supported on all text handling applications. And they should be on the keyboard. The solution I suggest is therefore to have the word joiner (and the sequences containing it) on Ctrl+Alt or Kana, and the zero width no-break space on Shift+Ctrl+Alt or Shift+Kana, so that users working efficently on good software may access the preferred character a bit easier than users who must use the deprecated character because their word processor does not properly support the preferred one. I'm sorry to have asked Unicode to remove the recommendation for U+2060. i'm accustomed to Microsoft's word processor, where I've got my huge autoexpand list. (This is written *without* autoexpand.) And I hadn't already tested that on OpenOffice/LibreOffice. Now, that's done. Regards, Marcel
