The upload for the screenshots failed. So I try again, on Safari.png it looks like it should, on Chrome.png it doesn't.

Deleted: Safari.png 684 KB

	Safari.png 684 KB View Download

Deleted: Chrome.png 677 KB

	Chrome.png 677 KB View Download

Able to reproduce this issue on Mac OS 10.12.3 using chrome M57 #57.0.2987.74 by following steps mentioned in the original comment. Observed there is a rendering issues of few fonts in the provided site.

Tested this issue on 35.0.1849.0 and observed issue still persists on older version od chrome as well, so considering this is a non-regression issue and marking it as untriaged.

Thanks!

Could you look into this when you get a chance drott?

Reproducible using http://roettsch.es/voda/voda.html with 
https://kabel.vodafone.de/static/fonts/ttf_vodafonelt-webfont.ttf on Chrome 57 beta, a modified Skia sample app as well as Firefox. Possible CoreText or font (metrics) issue.

It seems that all combined/component glyphs are truncated, same happens for glyphs like ¾ (three quarters) or ; (semicolon).

Filed  issue skia:6340  for this as well.

The font attached to the Skia issue contains an 'FFTM' table which is unique to FontForge and contains some date and time stamps. The source date for FontForge itself (essentially the build time) from this table is around Mon, 14 Sep 2009, so it's a bit old, but I don't think this bug has been fixed yet. Most likely, this is the same as  Issue 229010 .

So do I understand correctly: Your assumption is that this font has gone through processing similar to what is described in comments 4, 5 in https://bugs.chromium.org/p/chromium/issues/detail?id=229010#c4 e.g. converting upem from 1000 to 2048 or a related conversion which then results in incorrect bounding box outputs for the resulting font file that we find on the Vodafone site? Thanks for providing this reference.

I have contacted Dalton Maag about this issue and I am awaiting their feedback.

Running https://kabel.vodafone.de/static/fonts/ttf_vodafonelt-webfont.ttf through ttx from fonttools and then regenerating a font from it, which by default recalculates glyph bounding boxes, the font starts to work, example bounding box differences for semicolon:

Fixed:
    <TTGlyph name="semicolon" xMin="88" yMin="-199" xMax="275" yMax="985">                                                                                                                            
      <component glyphName="comma" x="23" y="0" flags="0x1000"/>                                                                                                                                      
      <component glyphName="period" x="0" y="825" flags="0x1000"/>                                                                                                                                    
    </TTGlyph>       

Original:
    <TTGlyph name="semicolon" xMin="43" yMin="-97" xMax="146" yMax="904">                                                                                                                             
      <component glyphName="comma" x="23" y="0" flags="0x1000"/>                                                                                                                                      
      <component glyphName="period" x="0" y="825" flags="0x1000"/>                                                                                                                                    
    </TTGlyph>

Closing as WontFix, as this is an issue which needs fixing in the font.

Yeah, this has to be the same FontForge issue, the symptoms match up too well. Essentially what happens is that if you invoke a fontforge python script through python (instead of running the fontforge binary directly) and teh script resizes the font then the pre-computed bounding boxes for any composite only glyphs will be left unresized.

If you can get in touch with the authors of this font, be sure to point them at https://github.com/fontforge/fontforge/issues/528 . Also of interest are https://github.com/georgd/EB-Garamond/commit/b67738a422fbc72e51b236062e473ab10d35d157 , and https://github.com/georgd/EB-Garamond/commit/3424f22d866dbf79f62539dd6a1838849a75a798 . The first of these shows how to work around the issue, the second that EB-Garamond maintainers just decided not to do the resize since it isn't really needed. 

Vodafone's agency tells me they have identified the subsetting problem and have a fix ready to go out in their next release for the website.