Font scaling problems with source sans pro

[nigelbalchin]

Source Sans Pro seems to suffer from a bug in that the font renders numbers and characters with different heights when both are set to the same font size. The issue affects web pages as well as desktop applications and is more noticeable at given font sizes. The issue occurs at different font sizes depending on the browser; some examples:​
Chrome 8, 10, 13, 14, 17, 19, 24, 26, 28, 29, 30, 31…​
Firefox 10, 13, 16, 18, 21, 24, 27, 30, 32, 33…​
​
Using the zoom, both on WEB and desktop apps, has the effect of scaling the font, thus either fixing or introducing the problem, depending on the zoom scale factor.​

Note: The zoom doesn’t seem to introduce the problem when starting from a scale-safe font size

Internet Explorer​
This font is not designed to work with IE, as stated by the google font portal when trying to load the Source Sans Pro page in IE

We thought to baseline on this font, yet are now needing to review our systems as a workaround to try to make sure that no irregular rescaling of the font-size takes place.

[frankrolf]

See also #109 – to circumvent traditional figure size you can use the case feature which swaps figures to cap-height versions.
FYI Noto Sans in your screenshot does not seem to be Noto Sans.

[nigelbalchin]

Thanks for the suggestion Frank - we'll look into this now

[frankrolf]

Oops, I just realize Source Sans doesn’t provide cap-height figures (unlike the other members of the Source family). Since this has been requested more than once, we should look into adding this feature.
For now – there is no scaling problem, rasterization differences are only due to the fact that the figures are generally slightly lower than caps.

[pauldhunt]

In fact, the upright versions of the fonts do include cap-height numerals accessible via the feature in the latest release:
https://github.com/adobe-fonts/source-sans-pro/releases/tag/2.020R-ro%2F1.075R-it

[frankrolf]

I made my remark based on the code in the case feature, in which I don’t see the cap figures referenced:
https://github.com/adobe-fonts/source-sans-pro/blob/ff3bdec0a9ed367bfd6b05572f5dabebf030e7bb/Roman/familyGSUB.fea#L744-L750

[nigelbalchin]

Thanks everyone - Paul and Frank - for the assists on this. We have downloaded this distribution and with this feature switched to on it seems to fix the height issue; just one minor point remaining in that the font weighting now seems lighter. We would be grateful please if there are any further thoughts; or this could please be escalated for full address and testing in the main code trunk.

Cheers

[frankrolf]

I’m sorry to say that Source Sans Pro currently does not support the feature I am describing. The cap-height figures have been designed, but they are not hooked up in the OpenType feature code.

The rasterization problem above is a completely different story – is the font on the right side still Source Sans Pro? Are you using the same font format?

[nigelbalchin]

Hi Frank - we'd like to know if you have a plan to fix this. The font on the right is the same so something must be working here but we can't have these bugs with the font's weighting. We need a robust solution for this so can you please advise when a fix will be in the codebase? Otherwise we may need to fork and get a fix put in there ourselves on a proprietary basis. This is not ideal for us as we would have to break continuity with your main trunk; and potentially re-align at some point in the future and we were not looking to do that with a typeface with a history as prominent as this one: http://www.adobe.com/uk/products/type/font-information/source-sans-pro-readme.html

[frankrolf]

This will definitely be fixed, but there is no timeline.

[nigelbalchin]

Hi Frank - we need a fix for this; is there an escalation point within the project or with Adobe where we could discuss this? I can see a couple of options - perhaps we commission a fontographer to make the fix on a fork, then offer that back to the project. OR leverage a fix by contributing to the project towards a resolution cost on this issue. Can you please advise me how I might progress with either tack? Cheers

[frankrolf]

This is an open source project. There is no escalation, this is as high as it gets.
You are free to do whatever you see fit (fork, contribute, hire someone to do it etc), as long as you follow the contribution rules (the forked project cannot be called Source).
@pauldhunt may have more to say, but as I already mentioned – we won’t commit to a timeline for bug fixes.

[nigelbalchin]

Thanks Frank - we are only trying to help resolve this position. We are working with a multi-national financial company who has made a decision to go for this typeface only to have them experience these issues with numerical display making it not fit for purpose for them. We are trying to accelerate a fix and are prepared to ask if we can help the project to fix it directly, or if we can fork the code we can perhaps merge it back if we can find a good fontographer, though we are not as expert as you in this. Any assistance or recommendations from you or @pauldhunt would be much appreciated as we are at an impasse at present and the typeface though suited for digital interface display is not giving us reliable performance with numbers.

[pauldhunt]

@nigelbalchin how soon would you need fonts for this purpose?

[nigelbalchin]

Hi @pauldhunt - really we need them now so we are looking to accelerate ourselves.
We are engaging a fontographer to manually adjust the numerals in the font to match the cap height. We could offer this work back to the source if you like - would that be something we could co-ordinate with you on? I'd be happy to put you in contact directly.
Otherwise if you make the fix yourselves in the main trunk, we could pick it up later.
Many thanks
Nigel

[frankrolf]

@nigelbalchin The scaled numbers already exist, all that’s missing is the internal hookup via OpenType features. See #126

[pauldhunt]

@nigelbalchin please contact me directly at: phunt (at) adobe (dot) com

[erniemarch]

Checked in Roman version 2.034 and Italic version 1.084. These figures are present in the fonts and work correctly in InDesign CC 2018, although I would point out the height difference is quite subtle.

[miguelsousa]

Fixed in version 2.040.