Fonts and images not rendering correctly

Browser Support
1

Using Brave Version 1.60.118, Sonoma 14.1.1 on an M2 mini
When I enter a degree symbol (shift-option-8) it displays properly when I type it in a forum window but when displayed after I post, it adds a  character in front of the °. Also, every time I open the comment field to edit, more characters are added.

A lot of googling research blames the webpage and how it handles extended characters. But guys on Windows say they don’t have a problem and again, it used to work fine with Brave.

How do I get brave back to good - to show a degree symbol as just a degree symbol - no added letters.

When I select UTF-8 encoding with Safari, it displays properly. When I ask “the internet” or an AI how to change the display encoding in Brave, it starts by leading me to setting choices that are no longer available - like “Advanced”. It wants me to change something in Languages but the only choice I see there is a specific language - like USA English - not an encoding.

Thank you for any insight,
Paul

1 Like
3

I had no issues here, maybe test paste in other forms. Also test in private window mode

4

Let’s see what happens when I post there the following should be a degree symbol (Shift-Option-8 on a Mac) degree symbol = °

So it works here. This is nuts. Of course, the website is saying I’m the only one having the problem (most of their viewers use PC’s) so it must be a problem with my browser. But clearly there is no problem posting into this forum.

5

Still no replies about this issue. Is anyone else having a problem with UTF-8 characters rendering correctly in the Brave Browser?

To see what I mean, go to www.hammockforums.net, click on the “Feedback, Suggestions, and Site Questions” sub-forum, and then the “Fonts not rendering correctly” thread (near the top). Several Windows people who use the Alt+number code say they don’t have a problem. Often people who reply don’t understand that the browser, platform, and OS make a difference.

My issue is with M2 MacMini hardware and Ventura/Sonoma OS. It does not appear with other browsers and other browsers give me the option, usually under a View menu, to change the default encoding.

The tug-of-war is, that some suggestions lay the blame completely on the Website itself, while others say the browser’s settings are at fault.

A strange component is, I’m pretty sure Brave used to render those characters correctly in the past - though I was using Opera in the past too - memory fades.

It’s strange that I can enter the degree symbol correcting in a “post” field such as this, but when it is posted, the degree symbol has an  added to the front. And each time I edit the post, additional characters are added. Or I might post just an  but when the post is displayed that character is rendered as Ã.

So who/what is changing those characters? Is it Brave after I push the Submit button or is the WebSite after it gets my post? And if that’s the case, what do I tell the webmaster so he/she can ferret out the problem on their end?

That’s what I’m looking for.
Thank you,
Paul

1 Like
6

I loaded https://www.hammockforums.net/forum/showthread.php/166385-Fonts-not-rendering-correctly-see-°-for-degree

Seemed to load (on a mac). does it load correctly in Brave Beta?

1 Like
7

Fanboynz, thank you for looking into this. Let’s see how close we are to having equal systems. I’m using an M2 MacMini. I’m running Sonoma OS. The Brave version (says Up-to-Date) is 1.60.118.

When you say, “Seems to load”, I’m not sure what you mean. My issue is with using “special” characters, like the degree symbol.

In this forum, it renders as it should. When I enter Shift-Option-8 here, I get the degree symbol. When I push reply and see my post, I see the degree symbol. All is well.

On the HammockForums.net site. When I enter the Shift-Option-8 in the reply field, it looks okay, but when posted it changes to have a capital circumflex A in front of it.

In fact, that circumflex A - Â - appears all over the website:
“Clark Hammock Company purchased by Dutchware”

I’m in the usual user position where one person says, “It works on our site so it must be the website’s problem.”, while people from the website say, “No one else is having the problem, must be your browser.”

I’m not so keen on loading beta software but I can give it a try. It would help if someone was knowledgeable about UTF-8 issues and could recognize what is going on with the added  character.

1 Like
8

Here’s a more direct question - What encoding does the current Brave Release use? Is there a way to change it if it is not UTF-8?

9

Sorry for the delay, Not sure if we differ from Chrome here, there isn’t any specific patches which would change this from upstream chromium

Looking at brave://settings/languages & brave://settings/fonts

10

Fanboynz - still nothing about encoding, just language selection.
Looks like Brave Updated to a new version today. I’m hesitant to go back to www.hammockforums.net and try it again. I’m pretty sure the webmaster is tired of my posts about this issue there. They think it is just my problem with my browser/Mac/OS choices. And yet, I can type, post, and see the ° (without the leading Â) on other sites. Like this one. :grinning:

11

Does the issue show up Chrome?

12

