Nikolay Sivov nsivov@codeweavers.com wrote:
On 1/11/22 16:56, Dmitry Timoshkov wrote:
Nikolay Sivov nsivov@codeweavers.com wrote:
I don't think we want to test for font name match.
Could you please elaborate?
It's undocumented, could change over time,
Isn't that a pure speculation? Since there are applications depending on this it's pretty safe to assume that this mapping will be kept: https://stackoverflow.com/questions/25693651/how-does-directwrite-createtext...
and it's not something linux/mac users can easily install.
This has nothing to do with the problem.
For patch 2/2, it's not clear to me if using exact windows font name is a good idea, choice of characters range is also unclear.
I have a .Net WPF application that does precisely what the test replicates, and expects the exact character being rendered.
Test checks if fallback for 0x25d4 character returns a font that supports this character, that's what a successful result for MapCharacters() is in general. So why [0x2196, 0x2bef] specifically?
I have a program (attached) that generates the fallback ranges. I've slightly modified the resulting range(s) to avoid using complex ones, if required the range could be futher tuned for a particular usage pattern. An alternative is to look at the unicode ranges of the Segoe UI Symbol using fontforge.