Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
directwrite: always read metadata on our own via FreeType
DirectWrite sometimes returns names that differ from GDI's. Instead of trusting it, use our own GDI-compatible code, even if it costs us some extra resources. Conceptually, this reverts commit 4fb7394 "directwrite: read metadata from IDWriteFontFace3 if possible": the refactoring is kept, and so is the read of the PostScript name purely for logging purposes in case of error, but we turn back to (re)reading all metadata on our own. In addition to reverting the logic of the IDWriteFontFace3 path, this also makes the CreateFontFromLOGFONT path similarly go via FreeType. This fixes libass#675 and facilitates future improvements to long font name matching (libass#459). To avoid exotic failures, especially font fallback failures, save DirectWrite's WIN32_FAMILY_NAME as our extended_family. get_fallback returns the WIN32_FAMILY_NAME, and it *should* match what we read for the same font via FreeType, but it is not unfathomable that in some exotic cases it might not match or we might not read any family names at all. fontselect consults the extended_family for fallback fonts and for primary fonts that otherwise have no family names. We might actually want to use WWS_FAMILY_NAME (or presumably equivalently, DirectWrite's first-class font family names) as the extended_family to allow better fallback to multi-weight families given tags like \b900, but there are at least two reasons why WIN32_FAMILY_NAME seems better at the moment: * Across all Windows versions and variants, match_fonts is only guaranteed (if even that) to find a font by its WIN32_FAMILY_NAME. For the fallback font to work, we obviously need match_fonts to be able to find it. We could alleviate this by querying DirectWrite for fonts by its first-class family name in addition to the primary GDI-based path. * While WWS_FAMILY_NAME joins, for example, Arial and Arial Bold, which is desirable, it also joins Arial and Arial Narrow, but we do not distinguish between fonts that differ only in width/stretch. Barring additional width-based ordering logic somewhere, this could lead us to choose an inconsistent combination of fallback font faces, e. g. regular Arial for \i0 with Arial Narrow Italic for \i1.
- Loading branch information