I am stuck in a problem and require your guidance.
We want to display 100% same text in Mozilla, Chrome and IE11.... same word spacing, line height etc.
So far what I learned is all 3 browsers use different render engines and different font file extensions.
Is there anyway we can force all three browsers to use same font rendering engine or same font extension to achieve 100% accurate results?
Already tried the following trick in CSS but no result:
text-rendering: optimizelegibility;
The only way to control the rendering engine used is to make pre-rendered images of text and use those instead of real text. Use alt attributes on the images, so screen readers and search engines etc can make sense of it too.
Even with images, browsers on different systems may scale it slightly differently. You cannot guarantee every pixel will be identical (and you shouldn't try).
Related
I have a CSS declaration like this:
font-family: font1, font2, font3;
where font1 is an embedded eot/ttf font, but the problem is that this font is smaller than the other fonts so I want to have a different font-size (1.8em) for this font (font1). All other fonts (font2, font3) stay untouched.
The problem is, that I cannot verify if the user's browser uses font1, font2 or font3. Is there any css declaration which allows different font-sizes for different families?
Thanks.
There is a way to do this, but it's as of now very badly supported. The CSS property you are looking for is font-size-adjust - a new CSS3 property introduced specifically to address this problem. The specification says:
In situations where font fallback
occurs, fallback fonts may not share
the same aspect ratio as the desired
font family and will thus appear less
readable. The font-size-adjust
property is a way to preserve the
readability of text when font fallback
occurs. It does this by adjusting the
font-size so that the x-height is the
same irregardless of the font used.
However, it is only supported in Firefox as of now, so you might want to look for alternatives.
For examples of how to use it, see:
http://webdesignernotebook.com/css/the-little-known-font-size-adjust-css3-property/
https://developer.mozilla.org/en/CSS/font-size-adjust
http://www.fonttester.com/help/css_property/font-size-adjust.html
http://www.w3.org/TR/css3-fonts/#relative-sizing-the-font-size-adjust-pro
I know it has been a while, but recently I stumbled upon the very same problem as described by the OP. As font-size-adjust is still very poorly supported, I'd like to share another solution that worked for me:
Note: The following solution does only work if the fonts are embedded using the #font-face-declaration.
In that case just include e.g.
size-adjust: 90%;
in your #font-face-declaration. The relevant font will appear at only 90% the size of the specified size.
Browser support
Browser support is currently at 74% with all major browsers supported except for Safari and IE. I know this is far from optimal. But as this problem is "just" about design and not about functionality, I suppose it is better than nothing.
I'm attempting to use word-break to break a word with long character that exceeds its parent's width.
In this example, I have a <div> with width:43px and word "play" in it. In chrome, the word fits, but in Firefox, the word got is split over two lines.
Chrome Screenshot
Firefox Screenshot
http://jsfiddle.net/chenx/7rYAm/
Here is the jsfiddle, you can try to open it in both Firefox and Chrome to see the difference.
What I want is, they're both output the same result. I'll prefer Chrome as the correct result.
This could affect my apps, as they'll screenshot the view to canvas, and I don't want the customer complaining about output difference between browsers. What's the best practice here? Can word-break be standardized across browsers?
Thank you!
word-break is standardized. What's not standardized is how wide the word "play" will be. It depends on the font used, the exact font rasterization algorithm used, on antialiasing settings, and so forth.
On Windows, Firefox and Chrome use two different OS-provided font subsystems (GDI and DirectWrite), which have different rasterization and antialiasing behavior, leading to different widths of text.
The best practice in situations like this is to not use an overly small width for the parent and probably to test what happens when a user with poor eyesight forces a larger font than you asked for.
This is what I dislike about browsers doing their own thing. Firefox uses word-break: keep-all. On the other hand, Chrome uses word-break: break-word.
I am trying this solution for a star rating.
Can someone please explain why the stars are so much bigger in chrome than in firefox? (I know that webkit and gecko are doing different things from time to time but so much difference?)
And has someone a suggestion on how to fix that?
Update:
This is how big the difference is on my mac:
You are seeing the characters in different fonts in different browsers. The size of a character may well very by font (even when the font size is the same).
The technique uses the characters “★” U+2605 BLACK STAR and “☆” U+2606 WHITE STAR, which are present in a few fonts only. If the font-family property on the relevant element does not mention any font containing those characters, browsers will (or at least should) use some backup font, and different browsers use different lists of backup fonts.
You can make it more probable (though not certain) that different browsers in the same system use the same font for the characters by listing suitable fonts in the font-family list. Even then, the results will vary by system, depending on the set of installed fonts. And in some systems, the rendering may even fail, because no font contains those characters.
This issue could be addressed using downloadable fonts, but that would probably be overkill here.
The practical workaround is to use just images, with a sequence of elements like <img src=star.png alt=star> and <img src=whitestar.png alt=""> or (for better accessibility) a pre-made image that contains a specific number of stars, like <img src=stars4.png alt="four stars out of five">.
I had the same issue and have found that using U+2B51 and U+2B52 ("BLACK SMALL STAR" and "BLACK WHITE STAR") displays consistently between Chrome and Firefox. (Haven't tested thoroughly across other browsers and browser versions yet though.)
May be it's strange for you.. But I dont find any difference in the browsers.
find attached image.
Characters in different browsers may vary. Use image as star. Not char. http://i.imgur.com/I2x2Yld.png use {content:''; background:url(....) no-repeat;}
I've spent eons diving into #font-face issues for RTL languages, font-rendering on different browsers, PDF support, and so on.
My objective is to have CSS-compatible Arabic (a RTL language) text on an HTML document, which , when rendered into a PDF, looks, renders, and wraps exactly the same on the PDF as it did on the HTML webpage, regardless of the user's browser or platform.
I've been using #font-face but it turned out that Windows machines render fonts a little wider than they do on a Mac, while the PDF generator is browser-independent and seems to render fonts more like a Mac does. So what happens is that Windows users see one line of text, while the PDF ends up having the last word on that line wrapped over onto the next line, and so the PDF is not exactly what the Windows user expected it to be.
I thought at one point that Cufon could be the solution because apparently it looks the same cross-browser - but I think it doesn't support Arabic? I tried generation PDFs using wkhtmltodpf and PhantomJS, but despite being awesome 'virtual' browsers, both use Webkit QT, which renders text differently from Windows, so once again the PDF that was generated had line wraps or text width that wasn't the same as the original HTML document. Basically, my question is:
What's the best way to ensure that whatever the text the user sees on their browser is exactly what they will see on the PDF? I don't really need it to be exactly pixel-perfect, as long as the text at least follows the same line wraps, with a given width for the containing div. I think the only thing I really need to make sure of is that font hinting is uniform. Or does it all come down to using images?
On an aside, does HTML5 have some sort of cross-browser font-rendering?
I can suggest you two things:
Use em´s for the size of your fonts. em´s are a relative measure.
Don´t use sIFR or anything based on flash rendering due that it won´t work on mobile devices that doesn´t support flash.
There is no way to render the exact same thing across all existing web browsers, that will be like being in heaven. But as we are not there, what I suggest you too is to reduce a little bit the font until it fits your goal.
Regards.
I have a problem with some text rendering with the HTML5 Canvas that you can see at http://jsfiddle.net/qcVAV/.
It seems that Firefox and Internet explorer measure the text and fill it consistently, but Chrome doesn't.
In the provided link, you'll see that Internet Explorer and Firefox appear the same, and the measureText call shows that the provided text measures to 1679. In Firefox there is extra precision. For Chrome, however, the text measures to 1651.
I tried adding in the css reset http://cssreset.com - as I thought that maybe the css could be throwing things off.
What else can I do (if anything) to get text to be rendered consistently?
Sorry, you're out of luck here!
Text is not only measured differently on every browser, it scales and renders vastly differently, too! Try multiplying the font size by 4 and mutliplying the scale by 4, the results might surprise you. Kerning in some browsers will be off, and Opera looks awful when a scale is applied at all.
The only way to make measureText consistent is to pre-compute.
The only way to make fillText consistent is to use images instead of text. It's must faster, anyway.
Both of these are untenable if the text is extremely dynamic, but if you only ever write say, less than 100 different pieces of text in your app, images are probably your best bet.