With StbTrueTypeFont no longer being embarrassingly slow due to a stupid
error, the MagnumFont plugin doesn't really provide any advantage
anymore. Originally I thought I'd update it to not be forcibly relying
on a TGA format and maybe add kerning support, but the image + text
format is extremely inefficient compared to basically anything else and
so I don't see a point in supporting it further. Marking it as
deprecated should also hint to people that using this thing is not a
good idea.
The MagnumFontConverter plugin was also the only user of the
AbstractFontConverter APIs, which right now are the last that didn't go
through a STL cleanup process. I plan to make a converter plugin for
font "minification" using HarfBuzz subsetting functionality, and not
having to support anything else that relies on the outdated APIs will
make the font converter API updates a bit easier.
Finally, the MagnumFont plugin was also the last one that directly
instantiated the TgaImporter plugin, instead of going through
AnyImageConverter. Marking it deprecated allows me to deprecate direct
instatiation in the remaining plugins as well.
Glyph cache implementations in the Text library pick features based on
those, and while I'm pretty sure I tested both codepaths at some point,
not having them automatically covered makes them prone to code rot.
This was already done in Magnum Extras, but because here the code
coverage is not 99.99% I never actually saw these. Until now, where both
Text::AbstractShaper and Text::AbstractGlyphCache report destructor
*declaration* as uncovered. Destructor definition is covered, obviously,
so reporting this as uncovered is wrong.
Which makes libc++ since version 16 not use transitive includes for
backwards compatibility, both for faster build times and to detect if
some code is missing a transitive include (which could blow up for the
user even w/o this macro defined, as compiling with -std=c++23 also
removes quite a lot such includes).
This affects Android, macOS/iOS and Emscripten. On the CI right now all
VMs use older libc++, which means it does nothing, but it's done there
anyway to future-proof. Locally on Arch it affects the Android and
Emscripten builds already, as well as an explicit clang + libc++ build.
I thought I went over all these several years ago already, but
apparently not or maybe back then not all websites were HTTPS-ready. Now
they mostly are, except for maybe one or two.
I'm giving up there. Both Clang-cl and MinGW GCC report a far bigger
set of lines than their Linux / Mac counterparts (block ends, lines
containing just `else`, etc etc.), which wouldn't be a problem on its
own, if those lines would be covered. But on Windows there isn't a
single CI job that runs through GL/Vk codepaths -- as Mesa isn't easy to
get there and SwiftShader is utter crap -- which means there are extra
lines in GL/Vk codepaths that are reported as uncovered from Windows CI
jobs, while the same lines on Linux and Mac arere excluded and thus
there isn't anything that could make them green as well.
Not sure why this wasn't a problem in Corrade, maybe because here the
clang-cl build doesn't run GL tests and so while there the } lines were
marked by it as covered (instead of being ignored), here they're marked
as uncovered and all other jobs ignore them?
This means SwiftShader is only used for Mac ES3 build and Android.
Also remove the parallelism and --output-on-failure, it's unhelpful as
it only leads to less information being provided if the CI fails.
This apparently works well for quite some time (this is Ubuntu 18.04,
after all!), I just didn't know because the build defaults to GLX which
doesn't work headless. So, yeah, code coverage, here I come!