Why Does My Custom Font Have a Positional Offset in Some Browsers

Why does my custom font have a positional offset in some browsers?

I have figured it out and it is rather strange and consists of two things.

1) The .ttf and .eot I got from the font-squirrel were no good. Getting the original .ttf back from the font-site and converting it to .eot myself was necessary for proper rendition. I do not know whether this is actually font-squirrel's fault because the differences in rendition seem very arbitrary and strange, also see point 2).

2) Removing the .woff entry from the css. The .woff was only added for safety, I was not sure whether this was used by any, but it seems all browsers still render it correctly.

It seems very bizarre, because the browsers involved all use the same .ttf (except IE8 and less which use the .eot) but render it differently. Also the .woff has to be removed, why? ALthough I have solved my problem it still seems a rather random and strange problem. If anyone knows more about this stuff I would love to know.

I hope this question will be of use to others to come. font-face has still a long way to go in being easy to use, and browsers should be more wary of proper compliance regarding it.

Webfont position rendering issue

This is can be caused by webkit when rendering custom fonts try using -webkit-font-smoothing. The default value of which is subpixel-antialiased. Try setting:

h1,h2,h3,h4,h5,h6 {
    -webkit-font-smoothing: antialiased;
}

Alternative solution

If the above doesn't work then this may work, I had a similar issue before with chrome and randomly found this fix on the interent. Not sure where but it basically forces Chrome to use the SVG version of the font.

@media screen and (-webkit-min-device-pixel-ratio:0) {
    @font-face {
        font-family: 'nameOfFontFamily';
        src: font-url('url/to/svgfont.svg') format('svg');
    }
}

CSS custom font vertical offset (bug?)

It's possible there is not anything you are doing wrong. Here are some points that may apply, some controllable by you, some not.

1. Just to be sure, explicitly set vertical-align: baseline.
2. The different files (.eof, .woff, .ttf) themselves may not be defined the same, and thus different browsers are using different files and displaying differences.
3. Not sure if having two src calls is messing things up, but you can try eliminating the second one:

@font-face {
    font-family: 'Gabriola';
    src: url('Gabriola.eot'),
         url('Gabriola.eot?#iefix') format('embedded-opentype'),
         url('Gabriola.woff') format('woff'),
         url('Gabriola.ttf') format('truetype');
    font-weight: normal;
    font-style: normal;
}

These are all mere guesses. You will have to test #1, 3. If the issue is #2, I'm not sure there is an elegant solution.

There is, of course, the caveat on this site:

Keep in mind that font rendering can vary widely across browsers and
operating systems. Many developers have experienced such poor results
from Windows and Internet Explorer that they avoid using custom fonts
altogether. Always be sure to examine your results closely on all the
browsers that you can to decide if the quality is acceptable.

Update

This post gives some tips about possibly resolving rendering issues. This is for Font Squirrel, and he specifically notes:

If you downloaded the kit, you might try regenerating the font with
the generator. We make periodic adjustments to the generator that
might improve the hinting or rendering of the font.

But he also confirms,

Not to pass the buck, but the most common cause is a bad original
font.

Which goes with my point #2.

EaselJS custom font lineheight cross browser issues

The following font attributes are available on the drawing context (canvas):

• font can be anything you would put in a CSS font rule. That includes font style, font variant, font weight, font size, line height, and font family.
• textAlign controls text alignment. It is similar (but not identical) to a CSS text-align rule. Possible values are start, end, left, right, and center.
• textBaseline controls where the text is drawn relative to the starting point. Possible values are top, hanging, middle, alphabetic, ideographic, or bottom.

When drawing to the canvas set the textBaseline explicitly (js):

context.textBaseline = "alphabetic";

http://diveintohtml5.info/canvas.html

Did you try the text-rendering declaration? (css)

text-rendering: geometricPrecision;

https://developer.mozilla.org/en-US/docs/Web/CSS/text-rendering

Disclaimer: These are just wild guesses since you didn't supply any code.

Why does the font on my website look so much smoother on Chrome for Android?

Short answer: blame the browser if you're on Windows 7, blame both the browser and your monitor if you're on Windows 8.

