contents within () {} [] jump a little bit following non-ascii characters

[nuitlejour]

copy the following line into geany, and click at the end of the line:
编辑器(geany)
the '(geany)' part will jump a little bit.
can you fix this?

[elextr]

Do not see "jump", needs more information to reproduce, Version of Geany, Version of GTK and Glib, platform.

Edit: and a definition what you mean by "jump"

[nyamatongwe]

It may also depend on the font and the font's kerning settings.

While unstated, the scenario likely involves brace matching turning the '(' and ')' blue and bold. This causes the text, which was previously drawn in 1 operation "编辑器(geany)", to be drawn in 4 operations: ["编辑器", "(", "geany", ")"]. The platform drawing APIs may position the text slightly differently because of kerning or similar features: perhaps if it sees "(g" together, the "g" is moved slightly towards the "(". However, it is unlikely there would be discernable kerning of this pair.

To avoid text movement for brace matching, Scintilla does not re-layout the text and uses the original reported position of the "g" in the full "编辑器(geany)" context. Thus, even if the "(" becomes bold and uses some more space, "geany" should not move.

Any text movement could be avoided with an option to use indicators (like a blue/red rectangle) to mark brace matches instead of changing the brace appearance. The API to do this is SCI_BRACEHIGHLIGHTINDICATOR.

[nuitlejour]

Thank you for your reply
I am using lastest Geany 2.0 with GTK+ v3.24.39 and GLib v2.78.0 runtime libraries on Windows 11 platform.
It's hard to explain 'jump' with words, please refer to the attached two snapshots:
1.png shows characters in normal position,
2. png show characters move down little bit after click at the end of line.
and you can see the vertical position of characters within the parenthesis 'jumps' every time you click at the end of line.

[elextr]

So its a vertical shift in the position of the characters inside the parens. @nyamatongwe you were thinking of a horizontal movement I suspect.

Not observed here with the original text, either with "geany" inside the parens, or with the asian characters inside the parens. Which font are you using?

22:11:39: Geany INFO		: Geany 2.1 (git >= 430de3b74), en_AU.UTF-8
22:11:39: Geany INFO		: GTK 3.24.20, GLib 2.64.6
22:11:39: Geany INFO		: OS: Linux Mint 20 (ulyana)

Font is Deja Vu Sans Book and Deja Vu Sans Mono Book.

[nyamatongwe]

@nuitlejour: 1.png shows characters in normal position,

Please specify the text as text instead of just a picture. Sometimes problems are sensitive to the actual text. Since I don't speak Chinese, it would likely take me half an hour to reconstruct that text and it is easy to make mistakes.

@nuitlejour: on Windows 11

That adds to the complexity compared to Linux+Wayland and makes it less likely that this will be fixed.

There is a good chance that choosing a different font will avoid this problem.

@elextr: @nyamatongwe you were thinking of a horizontal movement I suspect.

Yes, but vertical movement is also possible. The Chinese portion of the text appears a little wider (1 pixel extra per character) in the second image.

Text drawing functions may choose from a wide range of shaping and font selection options to match contextual drawing conventions. In this case, it may be following the conventions for a fully Chinese document when it only sees Chinese characters in an isolated string but modifies the positions for mixed language text.

@elextr: Font is Deja Vu Sans Book and Deja Vu Sans Mono Book.

I don't think these fonts include Chinese characters so a substitute font will be used for those characters and the choice of substitute font may be significant. Switching (or not switching) between fonts is a potential cause of these sorts of issues.

[elextr]

I don't think these fonts include Chinese characters so a substitute font will be used for those characters

Yes, fc-match says NotoSansCJK-Regular.ttc: "Noto Sans CJK JP" "Regular" for the first character in the original text (U+7F16).

PS as its an olde LM its Linux+X11 not Wayland 😁

[nuitlejour]

Thank you for your suggestions,

I found it is indeed a font problem, the default font 'monospace normal' will produce the 'jumping' problem, and I have tried other fonts, like 'Microsoft YaHei normal', the 'jumping' problem disapeared.

Here are some examples that have the 'jumping' problem:
(你好)
你好(hello)
你好{}
你好[]

Here are some examples that are fine for both fonts:
hello(hello)
hello(你好)