Re: NBSP supposed to stretch, right?
On 2019-12-17 12:50 AM, Shriramana Sharma via Unicode wrote: I would have gone and filed this as a LibreOffice bug since that's the software I use most, but when I found this is a cross-software problem, I thought it would be best to have this discussed and documented here (and in a future version of the standard). There's a bug report for the LibreOffice application here... https://bugs.documentfoundation.org/show_bug.cgi?id=41652 ...which shows an interesting history of the situation. One issue is whether to be Unicode compliant or MS-Word compliant. MS-Word had apparently corrected the bug with Word 2013 but had reverted to the incorrect behavior by the time Word 2016 rolled out. On that page it's noted that applications like InDesign, Firefox, TeX, and QuarkXPress handle U+00A0 correctly.
Re: HEAVY EQUALS SIGN
On 2019-12-18 12:42 PM, Marius Spix via Unicode wrote: Unicode has a HEAVY PLUS SIGN (U+2795) and a HEAVY MINUS SIGN (U+2796). I wonder, if a HEAVY EQUALS SIGN could complete that character set. This would allow emoji phrases like ➕= ❤️. (man plus cat equals love) looking typographically better, when you replace the equals sign with a new HEAVY EQUALS SIGN character. Thoughts? Marius ➕ ⚌ ❤️
Re: HEAVY EQUALS SIGN
On Wednesday, December 18, 2019 9:43:06 PM PST Joao S. O. Bueno via Unicode wrote: > Maybe it would make more sense to try and check whether modification > combining characters to shift the change the combined character into other > weight/decoration/color and/or other character effects could be built, that > could be used not only along emoji, but with all other characters. > > Currently those transforms require the use of another text protocol, like > HTML, or ANSI sequences for terminal, or even proprietary and add-hoc text > file structures like Microsoft's .doc and .rtf (and other not that > proprietary, but equally dependant on specific software to be proper > rendered, like .ooxml and .odf). > > Does anyone know if there is already an initiative like that? I'd like to > know more about it. There was a request like this, and it was first recommended for rejection by the Script Ad Hoc committee, and was then rejected by the Unicode Technical Committee. It wasn't for bold, it was for italic, but the reasons for its rejection apply broadly to bold, rotalic, etc. The request was L2/19-063, “A proposal for encoding italics in plain text using Variation Selector 14,” by William Overington, submitted 2019-02-07. Deborah Anderson, et al., recommended the request for rejection in L2/19-173, “Recommendations to UTC #159 April-May 2019 on Script Proposals”. In practice, although the UTC has the power to ignore their recommendation, they rarely ever do. Overington tried to answer some of their concerns in L2/19-195, “Comments on comments about L2/19-063 Italics in Plain Text”. His comments did not sway the UTC and the UTC rejected the request. https://www.unicode.org/L2/L2019/19122.htm#159-C24 It's not worth writing another request for generic bold/italic in plaintext for any glyph in my humble opinion. The UTC and its subcommittees are opposed. I agree with them, so do many others. Best, Fred Brennan
Re: NBSP supposed to stretch, right?
U+0020 SPACE U+00A0 NO-BREAK SPACE These two characters are equal in every way except that one of them offers an opportunity for a line break and the other does not. If the above statement is true, then any conformant application must treat/process/display both characters identically. Responding to Asmus Freytag, > Now, if someone can show us that there are widespread implementations that > follow the above recommendation and have no interoperability issues with HTML > then I may change my tune. Can anyone show us that there are widespread implementations which would break if they started following the above recommendation? Quoting from this HTML basics page, http://www.htmlbasictutor.ca/non-breaking-space.htm “Some browsers will ignore beyond the first instance of the non-breaking space.” and “Not all browsers acknowledge the additional instances of the non-breaking space.” Fifteen or twenty years ago, we used NO-BREAK SPACE to indent paragraphs and to position text and graphics. Both of those uses are presently considered no-nos because some browsers collapse NBSPs and because there are proper ways now to accomplish these kinds of effects. The introduction of browsers which collapsed NBSP strings broke existing web pages. Perhaps the developers of those browsers decided that SPACE and NO-BREAK SPACE are indeed identical except for line breaking. Are there any modern mark-up language uses of SPACE vs NO-BREAK SPACE which would be broken if they follow the above recommendation?
Re: NBSP supposed to stretch, right?
On 12/17/2019 5:49 PM, James Kass via Unicode wrote: Asmus Freytag wrote, > And any recommendation that is not compatible with what the overwhelming > majority of software has been doing should be ignored (or only enabled on > explicit user input). > > Otherwise, you'll just advocating for a massively breaking change. It seems like the recommendations are already in place and the “overwhelming majority of software” is already disregarding them. so they are dead letter and should be deprecated... I don’t see the massively breaking change here. Are there any illustrations? If legacy text containing NON-BREAK SPACE characters is popped into a justifier, the worst thing that can happen is that the text will be correctly justified under a revised application. That’s not breaking anything, it’s fixing it. Unlike changing the font-face, font size, or page width (which often results in reformatting the text), the line breaks are calculated before justification occurs. If a string of NON-BREAK SPACE characters appears in an HTML file, the browser should proportionally adjust all of those space characters identically with the “normal” space characters. This should preserve the authorial intent. As for pre-Unicode usage of NON-BREAK SPACE, were there ever any exlicit guidelines suggesting that the normal SPACE character should expand or contract for justification but that the NON-BREAK SPACE must not expand or contract?
Re: HEAVY EQUALS SIGN
I think that as your object is emoji drawing, not mathematics, this request can't be justified that way. Maybe it would make more sense to try and check whether modification combining characters to shift the change the combined character into other weight/decoration/color and/or other character effects could be built, that could be used not only along emoji, but with all other characters. Currently those transforms require the use of another text protocol, like HTML, or ANSI sequences for terminal, or even proprietary and add-hoc text file structures like Microsoft's .doc and .rtf (and other not that proprietary, but equally dependant on specific software to be proper rendered, like .ooxml and .odf). Since modificator characters for color and others have been tried and tested in Unicode land for some emojis, the ball to have in-unicode proper character transforms could start to roll - Does anyone know if there is already an initiative like that? I'd like to know more about it. (as for the O.P.: I think the way out for you now is to use an out-of-unicode markup to select a heavier-looking font for the `+` and `=` characters) js -><- On Wed, 18 Dec 2019 at 09:42, Marius Spix via Unicode wrote: > Unicode has a HEAVY PLUS SIGN (U+2795) and a HEAVY MINUS SIGN (U+2796). > I wonder, if a HEAVY EQUALS SIGN could complete that character set. > This would allow emoji phrases like ➕= ❤️. (man plus cat equals > love) looking typographically better, when you replace the equals sign > with a new HEAVY EQUALS SIGN character. Thoughts? > > Marius >
HEAVY EQUALS SIGN
Unicode has a HEAVY PLUS SIGN (U+2795) and a HEAVY MINUS SIGN (U+2796). I wonder, if a HEAVY EQUALS SIGN could complete that character set. This would allow emoji phrases like ➕= ❤️. (man plus cat equals love) looking typographically better, when you replace the equals sign with a new HEAVY EQUALS SIGN character. Thoughts? Marius pgpL2KRR84mbX.pgp Description: Digitale Signatur von OpenPGP
