Espaces fines
If I understand this correctly, then:
- If we say "Abc <nbsp>: def", and I copy it, and paste it into another document, then I will get "Abc : def" (which is good).
- If we say "Abc <nnbsp>: def", and I copy it, and paste it into another document, then I will get "Abc: def" (which is not good, right?).
If I understand this all correctly, then I prefer the one that copies/pastes better. (I don't know whether others will think that is important, but it would be a little helpful to me.)
copy-pastes are NOT removing spaces even if they are nbsp or nnbsp. If this ever happens on a nay device this is a clear violation of standards and a sever bug that may occur on some old versions using incorrect or very antique Unicode databases or making false assumptions.
I've tested on MacOS 13 and 14, both NBSP and NNBSP are supported and work as expected. I've not seen any one silently removed or replaced by SPACE, or not rendered as empty (except in monospaced consoles where NNBSP **may** be invisible but still unbreakable, or consoles using legacy non-Unicode 8-bit charsets like MacRoman, where NBSP may be replaced by SPACE and NNBSP may be dropped)
If you use legacy apps that generate texts not saved in UTF-8 but in legacy charsets (MacRoman, ISO8859-1,Windows1252, CP850, US-ASCII, TISCII, VISCII, TIS620, HKCS, GBK, SJIS,...), the NNBSP may then be dropped and this is not a defect, but NBSP will be replaced by SPACE where needed if the legacy charset maps no NBSP: this is a conversion, not a transcoding, it may be lossy in that case when the legacy charset is not supporting the whole UCS
(note: GB18030 supports the whole UCS, so even if GBK did not, this should no longer occur with GB18030 which is UCS-compliant and can be used now as a conforming UTF even if GB18030 is not defined in the Unicode standard itself but by the PR Chinese standard; GB18030 is not part of the Unicode standard because it also allows other extensions or distinct duplicate encodings that are not mapped to any UCS position, but there's a& GB18030 subset that is bijectively liked to the UCS and this bijection is now warrantied to be stable even in the PR Chinese standard; GB18030 was even amended to explicitly say that these extensioçns are now deprecated adn their support is NOT mandary in any GB18030-conforming application; this means that any Unicode-conforming application is now GB18030 conforming and the reverse is true as well for all newer GB18030 applications that chose to no longer honor the legacy extensions which were part of the unamended GB18030; this also means that the PR Chinese government no longer needs to maintain its own encoding standard, all is done in the UCS directly, along with the work made in the IRG working group for the ideographic script subset in the UCS and coordinated with relevant national standard bodies in PR China, Taiwan, Singapore, North and South Korea, Vietnam, Japan, Thailand, Burma, Mongolia, Russia and other countries having officially recognized Chinese-speaking communities, or with international organizations needing support for modern Chinese, Korean and Japanese, or for educational bodies like linguistic departments of universities).