How does Tcl/Tk's high DPI support compare to other state of the art languages?

[Alexandru]

I don't know about you, but for me, the whole high DPI topic in Tcl/Tk is a little bit too "clowdy". I feel unsure what the outcome will be on a high DPI screen, since I never developed an app with that in mind. I found a few links on the web but still feel that not everything is covered.

My first question: How does Tcl/Tk's high DPI support compare to other state of the art languages? Can I assume that if my app does not look good on a high DPI screen, that Tcl offers mee all the meanings to make it look good with little effort? Is it easier or harder in other languages (Python, Qt).

What are the things a Tcl/Tk developer should keep in mind when developing apps for high DPI screens?

Thanks!
Alexandru

[briang]

It's not completely automatic unless coded that way.
Fonts should scale appropriately, provided your Tk code uses point sizes as opposed to pixels sizes.
There is no support for automatic scaling of icons.
Depending on which theme is in use, there may be some manual tweaking required. Again, if points, cm, or inch units are used for sizing things, it should scale correctly. However, in practice, most widget sizing is done in pixels.

I believe if you plan the application right from the beginning, it is possible for it to look good in low-def and high def.

I think Qt has some issues too where it has to be coded not to do anything that will not scale.
(python is not a gui tool kit. It is bound to Qt or Tk, etc.)

-Brian

[Donal K. Fellows]

On 22/06/2019 21:59, briang wrote:
> Fonts should scale appropriately, provided your Tk code uses point sizes as opposed to pixels sizes.
> There is no support for automatic scaling of icons.
> Depending on which theme is in use, there may be some manual tweaking required. Again, if points, cm, or inch units are used for sizing things, it should scale correctly. However, in practice, most widget sizing is done in pixels.

It's probably important to use Ttk widgets with system themes; they
usually scale better (whereas the default widgets have pixel-width
settings for things like borders).

Donal.
--
Donal Fellows — Tcl user, Tcl maintainer, TIP editor.

[Alexandru]

Am Samstag, 22. Juni 2019 23:00:01 UTC+2 schrieb briang:
> On Saturday, June 22, 2019 at 2:33:30 AM UTC-7, Alexandru wrote:
> > I don't know about you, but for me, the whole high DPI topic in Tcl/Tk is a little bit too "clowdy". I feel unsure what the outcome will be on a high DPI screen, since I never developed an app with that in mind. I found a few links on the web but still feel that not everything is covered.
> >
> > My first question: How does Tcl/Tk's high DPI support compare to other state of the art languages? Can I assume that if my app does not look good on a high DPI screen, that Tcl offers mee all the meanings to make it look good with little effort? Is it easier or harder in other languages (Python, Qt).
> >
> > What are the things a Tcl/Tk developer should keep in mind when developing apps for high DPI screens?
> >
> > Thanks!
> > Alexandru
>
> It's not completely automatic unless coded that way.
> Fonts should scale appropriately, provided your Tk code uses point sizes as opposed to pixels sizes.
> There is no support for automatic scaling of icons.
> Depending on which theme is in use, there may be some manual tweaking required. Again, if points, cm, or inch units are used for sizing things, it should scale correctly. However, in practice, most widget sizing is done in pixels.

How about the command "tk scaling"? Do I need that?

>
> I believe if you plan the application right from the beginning, it is possible for it to look good in low-def and high def.
>
> I think Qt has some issues too where it has to be coded not to do anything that will not scale.
> (python is not a gui tool kit. It is bound to Qt or Tk, etc.)

Yes, I know that, but I might be that it wraps some additional settings, that Tcl/Tk does not per default.

>
> -Brian

[Alexandru]

Thanks Donal, I wasn't aware of that. I would say: Everybody should stop using the ancient widgets and start using the ttk palette. Unless you want you UI to look like stone age.

[Alexandru]

Found this about Qt high DPI support:

https://doc.qt.io/qt-5/highdpi.html

Seems a little more that what I found about Tcl/Tk.

What I miss are examples. In which situations, how do I use which commands to scale which widgets. For the moment I only see the way of buying a high DPI monitor and test and improve until the GUI looks fine, which is trial an error.

[Donal K. Fellows]

On 23/06/2019 09:07, Alexandru wrote:
> In which situations, how do I use which commands to scale which widgets.

The main thing in Tk is to look out for places where you can use
measurements instead of pixel sizes. Tk's font and geometry managers
generally cope well with differences in sizes of things so you can do
things well with little extra effort, but you need to not shoot yourself
in the foot. Watch out particularly for things like setting the overall
window size; that's always in pixels so it isn't portable to HighDPI
displays.

