Editor uses faux italics/bold

[HeyMyian]

Since around commit f2b9409 (the Unicode fix), the document editor uses faux italics/bold. This is only a minor issue since no functionality is impeded, but if it can be helped, true italics/bold styles are preferred.

(As far as I know, the document viewer has always displayed faux.)

Since faux styles seem to have been a problem in the past with KDE, I tested in a freshly setup VM with Debian 12 and Cinnamon. The screenshots are from there. Font in both cases is Noto Serif Regular (pre-installed).

novelWriter 2.7.4 release, installed with pip in venv
True talics/bold in the editor ✅

Current main
Faux italics/bold in the editor ❌

[vkbo]

The 4 byte Unicode fix should have no impact on the content of the editor unless there are 4 byte symbols present, so this is strange since you don't seem to have any in the example. Are you sure this is where the change occurs?

All of the font stuff is handled by the Qt font matching engine and not by novelWriter. I remember there were some issues with the native Qt PDF format in the past, but I can't remember what the issue was.

[HeyMyian]

The example is in a new, empty project. I only added the text to the editor as seen in the screenshot. The issue appears the same though in my sample project from the repo.

I learned a bit how to navigate the git tree and narrowed it down further in the unicode fix branch:

• 680fc32 first faux italics (Fix highlighting of markup and spell checking for 4 byte Unicode)
• 9af498d last true italics (Drop redundant re.UNICODE flag)

I hope this helps, I can't read this.

[HeyMyian]

When I add this line 438 back into the current main, italics and bold are fixed. I just don't know what else this does to the Unicode issue:

680fc32#diff-5d0fc7bd35dc01df2011f8efda214ab83ef8ef61d34575dbb00b72fd25f33f09L438

charFormat.setFontStyleName(name)

[vkbo]

Yeah, this has nothing to do with the Unicode change itself. It's just something I fixed at the same time because that's when I spotted it. It was used to mark certain text as markup so that the markup highlighting would take priority over other highlighting on those characters. I got the code from some example somewhere, and the old code used the setting incorrectly by high-jacking the fontStyleName property. The change moves the flag to a proper user-defined property instead. The fontStyleName property itself is related to font style matching: https://doc.qt.io/qt-6/qfont.html#styleName

I'm guessing setting it to the novelWriter internal labels used for syntax highlighting interfered with the font matching algorithm in some way, forcing it to behave differently. Restoring the line is not the correct solution, but at least it gives a clue to what is causing the change in behaviour.

Thanks for investigating!

[HeyMyian]

Thanks for investigating!

It seems I'm the faux italics person. If there is an issue with faux italics, I'm on the case!

[vkbo]

I don't even notice. 😆

[vkbo]

Ok, so I investigated a bit, and this is just tricky to figure out. However, I managed to make it work ... I think.

So, the code itself that I removed did not actually do anything directly. It had the curious effect, instead, of resetting the style name of the underlying loaded font. As I understand it, the syntax highlighting formats shouldn't have any effect on the document other than overlay syntax highlighting at render time. Clearly that isn't always the case.

Here is what happens, as far as I can figure out:

1. Font settings are loaded from config, and look something like this:
   textfont = Noto Serif,12,-1,5,400,0,0,0,0,0,0,0,0,0,0,1,Regular
   Notice the "Regular" at the end. That's the style you select in the font selection dialog in Preferences.
2. When the font is loaded, the "Regular" string, or whatever word is set there, seems to tell the font that it should use just "Regular" (in this case) and it seems to cause the text rendering to generate bold and italic from the "Regular" font style. This is actually what you select in Preferences, so I expect in some internal Qt logic, there is nothing wrong. The docs (linked earlier) even say you shouldn't use the font style name mixed with explicit weight and emphasis settings.
3. In the syntax highlighter, the old code used the setFontStyleName value to remember what syntax highlighting was applied to each piece of text. There is documentation out there that says this is correct, but the Qt docs themselves seem to contradict this. In any case, setting the value in the highlighter seems to have affected the underlying font object and since the style name is no longer set to "Regular" (in your example case) it goes back to matching from the family of font styles rather than just adapting the "Regular" font style. I.e. it's an unexpected side effect of the highlighting code (and perhaps a bug).
4. If I immediately after loading the font, call setFontStyleName(None) on the font object, the editor and viewer switch to select the italic style for italic text instead of just tilting the "Regular" style.
5. With the above change, the textfont setting in the config file no longer has the "Regular" bit at the end. However, if I select Noto Serif Italic in Preferences, all text is italic, and it stays that way even after reload, even without the "Regular" bit in the setting (it's handled by some of the other numeric flags).

I think this is the desired outcome, so I'm going to add the setFontStyleName(None) to my font matching helper function, like this:

The change has been pushed to the font_matching branch. It would be nice if you could run it through your varying tests to see if it resolves the issue!

[vkbo]

While researching, I came across this article which explains the use case I did use this setting for. It's not where I originally got it from, that was from some example code I adapted for the Collett app, but I added it to novelWriter after. I think the article is wrong. At least some of what it says seems to contradict what the Qt docs say.

https://runebook.dev/en/articles/qt/qfont/setStyleName

[HeyMyian]

font_matching fixes all my issues. On current main and previously, faux styles would be used in the following (on Linux/KDE neon at least, which we thought was a KDE specific issue):

• pdf build
• pdf preview
• novelWriter UI
• document viewer

This was also discussed in #2110.

In font_matching branch they're all true italics/bold ✨

Tested on KDE neon, and in Debian/Cinnamon VM.

[HeyMyian]

I also checked on Windows 10. The current main branch has all the same issues, and font_matching fixes all.

True italics are wonderful ✨
Thank you 🙂

[vkbo]

So much joy from a one-line fix 😆

[HeyMyian]

If I immediately after loading the font, call setFontStyleName(None) on the font object, the editor and viewer switch to select the italic style for italic text instead of just tilting the "Regular" style.

So weird though, the hoops one has to jump through to get this right. It feels like fighting the code or playing whack-a-mole. I hope this doesn't break anything else.