I have a font I want to use on my website. I live in a country where we use characters like "š,ř,č,ž,ě" and so on. I need those characters. When I open up Photoshop and use my font, it works with these (latin-extended I guess) chars without a problem.
When I use Font Squirrel to generate the #font-face, I set it all up to include almost every character possible. Still, in the character demo they provide in the download, the special-encoding characters are missing.
What could be the problem? Any solutions? I'm 100% sure the font supports the chars, but it seems Font Squirrel disregards that support. Or I'm setting something not the way I'm supposed to. Any alternatives? Thanks!
Related
I converted an SVG font to OTF using FontForge. I know the original font has certain errors, but really don't think any of those errors would cause the following issue:
When using CSS
writing-mode:vertical-lr; text-orientation:upright, I get the following results. The Firefox rendering is perfect, but for some reason the results seem to kern certain letter combinations in Chrome (ver. 96). I've tried doing everything I can think of in FontForge as far as clearing kerning tables, toggling options for "old kerning" and "microsoft kerning", etc. Nothing seems to make any difference to the result.
I know that upright orientation is not well supported by browsers in general, but it's apparent that Arial font renders perfectly under Chrome, so I think there must be something I can do to fix this problem.
The font is generated in FontForge from an SVG font that uses vert-adv-y. The values for that parameter are correct in the SVG (the SVG has other errors, but I don't think they have any bearing here). I'm linking a copy of the exported OTF file. Perhaps someone may discover some sort of kerning or letter-advancing issue there.
Or perhaps Chrome is doing some sort of automatic kerning, in which case, why doesn't it happen to the Arial font? Maybe the Arial font has GPOS settings, whereas my font has old-style kerning? I really have no clue.
LINK TO DOWNLOAD OTF FILE.
Although the letters on the left of the image are lowercase, they are produced using the uppercase keys A, B, C, etc.
Okay, so this seems to have been one of those miraculous-seeming instances when a problem seemed to fix itself. I resaved the file, which then kicks it to a microservice running FontForge, which coverts the SVG to an OTF, and when it reloaded everything appeared good.
I still have no idea why, since I didn't update the microservice, and I haven't changed the SVG-generating code AFAIK. All I did was upgrade Chrome (and the new version had been showing the issue with the old file), but it should still be sending the same data. Still, I'm not complaining!
in my web project I need to mix latin and cyrillic characters. Unfortunately the cyrillic characters are not part of the webfont, thus the fallback steps in.
As I use a bold webfont the latin characters are bold but the fallback would only be bold, if I set the whole paragraph as font-weight:bold or alike.
I remember discussions that this should be prevented as some browsers can't display them correctly, but during my tests I wasn't able to produce a really broken layout when bolding the webfonts.
What do you think? How can I solve this problem?
Thank you
Markus
Yes, most webfonts provide specific weights like 400 for Regular and 700 for bold. If these aren't provided and you bold/strong them, you are in essence using the font outside of its original intent.
Font weight values can be used, but I'd always stick with the ones provided with the webfont you're using.
Also, if a weight you declare is not available, it will not show on the page but simply default the "logically closest" (this from the CSS Tricks article below) weight.
See a little more basic description here: https://css-tricks.com/almanac/properties/f/font-weight/
Yes it's still recommended you don't do this.
By using font-weight:bold you're forcing the browser to try and create the bold version of this font itself, which can often look distorted / fuzzy. This is referred to as faux styling.
You should set different #font-face definitions with different font-weight values which make use of multiple font files.
I'm searching for a method to tell the browser to render each glyph rendered with a specific font, e.g. FreeMono, in a bigger font size than glyphs rendered with other fonts. The reason for that is, that I use characters like ᚠ in a website and these glyphs are rendered using FreeMono in Chrome (see inspect element → computed → rendered fonts) and they look always like they're to small to fit the surrounding text. Is there any way I can do that?
You cannot. CSS has no tools for such font-specific tuning, apart from the font-size-adjust property, which has very limited effect, limited browser support, and buggy support.
If you use a character such as “ᚠ” U+16A0 RUNIC LETTER FEHU FEOH FE F on a web page, then it will be up to each browser in each system which font (if any) is used to render it, at least if you do not explicitly suggest some font(s) that contain it. It may be FreeMono, but most computers in the world do not have it. Besides, in FreeMono, “ᚠ” is rather large—taller than uppercase Latin letters. So if it looks too small, the reason might be a mix of fonts.
To make, say, Runic letters match the style of other text, you should try and find a font that is suitable for both—so that you can use a single font, designer by a typographer to make things fit. You would then probably need to find a suitable free font and use it as a downloadable font (with #font-face). It might be FreeSerif or FreeSans; only in very peculiar circumstances would I consider FreeMono, a monospace font, suitable for rendering computer code in some cases and mostly unsuitable for everything else.
I recently bought a font and wanted to embed it into my website using web fonts.
Now the problem is: After buying it, I realized that the font is missing the umlauts, such as ä, ü and ö, so it shows an empty space instead of the (missing) character.
Is there a way to prevent this? Like tell the css to use another font for the missing characters? Or would I have to edit the font itself?
Because there is no "easy", or clean way around this except remodeling the font files, here's a small JS script to replace extended ASCII chars with a <span>. (One could only do this for the exact, required characters, but you'll propably end up asking yourself the same question again once you accidentally come across another character that's not supported.)
JS only on example text:
"Hêllo wörld. ÄÖÜßäöü".replace(/([\x80-\xff])/gi, '<span class="arial">$&</span>')
Result:
H<span class="arial">ê</span>llo w<span class="arial">ö</span>rld. <span class="arial">Ä</span><span class="arial">Ö</span><span class="arial">Ü</span><span class="arial">ß</span><span class="arial">ä</span><span class="arial">ö</span><span class="arial">ü</span>
jQuery:
$('.webfont').each(function(){
this.innerHTML = this.innerHTML.replace(/([\x80-\xff])/gi, '<span class="arial">$&</span>')
});
The nodes with .webfont should only contain text, although it should also work in most other cases.
There is no acceptable way to prevent this. Use a different font. (It is possible that there is an extended version, with higher fee, of the font you bought.) The font should be selected so that it contains all characters, at least all letters, that you may need in the text.
It is possible to use different fonts for different letters in a word, using various techniques (#font-face with range settings being the most elegant, but with limited browser support). However, it means a typographic disaster. Especially if the text contains e.g. both “ü” and “u”, there is usually a striking mismatch.
Editing the font itself is technically possible using a font editor, but normally illegal unless permitted in the font license or in exemptions to copyright in applicable legislation.
This week we stumbled upon a rather odd bug in IE7 (surprise, surprise) when embedding a EOT font file using the #font-face construct.
To save on bandwidth, we often edit out sets of characters from a font that we know will not be used on a site. In this particular instance, we were using this font for headers that were all composed in title case, but displayed in uppercase using the text-transform property. Logically, we saved all our font files with only the uppercase characters, as we simply don’t use the lowercase.
The site rendered perfectly in every browser (including IE6 and IE8) that supported the #font-face construct, with the notable exception of IE7. IE7 only displayed the first character of each word in the proper font — the rest of the characters were displaying in the browsers default font.
Scratching our heads, we finally figured out that since the headers were actually written as title case (and therefore contained lowercase characters), even though the text-transform property was deployed and characters were appearing in uppercase, IE7 required the lowercase letters to exist in the EOT file to display the uppercase characters. (Intuitive, isn’t it?)
The simple fix was the rebuild the EOT file with both upper and lowercase glyphs, even though the lowercase characters are never used.
Problem online: http://www.testdomeinnaam.nl/mike/
How can I fix this properly? (i.e. make IE7 render the uppercase characters without having to include lowercase glyphs in the font.)
Thanks!
I think you already have the best fix - just include both uppercase and lowercase glyphs in your .eot.
Your server is using HTTP compression.
The current .eot is 22.62 KB, and it's compressed down to 13.87 KB.
Even if adding the uppercase glyphs doubles the size, it would still only be ~28 KB compressed.
Unless there's a simple "actual fix" to the problem, just stick with this.
Is it an option to transform the case on the server-side? For example, php has this: http://php.net/manual/en/function.strtoupper.php
That might fix your IE7 problem, if it's practical to use such a function.
a just had the same problem and solved it quick:
for ie7 to render the font correct with text-transform "uppercase" it's enough for ie7 that the lowercase-letters are defined in the font file, they don't need to contain real letters = they lowercase-letters in the font-file can be empty and the size of the font does not increase.