Installing woff fonts

[KevinH]

Does it happen under Linux? I tested loading and opening DNSB's test epub 20 times in a row on macOS and it never had a problem.

If we can recreate it under Linux, we may be able to track it down easier.

[DiapDealer]

Originally Posted by DNSB

As an experiment, you might also want to try setting the display scaling to 100%. A while back I had an issue with an app using Qt6 that was not happy with some fonts that QT6 interpreted as passing invalid data when the display scaling was not 100%.

Bingo! I typically run at 125% on this laptop, but changing it to 100% allows the epub in question to load without crashing Sigil. So it IS Qt6. It also explains why it seems to be manifesting more on laptops. But I would expect anyone using a highdpi monitor with Windows to be running a scaling greater than 100%, no?

Unfortunately, telling users to change to 100% scaling isn't really a viable workaround. It'd be easier to tell them to ditch the woff fonts!

I don't really know where to begin.

[KevinH]

Does this bug recreate with Qt 6.6.2 as well? Perhaps it is fixed there (he said hopefully!).

[DiapDealer]

Originally Posted by KevinH

Does this bug recreate with Qt 6.6.2 as well? Perhaps it is fixed there (he said hopefully!).

No such luck. The version of Sigil I'm running on the laptop was built using our new Qt6.6.2.

I also tested on Linux and can't recreate the problem there. I've got a highdpi monitor for my linux box that scales the display to 175%.

[KevinH]

Well that sucks! The number of Windows font handling bugs listed in the qtbug database is quite large with many closed automatically after a time with no fixes.

There was one font bug related to dpi scaling that may be related but they found a workaround by disableing Windows directwrite as follows:

application.exe -platform windows:nodirectwrite


Does adding that prevent the crash?

If not, I am out of ideas.

[KevinH]

If we can track down where exactly it is crashing, we can probably find a patch workaround.

There was a nice testcase here that might be useful if it can recreate the crash:

https://bugreports.qt.io/browse/QTBUG-108204

[KevinH]

I wonder if this is a graphics driver bug that tickles a Qt bug. There were a number of font handling related bug reports in Qt all for a single type of graphics card.

Could everyone experiencing these issues with woff fonts by using the same graphics card company?

[KevinH]

And here is the only recent Windows specific font change that made it into dev head that is not in Qt 6.6.2 as far as I can tell.

https://github.com/qt/qtbase/commit/...827305ef4a7040

So there are different font backends on Windows we can try to see if any properly handle the woff fonts when dpi scaling is not 100%

They are listed in the commit comments.

[DiapDealer]

Originally Posted by KevinH

Well that sucks! The number of Windows font handling bugs listed in the qtbug database is quite large with many closed automatically after a time with no fixes.

There was one font bug related to dpi scaling that may be related but they found a workaround by disableing Windows directwrite as follows:

application.exe -platform windows:nodirectwrite


Does adding that prevent the crash?

If not, I am out of ideas.

That DOES, in fact, prevent the crash! I added it via the QT_QPA_PLATFORM environment variable. The Sigil debug output verifies that the platform argument is being implemented:

Debug: Current windows platform args:  QList("nomousefromtouch", "nodirectwrite")
Debug: New windows platform args:  "windows:nomousefromtouch:nodirectwrite:altgr"

After launching the epub in question (successfully), the debug output includes:

Warning: QWindowsFontDatabase::fontEngine: Can't change family name of font

Once for each of the 8 woff2 fonts included in the test epub.

[Doitsu]

I was able to reproduce this with Windows 11 and the Gentium Plus 6.200 fonts on my laptop.
https://software.sil.org/gentium/download/

Here are the steps:

• Download the Gentium fonts und unzip them.
• Right-click the Desktop, select Display Settings or enter Display Settings in the Search box.
• Scroll down to Scale & layout, select Custom Scaling and enter 120.
• Windows will ask you to log out.
• Login again and create a blank epub2 oder epub3 book.
• Add woff or woff2 fonts from the web sub folder to the Sigil Fonts folder.

BTW, Sigil won't crash, if any of the Gentium .ttf fonts are added to the Fonts folder. while custom scaling is in effect. It also appears that the Sigil font handler might have problems reading the font metadata, because it displays "No reliable font data" instead of the font name for all woff and woff2 fonts when no custom scaling is in effect.

[DiapDealer]

Originally Posted by KevinH

Could everyone experiencing these issues with woff fonts by using the same graphics card company?

I just noticed this, but I don't think it's the case. Mine is an integrated intel graphics card, and the user who reported the github issue appears to have an nvidia card (according to the machine specs in the link they included).

[Doitsu]

Originally Posted by DiapDealer

I just noticed this, but I don't think it's the case. Mine is an integrated intel graphics card, and the user who reported the github issue appears to have an nvidia card (according to the machine specs in the link they included).

My cheap laptop has an integrated graphics card:
Processor AMD A4-9125 RADEON R3, 4 COMPUTE CORES 2C+2G, 2300 Mhz, 2 Core(s), 2 Logical Processor(s)

[DiapDealer]

Did you check to see if adding Kevin's above platform argument works with scales other than 100%?

application.exe -platform windows:nodirectwrite

You can also set the QT_QPA_PLATFORM environment variable to windows:nodirectwrite

[KevinH]

FWIW, Qt 6 dev and 6.8 will default to always using the DirectWrite backend for fonts on Windows. But DirectWrite backend support is incomplete as of Qt 6.6.x as it is missing the following changes that dev provides:

https://github.com/qt/qtbase/commit/...9280ae524482b7

So the only thing that will workaround this issue to to force fallback to the gdi font backend on Windows.

Alternatively we could try to backport the directwrite backend fixes from dev back to Qt 6.6.2 and hope that does the trick as it completes support for more font types. I have no idea if that is doable or not.

[Doitsu]

Originally Posted by DiapDealer

Did you check to see if adding Kevin's above platform argument works with scales other than 100%?

When I used the following path in the Run dialog and hit Enter, Sigil didn't crash:

"C:\Program Files\Sigil\Sigil.exe" -platform windows:nodirectwrite