I'm using 'Raleway' from Google webfonts in my Wordpress site. The standard number glyphs in this font are 'Old Style', meaning some number go over and others under the baseline. When I download and check out the font in Fontlab, I can see there are glyphs with modern styled numbers, they don't have unicode numbers assigned to them, but they have names like three.lnum or eight.lnum
Is there a way to display these glyphs from custom fonts in Wordpress? They don't show up in the Special Characters List. Thanks.
By adding font-feature-settings: "lnum" 1; to the CSS you can force lining numerals.
There is apparently a problem with Raleway hosted at GoogleFonts which hampers the font-feature-settings. This means you have to host the font yourself. Luckily Raleway is free to redistribute.
You can download it from GoogleFonts and run it through the FontSquirrel Webfont Generator. Set options to Expert, under OpenType Flattening check Lining Numerals to set lining numerals as the default for your version of the font.
There is a great article at codesmite.com explaining old style and lining numerals.
Related
I've got a font rendered on webkit (specifically in the text editor "Nano") and I'd like to display an OTF font that has a variant called "Garamond Premier Pro Italic Display". I believe it's a "suitcase" font.
Here's what the font looks like in Font Book:
Things I've tried:
font-variant-alternates: character-variant("ItDisp");
and
font-variant-alternates: character-variant("Garamond Premier Pro Italic Display");
No dice.
Any thoughts here? Or is this just not possible?
Unfortunatly this is not possible on the web at the time of writing.
The only real options available to use are as follows:
italic
normal
oblique
You can read up on the font-style attribute and the different things you can do with it here: https://developer.mozilla.org/en-US/docs/Web/CSS/font-style
There are /MANY/ fonts on desktop platforms that simply will not work on the web, as the web use different file formats. It is recommended to use fonts that are specifically designed for use on the web.
Also a note that font-variant-alternates is only supported in Firefox 34+ and Safari, and as such should not be used in production.
I'm using the following css:
#font-face {
font-family: 'bariol_regularregular';
src: url('Bariol_Regular.otf');
}
The font is being used and there are no errors on the page. When I add this custom font to text on the page it is visibly different to the default styling.
This is how the font should show:
However, this is how it is showing:
Pay particular attention to the apostrophe (') and the letter'g' where the most noticeable differences occur.
If I use a native app then the font shows correctly. The demo lettering on the site where I downloaded the font also displays correctly - https://www.dafontfree.net/freefonts-bariol-f64170.htm
Is there something I'm missing/not doing correctly?
The typeface has multiple glyphs available for various characters so you'll need to find the character codes.
The goal is to remove the bold letters from fl and fi in the text
chrome 61
I was able to reproduce the issue in this codepen:
https://codepen.io/jossnaz/pen/vWgEGB
basically fira sans not applying any letter-spacing to the chars and they chars are bold. No idea why.
this is how it looks on firefox 56:
There is a CSS attribute designed for controlling how ligatures are generated automatically by browsers.
Try adding:
font-variant-ligatures: none;
to your paragraph element.
See this codepen: https://codepen.io/jossnaz/pen/vWgEGB
For the issue where you want to control character spacing, and your source text is composed like "truffle shuffle" with separate F and L characters, this will prevent the browser from generating ligatures and apply spacing as you'd probably expect.
However, this is not the only issue you are running into in your site!
In your page, the text is actually using the Unicode fi and fl ligature characters (U+FB01 and U+FB02). The browser will not separate these back into separate characters, and they are not included by the Google Fonts API. This is possibly some plugin in your CMS automatically converting ligatures, or perhaps the result of copying and pasting from an editor.
See: https://codepen.io/anon/pen/mqmLLZ for an example of this.
These ligature characters are not included in the webfont - the Latin ligatures are at U+FB00-FB06 and either the font or Google's Font API doesn't include them.
As a result, they are switching to the fallback font, which in this case is specified as the generic sans-serif - probably Arial or Helvetica.
They're not bold per se, but they're heavier than Fira Sans.
I'm having an issue with a script font called Thirsty Script Bold that I'm using on my site. The letter spacing appears to be correct for some letters, but not for others. I haven't even touched the letter spacing though. You can see an example of it here:
http://oi40.tinypic.com/2wpikgw.jpg. As you can see, the end of the "e" doesnt fully merge with the "b" and the "b" is too far right to merge with the "s".
I have tried messing with letter spacing, but it just seems to worsen the problem.
Here's my css for the page-
p.websites{
font-family: ThirstyScriptBold;
font-size: 80px;
text-align: center;
margin:0 auto;
}
Here's my HTML for the page-
<p class="websites">Websites</p>
Here's my css for fontface-
#font-face {font-family: 'ThirstyScriptBold';src: url('ThirstyScriptBold.eot');src: url('ThirstyScriptBold.eot?#iefix') format('embedded-opentype'),url('ThirstyScriptBold.woff') format('woff'),url('ThirstyScriptBold.ttf') format('truetype');}
This looks like a design flaw in the font, but it may actually depend on lack of kerning. Most browsers do not apply kerning by default, though Firefox does. So you could first try whether adding the following helps:
p.websites {
-webkit-font-feature-settings: "kern";
-moz-font-feature-settings: "kern";
font-feature-settings: "kern";
}
It is also possible that the software used to generate the web font versions destroyed the kerning table; this often happens. I would expect however that the Webfont package sold by fonts.com contains the WOFF, EOT, TTF, and SVG versions with kerning and other OpenType features properly included.
Unfortunately. I believe that is how the font is displayed. I recommend using another font that is similar, but works. You can find one for free at: http://www.google.com/fonts/
I ran into the same problem using the Thirsty Script web font. The foundry (Yellow Design Studio) stripped of all the OpenType features from the web fonts. This seems to have removed the kerning data.
"All OpenType features and all extended glyphs have been removed."
I solved the issue by using the Font Squirrel web font generator to make a new set of web fonts.
If you define an incorrect behavior, what you really need to do is notify the author (or vendor) of the font about the problem. On first, after fixing, you'll have a correct version of the font. On second, this will help other users of this font avoid the same problem in a future.
IE has trouble with #&8302;(Actual character references) be interpreted as white space
with multi byte
OK:http://tmp.zeg.la/shift_jis.html
OK:http://tmp.zeg.la/euc-jp.html
NOT OK:http://tmp.zeg.la/utf-8.html
I don't get white space, I get squares, and it's not to do with the character references, it's just because IE can't render that character in the fonts it is trying to use.
The browser needs to know the language of the document to choose the default font to render the document in. Each language has its own default font, for example Times New Roman for Latin alphabets, or MS Gothic for Japanese. You can change the default font for a language from the browser settings.
Some browsers switch the default font based on language, so you can set it by saying lang="ja" for Japanese. Others (such as IE) switch it based on the encoding of the page, so that encodings that are normally associated with Japanese such as Shift-JIS pick up a Japanese font by default. This is somewhat unfortunate as really the encoding of the page should have nothing to do with the font, but it's heuristic in common use. Some browsers use both.
This probably wouldn't greatly matter, except that IE is notoriously poor at choosing fall-back fonts for when glyphs aren't available in the selected font. If it hasn't managed to choose a particular font for the language in the document, it may well end up with the squares. For what it's worth, I get Japanese rendered correct for all your example pages when using a real Japanese Windows install (with Japanese as the locale for the system code page), but squares on an English install with extra Japanese fonts installed.
So:
(1) mark your document as being in Japanese:
<html lang="ja">
(2) use CSS to direct IE to the Japanese fonts that most IE users are likely to have installed:
body { font-family: "Meiryo", "MS Gothic", "ＭＳ 明朝", Verdana, sans-serif; }