Why do we need special settings for the documentation?
Shouldn't the system fonts be enough?

System font settings applied only for UI elements, not for QWebView therefore any web browser has own font settings dialog. The system font is usually a Sans Serif font, but HTML engines also requires Serif font settings for "normal quality" rendering. And last - same font size setting (12 e.g.) for UI and Web-content produces fonts which are not equals (Web font is smaller).

The simplest way to "fix" documentation fonts - only increase it's size to "normal" values (according with current system font size). But then we have the problem - default font families for Sans, Serif Serif and Monospace fonts. My test shows that QWebView gets font families from fontconfig (e.g. fc-match monospace) and ignores KDE's System Settings. But most of users don't change fontconfig settings and as a result we have:

• some default Sans Serif font from fontconfig which is used by QWebView,
• selected by user Sans Serif system font for UI
• different font sizes for UI and HTML-content.

I see your point that there is a problem with not the correct fonts to be used in the Webview. But is another font config dialog really required to solve it? E.g. the user already selected (or KTextEditor did it by default) fonts for the editor panes; same for sans serif fonts selected for the UI. Can't such fonts be silently applied to the Webview?

In D2902#54091, @cordlandwehr wrote:

I see your point that there is a problem with not the correct fonts to be used in the Webview. But is another font config dialog really required to solve it? E.g. the user already selected (or KTextEditor did it by default) fonts for the editor panes; same for sans serif fonts selected for the UI. Can't such fonts be silently applied to the Webview?

Ok, we can get monospace font setting from KTextEditor, you are right. But serif font setting will be get from fontconfig. By default, this (unconfigurable) serif font is used for displaying documentation text (tested with man pages, Qt and CMake). Personally, I prefer sans serif for "main text" but current version of documentation plugin don't allow to do it. It will be best variant to have global "HTML fonts" system settings, but now it's impossible :(.

I would really prefer to be able to go without any KCM.

Can you look into testing if it works by using the general font for those that don't have a clear mapping to QFontDatabase::systemFont? Maybe enforce a font family in these?

Can you look into testing if it works by using the general font for those that don't have a clear mapping to QFontDatabase::systemFont? Maybe enforce a font family in these?

Ok, I comment results later.

I would really prefer to be able to go without any KCM.

But what's wrong with the additional settings? I agree that it is not necessary to overload the interface, but too simplify it, too bad - we may get a situation like in Gnome DE (many settings are removed because they "confuse and scare users").

I agree, we should just use the system-wide GUI font here. Settings are good if they solve problems or differentiate use cases; this IMO doesn't, it just fixes a bug, which is that the web view uses a different font than the rest of the application.

Ok. Then say your suggests about last problem - Serif font. It's setting available only from fontconfig, which often is "not-synchronized" with DE settings. We can solve it with:

1. Get value from fontconfig "as is" and hope for a "not too bad "result :)

2. Replace Serif font with system font, which is Sans Serif for most users (I don't know anyone who uses Serif for UI).

As for me, I would prefer 2nd variant.

2. Replace Serif font with system font, which is Sans Serif for most users (I don't know anyone who uses Serif for UI).

We can have an intermediate. Enforce the font family onto the system's font. Something like:

QFont f = qGuiApp->font();
f.setFamily("Serif");
return f;

This way we'd maintain size and other settings the user might have set.

I didn't so exactly follow this, but I'm confused why the "+4" is necessary. This sounds like something which would break on other systems. Don't we get the correct font size from e.g. the KDE default font?

I didn't so exactly follow this, but I'm confused why the "+4" is necessary. This sounds like something which would break on other systems. Don't we get the correct font size from e.g. the KDE default font?

"Magic constant" is removed. Now we use pixelSize of system fonts. It works good on my system (linux) but resulting font size is slightly bigger than system font. It can be "fixed" with pixelSize() - 1, but I think it not necessary (and this again adds "magic constatnt"), slightly bigger new documentation fonts are better then current too small sizes.

Have you tried using the pointSize instead?

+1

Have you tried using the pointSize instead?

@apol, yes - it provides too small fonts.

Example for following system fonts:

• QFontDatabase::GeneralFont (Sans Serif) - Ubuntu 14
• QFontDatabase::FixedFont - Ubuntu Mono 16
• QFontDatabase::SmallestReadableFont - Ubuntu 13

Result with using pixelSize():

Result with using pointSize():

I'm still confused why this doesn't give the same font, but ok, if it works go for it ;)

@brauch, it seems that HTML engines uses pixel-size for fonts. I check my Firefox settings again and found font sizes also differ from UI system settings.