This question already has answers here:
Rectangles instead of whitespace in Chrome
(2 answers)
Closed 5 years ago.
I had an interesting issue pop up today on a couple of websites I host. Specifically a vertical rectangle character is displaying (mostly) near characters in my code (though I tend to use those sparingly) but only on Windows machines. I've only seen one instance where that the vertical character has displayed in the middle of a paragraph.
I checked the site in Firefox, Chrome and Safari on Mac and didn't see any issues. Even more interestingly, when I log in to the site backend on the Windows machine, the vertical rectangle character is actually selectable and deletable. No clue why this is happening.
Both sites are running on Wordpress. I've attached a screenshot for reference. Thanks!
Unknown Character Reference Screenshot
That is a character that your font doesn't know how to render properly. Try to copy and paste it into google, and see what it says it is. Chances are it is safe to remove it, try retyping that bit of information WITHOUT copying and pasting. Else, try a different font and see if it is still there. See this for more; specifically: The replacement character � (often a black diamond with a white question mark or an empty square box) is a symbol found in the Unicode standard at codepoint U+FFFD in the Specials table. (Bold Added)
Related
Screenshot of webpage, Chrome devtools inspection info, and source code
I have a Wordpress site where, for no reason I can find, the text caption under the graphics is being displayed in the browser as two or more lines, even though there's no line break specified in the source code.
As you can see in the screenshot, when I inspect it with Chrome, the console shows a line break in the code before and after the A tag, as well as two quotation marks around the first "line" that don't appear in the browser's render. However, when viewing the source code in Notepad, neither the line breaks nor the quotation marks are there.
The rendered page, with the erroneous line break, appears the same in Chrome, Firefox, and Edge (the last of which has no add-ons installed). This is all on Windows 10. Firefox's inspection panel shows the line breaks in the code, but not the quotation marks.
The page in the screenshot is behind a paywall, but you can see an identical situation at this link [now-obsolete link redacted]. In fact, it appears to be happening on other pages of the site too, for example this one [now-obsolete link redacted], where you can see an even more extreme example of a line break being inserted before and after every link. This started recently - all of these captions appeared normal, as if only a single line, a couple weeks ago at most.
I am totally stumped. What on earth is going on here? Is this somehow the doing of a WordPress theme/plugin? I could try disabling them all, but even if that fixes it, I'm still dying to know what it means for something to show up as multiple lines in the devtools inspector (and in the rendered output) but not in the actual source code.
The problem was that the A tag had the display: block property applied to it. Thanks to #MuhammadZohaib for the quick reply!
This was entirely my own doing - I had added a rule in the stylesheet making A tags in the caption container tables display as blocks as a way to fix some weird display results on the linked graphics themselves, and didn't realize I had allowed it to apply to the A tags in the actual caption text as well (in fact, I had almost completely forgotten about it).
Apparently the A tag still displays on a separate line in the devtools inspector's code display, but that's fine with me as long as the end users don't see it. Still no idea why Chrome's inspector is showing quotation marks around the first sentence (they're still there even after a hard refresh), but that's also apparently not a problem.
Can you help me with a way to go around this issue?
There is an Arabic font rendering issue, which, at first, I thought was a problem in the font I am currently designing. However, I now believe it originates from the browsers because the same problem appeared in the Arabic Typesetting font (arabtype.ttf), already built into my computer’s Windows 10 Home OS.
Also, this problem happens only in Edge and Chrome browsers under Windows OS and Android, but it doesn’t happen in Firefox.
Further, there is no problem under IOS, not even with Chrome or Edge.
The text renders correctly in MS Word.
The image below, showing text in the Arabic Typesetting font provided by Windows, depicts an example of this problem.
font rendering issue
The Problem: Ideally, a ligature glyph composed of 2, 3, or more characters has diacritical marks positioned in an ordered sequence above or below the combined ligature. The ligature in this example is a combination of two Arabic letters, Jeem and Heh, where the Fatha and Damma diacritics cluster only above the Heh instead of their assigned sequenced order.
You can try the text on the test webpage: https://www.colorfulquran.com/fonts/ProblemOfTheMarksAboveLigatures.html in any browser under any OS.
There is something so peculiar and strange about this problem! As shown in the attached images, a string of text in one paragraph has two occurrences of the same ligature. The problem occurs in one of them, but not the other!
I thought the problem was in the font I was designing. I have been trying to fix it for over three months. Finally, I thought to have fixed the problem by reordering the GSUB lookups. Unfortunately, while the problematic ligatures would render correctly, the same situation would reappear in other ligatures generated correctly before the reordering!
Can you help me with a way to go around this issue? For example, is there anything I should do in the font design? Or maybe something in the HTML/CSS design of the web page?
How can I get such ligature and diacritic intensive Arabic text to render correctly in all browsers under all operating systems?
Thanks.
This post is a follow-up.
I sent my original question to Google Chrome’s “Report an Issue” and MS Edge’s “Send Feedback.” A few days later, I noticed that the problem had disappeared from Chrome. They seem to have fixed it. Thanks, Google. But it still shows in Edge.
On the other hand, thanks to posting the question here, I found a workaround for the issue, although no one responded. While preparing the test webpage linked in the original question, I first thought of emphasizing the problematic words by making them bold. But then I turned them back to regular because, after making them bold, they rendered correctly, which defied the purpose of this question. Using HTML bold tag seems to reset the browser’s font rendering engine. So, as a workaround, I now turn each space between every two words to bold, which will not show, of course, because the space glyph is empty. This workaround seems to work on all browsers, including Edge.
Thanks.
Edge seems to have fixed the issue as well. Thanks, Microsoft.
I'm experiencing an odd rendering problem in SOME versions of Chrome when trying to render the unicode characters U+2795 thru U+2797, the Heavy Plus/Minus/Division Signs. On some versions of Chrome, the sign will render as an ugly gray with some kind of black pseudo-outline, which does not respond to CSS color commands. Here is an image:
For a sample of how it looks on every other browser I've tried, see FileFormat.info - Unicode Character HEAVY PLUS SIGN
By SOME versions, I mean, I can't seem to narrow it down to a particular version of Chrome. The same version of Chrome on two different computers running Win10 will render differently, and I can't find where the difference is.
Is this a bug in Chrome? I can't seem to find where anyone else has run into this problem. I'm trying to include this on a website, but if certain versions of Chrome render it ugly, I need to find another solution.
-- edit --
XY Problem
My purpose is to use the +/- as the "expand/collapse" markers in a collapsible accordion box where the background may be light-colored or dark-colored. I was hoping to be able to color them to match the remainder of the text without needing to resort to images, but based on the comments below I'm starting to think it may be easier to throw together an .svg, recolor it in CSS, and be done with it.
The problem is that the browser is replacing the glyphs with emoji, which will be rendered differently for each browser. Emoji cannot be colored using CSS -- the best you can do is silhouette them and color the silhouette, as described in Color for Unicode Emoji. Unfortunately, this still means that the glyphs will appear differently on different browsers, as the emoji won't render using the font you specify.
There isn't currently a way to force browsers to render glyphs instead of emoji. Appending \FE0E (as described in How to prevent Unicode characters from rendering as emoji in HTML from JavaScript?) will sometimes work, but this is not consistent, not guaranteed, and therefore not recommended.
You can provide a web font which contain the glyphs you need, but this is also not guaranteed to work, as some browsers (especially on mobile devices) will still replace them with emoji.
If you require consistent rendering, the best way seems to be to use an image instead of trying to force the browser not to use an emoji.
Please refer to this jsfiddle.
It includes text, both inside a highcharts chart and outside, where the text includes a "sun" character as shown in this page. I've also included variants both with and without variation selectors (see also here) to see what difference they make.
Outside highcharts:
<p>Embedded: ☼ ☼︎ ☼️</p>
symbols.innerHTML = '<p>Added: \u263C \u263C\uFE0E \u263C\uFE0F</p>';
Inside highcharts:
title: {
text: 'In highcharts: \u263C \u263C\uFE0E \u263C\uFE0F'
},
Now, it seems to depend on which browser you view this jsfiddle as to whether you get a coloured emoji version of the sun symbol, or a plain-text black version... or even both versions!
For example, in Chrome on a Windows desktop you get the plain version all round:
... while in Chrome on Android 7 you get part-plain and part-emoji:
I really don't like that the style of the emoji versions is completely out of my control, particularly when the style clashes horribly with the rest of the page (e.g. the sun symbol is bright orange and the equivalent moon symbol is bright blue).
So I'd like to force the page to use the plain version on all browsers in all contexts... any idea how?
It would seem completely crazy to have to resort to using images, because I want the symbols to have the same appearance as the surrounding text, including text colour (which the user can change at will). And isn't UTF-8 meant to be a character encoding rather than an emoji encoding? I have nothing against cute emojis per se, but only in the right context.
The symbols appearance depends on the font you use.
Please look at your updated jsfiddle.
I've just changed the font on all elements:
* {font-family:serif !important}
Any element can have its own font.
It's up to you which font to use. So choose the right one and tune it up.
Update
I have to clarify several points:
There are NO 'safe' or 'unsafe' fonts.
Basically font works like a key-value storage {code1 => glyph1, code2 => glyph2, ...}, input a code and get the corresponding glyph
Font may or may not contain any code-glyph pair
You can make your own font containing only desired symbols, having codes of your choice associated with glyphs of your choice e.g. \u263d can be any glyph you want, not always the moon
In css font-family: you can specify one or several font-families and/or generic-families (look here). When the style's being applied to the text the browser converts each symbol ('A', ' ' or '\u263d') to its code and tries to get the glyph from the specified font-families until the glyph has been found or no more fonts have left.
If the font contains the desired code-glyph pair we can see a glyph, if not - we can see a space, ?, an outlined rectangle, a rectangle with the code inside, etc. (depends on the browser).
In this case: {font-family:serif} for \u263d browser searches for the glyph for \u263d in all system fonts of generic-family serif. And on Android it firstly finds what you name the 'emoji'.
The solution is to find (see the jsfiddle) or to make (see the other jsfiddle) a font with the desired glyphs and apply it to the desired elements.
Hope it's helpful and clear.
The answer by Kosh Very has hit on something. Indeed, changing the font-family on all elements to serif does indeed result in the plain symbol being used in highcharts, even in Android 7. The trouble is, in actual use I cannot stick to a single "safe" font family... the font can be specified by the user, from any web font listed on Google fonts.
I've updated the jsfiddle to include loading and use of a web font:
// see https://github.com/typekit/webfontloader
WebFont.load({
google: {
families: ['Fresca:400']
}
});
And I use that font throughout, both inside and outside highcharts. The result on Windows Chrome is as before (plain text symbols all over), but now the result in Android 7 Chrome is:
So this now rather suggests that the issue isn't highcharts-specific after all, and more of a font issue as Kosh Very as indicated. Indeed in the original example, without any font stated explicitly, the font used in highcharts is different to that used outside... and probably hence the difference in symbol style.
But I've tried a couple of other completely different web fonts in the updated jsfiddle example, with the same result. In other words, the emoji sun symbol is not apparently coming from the font itself. Perhaps when a font is missing a particular character (these fonts probably don't have a character for every unicode value) then it reverts to using characters from the system font? From other discussions it seems that these coloured emojis might only show on Samsung devices, so maybe the system font on Samsung has these?
The solution (or workaround) seems to be use a "safe font" only where required (for the graphical characters), and your desired font elsewhere, as per this updated jsfiddle, which gives the following result on Android 7 Chrome:
BUT I've hit a snag with this solution... it works nicely for the sun symbol as above, but for the very next unicode character (moon symbol) it doesn't... so maybe that symbol is missing from the serif font family and it reverts again to system emoji.
jsfiddle with moon
So the solution is probably still very patchy... maybe only limited to certain symbols.
Even for a font like Cardo that apparently supports the moon character \u263d, this example doesn't work in Android Chrome... still get the coloured emoji version rather than the plain version.
Never seen before that url bar would change its font, but if you go to the following link in Chrome, you would see that "New Features" is written in different font:
Copying url into text file reveals some magic symbols:
http://g-wiki.net/wiki/Battlefield_3%EF%BC%9ANew_Features
Can anyone explain why it changes font and what else can I do with this technique (can I make red bold letters)?
That's a full-width colon character. The only difference should be that it takes more horizontal space; it's not supposed to affect the font and it doesn't do so for me. However, because it's missing from many fonts, some operating systems might switch to a different font or rendering mode in order to display that character, and may continue to apply this change to subsequent text.
I've noticed this before in instant messaging. I'll copy some Chinese characters into my message, and the rest of it will be displayed differently. It's the same effect and I'd consider this to be a bug in the the operating system/font routines. It's probably not been deliberately programmed.