Shifted webfont latin-only versus latin-arabic

Design
1

Hey Guys —

We’re designing a multi-script font and have come to the point of generating final webfonts.

Throughout we’ve generated the webfonts from Glyphs and topped up with SVGs using Transtype.

Recently however having output one of the larger sets (3200 glyphs) the WOFF was no longer being unpacked in Chrome. The solution / fix was to go back to Transtype to generate all of the files - as there were slightly different rendering issues I was forced to use Transtype as the de facto webfont generator across ALL scripts.

Having now generated an arabic-latin webfont in Transtype there is an vertical baseline shift as opposed to the latin only version staying in place, ie lining up with all the css elements correctly.

Technically all the vertical metric data is identical in the original source TTFs (glyphs, then Fontlab edited) though the arabic actually bursts these bounds.

So my question is what if anything is Glyphs doing differently to maintain a consistent baseline between a latin-only and latin-arabic font? Have you experienced a similiar issue previously?

In my desperation I used FontSquirrel only for the problems to multiply!

2

First check all vertical metrics settings in the final font (OS/2, hhea). If they didn’t change, it might be that the the browser calculates the line height from the bounding box and the arabic letters might have longer ascenders and descenders.

You know that you can add the SVG in Glyphs directly?

3

That’s what I was afraid of!

Will check the manual re SVGs. Good to know, thanks!