Closed kreier closed 3 months ago
Updated test: setting the font shape engine to the desired language and script every time before determining the string width solves this problem. At least for the moment. I added this line in the example code above and commented it out.
Thanks for reporting this issue @kreier, I will take a look as soon as possible
The determination of a string width with
pdf.get_string_width(string)
depends on the language set for the shape engine (when used). But even after explicit setting the shape engine to a specific script and language with something likepdf.set_text_shaping(use_shaping_engine=True, script="arab", language="ara")
this setting can change. For example, when a string with latin characters is printed. The shape engine examines the first character and realizes the mismatch, and changes to latin text shaping. But when the next string is rendered, the string width is determined first with the old (now latin) setting and after that the shape engine determines the language (arabic in this case) and switches to this script and language. But the return value is based on the calculation with the wrong latin setting.I discovered this bug in a document where both latin and non-latin strings are mixed, and sometimes the non-latin strings where misplaced. To visualize this behavior I have this example below
Minimal code
The output looks like this:
Environment
fpdf2
version used: git+https://github.com/py-pdf/fpdf2.git@fbbb3f701fd35abaff1cf0b04a8576fe45e204e2 (latest master)