Essential for text selection and editing in cases where mapping from the
input text to the actual shaped glyphs is nontrivial. I.e., in case of
HarfBuzzFont; both FreeTypeFont and StbTrueTypeFont perform a 1:1
translation from input (UTF-8) characters to glyphs so there it isn't
as important.
It fixed interpolation for a more precise rounding, which means the
ground truth files for this test are now off-by-one compared to before.
In particular, nothing in the _source_ BCn data or the Y-flip algorithm
changed, it's just that they're now decoded to RGBA differently by bcdec
so the tests fail.
Worked on x86, works on ARM Linux (with GCC) as well. Not sure if it has
anything to do with long doubles being 64bit there, but I don't think it
should.
Having it next to AbstractShaper didn't make sense, as there's various
use cases where font features are specified but the caller code doesn't
even know there's any shaper involved. Such as in the UI library.
Based on the actual text direction (either explicitly set or detected),
these resolve to either *Left or *Right. For the Text::Renderer it's
done automatically inside (and there's no way to actually set the
direction from outside due to the API being ancient and limited), for
the align*() utils the alignment has to be explicitly resolved using a
new alignmentForDirection() utility.
There shouldn't be any other values passed to these. Compilers, don't
even attempt to say that the alignment value is now maybe uninitialized,
I'm watching you!
Microsoft should fire all versioning scheme managers and then start
over. Why a single product needs
- a marketing version that's just a year number
- a major.minor.patch marketing version because the year was too coarse
to be meaningful for anything, and that version being also completely
unrelated to the year for good measure
- a runtime library version that used to match the major.minor marketing
version a decade ago but then it somehow got out of sync
- a _MSC_VER macro that was in sync with the short marketing version
last time in 1989 and never again
- an internal build number that feels like a countermeasure to "sorry,
can't have reproducible builds so be sure to ship the artifact number
194033811, that one we tested"
This is going to get called from fillGlyphCache() that takes a string,
and thus should be better than one virtual call per character. The
single-character variant still stays, as it's a nice convenience API.
Eventually glyphSize() will get a similar treatment as well.
Other (development) packages don't need this as they disable
makepkg-supplied buildflags altogether.
Co-authored-by: Konstantinos Chatzilygeroudis <costashatz@gmail.com>
Expands the test added in 789c52fd8a, for
which a fix was done in 8f6f4053fc but
which forgot to handle the case where a buffer is unbound. The test now
fails with an invalid error.
This was already done for all application libraries and then also all
contexts in 1c6f77389d, was forgotten here
for some reason. A use case that may need it is a shared library shared
(heh) by multiple test executables.
This was due to the internal counter in the object being just 2 bytes,
which was made in order to optimize the Object class size. In practice
however, not counting the vtables, the class has SEVEN pointers and then
a transformation part that's in most cases multiple of 8. Which means
that on 64 bit platforms there was always 5 bytes of padding next to
this 2-byte counter and 1-byte flags, thus no reason to have it 2-byte
anyway.
On 32-bit platforms this *might* cause the Object to get bigger, yes,
but as it's heap-allocated it's more likely that it's put on a
16-byte-aligned address and thus occupying a multiple of 16 bytes
anyway. In any case, this won't really hurt, because the SceneGraph
situation is bad enough already due to all the pointer chasings and
overhead from loose allocations.
It now delegates to Assimp for ASCII files, along with StlImporter that
does the same but was already marked as having minor caveats. Better
than nothing, and it's not my problem that Assimp leaks and crashes like
mad on broken files.
Took me quite a while to realize what was going on, but in retrospect
it's obvious -- the rasterizer just *rounds* the sub-pixel-positioned
glyph quads to nearest pixels. Which then can cause the neighboring
glyph data to leak to it (because the texture is then sampled not
directly on the edge pixel, but slightly outside of it), or it can also
cut away the edge, when it gets rounded in the other direction.
This was a problem with the original -- laughably inefficient -- atlas
packer as well, but because that packer had excessive padding around
everything, only the second edge-cutting artifact manifested, and that
one is rather subtle unless you know what to look for.
This means the packing is now slightly worse than before and sizes that
previously worked may no longer fit anymore. But since the new atlas
packer is relatively new (well, from September, time sure flies
different here), and the improvement compared to the original packer is
still quite massive, I don't think this is a problem.
Vladimír Vondruš