I don’t use Chrome, don’t have it on my computer. But I do have Safari, FireFox, Opera, and Brave. We know there’s an issue with Brave.

The forum moderator said he hadn’t heard back from his web-tech guy so I’ll wait a few days to see if he gets any feedback. I did try this with other browsers but it’s been some time since and I don’t recall, except that I’m pretty sure it worked on one of them.

The only other detail is I have Grammerly installed but when I disabled it, the problem still persisted. Also the typed character renders correctly when I type it in a box/field like this. It’s only after it’s sent (Push reply/submit) that it gets changed somewhere between the button push and when the reply is displayed as a post. any Circumflex A is changed to and Tilde A. The degree symbol has a Circumflex A added to the front. A single quote might have additional charcters added to the single quote or the single quote itself is replaced with several characters. And if I open the field to edit, but not change anything, additional extra characters are still added to the extra that are already there.

The galling thing is, it used to work fine.

AI bots I’ve asked suggest it’s an issue with the encoding on the web page. But you know the web page keepers are going to say it’s my browser that’s at fault. Because I can’t see what encoding Brave uses, I can’t say (in the words of Bob Dillon), “No, no, no, it ain’t me babe, it ain’t me you’re look’n to blame.”

13

@designer I just had seen this pop up again in recent and was trying to read through your discussions. A while back, I see Fanboynz had asked you to try in private window. I didn’t see anything in any of your responses to suggest you attempted this. Can you verify if you tried in private window? The other thing I’d like to ask is if you can create a second profile by going to Hamburger Menu image → More Tools → Add new profile and test on that. Doing this creates a second profile with default settings and no extensions. It’s just a good troubleshooting step.

I guess I’m just curious if issue might be something within cookies or an extension. Testing private and/or new profile might help check that. At least just wanting to make sure you’ve tested this way.

Testing on it might be helpful though, if you’re willing to get it. That or even just regular Chromium. Main thing is just seeing if it persists that way. If so, it’s easier to know it’s chromium related. But if it doesn’t happen there as well, then it lets everyone know it’s something within Brave that is triggering the issue you’re presenting.

1 Like
14

I created the new profile and logged in with a private window. There was a little progress that I’ve seen a few times before - but thought I was seeing things. When I posted, the characters were correct. But when I opened to post to edit it - saying “It Works!” - then closed my edit, once again the charaters had been changed and this, “” was added in front of the degree symbol (shift-option-8)

1 Like
15

So this does sound like it’s definitely something on the site. I know if you search to ask things such as about the  appearing, it comes up with a lot of varying topics.

But as much as I can see this, I’m not anywhere near knowledgeable enough to know what to guide to afterward.

Also to circle back around, you’re saying this issue doesn’t happen in any of the others except for Brave? If so, I really do hope you could give it a test on Chrome or Chromium. By all means can uninstall after, but wondering if it’s just a chromium engine issue.

16

just a quick answer on that first question - the problem does happen with other browsers - but maybe not all - it’s been a while since I’ve gone down that road and I’m still waiting for a reply from the forum moderator - who is waiting in his web master.

I do know that the windows crowd doesn’t have a problem - inspiring them to be so ready to blame it on my Mac. I am surprised that no Mac owners have chimed in to say if they are, or are not having the same problem on the site.

I will try Chrome. Also, there was a time when this wasn’t a problem. I do have an old High Sierra machine with its vintage software versions.

It just seems that if it was “local”, I’d see it when I typed into the “post” field, as I’m doing now. Also, I’d see the problem here. As you’ve seen from earlier posts, the ° symbol renders fine.

When I use development tools with FireFox, I didn’t see any UTF-8 specification.

I do have Grammerly but the problem persists when I turn that off.

And again - bottom line - it works fine on this webpage.

It definitely looks like a Latin-1 (ISO-8859-1) vs UTF-8 display issue. But who is the Latin (website or Brave) and who is the UTF-8 (website or Brave)?

1 Like
17

What we have here is the classic problem between two pieces of software with the user in the middle.

I have asked HammockForums.net what encoding they use on their website and am still in the “Out tech guy hasn’t gotten back to us yet.” waiting pattern. I have mentioned the problem at length here and have not had a definitive reply stating the encoding Brave uses. Yet, the problem appears to be a mismatch with encoding.

Can anyone state directly what the current Brave (ver: 1.61.104) uses for encoding?

18

They use same as Chromium. To quote from a source back in 2016:

Chrome 55 has removed the Encoding menu and Chrome will do auto-encoding detection now:

https://bugs.chromium.org/p/chromium/issues/detail?id=597488 - Remove encoding menu

