Font differences between 7.9 and 8.1

SonarQube
1
  • Versions used (SonarQube 8.1)
  • Error observed: The font looks bad. Everything is bolded.
  • View the SonarQube 8.1 web interface without Helvetica fonts installed
  • Cause: Segoe UI was removed from the font family to “improve fonts for windows users”
    See: [SONAR-12468] Broken fonts on Windows system - SonarSource

Comparison:

7.9

image
image1001×886 48.4 KB

8.1

image
image991×837 46.7 KB

Arial is fine as a fallback font, but it’s not the most attractive look. Segoe UI was a far better font for Windows users.
I believe it would be beneficial for Segoe UI or a comparable font to be added back into the font family.

Cheers,
Jonah

3

Hi @Jonah_IntegraDev,

Indeed, Segoe UI looks more elegant at first glance, which is why we were using it so far. However, it has issues when it comes to aligning elements. It tends to have a slightly lower baseline, which sometimes crops letters that drop below it (like g, p, y, etc).

One example:

cropped

We didn’t dig too far, but this is likely related to Microsoft having updated the font for more recent Windows releases (issues were reported on Windows 10, Chrome and Edge).

As we don’t apply OS-specific styles, this isn’t something we can – or want to – fix for Windows only :man_shrugging:. We weren’t in favor of adjusting sizes or styles of parts of the UI that were working just fine before, and still are for users that don’t have the “faulty” version of Segoe UI.

In the end, Arial is very close to Helvetica, which gives us more confidence when validating the UI, knowing most Windows and macOS users will have a very similar experience (Linux, unfortunately, is another story :sweat_smile:).

4

Hi @Wouter_Admiraal,

Thanks for your response.

I’m not sure that removing this font is the correct solution to the problem.
Display issues around Segoe UI’s lower baseline are actually a symptom of the assumption that all line heights will be 1.23076923, and this styling being applied to the body of the page. That line height is then relied on for the alignment of various elements throughout the page.

The fix for your example is as simple as specifying ‘line-height: normal’ on the .text-ellipsis class.

Please let me know what your thoughts.

Cheers,
Jonah

5

.text-ellipsis doesn’t define a line-height (and it shouldn’t). It’s role is purely to make overflowing text show up as an ellipsis.

True, the default global line-height might not work for Segoe UI. But setting different line-heights to specific elements just to make it work for Segoe UI is exactly what we’re trying to avoid :man_shrugging: .

6

Hi @Wouter_Admiraal,
A quick search of the main css file indicates that there are already 49 other line-height overrides.
Is there a reason this would be any different?

7

These are always in highly specific contexts. No way we’re introducing such overrides in something generic that can be used in a wide variety of locations.

SonarQube is not a marketing tool or a pretty website. It’s a tool. Its main purpose is not to look good, it’s to make life as easy and as efficient as possible for developers around the world. I’m truly sorry you don’t like the font change on Windows, and as an ex-designer-turned-webdev, I get that. But it works, it makes our life easier when validating features (knowing it will look almost identical on at least Windows and macOS), which in turn frees up more time and resources to focus on other, more valuable aspects :man_shrugging:.

Thanks for taking the time investigating this, and showing that you care about SonarQube. We might consider putting Segoe UI back in the future, but right now, it’s not on our priority list.