[PATCH] Fix default font scaling

[PATCH] Fix default font scaling

[Serhii Tereshchenko]

This fixes font scaling for default fonts, where we don't set font
sizes explicitly.

Without this, on 4k monitor with text-scaling-factor configured in Gnome,
labels, buttons and settings are using very small font sizes. (Probably,
not just Gnome but anything that sets custom DPI).

Screenshots here: https://twiukraine.com/@partizan/112619567918546426

Signed-off-by: Serhii Tereshchenko <serg.partizan@gmail.com>
---
 git-gui.sh | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/git-gui.sh b/git-gui.sh
index 8bc8892..23dd82d 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -810,6 +810,16 @@ if {[is_Windows]} {
 ## config defaults
 
 set cursor_ptr arrow
+
+# For whatever reason, Tk does not apply font scaling to default fonts,
+# but applies font scaling when setting size explicitly.
+# Default -size 10 is still 10, when you look at it with `font actual ...`,
+# but explicitl -size 10 becomes 10 * scale factor.
+# So, we need to configure fonts to use their default font sizes, but scaled.
+foreach font_name [font names] {
+	font configure $font_name -size [font actual $font_name -size]
+}
+
 font create font_ui
 if {[lsearch -exact [font names] TkDefaultFont] != -1} {
 	eval [linsert [font actual TkDefaultFont] 0 font configure font_ui]
-- 
2.45.2

Re: [PATCH] Fix default font scaling

[Eric Sunshine]

On Sat, Jun 15, 2024 at 4:54 AM Serhii Tereshchenko
<serg.partizan@gmail.com> wrote:
> This fixes font scaling for default fonts, where we don't set font
> sizes explicitly.
>
> Without this, on 4k monitor with text-scaling-factor configured in Gnome,
> labels, buttons and settings are using very small font sizes. (Probably,
> not just Gnome but anything that sets custom DPI).
>
> Signed-off-by: Serhii Tereshchenko <serg.partizan@gmail.com>
> ---

I'm adding Johannes Sixt <j6t@kdbg.org>, the new git-gui
maintainer[*], to the Cc: list.

[*]: https://lore.kernel.org/git/0241021e-0b17-4031-ad9f-8abe8e0c0097@kdbg.org/

> diff --git a/git-gui.sh b/git-gui.sh
> @@ -810,6 +810,16 @@ if {[is_Windows]} {
> +# For whatever reason, Tk does not apply font scaling to default fonts,
> +# but applies font scaling when setting size explicitly.
> +# Default -size 10 is still 10, when you look at it with `font actual ...`,
> +# but explicitl -size 10 becomes 10 * scale factor.

s/explicitl/explicit/

> +# So, we need to configure fonts to use their default font sizes, but scaled.
> +foreach font_name [font names] {
> +       font configure $font_name -size [font actual $font_name -size]
> +}

Re: [PATCH] Fix default font scaling

[Johannes Sixt]

Am 15.06.24 um 10:53 schrieb Serhii Tereshchenko:
> This fixes font scaling for default fonts, where we don't set font
> sizes explicitly.
> 
> Without this, on 4k monitor with text-scaling-factor configured in Gnome,
> labels, buttons and settings are using very small font sizes. (Probably,
> not just Gnome but anything that sets custom DPI).
> 
> Screenshots here: https://twiukraine.com/@partizan/112619567918546426
> 
> Signed-off-by: Serhii Tereshchenko <serg.partizan@gmail.com>

Thank you. I have adjusted the title to read

  git-gui: fix scaled default fonts

to follow the convention.

> ---
>  git-gui.sh | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/git-gui.sh b/git-gui.sh
> index 8bc8892..23dd82d 100755
> --- a/git-gui.sh
> +++ b/git-gui.sh
> @@ -810,6 +810,16 @@ if {[is_Windows]} {
>  ## config defaults
>  
>  set cursor_ptr arrow
> +
> +# For whatever reason, Tk does not apply font scaling to default fonts,
> +# but applies font scaling when setting size explicitly.
> +# Default -size 10 is still 10, when you look at it with `font actual ...`,
> +# but explicitl -size 10 becomes 10 * scale factor.

I fixed this typo: s/explicitl/explict/

> +# So, we need to configure fonts to use their default font sizes, but scaled.
> +foreach font_name [font names] {
> +	font configure $font_name -size [font actual $font_name -size]
> +}

Have you seen https://wiki.tcl-lang.org/page/font+scaling where [font
configure ...] instead of [font actual ...] is suggested as a preferable
solution? I am not so much into Tcl/Tk that I can judge what is best.

> +
>  font create font_ui
>  if {[lsearch -exact [font names] TkDefaultFont] != -1} {
>  	eval [linsert [font actual TkDefaultFont] 0 font configure font_ui]

My setup does not have a 4k monitor, I run KDE and I do not know if I
have changed a DPI setting. For the test, I have removed the [gui]
sections from my configurations to ensure that the defaults are used.

Under these conditions, this change does not make a difference in how
Git GUI appears. I assume this is the expected outcome, so I take it as
a good sign.

The patch is available as

https://github.com/j6t/git-gui.git st/font-scaling-fix

for others to test. I'd appreciate your feedback.

-- Hannes

Re: [PATCH] Fix default font scaling

[Serhii Tereshchenko]

On Sun, Jun 16 2024 at 12:30:51 +02:00:00, Johannes Sixt <j6t@kdbg.org> 
wrote:
> Am 15.06.24 um 10:53 schrieb Serhii Tereshchenko:
>>  This fixes font scaling for default fonts, where we don't set font
>>  sizes explicitly.
>> 
>>  Without this, on 4k monitor with text-scaling-factor configured in 
>> Gnome,
>>  labels, buttons and settings are using very small font sizes. 
>> (Probably,
>>  not just Gnome but anything that sets custom DPI).
>> 
>>  Screenshots here: 
>> https://twiukraine.com/@partizan/112619567918546426
>> 
>>  Signed-off-by: Serhii Tereshchenko <serg.partizan@gmail.com>
> 
> Thank you. I have adjusted the title to read
> 
>   git-gui: fix scaled default fonts
> 
> to follow the convention.
> 
>>  ---
>>   git-gui.sh | 10 ++++++++++
>>   1 file changed, 10 insertions(+)
>> 
>>  diff --git a/git-gui.sh b/git-gui.sh
>>  index 8bc8892..23dd82d 100755
>>  --- a/git-gui.sh
>>  +++ b/git-gui.sh
>>  @@ -810,6 +810,16 @@ if {[is_Windows]} {
>>   ## config defaults
>> 
>>   set cursor_ptr arrow
>>  +
>>  +# For whatever reason, Tk does not apply font scaling to default 
>> fonts,
>>  +# but applies font scaling when setting size explicitly.
>>  +# Default -size 10 is still 10, when you look at it with `font 
>> actual ...`,
>>  +# but explicitl -size 10 becomes 10 * scale factor.
> 
> I fixed this typo: s/explicitl/explict/
> 
Thanks!

>>  +# So, we need to configure fonts to use their default font sizes, 
>> but scaled.
>>  +foreach font_name [font names] {
>>  +	font configure $font_name -size [font actual $font_name -size]
>>  +}
> 
> Have you seen https://wiki.tcl-lang.org/page/font+scaling where [font
> configure ...] instead of [font actual ...] is suggested as a 
> preferable
> solution? I am not so much into Tcl/Tk that I can judge what is best.
> 

No, I haven't seen this, but suggested preferable solution doesn't work.

`font configure $font -size` returns negative numbers for me.

According to this
https://tkdocs.com/shipman/fonts.html

it means "size in pixels". And size in pixels does not scale. So, if we 
want fonts to scale with DPI, we should use "points" - and that's what 
`font actual ...` returns (i just hope it returns points, because it 
works for me and scales like points).

I'm also no expert in Tcl/Tk, this just my second time writing patches 
for git-gui :)

Probably, after all this we should change comment to:

# Default Tk fonts are defined in pixels, and they
# does not scale with DPI, here we're converting them
# into points, allowing them to scale just like
# explicitly defined fonts.


>>  +
>>   font create font_ui
>>   if {[lsearch -exact [font names] TkDefaultFont] != -1} {
>>   	eval [linsert [font actual TkDefaultFont] 0 font configure 
>> font_ui]
> 
> My setup does not have a 4k monitor, I run KDE and I do not know if I
> have changed a DPI setting. For the test, I have removed the [gui]
> sections from my configurations to ensure that the defaults are used.
> 
> Under these conditions, this change does not make a difference in how
> Git GUI appears. I assume this is the expected outcome, so I take it 
> as
> a good sign.
> 

You can test it, by changing DPI in `~/.Xresources`

`xrdb -query` to see your current DPI, then increase it a little.

```
Xft.dpi: 154
```

`xrdb -merge ~/.Xresources` to apply new scaling.


> The patch is available as
> 
> https://github.com/j6t/git-gui.git st/font-scaling-fix
> 
> for others to test. I'd appreciate your feedback.
> 
> 
> -- Hannes
> 

Re: [PATCH] Fix default font scaling

[Johannes Sixt]

Am 16.06.24 um 14:37 schrieb Serhii Tereshchenko:
> On Sun, Jun 16 2024 at 12:30:51 +02:00:00, Johannes Sixt <j6t@kdbg.org>
> wrote:
>> Am 15.06.24 um 10:53 schrieb Serhii Tereshchenko:
>>>   font create font_ui
>>>   if {[lsearch -exact [font names] TkDefaultFont] != -1} {
>>>       eval [linsert [font actual TkDefaultFont] 0 font configure
>>> font_ui]
>>
>> My setup does not have a 4k monitor, I run KDE and I do not know if I
>> have changed a DPI setting. For the test, I have removed the [gui]
>> sections from my configurations to ensure that the defaults are used.
>>
>> Under these conditions, this change does not make a difference in how
>> Git GUI appears. I assume this is the expected outcome, so I take it as
>> a good sign.
>>
> 
> You can test it, by changing DPI in `~/.Xresources`
> 
> `xrdb -query` to see your current DPI, then increase it a little.
> 
> ```
> Xft.dpi: 154
> ```
> 
> `xrdb -merge ~/.Xresources` to apply new scaling.

Thank you for this recipe. What is the expected result on the font size
with small and with large DPI values, with and without this patch?

- When I set Xft.dpi 100, I get tiny fonts.
- When I set it to 200, I get huge fonts.

And that is the case with and without this patch. I expected that the
font size is independent from the DPI with the patch. (I run ./git-gui
after `make`, but without installing.)

I also see the change in font size after modifying Xft.dpi in gitk, BTW.

At a minimum, the patch does not make things worse.

-- Hannes

Re: [PATCH] Fix default font scaling

[Serhii Tereshchenko]

Yeah, I'm also testing this way.

No, fonts should not be independent from DPI, but now some fonts are 
scaling just like the others.

To clearly see the result, set comfortable DPI, so fonts are reasonably 
sized (if this value is close to 96, better use something larger, like 
130 or 200 to see the effect).

When you run "git-gui" from the master branch, look at the fonts for:

- menubar and menu (explicitly set, scaled with DPI - our baseline)
- buttons in the lower part (Commit, Rescan, etc), labels like "Current 
branch" - (unscaled, visibly smaller than menubar)
- you can also open "Edit -> Options", and everything there will be 
smaller size as well.

After applying patch, all fonts are scaled equally (e.q. - small DPI - 
everything small, large DPI - everything big).

If, however - you see second behavior on both cases, I'm really 
interested to get more details:

- What OS and Tcl/Tk are you using?

I remember few years ago it worked fine on my ArchLinux, so if other 
distros aren't updated something yet, it may still work.

On Arch we have Tcl/Tk 8.6.14.

And to go even deeper, we may compare results from `wish`:

 > package require Tk 8.5
8.6.14
 > font configure TkDefaultFont
-family sans-serif -size -12 -weight normal -slant roman -underline 0 
-overstrike 0
 > font actual TkDefaultFont
-family {Nokia Sans S60} -size 9 -weight normal -slant roman -underline 
0 -overstrike 0

On Thu, Jun 20 2024 at 19:24:03 +02:00:00, Johannes Sixt <j6t@kdbg.org> 
wrote:
> Am 16.06.24 um 14:37 schrieb Serhii Tereshchenko:
>>  On Sun, Jun 16 2024 at 12:30:51 +02:00:00, Johannes Sixt 
>> <j6t@kdbg.org>
>>  wrote:
>>>  Am 15.06.24 um 10:53 schrieb Serhii Tereshchenko:
>>>>    font create font_ui
>>>>    if {[lsearch -exact [font names] TkDefaultFont] != -1} {
>>>>        eval [linsert [font actual TkDefaultFont] 0 font configure
>>>>  font_ui]
>>> 
>>>  My setup does not have a 4k monitor, I run KDE and I do not know 
>>> if I
>>>  have changed a DPI setting. For the test, I have removed the [gui]
>>>  sections from my configurations to ensure that the defaults are 
>>> used.
>>> 
>>>  Under these conditions, this change does not make a difference in 
>>> how
>>>  Git GUI appears. I assume this is the expected outcome, so I take 
>>> it as
>>>  a good sign.
>>> 
>> 
>>  You can test it, by changing DPI in `~/.Xresources`
>> 
>>  `xrdb -query` to see your current DPI, then increase it a little.
>> 
>>  ```
>>  Xft.dpi: 154
>>  ```
>> 
>>  `xrdb -merge ~/.Xresources` to apply new scaling.
> 
> Thank you for this recipe. What is the expected result on the font 
> size
> with small and with large DPI values, with and without this patch?
> 
> - When I set Xft.dpi 100, I get tiny fonts.
> - When I set it to 200, I get huge fonts.
> 
> And that is the case with and without this patch. I expected that the
> font size is independent from the DPI with the patch. (I run ./git-gui
> after `make`, but without installing.)
> 
> I also see the change in font size after modifying Xft.dpi in gitk, 
> BTW.
> 
> At a minimum, the patch does not make things worse.
> 
> -- Hannes
> 

Re: [PATCH] Fix default font scaling

[Johannes Sixt]

Am 20.06.24 um 20:11 schrieb Serhii Tereshchenko:
> Yeah, I'm also testing this way.
> 
> No, fonts should not be independent from DPI, but now some fonts are
> scaling just like the others.
> 
> To clearly see the result, set comfortable DPI, so fonts are reasonably
> sized (if this value is close to 96, better use something larger, like
> 130 or 200 to see the effect).
> 
> When you run "git-gui" from the master branch, look at the fonts for:
> 
> - menubar and menu (explicitly set, scaled with DPI - our baseline)
> - buttons in the lower part (Commit, Rescan, etc), labels like "Current
> branch" - (unscaled, visibly smaller than menubar)
> - you can also open "Edit -> Options", and everything there will be
> smaller size as well.
> 
> After applying patch, all fonts are scaled equally (e.q. - small DPI -
> everything small, large DPI - everything big).
> 
> If, however - you see second behavior on both cases, I'm really
> interested to get more details:

I see the second behavior regardless of the patch, i.e. with small DPI
all fonts are small, with large DPI all fonts are large.

The label "Current branch" is the same size as other fonts except when I
select a different font size in Edit->Options as "Main Font".


> - What OS and Tcl/Tk are you using?
> 
> I remember few years ago it worked fine on my ArchLinux, so if other
> distros aren't updated something yet, it may still work.
> 
> On Arch we have Tcl/Tk 8.6.14.
> 
> And to go even deeper, we may compare results from `wish`:
> 
>> package require Tk 8.5
> 8.6.14
>> font configure TkDefaultFont
> -family sans-serif -size -12 -weight normal -slant roman -underline 0
> -overstrike 0
>> font actual TkDefaultFont
> -family {Nokia Sans S60} -size 9 -weight normal -slant roman -underline
> 0 -overstrike 0

I have this:

% package require Tk 8.5
8.6.12
% font configure TkDefaultFont
-family sans-serif -size -12 -weight normal -slant roman -underline 0
-overstrike 0
%
% font actual TkDefaultFont
-family Arial -size 9 -weight normal -slant roman -underline 0 -overstrike 0
%

I am using openSUSE Leap 15.5 under KDE Frameworks 5.103.0

-- Hannes

Re: [PATCH] Fix default font scaling

[Serhii Tereshchenko]

On Fri, Jun 21 2024 at 00:04:50 +02:00:00, Johannes Sixt <j6t@kdbg.org> 
wrote:
> Am 20.06.24 um 20:11 schrieb Serhii Tereshchenko:
>>  Yeah, I'm also testing this way.
>> 
>>  No, fonts should not be independent from DPI, but now some fonts are
>>  scaling just like the others.
>> 
>>  To clearly see the result, set comfortable DPI, so fonts are 
>> reasonably
>>  sized (if this value is close to 96, better use something larger, 
>> like
>>  130 or 200 to see the effect).
>> 
>>  When you run "git-gui" from the master branch, look at the fonts 
>> for:
>> 
>>  - menubar and menu (explicitly set, scaled with DPI - our baseline)
>>  - buttons in the lower part (Commit, Rescan, etc), labels like 
>> "Current
>>  branch" - (unscaled, visibly smaller than menubar)
>>  - you can also open "Edit -> Options", and everything there will be
>>  smaller size as well.
>> 
>>  After applying patch, all fonts are scaled equally (e.q. - small 
>> DPI -
>>  everything small, large DPI - everything big).
>> 
>>  If, however - you see second behavior on both cases, I'm really
>>  interested to get more details:
> 
> I see the second behavior regardless of the patch, i.e. with small DPI
> all fonts are small, with large DPI all fonts are large.
> 
> The label "Current branch" is the same size as other fonts except 
> when I
> select a different font size in Edit->Options as "Main Font".
> 
> 
>>  - What OS and Tcl/Tk are you using?
>> 
>>  I remember few years ago it worked fine on my ArchLinux, so if other
>>  distros aren't updated something yet, it may still work.
>> 
>>  On Arch we have Tcl/Tk 8.6.14.
>> 
>>  And to go even deeper, we may compare results from `wish`:
>> 
>>>  package require Tk 8.5
>>  8.6.14
>>>  font configure TkDefaultFont
>>  -family sans-serif -size -12 -weight normal -slant roman -underline 
>> 0
>>  -overstrike 0
>>>  font actual TkDefaultFont
>>  -family {Nokia Sans S60} -size 9 -weight normal -slant roman 
>> -underline
>>  0 -overstrike 0
> 
> I have this:
> 
> % package require Tk 8.5
> 8.6.12
> % font configure TkDefaultFont
> -family sans-serif -size -12 -weight normal -slant roman -underline 0
> -overstrike 0
> %
> % font actual TkDefaultFont
> -family Arial -size 9 -weight normal -slant roman -underline 0 
> -overstrike 0
> %
> 
> I am using openSUSE Leap 15.5 under KDE Frameworks 5.103.0
> 
> -- Hannes
> 

Thanks! I tried booting into Fedora/37 with the same Tk version, and it 
indeed does not have this scaling problem.

Then, I downgraded packages on Arch to 8.6.12 and 8.6.13 - also no 
problem.

The only version affected is 8.6.14.

That's probably a bug in Tk (and there's quite a few reported, mostly 
about "tk scaling" https://core.tcl-lang.org/tk/info/1de3a48312, we 
don't use it explicitly in git-gui but on my system it is set to 1.3)

Re: [PATCH] Fix default font scaling

[Johannes Sixt]

Am 21.06.24 um 09:18 schrieb Serhii Tereshchenko:
> Thanks! I tried booting into Fedora/37 with the same Tk version, and it
> indeed does not have this scaling problem.
> 
> Then, I downgraded packages on Arch to 8.6.12 and 8.6.13 - also no problem.
> 
> The only version affected is 8.6.14.
> 
> That's probably a bug in Tk (and there's quite a few reported, mostly
> about "tk scaling" https://core.tcl-lang.org/tk/info/1de3a48312, we
> don't use it explicitly in git-gui but on my system it is set to 1.3)

What is the best course of action now? Since this change does not make
things any different for me on Linux+KDE, I am inclined to pick up this
patch with a modified commit message and code comment that clearly state
that this is a work-around for a bug in Tk introduced in 8.6.14. This
would help users who upgrade from an earlier version of Tk, because it
does not look like a fix of Tk is in the works (or that the issue is
regarded as a regression by Tk people at all).

Suggestions?

-- Hannes

Re: [PATCH] Fix default font scaling

[serg.partizan]

On нд, чер 23 2024 at 11:13:53 +02:00:00, Johannes Sixt 
<j6t@kdbg.org> wrote:
> Am 21.06.24 um 09:18 schrieb Serhii Tereshchenko:
>>  Thanks! I tried booting into Fedora/37 with the same Tk version, 
>> and it
>>  indeed does not have this scaling problem.
>> 
>>  Then, I downgraded packages on Arch to 8.6.12 and 8.6.13 - also no 
>> problem.
>> 
>>  The only version affected is 8.6.14.
>> 
>>  That's probably a bug in Tk (and there's quite a few reported, 
>> mostly
>>  about "tk scaling" https://core.tcl-lang.org/tk/info/1de3a48312, we
>>  don't use it explicitly in git-gui but on my system it is set to 
>> 1.3)
> 
> What is the best course of action now? Since this change does not make
> things any different for me on Linux+KDE, I am inclined to pick up 
> this
> patch with a modified commit message and code comment that clearly 
> state
> that this is a work-around for a bug in Tk introduced in 8.6.14. This
> would help users who upgrade from an earlier version of Tk, because it
> does not look like a fix of Tk is in the works (or that the issue is
> regarded as a regression by Tk people at all).
> 
> Suggestions?
> 
> -- Hannes

I tried running default git-gui and this patch on macOS 12 Monterey, 
and that version does not have font scaling, so there's no problem. I 
will ask around and maybe find someone with latest macOS, which has 
font scaling, and see if there's a problem.

Patch does not breaks anything, but produces a warning due to system 
fonts being present in 'font names'.

Then, if turns out this linux-specific problem - i'd limit this fix 
only to linux. If this affects other platforms - i'd filter fonts to 
only include those starting with 'Tk' prefix.

Re: [PATCH] Fix default font scaling

[serg.partizan]

On нд, чер 23 2024 at 13:11:22 +03:00:00, serg.partizan@gmail.com 
wrote:
> 
> 
> On нд, чер 23 2024 at 11:13:53 +02:00:00, Johannes Sixt 
> <j6t@kdbg.org> wrote:
>> Am 21.06.24 um 09:18 schrieb Serhii Tereshchenko:
>>>  Thanks! I tried booting into Fedora/37 with the same Tk version, 
>>> \x7f\x7fand it
>>>  indeed does not have this scaling problem.
>>> 
>>>  Then, I downgraded packages on Arch to 8.6.12 and 8.6.13 - also no 
>>> \x7f\x7fproblem.
>>> 
>>>  The only version affected is 8.6.14.
>>> 
>>>  That's probably a bug in Tk (and there's quite a few reported, 
>>> \x7f\x7fmostly
>>>  about "tk scaling" https://core.tcl-lang.org/tk/info/1de3a48312, we
>>>  don't use it explicitly in git-gui but on my system it is set to 
>>> \x7f\x7f1.3)
>> 
>> What is the best course of action now? Since this change does not 
>> make
>> things any different for me on Linux+KDE, I am inclined to pick up 
>> \x7fthis
>> patch with a modified commit message and code comment that clearly 
>> \x7fstate
>> that this is a work-around for a bug in Tk introduced in 8.6.14. This
>> would help users who upgrade from an earlier version of Tk, because 
>> it
>> does not look like a fix of Tk is in the works (or that the issue is
>> regarded as a regression by Tk people at all).
>> 
>> Suggestions?
>> 
>> -- Hannes
> 
> I tried running default git-gui and this patch on macOS 12 Monterey, 
> and that version does not have font scaling, so there's no problem. I 
> will ask around and maybe find someone with latest macOS, which has 
> font scaling, and see if there's a problem.
> 
> Patch does not breaks anything, but produces a warning due to system 
> fonts being present in 'font names'.
> 
> Then, if turns out this linux-specific problem - i'd limit this fix 
> only to linux. If this affects other platforms - i'd filter fonts to 
> only include those starting with 'Tk' prefix.

After more reasearch, I found this:

https://core.tcl-lang.org/tk/info/dccd82bdc7

This is x11-only bug, which existed for a long time and i'm suprized 
we're seeing it only in 8.6.14, because .13 and .12 are using the same 
negative sizes.

It is also fixed for a long time in the 8.7 branch and not backported 
into 8.6.

https://github.com/tcltk/tk/blob/7c3e2ff815e23cc6ac1ce9891ca659e709776ea4/library/ttk/fonts.tcl

Also, you may be not seeing this, because your distro may have applied 
this patch: 
https://sources.debian.org/patches/tk8.6/8.6.9-2/font-sizes.diff/

With this information, i'm more inclined to making a patch for 
ArchLinux package. So, it will fix every tk app, and not only git-gui.

What do you think?

Re: [PATCH] Fix default font scaling

[Johannes Sixt]

Am 23.06.24 um 16:00 schrieb serg.partizan@gmail.com:
> This is x11-only bug, which existed for a long time and i'm suprized
> we're seeing it only in 8.6.14, because .13 and .12 are using the same
> negative sizes.
> 
> It is also fixed for a long time in the 8.7 branch and not backported
> into 8.6.
> 
> https://github.com/tcltk/tk/blob/7c3e2ff815e23cc6ac1ce9891ca659e709776ea4/library/ttk/fonts.tcl
> 
> Also, you may be not seeing this, because your distro may have applied
> this patch:
> https://sources.debian.org/patches/tk8.6/8.6.9-2/font-sizes.diff/
> 
> With this information, i'm more inclined to making a patch for ArchLinux
> package. So, it will fix every tk app, and not only git-gui.
> 
> What do you think?

I think that would make sense. It would relieve me from taking
responsibility for a patch whose effects I do not understand well.

Thanks,
-- Hannes