8.7 will make things a bit easier; that has some support for SVG images.

[Donal K. Fellows]

On 23/06/2019 08:53, Alexandru wrote:
> How about the command "tk scaling"? Do I need that?

Hopefully you won't need to set the scaling factor. That's supposed to
be correct by default. Reading the scaling factor may help when working
with APIs that only accept pixel sizes/widths.

[Brad Lanam]

I made some notes here.

https://wiki.tcl-lang.org/page/User+Interface+Design%3A+Sizing+of+Elements

More notes and discussion:
I describe how I was able to test 4k without buying a monitor.

https://wiki.tcl-lang.org/page/High+Resolution+Displays?R=0

I wrote some scalable widgets:

https://wiki.tcl-lang.org/page/Scaled+Radiobutton

https://wiki.tcl-lang.org/page/Scaled+checkbutton

https://wiki.tcl-lang.org/page/Localized%2C+Scalable+Spinbox+Widget

I'm not sure that the source code is up to date on the wiki pages.
Let me know if you have any interest in using these, and I will
supply pointers to the source.

[Harald Oehlmann]

Hi Alexandru,

my personal solution with Tk is as follows:
- the font size was chosen as the parameter to change with dpi of the screen
- the font size may be adapted on user need (menu or pinch to zoom gesture)
- the height of the font is measured in pixels
- all icons are scaled to this size (nanosvg)
- only on touch devices, button-only icons are held to a fix size of 1cm
height (Android)

I am involved with projects with Qt (qtzint). This application does not
scale at all.

Hope this helps,
Harald

[Alexandru]

Do you think it's worth it to put your above sentence into the man page of "tk scaling"? This way we can avoid readers starting to think, that this command is relevant or even a "must".

[Alexandru]

Great! I will go through the content.

[Alexandru]

Thanks for sharing! Do you mean the implementation of nanosvg in Tcl: https://github.com/auriocus/tksvg?

[Harald Oehlmann]

Well, I took the version from the current tk branch tip545 and plugged
it in Christians version.
The -scaletoheight option avoids a two-step process which has
performence impacts.

I will present it at ETCL conference in Nürnberg.

Enjoy,
Harald

[Alexandru]

So if I want to load SVG into Tcl, I must combine some code freom two different sources?

[Harald Oehlmann]

Am 24.06.2019 um 10:24 schrieb Alexandru:
>>> Thanks for sharing! Do you mean the implementation of nanosvg in Tcl: https://github.com/auriocus/tksvg?
>>>
>> Well, I took the version from the current tk branch tip545 and plugged
>> it in Christians version.
>> The -scaletoheight option avoids a two-step process which has
>> performence impacts.
>>
>> I will present it at ETCL conference in Nürnberg.
>>
>> Enjoy,
>> Harald
>
> So if I want to load SVG into Tcl, I must combine some code freom two different sources?
>

You may directly use the version from Christian Gollwitzer on GitHub. It
was developped by Christian Werner.
It is identical to the version currenty in tk trunk.

Tip 545 tries to add the additional parameter "-scaletoheight" to
support my scheme without a two step procedure.

See the TIP for a description.

When the TIP is voted, maybe the Christians may update their versions to...

I can send you Windows binaries for Tk 8.6.

Thank you,
Harald

[Christian Gollwitzer]

Am 24.06.19 um 10:32 schrieb Harald Oehlmann:

> When the TIP is voted, maybe the Christians may update their versions to...
>

I have no trouble to update my version. Just send me a cleanly mergable
pull request via github (its a one-click thing for me, then).

Concerning the HiDPI stuff, on OSX it is handled by the OS. So Tcl Apps
have clean fonts and GUI elements by default, the only drawback is that
icons are fuzzy. It is impossible at the moment to load sharp images
into Tk on OSX, because the photo image is always interpreted as "Low
resolution" and then upscaled. With SVG, there would be the chance to
render at high resolution, but currently its not possible.

Christian

[Alexandru]

No sure I#m getting it right. Using your tksvg I can load SVG images and use them in ttk::button as an icon, right? If I can also specify a pixel size of the reasterized image (though I don't see that option), then I have all I need right?

[Christian Gollwitzer]

Am 24.06.19 um 10:57 schrieb Alexandru:

I think on Windows, that is enough I think, yes.

