[go: up one dir, main page]

Better handle text to glyph edge cases

karliss1requested to merge
karliss1/inkscape:text_to_glyphs into master
  • multiple char/single glyph ligatures
  • manual kerning offsets and rotation
  • letters with complex diacritic marks

Fixes #5876 (closed)

Instead of trying to calculate character position manually leverage more of the work already done by text layout.

Screenshots

Screenshots Input: Connected text Before: Before After: After After with individual objects selected image

Additional changes

Added option for CLI tests to rasterize reference image using inkscape. Usually it should be avoided, as testing inkscape against itself means that broken reference image could hide a bug. In this case due to size using reference image as PNG and due to complexity of image converting using imagemagick wasn't reliable. Edge antialiasing produced too many differences that couldn't be easily handled using FUZZ_PERCENTAGE without introducing false negatives.

CLI tests have 2 default comparison scripts. For REFERENCE_IMAGE the FUZZ_PERCENTAGE determines how much a pixel can differ. And for FUZZYREF_FILENAME FUZZ_PERCENTAGE determines how many pixels can differ from reference.

First one is preferable but if one of the edges has shifted by more than 1 pixel then it doesn't matter how high you set the FUZZ_PERCENTAGE. Even with quite high values couldn't get it to work reliably both locally and in CI.

In the second mode setting FUZZ_PERCENTAGE would probably deal with all the edge antialiasing differences, but due to the amount of edge pixels it would also prevent detecting any bugs that cause something like one of diacritic marks be incorrectly positioned even if position is wrong by a lot.

Other thoughts

I have strong feeling that it would be good to add back a command which converts text into separate glyph paths (similar to the old object to path behavior) instead of as multiple text objects. This MR improved some of the edge cases but I feel like there are a bunch more and some of them are nearly impossible to handle with text -> many text splitting approach. For example context sensitive ligatures. Text direction specific character substitutions/ligatures are also a bit problematic. Converting to path objects can be done a lot more robustly with less bad failure cases than attempts to split text.

Edited by karliss1

Merge request reports