Why Google Chrome on Windows 7 looks bad

The latest version of Google Chrome on Windows uses GDI, an API that provides legacy text rendering. GDI relies on strongly hinted fonts (fonts which explicitly specify how to reshape characters to make them look sharper and less jagged). Most webfonts from Google are unlikely to be serving the strongly hinted fonts that GDI needs to render smooth text.

Second thing is, GDI wasn't designed in the days where big font sizes were prevalent, so it doesn't render smooth text at large font sizes. It occurs everywhere even with the system fonts (e.g. Arial) that are already well hinted.

Android's built-in text renderer, however, is simply better at text rendering.

Blame Google Chrome for using a legacy API on Windows.

Alternatives

Internet Explorer 9+ and Mozilla Firefox use Direct2D, a new graphics API that provides better text-rendering. However, it is only supported on Windows Vista and Windows 7. You'll find that IE and Fx will render the text more or less the same on Windows XP because only GDI exists on that platform.

More on Cleartype

Cleartype refers to a multitude of rendering methods to smooth text out on a monitor. The Cleartype methods employed by GDI are vastly different than that employed by Direct2D. To further complicate things, Direct2D can simulate the Cleartype rending in GDI, or use a cross-over of the default Cleartype in Direct2D and the Cleartype in GDI. There is nothing much the web developer can do but hope that browsers choose a suitable choice. Take note however, that to one Cleartype might look smoother, to others one might think it looks blurry.

The issue with Windows 8

As if things weren't complicated enough, on Windows 8, in IE 10 and in Windows Store Apps, Cleartype uses greyscale anti-aliasing instead of sub-pixel aliasing on both the horizontal and vertical axes. This is because in Windows 8, screens are more likely to rotated, and using sub-pixel anti-aliasing would break as the subpixels are no longer perpendicular to the anti-aliasing direction. Since greyscale anti-aliasing doesn't use subpixels, it looks horrible if the pixels on your monitor are big (i.e. low-dpi/ppi monitor).

But hey, isn't this what Android and iOS do?

Greyscale anti-aliasing is indeed the method employed by Android and iOS. But since these mobile devices have such high dpi screens, it looks just about as good as sub-pixel anti-aliasing would offer.

Why does an input field reduce width with font-style:italic?

This is the effect of the HTML5 specification.

In the rendering section 14.5.5. The input element as a text entry widget. it says:

If an input element whose type attribute is [text] does not have a size attribute, then the user agent is expected to act as if it had a user-agent-level style sheet rule setting the 'width' property on the element to the value obtained from applying the converting a character width to pixels algorithm to the number 20.

The converting a character width to pixels algorithm returns (size-1)×avg + max, where size is the character width to convert, avg is the average character width of the primary font for the element for which the algorithm is being run, in pixels, and max is the maximum character width of that same font, also in pixels. (The element's 'letter-spacing' property does not affect the result.)

That calculation means that the width of the input box depends on the character font. Chrome is taking italic as a separate font from normal characters and applying a different average value, and therefore a different total width.

You can see this further by altering the font-family for the input element. In some fonts, the italic version results in a longer box, in others, shorter.

Firefox and Edge currently don't use a different average for italic.

jQuery offset returning wrong in Firefox / Safari

As a proper answer (instead of a comment):

Your javascript is executed immediately after the browser receives it. Depending on the position in the document of this script this happens even before the DOM is fully loaded.

$(document).ready(function(){ headalign(); }); would execute your function on DOM-load. But at this point neither the images nor the 'BlockGothic'-font is rendered. Therefore custom_offset_top is 0 or some other value (no image, no custom font).

You need to wait until the page is fully rendered:

$(window).load(function(){ headalign(); });

This leads to an initial flicker or jump down of your "#maintitle". You can kind of "fix" that hiding "#maintitle" in the first place and fading it in after the page is rendered:

css:

#maintitle {
    display: none;
}

javascript:

$(window).load(function(){
    headalign();
    $("#maintitle").fadeIn(200);
});

Hope this helped!

---

Related Topics