I have a regular H3 element with a custom font (Didot from Linotype) in italic style. See:
I fixed a similar issue to this by adding a small text indent
text-indext: 4px;
The exact indent value needed will differ depending on the font itself and the size of the font. For emample using @Nico O jsfiddle adding a 16px text indent fixes the issue.
It is hard to tell if this a bug of chrome, an error in the font or a bug at all.
I tried to recreate the problem here: http://jsfiddle.net/p7wum0bp/1/
As you can see the italic, serif j is not beeing cut off, as in your image. I guess this can depend on font to font.
As u said, you don't want to give the element a padding, as the headline beeing shiftet away from the rest of the text. As a solution, you may use a combination of padding and margin, to get the text in the right position again. Like here:
.b-capa-list-item h3
{
font-family: "Linotype Didot eText W01";
font-size: 25px;
padding-bottom: 7px;
text-transform: lowercase;
font-style: italic;
margin: 0 -10px;
padding: 0 10px;
}
With this bit ugly workaround you reach the desired result of:
With the answer of @Ilya Streltsyn I was able to reprouce the problem in a jsFiddle using the opacity property. You can watch the behaviour here: http://jsfiddle.net/p7wum0bp/3/
This looks like the same rendering issue mentioned here: Bottom of custom font cut off in Opera and webkit
According to https://stackoverflow.com/a/8617238/4097933 the css file for your fonts chrome will load the EOT and ignore the following woff,ttf and svg fonts.
@font-face{
font-family:"Linotype Didot eText W01";
src:url("/dv2/2/dbcd27d7-e1e4-4757-b144-32def75c2eaa.eot? d44f19a684109620e4841579a790e818c1a37164efcdf0e038d168bbbe670847e33d73662846b089fb09be21eee584570d77c537 80c9058895373c54fba457480d6ed4c5ba215f67d79aebaaeaeeccdfa718e07c265a761f65012da2ebccc6f4b9c3f5f9&projectId=de149dbb-2608-424a-b0f0-ab02bbf5b45c");
src:url("/dv2/3/6bfc2eb5-d4a7-42d3-a372-305f28511a22.woff?d44f19a684109620e4841579a790e818c1a37164efcdf0e038d168bbbe670847e33d73662846b089fb09be21eee584570d77c53780c9058895373c54fba457480d6ed4c5ba215f67d79aebaaeaeeccdfa718e07c265a761f65012da2ebccc6f4b9c3f5f9&projectId=de149dbb-2608-424a-b0f0-ab02bbf5b45c") format("woff"),url("/dv2/1/b66a964d-58b6-42f1-a3f7-fecb060b2ec3.ttf?d44f19a684109620e4841579a790e818c1a37164efcdf0e038d168bbbe670847e33d73662846b089fb09be21eee584570d77c53780c9058895373c54fba457480d6ed4c5ba215f67d79aebaaeaeeccdfa718e07c265a761f65012da2ebccc6f4b9c3f5f9&projectId=de149dbb-2608-424a-b0f0-ab02bbf5b45c") format("truetype"),url("/dv2/11/0a52b68f-a61f-4fa5-a685-99f557fcd924.svg?d44f19a684109620e4841579a790e818c1a37164efcdf0e038d168bbbe670847e33d73662846b089fb09be21eee584570d77c53780c9058895373c54fba457480d6ed4c5ba215f67d79aebaaeaeeccdfa718e07c265a761f65012da2ebccc6f4b9c3f5f9&projectId=de149dbb-2608-424a-b0f0-ab02bbf5b45c#0a52b68f-a61f-4fa5-a685-99f557fcd924") format("svg");
font-weight:400;font-style:normal;
}
Given this try put svg fonts first, then ttf, then wof.
Update:I can not find anything support the idea that Chrome will load EOT font files and therefore ignore the following fonts.
It appears that the text starts to be cut off when at least one CSS property that promotes the element to RenderLayer is applied (e.g. transform
or opacity
). So it seems to be the internal problem of the renderer that can't be fixed easily at CSS level. I'd recommend just to add some left padding (and right padding, if necessary) to make all letters fit inside the element boundaries, and compensate these paddings by transform or negative margins.