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.
Related
i have table tag with border='1' attribute as source html.
it gives a different table out in IE8, and different in Chrome latest version.
border is different in style.
Why is such big difference and how can i achieve a consistent look and feel across different browsers?
Welcome to the frustration called web development and the inconsistency that comes with that.
Why is such big difference
The HTML5 and css RFC has a technical definition of every feature of the language, but it is not specific enough. Thus, it resulted in different browsers having different implementations of this language and therefore you'll notice slight variations that can break entire layouts. Also, often browsers implement features that are not officially supported by the language RFC, so those are not supported by other browsers.
how can i achieve a consistent look and feel across different browsers
Often you'll have to explicitly add properties to your style sheet to get rid of default styles. You can choose to limit yourself to features that are officially supported. Or you can create custom elements like custom dropdown menus and such.
I am attempting to ask a more specific question than "how does browsers work??", please bear with me :)
If I understand correctly, html elements may have some default properties that determine their behavior. For example, <div> has display: block property set by default, while span has display: inline
These defaults exist because they are defined in the browser's default stylesheet.
Ok cool, I get that (hopefully). But what about <br /> or <img>? The behavior of those is determined by more than their properties right? Is it just up to the browser's implementation to make them behave how the W3 html5 specification says they should?
Also, is there an official word for this kind element behavior or does it just fall under 'browser implementation'?
So, you're really asking two questions here:
What is the default presentation and behavior of HTML elements?
Who/what determines how this works in a browser?
Let's start with question 2
The HTML specification is written and reviewed by a group within the W3C called the HTML Working Group. When they've agreed on a specification they publish it as a Recommendation. You can read the HTML 5 spec here, but I don't recommend reading the whole thing - it's very long and boring full of technical jargon.
However, the W3C's recommendation defines only the syntax and intended purposes of the features of HTML - it does not define how browsers should render HTML. Browser vendors, like Microsoft (IE), Mozilla (FireFox), Apple (Safari), and Google (Chrome), get to determine how their browsers render and implement the features of HTML.
Fortunately, most of the common HTML elements behave almost exactly the same from browser to browser. It's in the vendor's best interests to stay consistent among each other, because if one of them decided to do something drastically differently from all the others, the people who build websites would have to spend more time supporting that specific browser and it would fall out of favor (as was the case with IE 6 up until IE 11).
What determines the behavior of HTML elements?
The browser's rendering engine. Some browsers share the same rendering engines (like Safari and Chrome) (not true anymore - see comments), but not all. This article offers some insights (and leads to more insights) about how browsers are built, and here's an article listing several browser engines.
For the most part, you can affect how your HTML document looks by changing its CSS properties, but the behavior of most HTML elements is unchangeable without scripting using JavaScript.
The default CSS styles applied by your browser is defined by a stylesheet called its User Agent Stylesheet. These are usually pretty basic styles that browser vendors design in order to make HTML documents a little more readable without drastically affecting the presentation of the document.
However, there are so many basic styles applied by different browsers, that it's very common for web developers/designers to what's called a CSS reset. Normalize.css is a great example of this, and it's one of the most popular ones.
I believe it is up to the browser implementation. The way it will appear on the screen is up to the browser implementation.
Although, all browsers agree on how it should appear on screen.
These standards are defined by the World Wide Web Consortium - (wikipedia).
I guess this information you are seeking can be found in these sites!
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.
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.)
Consider an HTML page which is encoded as UTF-8, and a bizarre unicode character appears in it - form a rare language or some other Unicode idiosyncrasy.
Is there a standard behavior for such scenario? Will the browser try to find an appropriate font? Can the browser behavior be configured using HTML parameters?
The CSS 2.1 font matching algorithm means that a browser shall select, for each character, a glyph from the fonts suggested in the applicable font-family declarations and, failing that, use a browser-dependent default font. If even it does not contain the character, then “the UA [= browser] may use other means to determine a suitable font for that character. The UA should map each character for which it has no suitable font to a visible symbol chosen by the UA, preferably a ‘missing character’ glyph from one of the font faces available to the UA.”
So it is pretty well defined, but with browser dependencies. The algorithm allows a browser to display a missing character symbol even if some of the fonts in the system contains a glyph for it. Modern browsers usually don’t do that, but IE isn’t particularly modern in this respect either. Moreover, there are quirks and oddities in browsers, partly because they sometimes fail to get proper information about a font from the font itself.
You can’t configure the basic behavior, but you can play by its rules. The thing that works best is the use of author-supplied font families. If you have an odd character, you should try and determine a set of fonts that contain it and write a suitable CSS rule. However, for very rare characters the options are really: 1) the use of a downloadable font for it, 2) the use of an image. More info: http://www.cs.tut.fi/~jkorpela/html/characters.html
Yes, the browser will typically try to display it in some font as best it can. Some browsers/operating system do a better job than others. Some may simply give up if the default font for the page doesn't contain the character, but most will try to find other installed fonts that contain the character. If none matches, the browser will display some placeholder, usually a square.
And that's all. Nothing bizarre about it, that's how font rendering works.