Description of the issue:
In several common fonts, text containing non-breaking hyphens (Unicode U+2011 or & # 8209 ; ) displays a box instead of a hyphen.
How can this issue be reproduced?
Load any website containing a non-breaking hyphen in various fonts including Verdana, Arial, and Times. For example, the page https://LincMad.com/nbh.html shows those three fonts plus Palatino (which works correctly).
Expected result:
The word “non‑breaking” should display with a hyphen in the middle, not a ▯. The glyph exists in all of the fonts mentioned above, and other browsers display it correctly in all 4 fonts.
Additional Information:
Other browsers tested on MacOS 12.2.1 (x86_64): Safari 15.3 (17612.4.9.1.8), Firefox 97.0.2, Google Chrome 99.0.4484.51 (does NOT work correctly, same as Brave).
Other browsers tested on iOS 15.3.1: Chrome (DOES work), Firefox, Safari
I just now upgraded to 1.36.111 (the “check for updates” feature on v1.35.104 gave me a never-ending rotating cursor for some reason, but I manually downloaded the new one). However, I still get the problem, in a regular window or a private window. (I didn’t bother to disable scripts or cross-site stuff, because the test page has literally nothing but CSS styles to set the fonts and then the sample text).
The problem also still shows up on this page, directly under “Expected result” in the original post.
I stumbled upon another issue that appears related. On the English Wikipedia page for Croatia, the pronunciation of the Croatian name Hrvatska in IPA symbols is mangled beyond recognition. The text in question is, in ASCII (minus the & and with spaces added for clarity),
[ x #x0159; #x0329; #x028B; a #x02D0; tska #x02D0; ]
Character U+0159 displays correctly, but the other three character entities do not. The Apple Dictionary app displays them correctly, AS DOES CHROME.
I am currently using Brave 1.36.119 (Chromium 99.0.4844.83) and Chrome 99.0.4844.83 on MacOS 12.3.0 (x86), which suggests that this problem is at least partly in Brave itself rather than in the Chrome engine.
I haven’t encountered any case of Brave incorrectly displaying basic ASCII characters, particularly not displaying them as Devanagari. That seems likely to be a different issue from this case of mangling some non-ASCII characters. Take a screen grab and post it as a new thread, along with details of the website(s) where you encountered the problem, version numbers of Brave and the OS, etc.
My (first) guess, is that both problems are in Chromium, and might be closely related.
Roughly around the time that you made the OP, was about the same time when foreign language characters appeared instead of English. First, Russian, then lately, Devanagari.
Occurring first, in search engine results . . . but lately, creeping into pieces of some webpages (examples of, I included in the link I provided).
As if, somebody is messing around in a certain area within Chromium?
I am concerned about a potential intruder, who is testing pathways into Chromium.
But, I just checked by way of Safari, and get the same result - foreign characters in some portions.
So, maybe a situation not related to your OP. Apologies.
Hello, @lincmad. I couldn’t reproduce these issues in Brave Nightly (1.39.10 / 100.0.4896.46), so I downloaded the official current release (1.37.109 / 100.0.4896.60 - guess Nightly needs updating). Neither issue appeared in the current release, either, so since the version is a bit farther on than the last you reported, perhaps updating will fix the issue?
There’s a slight chance that it’s a Monterrey thing. I’m on an old Intel MBP running macOS Version 10.14.6, but when I leave the office I can check on a Mac running macOS 12.3.
Well, this is just weird. Brave in 12.3 also had the issue on the Croatia page, only maybe worse than 12.2, so I started tinkering with the brave://settings/fonts option under Appearance in Brave Settings. This showed the issue on the non-breaking space page @lincmad created, too.
@Mattches There really appears to be an issue with the way Chromium-based browsers handle 12.3’s versions or renderings of the on-board sans serif fonts. Brave and Epic (based on Chromium) both show the issue, while Firefox and Safari do not. Of course, I can’t figure out how to change fonts in Safari and it’s probably using Helvetica, which works fine in Brave, too.
This is hardly exhaustive, but in Brave, Verdana, Trebuchet MS, Skia, and PT Sans yield boxes or spaces where the special divider characters are, but Arial, DejaVu Sans, and Helvetica work fine. The ages of most of these are suspect because I’m using the listed copyright dates, and Helvetica demonstrates that the copyright date may not reflect the date the version was actually created.
Verdana (Version 5.01x (c) 2006):
Trebuchet MS (Version 5.00x (c) 2006):
Skia (Version 13.0d1e54 (c) maybe 2014):
PT Sans (Version 13.0d3e2
(c) 2009):
Arial (Version 5.01.2x (c) 2006):
DejaVu Sans (Version 2.37 (c) 2006):
Helvetica (version 17.0d1e1; 2020-09-21 (c) 2006):
This was supposed to be fixed in cr98 but apparently it was not. At any rate we’ll likely have to wait for an upstream fix for this. Apologies for the inconvenience. I’ve reached out to our macOS team with this info as well, just in case they know more than I do (they usually do).
I have updated to macOS 12.3.1, Brave 1.37.111 (Chromium 100.0.4896.79), and Chrome 100.0.4896.75, and I found the following results:
• both Brave and Chrome continue to incorrectly display non-breaking hyphens
• Brave continues to incorrectly display the IPA symbols in the Wikipedia “Croatia” page, but Chrome displays them correctly
• Safari and Firefox continue to display all of the above correctly
