I have Museo-300 mostly working with #font-face, but certain letter combinations like "ff" and "fi" are disappearing in Firefox (confirmed in v3.6 and v7.0.1). So "microfinance" becomes "micronance".
Note that I'm outputting these as individual letters, not as ligatures. When I view source on both the server and the browser, "coffee" for example is spelled with all six letters individually—not a unicode ligature character for "ff".
The output looks right in Opera, Chrome, Safari, and IE (even IE6).
I downloaded Museo-300 from MyFonts along with their web font example template.
#font-face {
font-family: 'Museo-300';
src: url('webfonts/151B6C_0.eot');
src: url('webfonts/151B6C_0.eot?#iefix') format('embedded-opentype'),url('webfonts/151B6C_0.woff') format('woff'),url('webfonts/151B6C_0.ttf') format('truetype'),url('webfonts/151B6C_0.svg#wf') format('svg');
}
and all the referenced files are in place. I invoke it like this:
font-family: 'Museo-300', sans-serif;
I tried a different font as a test (Code Pro Light Demo, also gotten from MyFonts) and Firefox dropps "fi" but not "ff" for that one.
An idea what's going wrong?
For anyone reading this in the future, note that as of FF 15 (I think) the syntax has now changed, and you'll need to use this:
-moz-font-feature-settings: "liga=0";
-moz-font-feature-settings: "liga" 0;
You can tell Firefox to skip looking for ligatures and treat them as regular characters by adding
-moz-font-feature-settings: "liga=0" in your font-face declaration.
In case others hit this problem, I resolved it with help from MyFonts technical support. I'm not sure whether this issues is specific to MyFonts, but I suspect it affects other web font sources.
Direct (Solvable) Cause
When a standard True Type font (TTF) gets processed into the multiple versions that are useful for a web font (EOT, SVG, WOFF), the processing tool or vendor can decide whether or not to include the font's full character set. Some will default to a reduced character set to reduce file sizes.
In my case, one or more of the generated web font files excluded ligatures, presumably considering them to be non-essential typographic tweaks. To fix the problem I used a custom web font builder at MyFonts to generate font files with the full character set.
(For MyFonts specifically this was at Order History > select relevant font > Webfont Kit Builder tab > Advanced, then check both "Complete Character Set" and "Keep OpenType Layout".)
Underlying Cause
My belief, which is only an educated guess:
I think Firefox is going out of its way to do nice typography, more so than other browsers. So when it sees something that it could render as a ligature ("fi", "fl", "ff", etc.) it tries to render the letters as a single ligature glyph rather than as two distinct characters. If your web font doesn't include the ligature glyphs, your letters will disappear. (If my guess is right, I'm surprised I haven't read about this problem before.)
Myfonts.com recently changed some display settings. Their support wrote back very quickly with the following info:
If you click on the Font image (the image that shows the sample),
which is located right above Kit Options, you will see the Complete
Character set and Keep OpenType Layout options.
This view is not currently available through Firefox though, but I was able to download the complete character sets using IE9.
Related
Not sure if SO is the best place for this question, but don't know where else to ask.
Is there any way to transform a svg like this one for ex: (https://svgsilh.com/image/1775543.html) into something that i can use inside an editor with copy/paste like this one? 🦄
No, because the unicorn emoticon is one example of a character. And just as with letters, digits, and punctuation, the appearance of emoticons and other plain-text symbols is decided by fonts.
LSerni wrote the following:
The reason you can "copy and paste" that icon is that the icon already has a UTF-8 code and your editor is UTF-8 aware. And this is why the same emoticon is slightly different between Apple, Android and so on: it's because it's always code XYZ, but code XYZ is rendered with different icons on different platforms.
But that's not entirely correct. The difference in rendering lies more in the font than in the operating system that displays emoticons. Unless the font supplies its own version of a symbol, that symbol will usually be supplied by the font specified by default by the operating system, and different operating systems supply different symbol fonts.
We're having some trouble displaying the latin small letter a with caron (ǎ or U+01CE) correctly in Windows 10 - Chrome with font-family Verana. It displays the caron next to the letter 'a'. Other fonts display it correctly.
It works fine in Firefox and IE (under Windows/Linux/macOS) with Verdana.
Also Chrome in Linux/macOS displays it perfectly. The combination Windows + Chrome + Verdana seems to be the only one having difficulty.
For example, check Graphemica a with caron and put the font-family of the example letter on
font-family: Verdana
If you have Windows it will display the caron not above, but next to the letter 'a'.
Does anybody have an idea how we can fix this for Windows Chrome users?
Other letters with a caron, for example: č (U+010D) works fine.
Does anybody have a suggestion how we can let this 'ǎ' work in Chrome - Windows - Verdana, without changing the font?
Thanks in advance.
It doesn't display correctly because U+01CE is not present in Verdana. The components (a, caron) are both present, but there is no character (nor any OpenType layout rules) that combine them into U+01CE form. When you see it "working" in other browsers, it's likely because it's substituting with a fallback font whose design is similar to Verdana (or it's at a small text size where you can't see the difference).
More about Verdana here: https://learn.microsoft.com/en-us/typography/font-list/verdana, have a look at the "Code pages" section. None of the listed pages contains U+01CE, so the font simply doesn't support that character. The other characters you mention are in Verdana.
To work around, you could use some simple CSS to set up a fallback for that specific unicode, for example something like this:
#font-face {
font-family: "fallbackfont";
src: local('Tahoma');
unicode-range: U+0100-01FF;
}
<p style='font-family: fallbackfont, Verdana; font-size:72px'>a ǎ</p>
NOTE: I chose local 'Tahoma' for a fallback here because its design is more similar to Verdana than others. And it is selected for use for the entire Unicode range of U+0100-01FF. But you could (probably should) use a webfont or other local/"web-safe" font of your choosing. Also, you could set the unicode-range for just the one character if you're sure that's the only one not displaying correctly for your text.
Take the character "ب". It shows in stack overflow. I can see this in a cshtml file and in a js file
The character "ُ" on the other hand shows here correctly. However it shows as a question mark in the cshtml file and js file. If I copy it to notepad it shows as a Ḍammah (a loop normally above a letter which indicates a 'u' sound)
Why is it a question mark in the cshtml file if notepad understands it? ALso Visual Studio understands other arabic characters so why not this one
All I can think of is that a Dammah (as far as I know) always sits above another letter so can't be used in isolation?
What I'm trying to do is detect words that have a Dammah in them via Javascript
I'm completely new to unicode and non acii characters so this may be a stupid question, apologies if so
It often happens that an application uses a default font that does not support all the unicode characters that a usecase requires. In such a case, try to change the font to a more compatible one. "Courier New" works mostly well, also "Arial Unicode MS" does a good job. But there is no font that covers totally everything, so maybe you will need to switch between two or three fonts to cover all required characters. For Arabic, "Arial" is a good choice, but there are many interesting alternatives.
Firefox can display the following character in div but cannot display it in input.
龗 滙 羣 邨 埗 衞
There are two issues here. First, Firefox (like browsers in general) uses a specific default font for input element (though this font depends on user settings). That font may well lack glyphs for some characters that are present in the font used for normal text (whether as per browser defaults or as per your CSS settings). This can be handled by setting the font-family for input elements suitably. To set it the same as the normal text font, you can use the following CSS rule:
input { font-family: inherit }
Second, your data contains Private Use code points such as U+F5D0. They have absolutely no meaning outside of private agreements on their use. In HTML, they are typically used in conjunction with privately-encoded “icon fonts” that have fancy icons placed in those code points, though they might also be used e.g. for rare Chinese characters (typically occurring in proper names only) that have not (yet) been encoded as characters in Unicode.
This means that such a specific font must be used to make any sense of the content. To make things work across devices, this should be a downloadable font specified with #font-face. If you have done that, simply declare that same font for input elements in CSS.
The browser shoule be able to display HKSCS if the Font set as 細明體_HKSCS, MingLiu_HKSCS, PMingLiU or MingLiU.
I tested in Firefox, Internet explorer and Chrome.
I'm trying to find a way to make dingbats appear exactly the same in Firefox, Chrome, Safari and IE.
I noticed that the Dingbats appear the same in IE/Chrome/Safari, HOWEVER - in Firefox - they look "thinner".
For example - try to visit the following page:
http://en.wikipedia.org/wiki/Dingbat
You'll notice that when viewing that page in Firefox - the characters look different in comparison to Chrome/IE.
Does anybody know why and how can I cause Firefox to display the characters EXACTLY like they appear in Chrome/IE?
I'm trying to find a way to make dingbats appear exactly the same
You will never make fonts look exactly the same in all browsers, whether the characters in question are Dingbats or not.
For me, most of the characters on that page don't render in IE or WebKit. IE traditionally has poorer font fallback than average and Firefox typically better then average. The font that Firefox and Opera manage to choose to render the symbols for me is Meiryo (a Japanese font installed with Windows Vista and later). On IE and WebKit it falls back to the much more limited selection of symbols available in Arial, leaving most of the characters missing.
So for the best chance of rendering symbol characters how you want, do as you do for any other characters, and specify the font you want, eg. CSS font-family: Meiryo. But of course anyone who doesn't have that font installed will get something different, and browser/OS settings may change how fonts are rendered in general.
The symbol characters from the Zapf Dingbats set are not safe to use on the web, as the basic default sets of fonts installed by operating systems do not typically include glyphs for most of them. (‘Wingdings’ on Windows does, but it's a legacy font with a custom mapping that puts the symbols on ASCII characters instead of where they should be in Unicode, so again it's not safe to use on the web.)
There are a few symbol characters that you can typically get away with using for commonly-available font sets, eg:
● ■ ☺ ☻ ♥ ♦ ♣ ♠ • ▲ ▼
others, I'd try to avoid.
Interesting...On a MacOS X 10.6.6 machine with Firefox 3.6.13 and Chrome 8.0.552.231, the Wikipedia pages do render the first table, the ITC Zapf Dingbats, slightly differently. The effect is most noticeable on the solid half-circle at the bottom left corner of the set of characters.
The main Unicode Dingbats table renders almost the same; Firefox generates boxes containing the 4 hex digits of the missing character for the missing symbols, but Chrome just generates empty boxes - I prefer Firefox's technique.
The browsers must either be using slightly different fonts or slightly different font sizes (though I can't detect a size difference by eye). I've not looked at the HTML that is being rendered.
On the whole, I think that this is within the realm of 'allowable variation' - but I'm not an expert. I suspect you have a world of worry ahead of you if you demand pixel-for-pixel similarity between browsers. The concern should be to get the message across clearly.