So what it has moved to is auto-encoding detection and all. If you want to know more on that, I will quote the below:

The answer to whether Chromium uses UTF by default is a bit nuanced and depends on several factors:

Technically:

  • No, Chromium doesn’t have a fixed default character encoding. This means it relies on various mechanisms to determine the encoding of a web page, including:
    • HTTP headers: If the server sends an Content-Type header specifying the encoding, Chromium will use that.
    • Meta tags: If the HTML document contains a <meta charset> tag, Chromium will use that encoding.
    • Heuristics: If no explicit encoding information is available, Chromium uses a built-in encoding detector to guess the most likely encoding based on the content of the page.

Therefore, while Chromium doesn’t technically have a fixed UTF-8 default, in most practical situations, it will behave as if UTF-8 is the default encoding.

@designer there’s just a lot of little things that can go wrong. For example, I find https://stackoverflow.com/questions/10134754/why-isnt-google-chrome-showing-the-proper-encoding to be a little interesting, where they point out font was the issue for characters not showing up properly rather than an encoding issue. Of course, that also was many years ago as well.

19

I looked into switching to the system font for windows - as window’s users don’t have an issue - but google says it uses “segoe” - which I don’t have on the Mac

I installed Chrome and tried it - same problem.

I read the posts last mentioned and one mentioned deselecting and reselecting Auto-Detect and UTF-8, which is now not available.

The fact that everything seems do display here makes me hesitate to change something on my end.

I need to take a break from this for a few days. Then I’ll start from scratch - Safari, FirFox, Opera, and Brave. I’ll keep Chrome on installed for now; but not forever.

I’ve emailed the Moderator of the forum a few times and you know there’s a fine line between “nudging” and becoming obnoxious. I understand he’s not a web techie - he’s relying on someone else for that, and that someone else hasn’t replied to his inquires.

20

Yeah, that’s why I prompted you prior to linking that they removed the encoding menu. I also then shared the details of how Chromium and Brave determine which encoding is applicable on a site, such as HTTP headers and meta tags.

And on that one thread on stackoverflow, it had person say the solution was them changing their font. Yes, other comments spoke about encoding menu (which doesn’t exist), but I just wanted you to see the conversation of font as I wasn’t sure if that could somehow be an issue on your end.

Remind me, when you’re seeing the Â, does everyone see it? Like the Windows people who said they aren’t having issues, are they seeing the  when you are seeing and posting?

And I’m still kind of stuck on this. Like if you left it alone, would it have stayed fine? Did it only get messed up when you opened to edit it?

At least seeing this affirms it’s not a Brave issue. It’s likely something on your device or the website. Small chance it’s Chromium, but I’d say it’s unlikely. Guess will have to see what you find out.

21

Saoriay, I appreciate you sticking with me on this. It has been very difficult to get definitive answers from the hammock forum members.

For example, they will say they see the “°” symbol but don’t add if they see the  (or other) letters in front of it or not. Or someone will say they don’t see it on their Mac, but don’t mention the Browser or OS (or cpu - Intel or Mac Silicon) they are using. And when they say they “don’t see” the problem. It’s not clear if they mean it doesn’t happen to them or that they don’t see the extra characters in front of the symbols. I can only push so much.

When I started on this journey I was hoping for a quick, “We use [this] encoding (on the web page).” and I would continue my investigation from there. But I’ve heard nothing back from the website - other than, “No one else is having the problem. It must be your web browser.” or “My Web guy hasn’t gotten back to me yet.”

This was not supposed to be a lifetime project :grinning:

It was a minor issue an I thought it would be a quick fix. I’d find out what HammockForums.net was using for encoding and make sure it matched what the browser was doing. As you understand, better than me, it hasn’t been that simple.

I not this was working at one time. it’s been so long now, maybe when I was using Opera I’m trying to recall why I switched from Opera to Brave. So it could be that I changed a display font.

But we can’t ignore the fact that everything works, as is, on other websites - like this one.

The situations where I post my reply, and it shows up correctly, until I edit it, is puzzling to me too because it doesn’t happen that way everytime.

I’ve been picking on the degree symbol because that’s what I was using when I first saw the problem. Note that the characters are also - sometimes - messed up when displaying what other people post. For example (someone else’s post):

l just made an order on the 1.2 Hexon Chameleon…. l have a couple older Chameleons a Multicam and nylon D…. but now keen to go hang out on a limb… with little more of stretch…. Personally liking feels of HyperD…. the NylonD is nice too. Now set to go with 1.2 Hexon…