I recently discovered this historical document, which purports to act as a test of UTF-8 encoding for whatever application displays it.
When I paste it into my terminal (iterm2), it loads the box drawings at the end beautifully (except for a couple at bottom right):
But in both Chrome and Firefox, they are crooked and clearly wrong:
It seems the difference has to do with the width of the rendered character: for example "╲" displays in my terminal as wide as other characters such as "a", but in the browser it displays wider.
Is this a deliberate choice, and if so what inspired it? If not, where is the right place to file a bug?
EDIT
Thanks to Tom Blodget's answer, I am now aware that fonts are an important consideration. I'll clarify:
In my screenshots above, Firefox and Chrome are using Courier as the monospace font, while the terminal is using Monaco. In both contexts, the font seems to apply as much to the box-drawing characters as to the ASCII ones: when I change the font, the appearance of the drawings changes as well as that of the surrounding text.
When I switch the terminal to either Courier or Courier New, it shows the box drawings equally well -- in some ways better!
When I switch either browser to Monaco, it still shows the box drawings wrong, again from characters apparently displaying at a wider-than-monospace width.
So it still seems like the browsers are doing something wrong.
When I go to dev tools, I see the entire test is one pre element. Several fonts are being used on my system. Everything looks okay except the hatch pattern on the right.
If I hack out all of the other text, the only font used is Consolas and it looks okay. I think it's down to which fonts you have, how the browser prioritizes them, especially when it has to use more than one, and (conjecture) two monospaced fonts need not have the same width.
A terminal is likely to be less adept at using multiple fonts, instead, using one fixed one or selecting one "best" match for the required characters.
[Google Chrome 72.0.3626.96 on Windows 10.]
This is likely the same as https://bugs.debian.org/981577
If you have any old fonts installed that don't cover the unicode BOX DRAWING range, it's likely that your browser is stitching them together. While each font itself might be monospace (each glyph is the same width within the font), the combination of fonts might not be monospace (because glyph width differs between fonts), which is why the alignment fails.
I found on my system that uninstalling the legacy Bitstream Vera font resolved the issue. (Bitstream Vera has been superseded by DejaVu Sans)
Related
Why does gvim guifont look too wide, or "interfont" space too wide, regardless of which one I choose?
Instead of looking like this:
It looks like this:
What I've tried
I checked the installed fonts into the docker container:
$ fc-list | grep -i light
/usr/share/fonts/dejavu/DejaVuSans-ExtraLight.ttf: DejaVu Sans,DejaVu Sans Light:style=ExtraLight
$
Then I try such font on gvim:
But it still looks wider than the . Same thing if I try with another font.
So, what do I need to do to make it look like the first screenshot?
Where to start?
In the first screenshot, the name of the font in use is clearly visible: Inconsolata. If you want another GVim to look like that one, you will rather obviously need the same font. If you don't have it, then install it.
As for why your attempts were unsuccessful… fonts basically exist in two kinds:
"Variable-width", where each glyph has its own metrics and the spacing between two glyphs can also be adjusted on a case-by-case basis.
These fonts are optimised for reading in a natural way, where your eyes follow the horizontal flow of the text. They are the default fonts used in word processors, web pages, or books.
"Fixed-width" (or "monospaced"), where all glyphs have the exact same metrics and no attempt is made to adjust spacing between glyphs.
These fonts are optimised for being displayed in a grid, with each glyph perfectly aligned horizontally and vertically with the others, allowing your eyes to process text in both directions, following alignments, patterns, etc. They are the default fonts used in terminal emulators and programming text editors/IDEs.
GVim being nothing more than a glorified and extremely specialised terminal emulator, it only knows how to display text in a grid so it only really works with monospaced fonts like Inconsolata. Tell it to use a variable-width font and you get a mess.
DejaVu Sans being a variable-width font, you get the only possible outcome. If you choose Monospace from that font chooser you should get a usable, at least, setup.
I am trying to insert Unicode characters into a TextView. In particular, I want to include a check mark and an "X". I found two Unicode characters to do this, namely \u2714 and \u2716. These show up as shown below. These are Ok I guess but I'm not crazy about the colors. Ideally, the check mark would be green and the cross red. Or at least both the same color. TextView.setTextColor doesn't help.
My guess is that these colors are baked into the font (typeface). I guess I could download a boatload of TrueType fonts and try them one-by-one, but that seems like cruel and unusual punishment.
Does anybody know a way to change the colors? (or otherwise do what I want)
I suppose I could re-architect the app to use images but that would entail unacceptably major re-structuring.
Well, no one responded, so I'm posting this answer to capture what I think I learned. From my reading, it appears that color in TrueType fonts is a non-standard, vendor-specific extension to the TrueType specification, which was added to accommodate emoticons. So I guess I'm out of luck. Fortunately, It works fine on my Samsung if I can tolerate the colors.
I've been building a website under Ubuntu 17.10 and use Firefox and Chromium for testing. The two browsers show quite different colors (not only for images but all colors) and I always thought that it is Chromium which for some reason wrongly over-saturates them, so up until now I always chose colors that looked right in Firefox.
But I'm starting to get more and more complaints about the website's background being too purple - which it shouldn't be in my opinion as only the blue component of it's color (#eeeeff) is "elevated", but it has reached a point that more people are seeing it as purple than blue, what makes me confused.
This is the aforementioned color displayed in Firefox (left) and Chromium (right).
And this is how I see a website:
The difference is quite large (notice how even the favicon is different) and I'm asking you to tell me which one is the browser I should trust when choosing the colours of my websites and whether I could do something to avoid it being displayed so differently in different browsers.
(There are some users that see the overly saturated colors in Firefox too. So now which is the right one, really?)
Another option is to open chrome://flags/ and select the option sRGB on the Force color profile item.
By using this setting instead of disabling the Use hardware acceleration when available, you don't lose some nice features like the 3D view on Google Maps.
Solution found here: https://www.reddit.com/r/Fedora/comments/74h5yh/blue_shows_as_purple_in_chrome/
Using GPick as a Color Picker and calling a Website with Color Hexcode like
http://www.color-hex.com/color-palette/54430
I see, that Firefox renders the RGB Colors exactly, meaning GPick identifies the same Hex Code from CSS.
Whereas Chromium renders some kind of differnt color.
You can call
chrome://flags/#force-color-profile
and set the Color Profile in Chromium to sRGB, so the rendered Color from Chromium is identified the same as the HexCode with GPick.
If you disable 'Use hardware acceleration when available' in Chromium Settings and relaunch, Chromium displays colors correctly. When turned on, Chromium colors are off. I consider this as a workaround until Chromium color management issue with hardware acceleration is resolved.
With the other two colours being equal, your colour is right in the middle of "blue territory".
If you convert it to HSL and look on the hue line, you can see it is right in the middle of the "blue" frequency range.
Consequently, any hint of green or red is incorrect.
Hi I'm using Inconsolata for powerline font in linux (link 1). Now I want to had some extra symbols. I've successfully added the awesome font symbols from the Inconsolata patched fonts in link 2 to my own copy of Inconsolata for powerline font (i.e. I can successfully copy glyphs to my font and they appear on the terminal).
However when I try to add icons from other fonts, namely the battery icons from Typicons (see link 3) they simply do not appear in the terminal. I've scaled and changed multiple properties but it's always the same.
I'm doing fc-cache -fv and I've checked that if I manually create a glyph it appears after an fc-cache. I'm completely lost here, I'm sure it must be something simple but I've already lost a lot of hours with this and the glyphs never appear in the terminal no matter what I do :-(
Try adding few glyphs from each to a new font file project. If it is a symbol-only font and you don't care/need to follow Unicode assignments, use codepoints for alphabetical characters and numbers.
Generate your file and check for errors. Fix any issues reported by FontForge.
I've discovered the problem. In two words lbearing and rbearing. They must be the same as the other glyphs. The size is also important. Even with a similar lbearing and rbearing if the size of the glyph is too big it will not appear.
There are small lines appearing sometimes in front of words. In the pictures they are to the right of +syntax/ and swo and delmenu.vim.
Is this a bug or those lines mean something?
Do this happened to you before?
Would they get worse in the future?
PS: I'm using Microsoft Windows XP SP2 AMD
alt text http://img97.imageshack.us/img97/7673/picpd.jpg
EDIT: I change the font to Consolas and they disappeared. Is there a way to solve the problem while still using my favorite font, Monaco (and not turning off Cleartype)?
This is caused by cleartype font smoothing.
If you use a fixed font for gvim the problem goes away (.fon files). ttf files contain font smoothing information which gets messed up in gvim.
fixedsys renders well. There are a bunch of other ones that also work well.
An alternative is to turn off font smoothing altogher using the display properties, but that will have undesirable effects on all other applications.
This does indeed look like a rendering bug. You should report it to the gvim team. But you should also never use jpegs for screen shots - the compression doesn't work nearly as well as pngs, and could potentially introduce distortion in shots exactly like this one.
Just a guess, but it may be related to the font you are using. Maybe you could try to change it to see if these lines still appear, or disappear, or move to other lines ...