I need to use Vegur font, which is available in otf format, for a website. However, when I try to convert it using font squirrel or any other similar font-face generator (e.g. http://fontface.codeandmore.com/) font immediately loses all smoothness and quality...
Is anyone aware of where I could get a pre-converted version of the font? Or what else could I use to convert the font.
have you checked this page with html characters rather than the one you've linked to (that has images)?
http://www.fontspace.com/arro/vegur/22551.charmap
My OS is windowsXP (using Chrome at the moment) and XP notoriously renders non default fonts with poor quality and no smoothness. On the page you've linked to, the font looks nice and smooth because is just an image, while when I check the link above, all chars render poorly... what's your OS?
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!
I cannot get Chrome on OSX to print emoji, is there any css trick or other?
Here are 2 emoji: 👍🇦🇹
When I try to print this page, the emoji space is preserved, but it's white. In Safari printing the emoji works just fine.
Here is a screenshot of the print preview of this page on Chrome:
After a lot of dialog in the question's comments, it seems you have a font rendering issue (perhaps a Chrome bug). I do not think this can be solved with any combination of HTML, CSS, or Javascript.
There is, however, the option to work around the issue by not using a font.
You can use a vector image like SVG to have the same kind of scaling capabilities as a font:
SVG for 👍THUMBS UP SIGN Unicode character
SVG for 🇦 REGIONAL INDICATOR SYMBOL LETTER A Unicode character
SVG for 🇹 REGIONAL INDICATOR SYMBOL LETTER T Unicode character
SVG for Thumbs up sign
SVG for Austrian flag
Just link to the SVG as an image and specify its dimensions either in HTML or in CSS as needed.
With a little work, you could automate conversion of user-generated emojis to images by using a dictionary of known images and supplement the misses with the either the SVG or the emoji PNG at FileFormat.Info. They have a list of emojis you could scrape (assuming it's not a violation of their terms of service) for PNGs as well as an SVG for every character (emoji or otherwise) which can be obtained from from just the character code. For example, here's U+1f44d (👍):
http://www.fileformat.info/info/unicode/char/1f44d
It'll be the only SVG link on the page, so you could do this in JS:
var svg_src = fileformat_info.querySelector('a[href$=".svg"]').href;
That said, it'd be vastly preferable to have this ready-made rather than creating from scratch. #pandawan's answer suggesting twemoji looks promising.
Perhaps there is a CSS-only workaround: I've also read elsewhere that you can properly print these characters by avoiding bold (and perhaps all font and text manipulation? perhaps just make the font size bigger?). This may depend on the fonts installed on the client system.
This is due to a rendering difference between Chrome and Safari, I would not named it a bug since I do not believe that the expect behavior is defined anywhere (Firefox has issues rendering your emojis too by the way).
If you want a full and simple emoji support across all platforms you can use twemoji, a small library developed by Twitter for this specific need.
while i was developing a Japanese website for my client, i encountered the following:
in the screenshot, the hiragana/katakana rendering and the kanji rendering look like it's using two different fonts
in google chrome and other modern browsers:
it's not limited to japanese only, if I use Simplified Chinese(GB2312), this kind of issue happens as well; Traditional Chinese(Big5) have no such issue
the rendering in IE looks terrible, the major audiences will be using IE, how can i solve this issue?
I did not specify any font in CSS
Most probably, the rendering does use two (or more) different fonts. To fix this, specify a list of fonts for the content, selecting the fonts so that a) each of them contains all the characters you are using and b) the computers that your visitors will use contain at least one of those fonts.
As a rough starting point, check out http://en.wikipedia.org/wiki/List_of_Microsoft_Windows_fonts
The reason for different browser behavior is that browsers have different default fonts and fallback strategies (for selecting alternate fonts when the browser's default font does not contain all the characters needed).
It's also a good idea to declare the language: <html lang="ja">. It may affect font choice by a browser, so that a font suitable for Japanese is selected. But this normally does not matter when you specify fonts in your document.
I've been wondering myself why on windows my font looks smaller, and much crappier than on OSX.
Screenshot Mac VS Windows : http://screencast.com/t/UUxqLRhM
Is that because i used "em" on some rules instead of "px" ?
Thanks.
(This is from a comment, but I'll post as an answer.)
This is nothing on your end, and the culprit is different font rendering engines. Mac OS X tries to render fonts exactly as they were designed, whereas Windows tries to alter them slightly to make them more readable. The problem is, with certain fonts and sizes, it actually makes them look worse. (This article is a good read on the subject.)
If you make the font bigger, it will probably make it look better on Windows. I would venture to say that if you removed the bold font-weight, it would also look cleaner. You could also try a different font.
Overall though, all you can do is just play with different settings and see what looks good and what doesn't; the actual rendering is out of your control.
Different browsers do have different standard font-sizes. Maybo other font-types and the different way to show fonts of the OS.
100% same look is... not possible
The way MAC and PC handle fonts is different, but that is not what is happening here. You have set a font that is not web-safe, "MyHelveticaBold", and the font windows is using is clearly not the same as the one on your Mac. If you don't want to use a web-safe font then you should use open source web fonts that you can serve to the user upon visiting.
There are some CSS properties that can adjust how a font is rendered such as -webkit-font-smoothing. Read more here: http://blog.typekit.com/2011/01/26/css-properties-that-affect-type-rendering/
Using Georgia for body copy on a web site we've noticed major differences between how the text is rendered on a mac vs Windows.
It would appear the issue is with Windows when using smaller font sizes, since the text rendered by the browser (tested in Chrome, Safari, Firefox) looks very different to the installed font.
At 36px the text rendered by the browser (top) matches the text typed directly into PhotoShop (bottom):
At 12px the text rendered by the browser is very different (characters look elongated):
Can anyone explain why this is the case? We need to ensure consistent rendering of type across browsers/platforms.
Update
It's worth noting that if I import the system font directly (using #font-face), the type renders correctly.
If you want to ensure consistent rendering use an image, there is simply no consistent font rendering across systems. The font renderer for Windows is is very different from the font rendering in Mac OSX. Here is an elaborate article on the topic: Link
"It's worth noting that if I import the system font directly (using #font-face), the type renders correctly."
Why don't you simply import the system font directly, then?
On the other hand, I'm with Florian. The difference is minor enough I wouldn't really be concerned with it.