With some fonts have a problem. For example Neo Sans W1G. On different platforms, they have different vertical alignment.
On Linux and Mac OS font rises to the top, but on windows it looks fine. I'm testing on browsers chrome, safari and firefox.
Maybe someone else encountered this problem?
font-size: 48px;
line-height: 50px;
screenshot
http://imglink.ru/show-image.php?id=76735ce51bbdb8b7a11f4378c2e667c8
It's caused by font format history and Microsoft/Apple/Adobe format wars, different font formats included different metadata fields to compute line height, and the situation was "fixed" by allowing to declare all of them in later formats. (different metadata = different fields with different definitions, not same fields with different names)
Basically any software can pick and choose any of the line height computation algorithms as long as the corresponding metadata is present in the font. Unless the font creator was very careful with the values he put in this metadata all the algorithms won't produce the same value. Most font authoring tools will try to fill all the possible variants of metadata in order to "work" on as many platforms as possible. They rely on the font author to check the values they put there before release. Since most font creators only test a specific platform weird things happen when you try to use their fonts in a cross-platform context.
Likewise, depending on its original platform an app will prefer one algorithm over others for legacy compatibility reasons.
Some webfont platforms propose to "fix" legacy fonts but you need to have a license to modify the font files.
IIRC the typography CSS workgroup wanted to replace all of this with a new unified algorithm, I don't think they have finished yet and when they will have I'm not sure it will actually replace legacy methods instead of adding one more possibility to the mix.
Better, not to make your design depend on an exact value here.
Related
Is anybody aware of whether the Optical kerning in Illustrator via algorithm has a CSS equivalent?
My hunch is that the answer is no.
CONTEXT:
The Optical Kerning done by Illustrator is done via an algorithm which as far as I can tell is not within the CSS spec.
I am referring specifically to Optical Kerning (not Optical sizing) -- the difference was made abundantly in this Stackoverflow question & answer.
The most similar property I could find is this:
text-rendering: optimizeLegibility the definition of which you can see here (scroll down to 'text-rendering' property - ON).
It's options are auto, optimizeSpeed, optimizeLegibility, geometricPrecision
(And yes, I realize I am going on a very light connection via a semantic similarity only but it was the closest CSS property I could find. It turns out it is hard to prove a negative after all.)
Findings so far:
text-rendering's mdn's web page is here which states the
property enables ligatures when font-size is smaller than 20px.
(Pretty different, so not the same.)
text-rendering is actually an SVG spec and not a CSS spec per say
(but that's not a huge deal as it is supported in HTML rendering by
Gecko, WebKit, and Blink (Firefox, Safari, and Chrome) respectively
(not CSS per say, but for practical purposes, doesn't seem to matter
for my use case)
In this css-tricks article about text-rendering, it says Some font files contain additional information about how the font should be rendered. optimizeLegibility makes use of this information, and optimizeSpeed does not.. The fact that it is included in the font file says to me, it is manually added by the foundry hence not via algorithm. (Pretty different, so not the same)
So at this point, I'm thinking Optimal kerning in Illustrator does NOT have a CSS equivalent. Would appreciate your thoughts and experience on the matter.
To be supported in CSS, it has to be supportable in all browsers. This sounds like a proprietary Adobe algorithm. Not surprisingly, I don't see anything like this in CSS.
What CSS does provide is the font-kerning property. One of the values defined is auto, which means that the browser can use its own criteria to decide whether to enable kerning. But it doesn't appear to be intended that the browser can decide how kerning is done: "This property controls metric kerning, kerning that utilizes adjustment data contained in the font."
The data in the font can take one of two forms. The legacy 'kern' table was part of the original TrueType spec and can be used to list specific glyph pairs and the spacing adjustment for each. Size-wise, it's not very efficient.
A newer approach was introduced in the OpenType spec: the 'kern' feature (or the 'vkrn' feature for vertical layout) can be used to activate metric adjustment actions in the 'GPOS' (glyph positioning) table. In the GPOS table, positioning actions can be specified for sets of glyphs that require the same metric adjustments.
The GPOS table supports several different types of positioning actions. (In the OpenType spec, these are referred to as "lookup tables".) When using a GPOS table with the 'kern' feature, typically the font developer would implement using pair positioning actions.
With font-kerning, whether the browser is utilizing a 'kern' table in the font or activating a GPOS 'kern' feature, the amount of spacing adjustment for any glyph pair is specified in the font with data provided by the font developer. Adobe's "optical kerning" is using an algorithm that examines the shapes of glyphs to decide how much to adjust spacing for a given glyph pair rather than relying on 'kern' or GPOS data in the font.
The context
I wrote a home dashboard which, among others, provides a visual indication of the likelihood of rain in the next hour. If rain is expected, the 💧 symbol is displayed (with Open Sans), otherwise it is styled with filter: opacity(10%);.
In terms of code (HTML, CSS, Vue.js), it is displayed via
<span class="drop" :class="isDrop(horaires.first.rain, 2)">💧</span>
The dynamic class is calculated by
isDrop(rain, level) {
return rain >= level ? "full" : "empty"
}
and the class empty is
.empty {
filter: opacity(10%);
}
(the class full is not defined yet)
The problem
The drops look significantly different on my development environment (Windows 10, Chrome or Firefox)
and the actual dashboard (Raspberry Pi with Debian, Firefox)
Where does this discrepancy may come from?
the source of the page is the same in both cases
the font used on the page is explicitly loaded via #import url('https://fonts.googleapis.com/css?family=Open+Sans:400,600,700,800');
not only the filtered version is different (visoble in one case, invisible in the other) but even the non-styled drop looks different - despite being rendered with the same font.
That is because the font you use (Google Open Sans) doesn't include all the unicode glyphs, and more importantly for you, it doesn't include emojis.
So when the browser encounter these glyphs, it will fallback to one available on the system, and different browsers may use different order for choosing which font to use and you may indeed have different font used to represent the same glyph even on the same computer. However, you may be almost sure that different OS will have different fonts, and thus different rendering for these glyphs. Most modern browser's dev-tools allow you to verify which font are being used, check it to be sure which one are toggled on your system.
The solution is to use a web-font which does include these glyphs.
Google has a Noto font which does handle only emojis, Noto Emoji, but the color version is 8MB for only these emoji glyphs!. Saying this so that you understand it's not an easy thing to include these glyphs in any web-font.
There are other web-fonts that seem to exist, but all the free ones I can see are monochrome, so here I'll use Google's one for the example.
#font-face {
font-family: "NotoEmoji-Regular";
src: url("https://cdn.jsdelivr.net/gh/googlefonts/noto-emoji/fonts/NotoEmoji-Regular.ttf") format("truetype");
}
body {
font-family: "NotoEmoji-Regular";
}
💧
If you only have a small set of these emojis you'll use, you could probably make a fork of Google's one or of an other open font so it includes only the ones you need (and be lighter).
Or alternatively, if you have a good designer, you could make your own set of emojis and use a service like icomoon et al. to make your own font based on svg graphics.
Each browser has its own set of emojis. you can see diffrent emoji set here.
if you want an icon to be displayed the same way in every browser, you sould create an icon set and use svg.
I am making an application, and I want to add a "HOME" button.
After much struggling with various icon libraries, I stumbled upon this site,
http://graphemica.com/%F0%9F%8F%A0, with this
🏠
A unicode symbol, which is more akin to a letter than an image.
I pasted it into my HTML, and it just workedTM.
All this seems a little too easy, though. Are unicode symbols widely supported? Is there some kind of problem with them that leads people to use icon libraries instead?
It depends on what do you mean for "safe".
User should have the fonts, so you must include the relative font, and in various formats: there is not yet a format recognized by most used web-browsers.
Additionally, font with multiple colours are not fully understood by various systems, so you should care about what do you expect from users (click, select, copy, etc.).
Additionally, every fonts has own design, so between different fonts (so browsers and operating system) things can look differently. We do not have yet a "Helvetica 'Home'", a "Times New Roman 'Home'".
All this points, could be solved by using a web font, with monochrome glyphs (but it could be huge, if it includes all Unicode code points (+ usual combinations).
It seems that various recent browser crashes if there are many different glyphs, but usually it should not be a problem.
I also recommend aria stuffs so that you page could be used also by e.g. readers (and braille screen).
Note: on the plus side, the few people that use text browser can better see the HOME (not the case in case of an image), if somebody still care about this use case.
Some things you want to make sure you’re doing:
Save your HTML file as UTF-8. In fact, save all text files as UTF-8 unless there’s some reason you can’t.
Put the line <meta charset="utf-8" /> near the top of your HTML file.
Make sure your server isn’t misconfigured to tell all browsers that webpages are in the wrong encoding.
If, somehow, it is and you can’t fix it, fall back on &entities;.
Specify a font stack for your emoji in CSS with a set of fonts that cover nearly every system, perhaps including Apple Color Emoji, Noto Color Emoji, Segoe UI Emoji and Twemoji.
If a free font such as Noto or Symbola contains the emoji you use, you can package it as a WOFF to be sure it will always display the way you want. (As of 2018, Tor browser does not show most emoji correctly by default, but mainstream browsers do.)
I think using unicode is a good practice for development. Beacause The unicodes are essentially part of your operating system so you don’t need any special library or plugin and you treat them like regular text.
The only problem is - code can be defficult to read or understand. I think it is not easy to understand that (ㇼ 8;🏠) printing home icon.
Even the 8 bit PNGs are faster then the font icons.
Image icons can be lightweight but still slow down your site with another HTTP request and time for the image to load. With images you don’t have flexibility over the color and scaling. SVG vector image alternatives are still not faster than plain-text (Unicode characters). Unicode doesn’t require additional HTTP requests and can be made to scale nicely.
If you are developing a website using only simple shapes, you can use unicode UTF-8 symbols as replacement for font icons.
I think :
Almost every developer use libraries for icons because of readablility of code, Easy to use and get more options.
Safe or Not
I can not say whether it is safe or not.
Because Unicode contains such a large number of characters and incorporates the varied writing systems of the world, incorrect usage can expose programs or systems to possible security attacks. This is especially important as more and more products are internationalized. This document describes some of the security considerations that programmers, system analysts, standards developers, and users should take into account, and provides specific recommendations to reduce the risk of problems.
Read about UNICODE SECURITY CONSIDERATIONS
Here are few precautions to be taken while doing that, I did some research and found this to be more helpful for your question. Also I dont know how you can do but credits go to Mr.GOY
Displaying unicode symbols in HTML
There are a number of asterisk (*) types as you can see here:
http://www.eki.ee/letter/chardata.cgi?search=asterisk
Even now, we can see that some of these characters like the one with the code: "204E" also known as "low asterisk" is not rendered in HTML (at least while using Chrome anyway).
You can see the character here:
⁎ -> ⁎
Other similar types work however:
✢ -> ✢
✣ -> ✣
✤ -> ✤
Of course out of all the possible types, the authors of my input data have chosen ⁎ to work with.
It makes me think it should be somewhat general, because I saw solutions where a tiny image was used instead of this character in the entire HTML document. Needless to say I do not like that approach even a bit.
Is there a way to make this work in HTML? Is this possibly a browser specific issue?
UPDATE:
Internet Explorer 9 and Google Chrome also fail to render this special character.
Firefox and Chromium (Ubuntu) seem to be able to render it.
Please note, that I would like to find a general solution if possible.
My HTML code:
<html>
it works in chromium though ⁎
</html>
I use Chromium in Ubuntu, and it works fine in it.
and here goes screen shot of IE, in case you want to see it.
Furthermore: for those looking for a middle asterisk ∗ -> ∗
This primarily depends on the fonts installed in the user’s system, not on browser (though some browsers, most notably IE, might be unable to utilize all the fonts in the system, as they should). Regarding e.g. U+204E, font support is relatively limited: no font shipped with Windows contains it, whereas Linux systems probably have some font that contains it.
Using #font-face for some suitable free font, you could make the character display in most computers (excluding basically just those that have font loading disabled). See my Guide to using special characters in HTML.
In this case, that would probably be overkill, if you just need e.g. a low asterisk. A normal asterisk, in a lowered position, should be sufficient – at least compared with the overall typographic quality of HTML documents. Example:
<style>
.low {
position: relative;
top: 0.55ex;
}
</style>
Compare: *⁎<span class=low>*</span>
(Using relative positioning is safer than using vertical-align, directly or via the sub element, since vertical-align usually messes up line spacing.)
I'm making heavy use of → / ← arrow symbols in HTML so that i spare myself the pain of having to go with images. This is for an enclosed system, not for a public website.
Now i noticed that my client does not have those symbols in their charsets somehow - and i am wondering why. Since i am using CSS to select the font, the charset should be the same, right? And the symbols should be available. But they are not. Instead they just get blanks.
The font in use is Verdana.
Since i am using CSS to select the font, the charset should be the same, right?
Not necessarily: The font might not be installed on every machine, and fonts can have different versions. You can't trust every client machine 100% to have exactly the font you need.
See this question for more background and approaches to determine font support for a specific glyph: Unicode support in Web standard fonts
The only way to make pretty sure the user has the correct font is to embed it into your web page using #font-face or using a hosted one by Google Web Fonts. In all browsers that support this method, you can then trust the same font to be delivered to every client.
However, embedding a font using font-face is tantamount to redistributing it, which most commercial licenses do not allow (see e.g. the Microsoft Typography FAQ). You would need to find a completely free font that allows redistribution this way - ideally one from Google's portfolio, or from a place like the Open Font Library.
These symbols are not included in Verdana. Use e.g. Arial, Times, Courier New, Garamond