On OSX however the OS manages the high DPI screen, i.e. it uses "Logical
pixels" instead of real pixels. Therefore your app always looks the same
size, but different sharpness. This works fully transparent if you use
fonts, and regular buttons etc. But for pixel based images, it can't
work. "photo" images are always upscaled. Now with SVG we could render
te image in the "true resolution", not the "logical resolution". But
then you need to tell the OS that the bitmap has higher resolution. OSX
Tk does not have this facility. i.e. you can only render low resolution
(ugly) icons.

Christian

[paul...@googlemail.com]

On Saturday, June 22, 2019 at 10:33:30 AM UTC+1, Alexandru wrote:

>
> What are the things a Tcl/Tk developer should keep in mind when developing apps for high DPI screens?
>

I recently updated one of my apps so I could use it on a new laptop I bought with a high DPI screen. The app has a fairly simple GUI, but to get it to be usable I did two things:

(1) Provide a font size menu button in a settings dialog, and then I could change the font size to be just right (and also used points instead of pixels for size, so that it's more right to start with).

Once I got the font size from the settings dialog, I then changed the fonts using the following code:

foreach f [font names] {
font configure $f -size $size
}

where I found a size of between 8 to 12 gives a more than adequate range.

(2) Change all the locations where I'd used pixel sizes to point sizes for a nice widget layout, so for example from this

grid $someWidget -padx 10 -pady 10

to this

grid $someWidget -padx 7pt -pady 7pt

I still need to do something about my toolbar icons, but the rest of my app now is fine, and the toolbar icons are not that bad. What I'll do there is probably just have two sizes of icons and use the ones most appropriate based on the DPI reported by Tk.

[Brad Lanam]

Correct by default? Have never seen that.
Very relevant. Setting it is a must.

[Christopher Chavez]

I recently tried setting some non-default DPI†, with the expected result
being that apps scale appropriately. I did this after taking off my
"power user" hat and putting on my "ordinary end user" hat, where I
would set this from the OS or desktop environment preferences GUI for
end users, as available on Windows and X11 desktops; and not resort to
advanced methods like configuration files.

†(DPI—or PPI—as seen by the software; not the resulting physical DPI.)

Sure enough, Tk by itself seems to respect those settings, and checking
`tk scaling` shows a value that I expect: (my DPI)/72.0.

So I do not use .tclshrc or .wishrc to set `tk scaling`, and do not set
it anywhere in my programs, because it appears I do not need to. And so
I agree that users should expect to not have to set `tk scaling`.

Should someone find that `tk scaling` is not set to a reasonable default
based on their environment/OS/platform/window
manager/configuration/etc., then I would hope they've opened a bug
report, rather than—or at least before—telling everyone else to expect
they'll need to set `tk scaling` themselves.

[Brad Lanam]

Because it works for you on your configuration, therefore you can
generalize that it works everywhere? Good luck with that.

Should someone find that `tk scaling` is set to the proper value
based on their configuration, consider yourself lucky.

It will not work for your customers or in general.
I have yet to see tk scaling set to anything other than 1.335
through empirical testing on various configurations.

I will continue to suggest that every user use a tool to set it
properly, as that is what is expected and required.

I will continue to post contradictions to false statements also.

[Andreas Leitgeb]

Brad Lanam <brad....@gmail.com> wrote:
> I have yet to see tk scaling set to anything other than 1.335
> through empirical testing on various configurations.

Androwish on my phone reports 3.7352941176470584

(just providing the full decimal string in case someone feels like determining
a nice "fraction" for it -- screenwidth is 720 and screenheight is 1208,
the "mm"-sizes are 68 and 114)

[Ricardo kozmate.net]

Em 30/06/19 13:02, Andreas Leitgeb escreveu:

> Androwish on my phone reports 3.7352941176470584
>
> (just providing the full decimal string in case someone feels like determining
> a nice "fraction" for it

127/34 = 3.7352941176470590
is just about the same, up to the last digit.

Not very friendly, I suppose, as 127 is a prime number and 34 has only
two factors (2*17). Ans 1208 as a factor of 151 (and no 127 nor 17).

Continued fraction expansion is (likely exactly) equal to [3;1,2,1,3,2].
The next term would be in the order of 2*10^12, so it is likey just a
rounding error.
So successive "best" rational approximations (by truncated continued
fractions) are
4 / 1 = 4
11 / 3 = 3.666...
15 / 4 = 3.75
56 / 15 = 3.7333...
127 / 34 ~ 3.735294117647059


--
{ricardo from kozmate.net}

[Andreas Leitgeb]

Ricardo kozmate.net <ric...@kozmate.net> wrote:
> Em 30/06/19 13:02, Andreas Leitgeb escreveu:
>> Androwish on my phone reports 3.7352941176470584
>> (just providing the full decimal string in case someone feels like determining
>> a nice "fraction" for it
> 127/34 = 3.7352941176470590
> is just about the same, up to the last digit.

The factor 127 might come from some metric <-> inch conversion,
since 254mm are 10" and 254 = 127*2 . Just guessing.

[Alexandru]

I now have a 4K PC screen and I can test my Tcl/Tk app on it. Suprisingly, at a first glance I see no major issues with high DPI in Tk. I can set the scaling in the OS (Windows ) to 100% or 200% and Tk adapts automatically.

The only thing that is not so nice, is that the fonts are scaled as bitmaps: they only get larger but there is no increase in the resolution. Can this be improved in Tk?

I also have to find out what the issue was on another PC of a customer, whre the high DPI led to major issue in our app.

[Mike Griffiths]

What kind of widgets are you using? I've had numerous reports of issues, particularly with ttk treeviews (font size increases, actual line height does not), which unfortunately I've had little to no opportunity to try and resolve without a 4k display myself.

[Alexandru]

I use all possible ttk widgets. Maybe I'll rund into some issues while using the app with the high DPI display.

[paul...@googlemail.com]

On Monday, July 15, 2019 at 9:33:53 PM UTC+1, Mike Griffiths wrote:
gh DPI led to major issue in our app.
>
> What kind of widgets are you using? I've had numerous reports of issues, particularly with ttk treeviews (font size increases, actual line height does not), which unfortunately I've had little to no opportunity to try and resolve without a 4k display myself.

I've had that issue with treeview. For me it was because I wasn't using point fonts (pixel sizes is the default). The fix for this for me was setting all the fonts to use to point sizes. See the foreach font configure loop in the code I posted earlier.

[Alexandru]

What about the scaling of the fonts in genral? For me it looks like the fonts are scaled as bitmaps, not as vector graphics. Is this true?

[Rich]

Alexandru <alexandr...@meshparts.de> wrote:
>
> What about the scaling of the fonts in genral? For me it looks like
> the fonts are scaled as bitmaps, not as vector graphics. Is this
> true?

On my Linux system, TkDefaultFont is mapped to DejaVu Sans, and no
matter whether I ask for a large font in pixels or in points, the
resulting letter shapes look to have been scaled as vectors.

Perhaps your system is picking a bitmap font rather than a vector font
to use?

[briang]

It will depend on the actual font used. Try “font actual” command to determine this. The actual font has to be scalable, not all fonts are. Also make sure size is specified in points.

Professional applications will ship fonts with the product and use those instead of relying on any particular fonts being present in a customers installation.

-Brian

[Mike Griffiths]

I'll give that a go, thanks.

[Alexandru]

Hi Brian, I don't actually specify any font. Instead I leave the app to use the system's standard fonts. This way, the app will look familiar on any OS. Since I don't specify a font, I cann't execute the command "font actual".

[Rich]

Alexandru <alexandr...@meshparts.de> wrote:
> Since I don't specify a font, I cann't execute the command "font
> actual".

Incorrect. The font actual command can always be executed, and for
default fonts, it will tell you what system font Tk selected to use for
that particular default font name.

[Alexandru]

"font names" returns:
fixed oemfixed TkDefaultFont TkMenuFont ansifixed systemfixed TkHeadingFont device TkTooltipFont defaultgui TkTextFont ansi TkCaptionFont system TkSmallCaptionFont TkFixedFont TkIconFont

"font actual TkDefaultFont" returns:
-family {Segoe UI} -size 9 -weight normal -slant roman -underline 0 -overstrike 0

Assuming, that TkDefaultFont is the right argument for the function.

Size is specified in points. But is the font "Segoe UI" scalable or not? How can I know this? If this is the system default font, then looks like it is scalable in other apps on my system and not scalable in Tk.

[Rich]

Alexandru <alexandr...@meshparts.de> wrote:
> Am Mittwoch, 17. Juli 2019 12:25:55 UTC+2 schrieb Rich:
>> Alexandru <alexandr...@meshparts.de> wrote:
>> > Since I don't specify a font, I cann't execute the command "font
>> > actual".
>>
>> Incorrect. The font actual command can always be executed, and for
>> default fonts, it will tell you what system font Tk selected to use
>> for that particular default font name.
>
> "font names" returns:
> fixed oemfixed TkDefaultFont TkMenuFont ansifixed systemfixed
> TkHeadingFont device TkTooltipFont defaultgui TkTextFont ansi
> TkCaptionFont system TkSmallCaptionFont TkFixedFont TkIconFont
>
> "font actual TkDefaultFont" returns:
> -family {Segoe UI} -size 9 -weight normal -slant roman -underline 0
> -overstrike 0
>
> Assuming, that TkDefaultFont is the right argument for the function.

Yes, you give font actual any of the 'names' that return from font
names.

>
> But is the font "Segoe UI" scalable or not? How can I know this?

The answer to this question is directly system dependent.

> If this is the system default font, then looks like it is scalable in
> other apps on my system and not scalable in Tk.

Well, it is the font named "Segoe UI", but beyond that the answers lie
somewhere within your system.

An alternate would be for you to create a named font (font create)
using a -family that you have installed, and that you know to be
scalable, and see what results. If that known scalable font produces
what looks to be vector fonts, then this would imply that something
about Segoe UI is not scaling properly.

[Christian Gollwitzer]

Am 17.07.19 um 20:07 schrieb Rich:

> Alexandru <alexandr...@meshparts.de> wrote:
>>
>> But is the font "Segoe UI" scalable or not? How can I know this?
>
> The answer to this question is directly system dependent.

It is this font from MS: https://en.wikipedia.org/wiki/Segoe

>> If this is the system default font, then looks like it is scalable in
>> other apps on my system and not scalable in Tk.
>
> Well, it is the font named "Segoe UI", but beyond that the answers lie
> somewhere within your system.
>
> An alternate would be for you to create a named font (font create)
> using a -family that you have installed, and that you know to be
> scalable, and see what results. If that known scalable font produces
> what looks to be vector fonts, then this would imply that something
> about Segoe UI is not scaling properly.

I think this is leading nowhere. Non-scalable (i.e. bitmapped) fonts are
largely a thing of the past. There was some usage 10 years ago when the
typesetting engines were still not that good, and a good hand-made
bitmap font looked better than a rendered scalable outline font, but
these times are /long/ gone. MS Cleartype was released in 2000, i.e.
almost 20 years ago. I doubt that a current Windows system even has a
single bitmapped font installed - apart from the UEFI system on startup,
you'll never see a bitmapped font.

I believe there is a setting in Windows which tells it to scale a
certain application by enlarging it pixel-by-pixel, and others by
setting the screen dpi. The first way will always "work" in the sense
that the application remains usable, but give blurry results, the second
only works for applications adopted to High DPI.

This page describes some settings:

https://www.windowscentral.com/how-change-high-dpi-settings-classic-apps-windows-10-april-2018-update

For lack of a relevant system I can't try these things myself.

Christian

[Alexandru]

Am Mittwoch, 17. Juli 2019 20:31:19 UTC+2 schrieb Christian Gollwitzer:
> I believe there is a setting in Windows which tells it to scale a
> certain application by enlarging it pixel-by-pixel, and others by
> setting the screen dpi. The first way will always "work" in the sense
> that the application remains usable, but give blurry results, the second
> only works for applications adopted to High DPI.
>
> This page describes some settings:
>
> https://www.windowscentral.com/how-change-high-dpi-settings-classic-apps-windows-10-april-2018-update
>
> For lack of a relevant system I can't try these things myself.
>
> Christian

Yes the setting you describe exists in Win 10 and I activated it. After that I got into the same issue I saw on other screen of other users. Without that option in Windows, everything scales rigth in Tcl/Tk but with blurry results. I will see if setting the tk scaling helps...

[Alexandru]

After some tests on a 4k monitor on Win 10, I see that there is no need to set the "tk scaling". I very happy with this result, since I actually want to use the system setting to DPI scaling. Seems like Tk automatically gets the right scaling. When is start the console and simply type "tk scaling" the result is 3.3366 which is large enough to make my app look just fine. In Windows, the scaling is set to 250% (2.5x) so it's not clear how the Tk scaling relates to the Windows scaling.

Finaly, seems like the only problem of Tk with high DPI on Windows are the pictures, which in my case are PNGs. These are not affected by scalign and remain small. So I need to scale those in the app.

[Alexandru]

Hi Christian, I actually managed to compile your tksvg package an execute the small example you provide on gitgub https://github.com/auriocus/tksvg

So it works but how can I scale the result? I tried -width option but this has no effect.

[Christian Gollwitzer]

Hi Alexandru,


Am 29.07.19 um 21:27 schrieb Alexandru:

> Am Montag, 24. Juni 2019 20:06:20 UTC+2 schrieb Christian Gollwitzer:
>> On OSX however the OS manages the high DPI screen, i.e. it uses "Logical
>> pixels" instead of real pixels. Therefore your app always looks the same
>> size, but different sharpness. This works fully transparent if you use
>> fonts, and regular buttons etc. But for pixel based images, it can't
>> work. "photo" images are always upscaled. Now with SVG we could render
>> te image in the "true resolution", not the "logical resolution". But
>> then you need to tell the OS that the bitmap has higher resolution. OSX
>> Tk does not have this facility. i.e. you can only render low resolution
>> (ugly) icons.
>

> Hi Christian, I actually managed to compile your tksvg package an execute the small example you provide on gitgub https://github.com/auriocus/tksvg
>
> So it works but how can I scale the result? I tried -width option but this has no effect.
>

Try to see if "-scale 2" changes anything. However, I don't maintain
this extension any longer. Are you aware of TIP 507? The package is now
maintained as part of Tk 8.7.

Also, please note that not the full SVG standard is supported. Mot
notably, text and filters do not work.

Christian

[Alexandru]

Thanks for the tip. I read about the TIp, but for me TIPs are something that will happen in the future. Your tksvg works just fine:

set img [image create photo -file orb.
$img configure -format "svg -scale 2"

Cool about it: Already packed images are scaled too!

[Christian Gollwitzer]

Am 29.07.19 um 22:25 schrieb Alexandru:

> Am Montag, 29. Juli 2019 22:09:38 UTC+2 schrieb Christian Gollwitzer:
>> Hi Alexandru,

>> Are you aware of TIP 507? The package is now
>> maintained as part of Tk 8.7.

> Thanks for the tip. I read about the TIp, but for me TIPs are something that will happen in the future. Your tksvg works just fine

Well I tried to say that there is code available in the corresponding
branch of the tip, the lastest tip is
https://core.tcl-lang.org/tips/doc/trunk/tip/545.md

I have no idea how far it has diverged from tksvg on github. Maybe some
fixes/updates were integrated since then. You could of course pull the
code from the corresponding fossil branch at
https://core.tcl-lang.org/tk/timeline?r=tip-545-svg-options
It has a "scaletowidth" option, too.

>
> set img [image create photo -file orb.
> $img configure -format "svg -scale 2"
>
> Cool about it: Already packed images are scaled too!
>

Bad about it: it will read the .svg file again. In case you change the
directory in between, this might result in errors (something found and
possibly fixed by Harald Oehlmann).

Christian

[Alexandru]

Am Dienstag, 30. Juli 2019 20:42:06 UTC+2 schrieb Christian Gollwitzer:
> Am 29.07.19 um 22:25 schrieb Alexandru:
> > Am Montag, 29. Juli 2019 22:09:38 UTC+2 schrieb Christian Gollwitzer:
> >> Hi Alexandru,
> >> Are you aware of TIP 507? The package is now
> >> maintained as part of Tk 8.7.
>
> > Thanks for the tip. I read about the TIp, but for me TIPs are something that will happen in the future. Your tksvg works just fine
>
>
> Well I tried to say that there is code available in the corresponding
> branch of the tip, the lastest tip is
> https://core.tcl-lang.org/tips/doc/trunk/tip/545.md
>
> I have no idea how far it has diverged from tksvg on github. Maybe some
> fixes/updates were integrated since then. You could of course pull the
> code from the corresponding fossil branch at
> https://core.tcl-lang.org/tk/timeline?r=tip-545-svg-options
> It has a "scaletowidth" option, too.

Thanks, I'll try to download the source and compile again.

>
> >
> > set img [image create photo -file orb.
> > $img configure -format "svg -scale 2"
> >
> > Cool about it: Already packed images are scaled too!
> >
>
> Bad about it: it will read the .svg file again. In case you change the
> directory in between, this might result in errors (something found and
> possibly fixed by Harald Oehlmann).
>
> Christian

I always specify full paths of images, so there shoould be no problem with changing the current dir.

[Harald Oehlmann]

Alexandru,

I may provide you a binary for Windows 32 bit. I have sent it by private
E-Mail to some people.

The -scaletoheight option is specially for my button images.

I would like that there is a version for 8.6 and the start by Christian
is helpful. Maybe, Christian may also distribute the binary.

Thank you,
Harald

[Alexandru]

Hi Harald, thanks for the help. Please send me the binary at my work email adress, which you already have.