1

I have a regular H3 element with a custom font (Didot from Linotype) in italic style. See:

clipped text

The issue is that Chrome is clipping parts of the type (such as the descenders and serifs) while other browsers display the type just fine. The H3 is not in any container with hidden overflows.

I've tried (without luck):

  • overflow: visible
  • text-rendering: optimizeLegibility; (and other values)
  • * { overflow: visible !important; }
  • Other "kerning" tricks out there

The only solution that has appeared to ever work is giving the H3 some left padding... but I feel this is an inappropriate solution as I would then have to shift all contents below headings the same amount to the right.

Thoughts?

Rob W
  • 9,134
  • 1
  • 30
  • 50

4 Answers4

5

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.

Dobbo1989
  • 303
  • 6
  • 9
  • this works great when text is aligned left, but it won't work if text is aligned right. I've tried giving a negative value but it doesn't work. – jtate Mar 24 '17 at 16:16
4

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.

Community
  • 1
  • 1
Aurora Arcade
  • 131
  • 10
  • I've tried different orders of fonts - it doesn't seem to help. I also tried adding the `src:local('☺'),` trick. I confirmed it was loading in the proper order by checking the console network tab. Still gets cut off. Interestingly enough, however, http://typecast.com/preview/fontscom/1012:692325?plan=Custom works just fine (When switching the fonts to linotype italic w01) – Rob W Oct 01 '14 at 18:38
  • Does Chrome recognize EOT? Isn't EOT supported only by IE? I suppose that if Chrome ignored WOFF etc., the font would not be displayed at all. – Ilya Streltsyn Oct 01 '14 at 20:56
  • I can't find anything to say that Chrome will load EOT font files. – Aurora Arcade Oct 02 '14 at 05:37
  • By my testing, Chrome will ignore the eot and pick up WOFF/TTF/SVG instead -- whichever comes first. – Rob W Oct 02 '14 at 13:21
4

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.

Ilya Streltsyn
  • 13,076
  • 2
  • 37
  • 57
  • This is a great answer and makes sense. We are using translations and opacities. – Rob W Oct 01 '14 at 21:10
  • 1
    I tried to disable these properties one by one with DOM inspector. When the last one of them was disabled, the bug disappeared. So I decided that this may be the reason, since elements with RenderLayer and without it often render a bit differently (sometimes it reminds me the `hasLayout` behavior of old IEs). – Ilya Streltsyn Oct 01 '14 at 21:20
  • Very nice and interesting answer. Here is a jsFiddle showing the problem: http://jsfiddle.net/p7wum0bp/3/ – Nico O Oct 02 '14 at 08:48
  • I think I'll use that fiddle to submit a bug report.. maybe we can see what's going on. other browsers don't have an issue :| – Rob W Oct 02 '14 at 13:20
  • I confirm that @Nico's fiddle demonstrates the problem also in iOS 7 Safari, so the bug is probably somewhere deep in WebKit rendering engine. – Ilya Streltsyn Oct 02 '14 at 14:54
  • Posted on google product forums: https://productforums.google.com/d/topic/chrome/cBJY1aiWPBw/discussion - Not sure where else it could help to be posted. – Rob W Oct 02 '14 at 17:29
  • 1
    Also posted on CRBugs: https://code.google.com/p/chromium/issues/detail?id=419787&thanks=419787&ts=1412271687 – Rob W Oct 02 '14 at 17:41
2

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/

enter image description here

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:

enter image description here

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/

enter image description here

Community
  • 1
  • 1
Nico O
  • 13,762
  • 9
  • 54
  • 69