[src\meson.build] Add DirectWrite has dependency
[src\font_file_lister_gdi] Rework GDI FontCollector to use DirectWrite
This replaces all the logic of using the Windows registry to obtain the font path by using DirectWrite. The goal is simply to improve the quality of the code. This doesn't change any functionality
[src\meson.build] Remove Uniscribe has dependency
Uniscribe was only used for the FontCollector. Since we now use DirectWrite, we don't need it anymore.
[src\dialog_fonts_collector] Catch exceptions that FontCollector may raise
On Windows, the initialization of the FontCollector can raise an exception
[src\font_file_lister] Document the exception that GdiFontFileLister can throw
[src\font_file_lister_gdi] Correct possible memory leak when an error occur
Fix error caused by AddFontResource on Windows 10 or higher
[meson.build] Replace add_project_arguments with conf.set for HAVE_DWRITE_3
[src\dialog_fonts_collector] Update message error and optimisation
[src\font_file_lister_gdi] Correct documentation typo
[src\font_file_lister_gdi] Cosmetic nit - Initialize hfont in one line
[src\font_file_lister_gdi] Cosmetic nit - Remove if statements brace
[src\font_file_lister_gdi] Replace WCHAR param of normalizeFilePathCase to std::wstring
[src\font_file_lister_gdi] Replace WCHAR by std::wstring
[src\font_file_lister_gdi] Use IDWriteFontFace::GetSimulations to detect fake_italic/fake_bold
See this comment: https://github.com/arch1t3cht/Aegisub/pull/107#issuecomment-1975229652
[src\font_file_lister_gdi] If Win7/8 has Win 10 SDK on compile time, correctly verify if font has character(s)
With the Visual Studio 2019 toolchain on Windows 7, it installs the Windows 10 SDK by default. Because of this, ``HAVE_DWRITE_3`` is true, so the ``QueryInterface`` always fails. Now, if the ``QueryInterface`` fails, we try to verify if the font has characters with a Windows Vista SP2 compatible code.
[src\font_file_lister_gdi] Support facename that contains only whitespace AND truncated facename
Problem 1:
Previously, if a user wrote "\fn ", it would return the font Arial, which is not what we want. This is because when we request EnumFontFamiliesEx with whitespace or an empty lfFaceName, it will enumerate all the installed fonts.
Solution 1:
To resolve this issue, let's implement a solution similar to libass to determine if the selected facename exists: 649a7c2e1f/libass/ass_directwrite.c (L737-L747)
Problem 2:
GDI truncates font names to 31 characters. See: https://github.com/libass/libass/issues/459
However, since I changed the method to determine if a facename exists, I ensured that we still support this "feature".
To test this, I used the font in: https://github.com/libass/libass/issues/710
[src\font_file_lister_gdi] Add a FIXME comment regarding the utilization of std::wstring over WCHAR
[src\font_file_lister_gdi] Add FIXME comment about charset
This reverts commit c487dd2bdb.
Revert the commit that
partially reverted fffb138b81 ...
It turns out that this very much did break IME input, so reverting
this for now. This does make Aegisub use private symbols in wx again,
but the CI builds build wx from the wrap now. Still, this is why
this is on the workarounds branch. If this breaks for too many
people this could either go behind a meson option or be fixed in
some better magical way that I have yet to find.
Fixesarch1t3cht/Aegisub#90Fixesarch1t3cht/Aegisub#91
This default script will be executed to load any file whose file name
extension is not .py or .vpy .
The gui code for setting the default script is still a bit wonky as it
doesn't fit the rest of the preferences pages nicely, but it works for
now.
- To allow for XAudio2 to work properly, we need to rework how does provider work since they only are used to be able to take in mono audio.
- Other providers have been dumbed down to accept single channel audio since originally aegisub only accepted 1 channel audio.
- meson.build has been modified to accommodate for xaudio, as we currently don't accept redistributable forms of xaudio, we need to work around the WinNT version.
- There has been 1 more fix to res.rc to allow for compiling on non tagged releases.
Line folds are managed using metadata of AssDialogue elements, and
saved in the project properties. They only affect the appearance of the
subtitle grid, and have no impact on other line operations.
I haven't checked whether reverting this breaks IME input, and if it doesn't what changed on wx's end. However, this is the commit that uses private symbols, and so reverting it lets us build against upstream wx. Even if this is a loss in functionality, for now it's fine.
arch1t3cht