DWriteCore WOFF2 format

[timeester3648]

I noticed the WOFF2 and also WOFF formats are not supported. Are these planned? The space saved is noticable, especially when trying to embed fonts in the executable itself (for a sane default if the host system has none, or before any real default has loaded from system folders).

[DarranRowe]

Just to ask, the way this is done in regular DWrite is to use IDWriteFactory5::UnpackFontFile. Are you unable to query for this interface when using DWriteCore?

[castorix]

Just to ask, the way this is done in regular DWrite is to use IDWriteFactory5::UnpackFontFile. Are you unable to query for this interface when using DWriteCore?

I had tested too and it returns E_NOTIMPL with DWriteCoreCreateFactory (works with DWriteCreateFactory)

[timeester3648]

Aside from @castorix's answer, I use IDWriteInMemoryFontFileLoader::CreateInMemoryFontFileReference, to create a font file, which works. But then I use IDWriteFontFile::Analyze, which returns isSupportedFontType == FALSE, fontFileType == DWRITE_FONT_FILE_TYPE_UNKNOWN and fontFaceType == DWRITE_FONT_FACE_TYPE_UNKNOWN. The fact that it is not supported is also kind off predicatable by the fact that DWRITE_FONT_FILE_TYPE has no DWRITE_FONT_FILE_TYPE_WOFF2 or something.

[JohnnyWestlake]

@timeester3648 WOFF2 gets unpacked into its uncompressed format after using IDWriteFactory5::UnpackFontFile, so there will never be DWRITE_FONT_FILE_TYPE_WOFF2 - it will show one of the existing formats after being decompressed.

From a performance perspective not using WOFF2 is generally better, as the entire font file doesn't have to be loaded into memory to access specific glyphs given how well font files are packed and indexed. Keep in mind TTF/OTF were originally designed in a way to allow them to function without being fully loaded in memory. Unfortunately for WOFF2 it goes against that as you have to decompress the entire thing and load into memory - you get space savings in exchange for more memory usage, and, with multiple fonts, slower startup.

Useful for the web, not so much for desktop.

(Though that is tangential to the support in DWriteCore, given normal DWrite already allows manual WOFF2 usage)

[timeester3648]

@JohnnyWestlake That WOFF2 has to be completely decompressed first is no issue in my use case, since i use DWriteCore as a layout engine for text for game (engine) programming, and the entire font file needs to be preprocessed anyway. Gradual loading of fonts is not only undesirable in this use case, but actually a hard no too. So in that case it can be still useful for desktop (before it is packaged in the engine specific format of course). However, as @castorix has mentioned, IDWriteFactory5::UnpackFontFile seems to not be implemented, so instead of adding DWRITE_FONT_FILE_TYPE_WOFF2, the question can become whether IDWriteFactory5::UnpackFontFile is planned to be implemented again.

[DarranRowe]

To be absolutely correct, it is iffy to just add a DWRITE_FONT_FILE_TYPE enum value.

First, it seems like one of the big goals of DWriteCore is to keep as much compatibility as possible, so it would be problematic if DWriteCore had more values than DWrite. Second, DWrite is a COM like interface, this means things should stay fixed, and there should be no changes to the interface. Having a change in DWRITE_FONT_FILE_TYPE really should require a new DWRITE_FONT_FILE_TYPE (possibly named DWRITE_FONT_FILE_TYPE1) with the new values added. Then there should be a new interface, possibly IDWriteFontFile1 with a new member named Analyze1 that outputs the new enumeration.

[mominshaikhdevs]

@RDMacLachlan I don't get the point of converting this issue #5039 to "a discussion". as it's clearly a feature request. and It's not even resolved. so, that issue should've been kept open for future considerations.

[DarranRowe]

It's not just that, there is also no documentation indicating that IDWriteFactory5::UnpackFontFile is missing.

If this was always intended, then the documentation is incomplete. Missing functionality must be documented. If this wasn't intended then this is a bug.