On Sat Dec 21 23:25:51 2024 +0000, Nikolay Sivov wrote:
By range I mean a segment of original text that has uniform properties, one of them being writing script property. In directwrite this is done by splitting up the text by the script (each unicode point belongs to some script, or is attached to preceding/following range), and then further by properties that user had applied to the text, such as preferred locale for example. This way we never do font mapping for text that contains characters from different scripts. I don't remember now if I had tested this properly, but it's certainly possible to do. We probably don't do such segmentation in gdi+. For gdi+ this might be impossible to test reliably, because it does not let you control fallback behavior.
One thing I hadn't considered before: space characters will most likely be available in the desired font. On long strings, this is likely to lead to a lot of font switching, which is probably not good for performance.
I'm not really sure when this will come up in practice and what our priorities will be, but in every known regressive case, we ended up using font linking when every character was available in the requested font. In those cases, everything was done right before and we should make sure they're handled without a fallback. In other cases, they never worked correctly before.
With the priority being to avoid regressions, I think I should try to preserve established behavior of both cases as much as possible. I think that means going ahead and allowing font linking to be used, as before, for characters in the original font that follow characters that needed font linking.