With a file full of lines of underscore there appears to be an extra wide gap between characters every so often which shows as a vertical line of background colour.
I think actually every so often the underscore is short because when U has the right upright in the same place it seems thinner.
Happens at the same place with `Hack regular` and `DejaVu sans mono book`. At 9 point it is every 4/5 characters at 10 point it is only column 19 and 57. With `Freemono regular` does not show at 10 point but does at 9 point at every 5 characters (not varying 4/5 like the other two fonts).
Happens with Geany 2.0 Scintilla 5.3.7. Does not happen with Vscode with same file and font and size. Does not happen with the old Scite on this system (4.3.0).
Maybe its a float rounding/truncation issue somewhere in Scintilla.
Before reporting it to Scintilla, is this visible to anyone else, and with Scite if you have the latest (I will try it when I get a chance to build it)?
I have had a chance to take screen shots illustrating the effects, they show in the original images here, lets see if they survive the round trip to Github and back to the browser (they do show in preview so we may be lucky).
Can confirm that setting `pango_context_set_round_glyph_positions` to TRUE as suggested by @nyamatongwe on #3701 fixes this.
So its important that others test if they have the problem and report yes/no and any other side effects they see so we can decide to change it, or if there are significant side effects of having it `TRUE` maybe ask Neil to adopt the Geany approach (make it a setting :-)
@nyamatongwe Being aware of this now its visible in lots of places, not just lines of the same character, but lines with the same text on successive lines which occurs often in normal code. Note that lines of the same character occur often in markup if not in code.
For example in `Platgtk.cxx` in `FontHandle()` constructor the three `pango_font_description...` calls the gaps between `n` and `t` and `e` and `s` appear wider or the constructors of `SurfaceImpl` show wider gaps between `r` and `f`. Because these pieces of code make a column the artefact is more intrusive.
Given that code and markup are the main use-case for Geany, setting `TRUE` seems to be the correct default, but its currently hard coded so #3111 (the less common use-case) will regress, maybe making it settable is the solution until something (a Pango change maybe) allows both #3111 and this issue to be fixed at the same time.
Using Geany 2.0 (GTK+ v3.24.39 & GLib v2.78.3) on OpenSUSE Tumbleweed updated 1-19-2024, I see no graphical irregularities with Hack font size 9, 10, 12 or 14 using lines of underscores, Us, or random characters. System version of Pango is 1.51.1 and Harfbuzz is 8.3.0.
@Asherathe thanks. I am on a LTS distro so Pango 1.44.7 and Harfbuzz 2.6.4 which seems extraordinarily old, unless the versioning changed.
So will park this until I am forced to upgrade later this year when the LTS ends.
@Asherathe thanks. I am on a LTS distro so Pango 1.44.7 and Harfbuzz 2.6.4 which seems extraordinarily old, unless the versioning changed.
So will park this until I am forced to upgrade later this year when the LTS ends.
The Harfbuzz dev team seems very active. Looks like 2.6.4 was the last release of 2019. They've done a lot of work since then, and went through several versions in 2022.
The Harfbuzz dev team seems very active.
Or they keep making mistakes and are breaking the API all the time and are forced to up the major version, get it right guys so you can stabilise it and let your clients adapt.
Yeah 2019 would be the last version before 5 year LTS that ends this/next year.
github-comments@lists.geany.org