tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] Locale font selection

[Mark K. K. <mar...@gm...>]

Hi Shin-ichi,

> but does not change the UI font.

The UI font can be changed by changing PANGO_DEFAULT_FONT in fonts.h.  This
will change the font for all locales, however.  It would be nice to be able
to localize it.

Mark


On Fri, Dec 9, 2022 at 1:38 AM Shin-ichi TOYAMA <dol...@wm...>
wrote:

> Thanks Mark,
>
> Seeing your commit "3849480fd490bc7bf705a20b908b2201cbd22013", I added the
> locations of locale fonts on top of the directory list in the "fonts.conf"
> as follows and found the expected localized fontname for "ja.ttf" in the
> debug message.
>
>   <dir prefix="cwd">data/fonts/locale</dir>
>   <dir prefix="cwd">data/fonts</dir>
>
> This changes the locale font when using "text" or "label" tools, but does
> not
> change the UI font.
>
> I will see more.
>
>
> On Fri, 9 Dec 2022 00:08:11 -0500, Mark K. Kim wrote:
> >Oh, and... no, I don't think there exists today a way to call
> >TTF_FontFaceFamilyName() with the locale-based font facename, so that
> needs
> >to be localized.
> >
> >Mark
> >
> >On Thu, Dec 8, 2022 at 11:57 PM Mark K. Kim <mar...@gm...>
> wrote:
> >
> >> Hi Shin-ichi,
> >>
> >> > How do I know which font is used, and how can I force "ja.ttf" to be
> >> > used on ja_JP locale ?
> >>
> >> If you are using SDL Pango, the font folder needs to be listed in
> >> Fontconfig's configuration file ("fonts.conf" on Linux and macOS) for
> >> Pango to find it.  The file is named /opt/local/etc/fonts/fonts.conf on
> >> macOS using MacPorts.
> >>
> >> Then the font is loaded based on the font's *face*name (not its
> *file*name)
> >> passed to TuxPaint_Font_OpenFont().  The filename passed to
> >> TuxPaint_Font_OpenFont() is not used by SDL Pango; the filename is used
> >> by SDL_ttf only when SDL Pango is disabled.
> >>
> >> To get the facename from a filename, use TTF_FontFaceFamilyName() that
> >> comes with SDL_ttf (see fonts.c line ~369).  It looks like the font
> >> facename of ja.ttf is "Sazanami Gothic".
> >>
> >> To confirm fonts.conf is configured correctly and SDL Pango sees
> >> this font, enable DEBUG and VERBOSE in debug.h, recompile, start Tux
> >> Paint, then look for this line:
> >>
> >> ## src/tuxpaint.c, line 31079 in main() @ Thu Dec  8 22:06:09 2022
> >> pango ft2 fontmap[6] = '*Sazanami Gothic*'
> >>
> >>
> >> Mark
> >>
> >> On Thu, Dec 8, 2022 at 8:31 PM Shin-ichi TOYAMA <
> >> dol...@wm...> wrote:
> >>
> >>> Hi!
> >>>
> >>> Inspired from recent discussion about fonts, I tried to test a modern
> >>> font for Japanese based on the Universal Design, and noticed that the
> >>> locale font "ja.ttf" is not used.
> >>>
> >>> How do I know which font is used, and how can I force "ja.ttf" to be
> >>> used on ja_JP locale ?
> >>>
> >>> I feel the default Japanese fonts (both on Linux and Windows) are not
> >>> very bad but not the best.
> >>>
> >>> Thanks!
> >>>
> >>> --
> >>> Shin-ichi TOYAMA <dol...@wm...>
> >>>
> >>>
> >>> _______________________________________________
> >>> Tuxpaint-devel mailing list
> >>> Tux...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> >>>
> >>
>
>
> --
> Shin-ichi TOYAMA <dol...@wm...>
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Re: [Tuxpaint-devel] Locale font selection

[Shin-ichi T. <dol...@wm...>]

Thanks Mark,

Seeing your commit "3849480fd490bc7bf705a20b908b2201cbd22013", I added the
locations of locale fonts on top of the directory list in the "fonts.conf"
as follows and found the expected localized fontname for "ja.ttf" in the
debug message.

  <dir prefix="cwd">data/fonts/locale</dir>
  <dir prefix="cwd">data/fonts</dir>

This changes the locale font when using "text" or "label" tools, but does not
change the UI font.

I will see more.


On Fri, 9 Dec 2022 00:08:11 -0500, Mark K. Kim wrote:
>Oh, and... no, I don't think there exists today a way to call
>TTF_FontFaceFamilyName() with the locale-based font facename, so that needs
>to be localized.
>
>Mark
>
>On Thu, Dec 8, 2022 at 11:57 PM Mark K. Kim <mar...@gm...> wrote:
>
>> Hi Shin-ichi,
>>
>> > How do I know which font is used, and how can I force "ja.ttf" to be
>> > used on ja_JP locale ?
>>
>> If you are using SDL Pango, the font folder needs to be listed in
>> Fontconfig's configuration file ("fonts.conf" on Linux and macOS) for
>> Pango to find it.  The file is named /opt/local/etc/fonts/fonts.conf on
>> macOS using MacPorts.
>>
>> Then the font is loaded based on the font's *face*name (not its *file*name)
>> passed to TuxPaint_Font_OpenFont().  The filename passed to
>> TuxPaint_Font_OpenFont() is not used by SDL Pango; the filename is used
>> by SDL_ttf only when SDL Pango is disabled.
>>
>> To get the facename from a filename, use TTF_FontFaceFamilyName() that
>> comes with SDL_ttf (see fonts.c line ~369).  It looks like the font
>> facename of ja.ttf is "Sazanami Gothic".
>>
>> To confirm fonts.conf is configured correctly and SDL Pango sees
>> this font, enable DEBUG and VERBOSE in debug.h, recompile, start Tux
>> Paint, then look for this line:
>>
>> ## src/tuxpaint.c, line 31079 in main() @ Thu Dec  8 22:06:09 2022
>> pango ft2 fontmap[6] = '*Sazanami Gothic*'
>>
>>
>> Mark
>>
>> On Thu, Dec 8, 2022 at 8:31 PM Shin-ichi TOYAMA <
>> dol...@wm...> wrote:
>>
>>> Hi!
>>>
>>> Inspired from recent discussion about fonts, I tried to test a modern
>>> font for Japanese based on the Universal Design, and noticed that the
>>> locale font "ja.ttf" is not used.
>>>
>>> How do I know which font is used, and how can I force "ja.ttf" to be
>>> used on ja_JP locale ?
>>>
>>> I feel the default Japanese fonts (both on Linux and Windows) are not
>>> very bad but not the best.
>>>
>>> Thanks!
>>>
>>> --
>>> Shin-ichi TOYAMA <dol...@wm...>
>>>
>>>
>>> _______________________________________________
>>> Tuxpaint-devel mailing list
>>> Tux...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>>>
>>


-- 
Shin-ichi TOYAMA <dol...@wm...>

Re: [Tuxpaint-devel] Locale font selection

[Mark K. K. <mar...@gm...>]

Oh, and... no, I don't think there exists today a way to call
TTF_FontFaceFamilyName() with the locale-based font facename, so that needs
to be localized.

Mark

On Thu, Dec 8, 2022 at 11:57 PM Mark K. Kim <mar...@gm...> wrote:

> Hi Shin-ichi,
>
> > How do I know which font is used, and how can I force "ja.ttf" to be
> > used on ja_JP locale ?
>
> If you are using SDL Pango, the font folder needs to be listed in
> Fontconfig's configuration file ("fonts.conf" on Linux and macOS) for
> Pango to find it.  The file is named /opt/local/etc/fonts/fonts.conf on
> macOS using MacPorts.
>
> Then the font is loaded based on the font's *face*name (not its *file*name)
> passed to TuxPaint_Font_OpenFont().  The filename passed to
> TuxPaint_Font_OpenFont() is not used by SDL Pango; the filename is used
> by SDL_ttf only when SDL Pango is disabled.
>
> To get the facename from a filename, use TTF_FontFaceFamilyName() that
> comes with SDL_ttf (see fonts.c line ~369).  It looks like the font
> facename of ja.ttf is "Sazanami Gothic".
>
> To confirm fonts.conf is configured correctly and SDL Pango sees
> this font, enable DEBUG and VERBOSE in debug.h, recompile, start Tux
> Paint, then look for this line:
>
> ## src/tuxpaint.c, line 31079 in main() @ Thu Dec  8 22:06:09 2022
> pango ft2 fontmap[6] = '*Sazanami Gothic*'
>
>
> Mark
>
> On Thu, Dec 8, 2022 at 8:31 PM Shin-ichi TOYAMA <
> dol...@wm...> wrote:
>
>> Hi!
>>
>> Inspired from recent discussion about fonts, I tried to test a modern
>> font for Japanese based on the Universal Design, and noticed that the
>> locale font "ja.ttf" is not used.
>>
>> How do I know which font is used, and how can I force "ja.ttf" to be
>> used on ja_JP locale ?
>>
>> I feel the default Japanese fonts (both on Linux and Windows) are not
>> very bad but not the best.
>>
>> Thanks!
>>
>> --
>> Shin-ichi TOYAMA <dol...@wm...>
>>
>>
>> _______________________________________________
>> Tuxpaint-devel mailing list
>> Tux...@li...
>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>>
>

Re: [Tuxpaint-devel] Locale font selection

[Mark K. K. <mar...@gm...>]

Hi Shin-ichi,

> How do I know which font is used, and how can I force "ja.ttf" to be
> used on ja_JP locale ?

If you are using SDL Pango, the font folder needs to be listed in
Fontconfig's configuration file ("fonts.conf" on Linux and macOS) for Pango
to find it.  The file is named /opt/local/etc/fonts/fonts.conf on macOS
using MacPorts.

Then the font is loaded based on the font's *face*name (not its *file*name)
passed to TuxPaint_Font_OpenFont().  The filename passed to
TuxPaint_Font_OpenFont() is not used by SDL Pango; the filename is used by
SDL_ttf only when SDL Pango is disabled.

To get the facename from a filename, use TTF_FontFaceFamilyName() that
comes with SDL_ttf (see fonts.c line ~369).  It looks like the font
facename of ja.ttf is "Sazanami Gothic".

To confirm fonts.conf is configured correctly and SDL Pango sees this font,
enable DEBUG and VERBOSE in debug.h, recompile, start Tux Paint, then look
for this line:

## src/tuxpaint.c, line 31079 in main() @ Thu Dec  8 22:06:09 2022
pango ft2 fontmap[6] = '*Sazanami Gothic*'


Mark

On Thu, Dec 8, 2022 at 8:31 PM Shin-ichi TOYAMA <dol...@wm...>
wrote:

> Hi!
>
> Inspired from recent discussion about fonts, I tried to test a modern
> font for Japanese based on the Universal Design, and noticed that the
> locale font "ja.ttf" is not used.
>
> How do I know which font is used, and how can I force "ja.ttf" to be
> used on ja_JP locale ?
>
> I feel the default Japanese fonts (both on Linux and Windows) are not
> very bad but not the best.
>
> Thanks!
>
> --
> Shin-ichi TOYAMA <dol...@wm...>
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

[Tuxpaint-devel] Locale font selection

[Shin-ichi T. <dol...@wm...>]

Hi!

Inspired from recent discussion about fonts, I tried to test a modern 
font for Japanese based on the Universal Design, and noticed that the 
locale font "ja.ttf" is not used.

How do I know which font is used, and how can I force "ja.ttf" to be 
used on ja_JP locale ?

I feel the default Japanese fonts (both on Linux and Windows) are not 
very bad but not the best.

Thanks!

-- 
Shin-ichi TOYAMA <dol...@wm...>

Re: [Tuxpaint-devel] Musical symbols instead of text on UI labels!?

[Mark K. K. <mar...@gm...>]

You're welcome to keep BitStream Vera if you'd like, but then I suggest we
include its TTF file with Tux Paint.

Because right now we try to use BitStream Vera in Tux Paint, but none of
the fonts included with Tux Paint is BitStream Vera, so for users without
BitStream Vera on their OS a "random" font is used instead.  And in some
rare cases, the random font is only going to only show musical notes.

As a reminder, the fonts we include with Tux Paint are in
tuxpaint/data/fonts
<https://sourceforge.net/p/tuxpaint/tuxpaint/ci/master/tree/data/fonts/> (the
non-localized ones, anyway).

Mark

On Mon, Dec 5, 2022 at 2:34 AM Bill Kendrick <nb...@so...> wrote:

>
> I've also been reminded that we had a request to actually
> consider changing the defualt font to something like SIL Andika
> (https://software.sil.org/andika/), long long ago:
>
>   https://sourceforge.net/p/tuxpaint/feature-requests/146/
>
> I tried changing the hard-coded #define (quoted below) to
> "Andika" and posted an example:
>
>   https://twitter.com/TuxPaintTweets/status/1599667060623413248
>
> I think (per my comment in that ticket, 12 years ago!)
> that it might be nice to allow having whatever default font
> we choose (I'm leaning towards DejaVu Sans) with a user-chosen
> font, via config settings.  e.g.,:
>
>   tuxpaint --uifont="Andika"
>
> (If it fails, fall back to our default.)
>
> -bill!
>
> On Sun, Dec 04, 2022 at 10:35:45PM -0800, Bill Kendrick wrote:
> > On Fri, Dec 02, 2022 at 08:31:59PM -0500, Mark K. Kim wrote:
> > > Hi team,
> > >
> > > The issue has been resolved in a separate email thread.  It involved a
> few
> > > changes, mostly limited to macOS, but one affecting all platforms.
> Would
> > > anyone object to changing this setting in fonts.h:
> > >
> > > #define PANGO_DEFAULT_FONT "BitStream Vera"
> > >
> > >
> > > to:
> > >
> > > #define PANGO_DEFAULT_FONT "DejaVu Sans"
> > >
> > >
> > > ?
> > >
> > > It appears the default font we use, default_font.ttf, is actually named
> > > "DejaVu Sans", so attempting to load it using the name "BitStream
> Vera" can
> > > load a different font.
> >
> > I guess I don't have any objection.  They are very similar,
> > though DejaVu Sans seems to be wider, but not as tall
> > (less whitespace above the text in the Tux tip section at
> > the bottom of the UI).
> >
> > So while some strings (in English) now word-wrap differently
> > and potentially take up more space, I think the improved
> > vertical packing will counteract it.
> >
> > In terms of readability, they seem about the same.
> > In situations where text needs to get compressed horizontally
> > to fit on a button (e.g., "Color & White" magic tool),
> > they both have some good-looking and some bad-looking
> > results, so it's not like one is obviously a lot better
> > or worse than the other.
> >
> > I'm using default config (800x600 window, 48x48 buttons).
> >
> > Hrm actually, in a larger button size (78x78, the most I can
> > get with 1024x768 window), they look a bit better because
> > they are taller.
> >
> > So unless anyone else has any objections or problems,
> > I'm fine with it!
> >
> > I'll toy around with it in different locales, too,
> > and will follow-up if I notice anything weird.
> >
> > Thanks!
> >
> > -bill!
> >
> > >
> > > Happy holidays everyone!
> > >
> > > Mark
> > >
> > > On Mon, Nov 28, 2022 at 5:37 PM Bill Kendrick <nb...@so...> wrote:
> > >
> > > >
> > > > A user has reported that Tux Paint is showing random
> > > > musical glyphs, rather than text (e.g., "Tools", "Colors",
> > > > "Stamps", "Undo", etc.) in the UI!
> > > >
> > > > This is on macOS Monterey (also reproduced on Sierra),
> > > > with the latest version of Tux Paint (0.9.28).
> > > >
> > > > The user has not adjusted any TP settings, but I had them
> > > > try to set Tux Paint up in English (I'm actually unclear
> > > > whether they did this at the TP-level or OS-wide), and
> > > > apparently the issues persists.
> > > >
> > > > Screenshot here:
> > > >
> > > >   https://sourceforge.net/p/tuxpaint/bugs/265/
> > > >
> > > > Mark, any ideas here?  What other questions should I ask them?
> > > >
> > > > Thanks in advance,
> > > >
> > > > PS - I was hoping to get 0.9.29 out before year's end, but we
> > > > keep discovering these odd bugs that affect a handful of people.
> > > >
> > > > --
> > > > -bill!
> > > > Sent from my computer
> > > >
> > > >
> > > > _______________________________________________
> > > > Tuxpaint-devel mailing list
> > > > Tux...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> > > >
> >
> >
> > > _______________________________________________
> > > Tuxpaint-devel mailing list
> > > Tux...@li...
> > > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> >
> >
> > --
> > -bill!
> > Sent from my computer
>
> --
> -bill!
> Sent from my computer
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Re: [Tuxpaint-devel] Musical symbols instead of text on UI labels!?

[Bill K. <nb...@so...>]

I've also been reminded that we had a request to actually
consider changing the defualt font to something like SIL Andika
(https://software.sil.org/andika/), long long ago:

  https://sourceforge.net/p/tuxpaint/feature-requests/146/

I tried changing the hard-coded #define (quoted below) to
"Andika" and posted an example:

  https://twitter.com/TuxPaintTweets/status/1599667060623413248

I think (per my comment in that ticket, 12 years ago!)
that it might be nice to allow having whatever default font
we choose (I'm leaning towards DejaVu Sans) with a user-chosen
font, via config settings.  e.g.,:

  tuxpaint --uifont="Andika"

(If it fails, fall back to our default.)

-bill!

On Sun, Dec 04, 2022 at 10:35:45PM -0800, Bill Kendrick wrote:
> On Fri, Dec 02, 2022 at 08:31:59PM -0500, Mark K. Kim wrote:
> > Hi team,
> > 
> > The issue has been resolved in a separate email thread.  It involved a few
> > changes, mostly limited to macOS, but one affecting all platforms.  Would
> > anyone object to changing this setting in fonts.h:
> > 
> > #define PANGO_DEFAULT_FONT "BitStream Vera"
> > 
> > 
> > to:
> > 
> > #define PANGO_DEFAULT_FONT "DejaVu Sans"
> > 
> > 
> > ?
> > 
> > It appears the default font we use, default_font.ttf, is actually named
> > "DejaVu Sans", so attempting to load it using the name "BitStream Vera" can
> > load a different font.
> 
> I guess I don't have any objection.  They are very similar,
> though DejaVu Sans seems to be wider, but not as tall
> (less whitespace above the text in the Tux tip section at
> the bottom of the UI).
> 
> So while some strings (in English) now word-wrap differently
> and potentially take up more space, I think the improved
> vertical packing will counteract it.
> 
> In terms of readability, they seem about the same.
> In situations where text needs to get compressed horizontally
> to fit on a button (e.g., "Color & White" magic tool),
> they both have some good-looking and some bad-looking
> results, so it's not like one is obviously a lot better
> or worse than the other.
> 
> I'm using default config (800x600 window, 48x48 buttons).
> 
> Hrm actually, in a larger button size (78x78, the most I can
> get with 1024x768 window), they look a bit better because
> they are taller.
> 
> So unless anyone else has any objections or problems,
> I'm fine with it!
> 
> I'll toy around with it in different locales, too,
> and will follow-up if I notice anything weird.
> 
> Thanks!
> 
> -bill!
> 
> > 
> > Happy holidays everyone!
> > 
> > Mark
> > 
> > On Mon, Nov 28, 2022 at 5:37 PM Bill Kendrick <nb...@so...> wrote:
> > 
> > >
> > > A user has reported that Tux Paint is showing random
> > > musical glyphs, rather than text (e.g., "Tools", "Colors",
> > > "Stamps", "Undo", etc.) in the UI!
> > >
> > > This is on macOS Monterey (also reproduced on Sierra),
> > > with the latest version of Tux Paint (0.9.28).
> > >
> > > The user has not adjusted any TP settings, but I had them
> > > try to set Tux Paint up in English (I'm actually unclear
> > > whether they did this at the TP-level or OS-wide), and
> > > apparently the issues persists.
> > >
> > > Screenshot here:
> > >
> > >   https://sourceforge.net/p/tuxpaint/bugs/265/
> > >
> > > Mark, any ideas here?  What other questions should I ask them?
> > >
> > > Thanks in advance,
> > >
> > > PS - I was hoping to get 0.9.29 out before year's end, but we
> > > keep discovering these odd bugs that affect a handful of people.
> > >
> > > --
> > > -bill!
> > > Sent from my computer
> > >
> > >
> > > _______________________________________________
> > > Tuxpaint-devel mailing list
> > > Tux...@li...
> > > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> > >
> 
> 
> > _______________________________________________
> > Tuxpaint-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> 
> 
> -- 
> -bill!
> Sent from my computer

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Musical symbols instead of text on UI labels!?

[Bill K. <nb...@so...>]

On Fri, Dec 02, 2022 at 08:31:59PM -0500, Mark K. Kim wrote:
> Hi team,
> 
> The issue has been resolved in a separate email thread.  It involved a few
> changes, mostly limited to macOS, but one affecting all platforms.  Would
> anyone object to changing this setting in fonts.h:
> 
> #define PANGO_DEFAULT_FONT "BitStream Vera"
> 
> 
> to:
> 
> #define PANGO_DEFAULT_FONT "DejaVu Sans"
> 
> 
> ?
> 
> It appears the default font we use, default_font.ttf, is actually named
> "DejaVu Sans", so attempting to load it using the name "BitStream Vera" can
> load a different font.

I guess I don't have any objection.  They are very similar,
though DejaVu Sans seems to be wider, but not as tall
(less whitespace above the text in the Tux tip section at
the bottom of the UI).

So while some strings (in English) now word-wrap differently
and potentially take up more space, I think the improved
vertical packing will counteract it.

In terms of readability, they seem about the same.
In situations where text needs to get compressed horizontally
to fit on a button (e.g., "Color & White" magic tool),
they both have some good-looking and some bad-looking
results, so it's not like one is obviously a lot better
or worse than the other.

I'm using default config (800x600 window, 48x48 buttons).

Hrm actually, in a larger button size (78x78, the most I can
get with 1024x768 window), they look a bit better because
they are taller.

So unless anyone else has any objections or problems,
I'm fine with it!

I'll toy around with it in different locales, too,
and will follow-up if I notice anything weird.

Thanks!

-bill!

> 
> Happy holidays everyone!
> 
> Mark
> 
> On Mon, Nov 28, 2022 at 5:37 PM Bill Kendrick <nb...@so...> wrote:
> 
> >
> > A user has reported that Tux Paint is showing random
> > musical glyphs, rather than text (e.g., "Tools", "Colors",
> > "Stamps", "Undo", etc.) in the UI!
> >
> > This is on macOS Monterey (also reproduced on Sierra),
> > with the latest version of Tux Paint (0.9.28).
> >
> > The user has not adjusted any TP settings, but I had them
> > try to set Tux Paint up in English (I'm actually unclear
> > whether they did this at the TP-level or OS-wide), and
> > apparently the issues persists.
> >
> > Screenshot here:
> >
> >   https://sourceforge.net/p/tuxpaint/bugs/265/
> >
> > Mark, any ideas here?  What other questions should I ask them?
> >
> > Thanks in advance,
> >
> > PS - I was hoping to get 0.9.29 out before year's end, but we
> > keep discovering these odd bugs that affect a handful of people.
> >
> > --
> > -bill!
> > Sent from my computer
> >
> >
> > _______________________________________________
> > Tuxpaint-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> >


> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel


-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Musical symbols instead of text on UI labels!?

[Mark K. K. <mar...@gm...>]

Hi team,

The issue has been resolved in a separate email thread.  It involved a few
changes, mostly limited to macOS, but one affecting all platforms.  Would
anyone object to changing this setting in fonts.h:

#define PANGO_DEFAULT_FONT "BitStream Vera"


to:

#define PANGO_DEFAULT_FONT "DejaVu Sans"


?

It appears the default font we use, default_font.ttf, is actually named
"DejaVu Sans", so attempting to load it using the name "BitStream Vera" can
load a different font.

Happy holidays everyone!

Mark

On Mon, Nov 28, 2022 at 5:37 PM Bill Kendrick <nb...@so...> wrote:

>
> A user has reported that Tux Paint is showing random
> musical glyphs, rather than text (e.g., "Tools", "Colors",
> "Stamps", "Undo", etc.) in the UI!
>
> This is on macOS Monterey (also reproduced on Sierra),
> with the latest version of Tux Paint (0.9.28).
>
> The user has not adjusted any TP settings, but I had them
> try to set Tux Paint up in English (I'm actually unclear
> whether they did this at the TP-level or OS-wide), and
> apparently the issues persists.
>
> Screenshot here:
>
>   https://sourceforge.net/p/tuxpaint/bugs/265/
>
> Mark, any ideas here?  What other questions should I ask them?
>
> Thanks in advance,
>
> PS - I was hoping to get 0.9.29 out before year's end, but we
> keep discovering these odd bugs that affect a handful of people.
>
> --
> -bill!
> Sent from my computer
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Re: [Tuxpaint-devel] Musical symbols instead of text on UI labels!?

[Bill K. <nb...@so...>]

On Mon, Nov 28, 2022 at 09:20:33PM -0500, Mark K. Kim wrote:
> Here's the SDL2 0.9.28 build with debugging enabled. Can the user try it
> out then send us the log in /tmp/tuxpaint.log?
> 
> https://dl.cbreak.org/TuxPaint-0.9.28a-sdl2debug.dmg
> 

Thanks Mark!  (And happy holidays!)  I'll pass it along and tell you
what we find out,

-bill!

<snip>

Re: [Tuxpaint-devel] Musical symbols instead of text on UI labels!?

[Mark K. K. <mar...@gm...>]

Here's the SDL2 0.9.28 build with debugging enabled. Can the user try it
out then send us the log in /tmp/tuxpaint.log?

https://dl.cbreak.org/TuxPaint-0.9.28a-sdl2debug.dmg


Thanks,
Mark


On Mon, Nov 28, 2022 at 6:21 PM Mark K. Kim <mar...@gm...> wrote:

> On Mon, Nov 28, 2022 at 5:37 PM Bill Kendrick <nb...@so...> wrote:
>
>>
>> A user has reported that Tux Paint is showing random
>> musical glyphs [...] on macOS Monterey (also reproduced on Sierra),
>> with the latest version of Tux Paint (0.9.28).
>>
>
> Is it the SDL1 flavor of 0.9.28, or the SDL2 flavor?
>
> There appears to be some issue with the font search, but it's hard to tell
> what it's doing without the debug logs.  I can build a debug-enabled
> version of Tux Paint but it'll help to know if it's the SDL1 flavor or SDL2
> flavor that's having the issue so I don't have to build it 4 times (each
> flavor requires building it twice, once on x64 then again on arm64, then
> combining them to make a universal build.)
>
> The user has not adjusted any TP settings, but I had them
>> try to set Tux Paint up in English (I'm actually unclear
>> whether they did this at the TP-level or OS-wide), and
>> apparently the issues persists.
>>
>> Screenshot here:
>>
>>   https://sourceforge.net/p/tuxpaint/bugs/265/
>>
>> Mark, any ideas here?  What other questions should I ask them?
>>
>> Thanks in advance,
>>
>> PS - I was hoping to get 0.9.29 out before year's end, but we
>> keep discovering these odd bugs that affect a handful of people.
>>
>> --
>> -bill!
>> Sent from my computer
>>
>>
>> _______________________________________________
>> Tuxpaint-devel mailing list
>> Tux...@li...
>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>>
>

Re: [Tuxpaint-devel] Musical symbols instead of text on UI labels!?

[Mark K. K. <mar...@gm...>]

On Mon, Nov 28, 2022 at 5:37 PM Bill Kendrick <nb...@so...> wrote:

>
> A user has reported that Tux Paint is showing random
> musical glyphs [...] on macOS Monterey (also reproduced on Sierra),
> with the latest version of Tux Paint (0.9.28).
>

Is it the SDL1 flavor of 0.9.28, or the SDL2 flavor?

There appears to be some issue with the font search, but it's hard to tell
what it's doing without the debug logs.  I can build a debug-enabled
version of Tux Paint but it'll help to know if it's the SDL1 flavor or SDL2
flavor that's having the issue so I don't have to build it 4 times (each
flavor requires building it twice, once on x64 then again on arm64, then
combining them to make a universal build.)

The user has not adjusted any TP settings, but I had them
> try to set Tux Paint up in English (I'm actually unclear
> whether they did this at the TP-level or OS-wide), and
> apparently the issues persists.
>
> Screenshot here:
>
>   https://sourceforge.net/p/tuxpaint/bugs/265/
>
> Mark, any ideas here?  What other questions should I ask them?
>
> Thanks in advance,
>
> PS - I was hoping to get 0.9.29 out before year's end, but we
> keep discovering these odd bugs that affect a handful of people.
>
> --
> -bill!
> Sent from my computer
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

[Tuxpaint-devel] Musical symbols instead of text on UI labels!?

[Bill K. <nb...@so...>]

A user has reported that Tux Paint is showing random
musical glyphs, rather than text (e.g., "Tools", "Colors",
"Stamps", "Undo", etc.) in the UI!

This is on macOS Monterey (also reproduced on Sierra),
with the latest version of Tux Paint (0.9.28).

The user has not adjusted any TP settings, but I had them
try to set Tux Paint up in English (I'm actually unclear
whether they did this at the TP-level or OS-wide), and
apparently the issues persists.

Screenshot here:

  https://sourceforge.net/p/tuxpaint/bugs/265/

Mark, any ideas here?  What other questions should I ask them?

Thanks in advance,

PS - I was hoping to get 0.9.29 out before year's end, but we
keep discovering these odd bugs that affect a handful of people.

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Fwd: Keypress issues with Text tool in Tux Paint 0.9.28 under Windows 11 [SF.net bug #264]

[Shin-ichi T. <dol...@wm...>]

Hi!

New build on the latest MinGW/MSYS2 environment seems to fix this.
Please see my post on https://sourceforge.net/p/tuxpaint/bugs/264/

On Mon, 21 Nov 2022 21:18:05 +0900, Shin-ichi TOYAMA wrote:
>In addition, the problem does not happen with current git tree.
>
>We may be able to find the reason from the difference.
>
>On Mon, 21 Nov 2022 21:14:51 +0900, Shin-ichi TOYAMA wrote:
>>Wow!
>>
>>The "s" problem reproduced on my Windows 11 laptop !
>>
>>Considering that I have recently applied the 22H2 update, this might be the root of the evil.
>>
>>If we can ask the first reporter and confirm the correlation between the symptoms and the application of 22H2, I think we can clearly isolate the problem.
>>
>>On Sun, 20 Nov 2022 20:59:26 -0800, Bill Kendrick wrote:
>>>
>>>I just posted this to tuxpaint-users:
>>>
>>>-----
>>>
>>>Three people have reported issues typing some characters (i, j, and s)
>>>in Tux Paint's Text tool.  One opened, and another commented on,
>>>ticket #264 over on our SourceForge project.  Another emailed me
>>>directly, but didn't provide detail of their system, Tux Paint version,
>>>etc.  (I asked, but they haven't responded yet.)
>>>
>>>Has anyone else out here seen this behavior?  I cannot reproduce it
>>>under Linux.  Pere tried under Windows 10 and cannot, either.
>>>The person who commented on the ticket mentioned that it seemed to
>>>begin after a Microsoft Update to her Windows 11 laptop.
>>>
>>>More info, and follow along, here:
>>>
>>>  https://sourceforge.net/p/tuxpaint/bugs/264/
>>>
>>>-----
>>>
>>>Shin-ichi, any ideas?  I've pinged the SDL developers via their
>>>Twitter account.  (I miss their mailing lists; the dev. discussion
>>>has moved to a forum somewhere, and I never hopped onto it. ;-( )
>>>
>>>Thanks in advance,
>>>
>>>-bill!
>>>
>>>
>>>_______________________________________________
>>>Tuxpaint-devel mailing list
>>>Tux...@li...
>>>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>>
>>
>
>


-- 
Shin-ichi TOYAMA <dol...@wm...>

Re: [Tuxpaint-devel] Fwd: Keypress issues with Text tool in Tux Paint 0.9.28 under Windows 11 [SF.net bug #264]

[Shin-ichi T. <dol...@wm...>]

In addition, the problem does not happen with current git tree.

We may be able to find the reason from the difference.

On Mon, 21 Nov 2022 21:14:51 +0900, Shin-ichi TOYAMA wrote:
>Wow!
>
>The "s" problem reproduced on my Windows 11 laptop !
>
>Considering that I have recently applied the 22H2 update, this might be the root of the evil.
>
>If we can ask the first reporter and confirm the correlation between the symptoms and the application of 22H2, I think we can clearly isolate the problem.
>
>On Sun, 20 Nov 2022 20:59:26 -0800, Bill Kendrick wrote:
>>
>>I just posted this to tuxpaint-users:
>>
>>-----
>>
>>Three people have reported issues typing some characters (i, j, and s)
>>in Tux Paint's Text tool.  One opened, and another commented on,
>>ticket #264 over on our SourceForge project.  Another emailed me
>>directly, but didn't provide detail of their system, Tux Paint version,
>>etc.  (I asked, but they haven't responded yet.)
>>
>>Has anyone else out here seen this behavior?  I cannot reproduce it
>>under Linux.  Pere tried under Windows 10 and cannot, either.
>>The person who commented on the ticket mentioned that it seemed to
>>begin after a Microsoft Update to her Windows 11 laptop.
>>
>>More info, and follow along, here:
>>
>>  https://sourceforge.net/p/tuxpaint/bugs/264/
>>
>>-----
>>
>>Shin-ichi, any ideas?  I've pinged the SDL developers via their
>>Twitter account.  (I miss their mailing lists; the dev. discussion
>>has moved to a forum somewhere, and I never hopped onto it. ;-( )
>>
>>Thanks in advance,
>>
>>-bill!
>>
>>
>>_______________________________________________
>>Tuxpaint-devel mailing list
>>Tux...@li...
>>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>
>


-- 
Shin-ichi TOYAMA <dol...@wm...>

Re: [Tuxpaint-devel] Fwd: Keypress issues with Text tool in Tux Paint 0.9.28 under Windows 11 [SF.net bug #264]

[Shin-ichi T. <dol...@wm...>]

Wow!

The "s" problem reproduced on my Windows 11 laptop !

Considering that I have recently applied the 22H2 update, this might be the root of the evil.

If we can ask the first reporter and confirm the correlation between the symptoms and the application of 22H2, I think we can clearly isolate the problem.

On Sun, 20 Nov 2022 20:59:26 -0800, Bill Kendrick wrote:
>
>I just posted this to tuxpaint-users:
>
>-----
>
>Three people have reported issues typing some characters (i, j, and s)
>in Tux Paint's Text tool.  One opened, and another commented on,
>ticket #264 over on our SourceForge project.  Another emailed me
>directly, but didn't provide detail of their system, Tux Paint version,
>etc.  (I asked, but they haven't responded yet.)
>
>Has anyone else out here seen this behavior?  I cannot reproduce it
>under Linux.  Pere tried under Windows 10 and cannot, either.
>The person who commented on the ticket mentioned that it seemed to
>begin after a Microsoft Update to her Windows 11 laptop.
>
>More info, and follow along, here:
>
>  https://sourceforge.net/p/tuxpaint/bugs/264/
>
>-----
>
>Shin-ichi, any ideas?  I've pinged the SDL developers via their
>Twitter account.  (I miss their mailing lists; the dev. discussion
>has moved to a forum somewhere, and I never hopped onto it. ;-( )
>
>Thanks in advance,
>
>-bill!
>
>
>_______________________________________________
>Tuxpaint-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel


-- 
Shin-ichi TOYAMA <dol...@wm...>

Re: [Tuxpaint-devel] [nbs@sonic.net: Tux Paint on social media]

[Benson M. <ben...@em...>]

The Krita community uses Discourse:
https://krita-artists.org/
A number of software projects also use this for their mailing lists. It 
is more resource heavy than a PHP forum though.  Community moderation 
may also be required compared to post only webpages and service accounts.

There are activity pub libraries for PHP which can possibly be 
integrated with the website gallery, allowing people to receive 
notifications of new images in Mastodon and similar services, though it 
seems that not everything that is posted/re-posted is on the webpage 
gallery.

On 11/20/22 00:43, Bill Kendrick wrote:
> 
> FYI, for folks here on -devel who are not on -users.
> (And with this, I won't cross-post any further :) )
> 
> -bill!
> 
> ----- Forwarded message from Bill Kendrick <nb...@so...> -----
> 
> Date: Sat, 19 Nov 2022 13:41:00 -0800
> From: Bill Kendrick <nb...@so...>
> To: Tux Paint Users <tux...@li...>
> Subject: Tux Paint on social media
> 
> 
> With what seems to be an imminent collapse of the Twitter platform
> (which is sad, because it's been pretty rewarding and there's been
> high engagement, despite having about 1/15th the number of followers
> as our Facebook page!), I've been adding accounts to represent the
> Tux Paint project on more social media platforms.
> 
> The Facebook page has been around the longest (and has accumulated
> over 19,000 'fans'): https://www.facebook.com/TuxPaint
> 
> The Twitter account has been around for about 4.5 years (with over
> 1,100 followers): https://twitter.com/TuxPaintTweets
> 
> We have an account on Tumblr, which I believe has been around less
> than a year, but I can't recall (and they make it hard to tell!)
> https://www.tumblr.com/tuxpaint
> 
> I created a user account on Reddit, and promptly forgot about it,
> but am trying to revive it: https://www.reddit.com/user/TuxPaintDevs/
> 
> I've finally looked into Mastodon (which is the most similar to
> Twitter; a microblogging platform, though it's federated rather than
> centralized): https://floss.social/@tuxpaint
> 
> And I just hopped on Instagram, which appears to be the most
> difficult platform to use, since it's photo- and video-oriented.
> (It looks liek can't simply say "A new version is available,
> go download it!", I need to upload an image to go along with it.
> Thank goodness Tux Paint is art software! :-) )
> https://www.instagram.com/tuxpaintdevs/
> 
> 
> What you'll mostly see on these accounts are newly-added gallery
> images by people who have submitted them to me directly, or that I
> found on one of the sites, and asked permission to share.
> 
> On Twitter, Tumblr, and (presumably) Mastodon, you'll also see us
> reposting things that are relevant (hopefully!) to our audience:
> so things about art, other art software (especially open source),
> other educational software, etc.
> 
> Twitter made these kinds of interactions very easy; most of the other
> platforms don't seem to be designed for that kind of 'hobnobbing', and
> I feel a lot more like I'm shouting into a void.  (Even on Tumblr,
> when I ask a artists whether I can share drawings they've made on
> Tux Paint, it seems like the majority of the time I never even hear back.)
> 
> 
> Anyway, if you feel like following the Tux Paint project on any of
> these social media platforms, please do!  But if not, you'll hear from
> us here on this 'tuxpaint-users' mailing list.
> 
> The website is of course always updated whenever anything new is
> released.  (And gallery artwork is being added constantly!
> https://tuxpaint.org/gallery)
> 
> Take care!  (And Go Artemis & RIP Twitter)
> 

[Tuxpaint-devel] Fwd: Keypress issues with Text tool in Tux Paint 0.9.28 under Windows 11 [SF.net bug #264]

[Bill K. <nb...@so...>]

I just posted this to tuxpaint-users:

-----

Three people have reported issues typing some characters (i, j, and s)
in Tux Paint's Text tool.  One opened, and another commented on,
ticket #264 over on our SourceForge project.  Another emailed me
directly, but didn't provide detail of their system, Tux Paint version,
etc.  (I asked, but they haven't responded yet.)

Has anyone else out here seen this behavior?  I cannot reproduce it
under Linux.  Pere tried under Windows 10 and cannot, either.
The person who commented on the ticket mentioned that it seemed to
begin after a Microsoft Update to her Windows 11 laptop.

More info, and follow along, here:

  https://sourceforge.net/p/tuxpaint/bugs/264/

-----

Shin-ichi, any ideas?  I've pinged the SDL developers via their
Twitter account.  (I miss their mailing lists; the dev. discussion
has moved to a forum somewhere, and I never hopped onto it. ;-( )

Thanks in advance,

-bill!

[Tuxpaint-devel] [nbs@sonic.net: Tux Paint on social media]

[Bill K. <nb...@so...>]

FYI, for folks here on -devel who are not on -users.
(And with this, I won't cross-post any further :) )

-bill!

----- Forwarded message from Bill Kendrick <nb...@so...> -----

Date: Sat, 19 Nov 2022 13:41:00 -0800
From: Bill Kendrick <nb...@so...>
To: Tux Paint Users <tux...@li...>
Subject: Tux Paint on social media


With what seems to be an imminent collapse of the Twitter platform
(which is sad, because it's been pretty rewarding and there's been
high engagement, despite having about 1/15th the number of followers
as our Facebook page!), I've been adding accounts to represent the
Tux Paint project on more social media platforms.

The Facebook page has been around the longest (and has accumulated
over 19,000 'fans'): https://www.facebook.com/TuxPaint

The Twitter account has been around for about 4.5 years (with over
1,100 followers): https://twitter.com/TuxPaintTweets

We have an account on Tumblr, which I believe has been around less
than a year, but I can't recall (and they make it hard to tell!)
https://www.tumblr.com/tuxpaint

I created a user account on Reddit, and promptly forgot about it,
but am trying to revive it: https://www.reddit.com/user/TuxPaintDevs/

I've finally looked into Mastodon (which is the most similar to
Twitter; a microblogging platform, though it's federated rather than
centralized): https://floss.social/@tuxpaint

And I just hopped on Instagram, which appears to be the most
difficult platform to use, since it's photo- and video-oriented.
(It looks liek can't simply say "A new version is available,
go download it!", I need to upload an image to go along with it.
Thank goodness Tux Paint is art software! :-) )
https://www.instagram.com/tuxpaintdevs/


What you'll mostly see on these accounts are newly-added gallery
images by people who have submitted them to me directly, or that I
found on one of the sites, and asked permission to share.

On Twitter, Tumblr, and (presumably) Mastodon, you'll also see us
reposting things that are relevant (hopefully!) to our audience:
so things about art, other art software (especially open source),
other educational software, etc.

Twitter made these kinds of interactions very easy; most of the other
platforms don't seem to be designed for that kind of 'hobnobbing', and
I feel a lot more like I'm shouting into a void.  (Even on Tumblr,
when I ask a artists whether I can share drawings they've made on
Tux Paint, it seems like the majority of the time I never even hear back.)


Anyway, if you feel like following the Tux Paint project on any of
these social media platforms, please do!  But if not, you'll hear from
us here on this 'tuxpaint-users' mailing list.

The website is of course always updated whenever anything new is
released.  (And gallery artwork is being added constantly!
https://tuxpaint.org/gallery)

Take care!  (And Go Artemis & RIP Twitter)

-- 
-bill!
Sent from my computer

----- End forwarded message -----

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Can't recover original behavior of half-transparent brushes

[Bill K. <nb...@so...>]

On Sun, Sep 18, 2022 at 08:16:09PM +0200, Pere Pujal i Carabantes wrote:
> Hi all,
> 
> I was updating the Catalan translation when I noticed this:
> 
> Start Tux Paint, select a brush that is not fully opaque, like the sixth or seventh ones and paint a line,
> change the brush spacing to something bigger, then change it again to the smallest and paint another line
> 
> See the differences between both lines, I've not been able to get the original behavior again unless restarting Tux Paint.

I fiddled with this a bunch.  I think I've come up with a suitable
(if not perfect) solution.  If you choose an option that would, upon
calculating a new spacing, be very close but not _exactly_ the same as
the default -- be it a calculated or .dat-file-driven default -- it will
now 'nudge' the spacing to be the default.

For example, say you had a 20x20 brush with a default spacing of 15.

If the available spacings were therefore calculated to be:

  0, 8, 16, 25, 33, 41, ... 91, 100

Then the third option would actually choose 15, not 16, to be
consistent with the default spacing of the brush.

I'd accept other solutions.  And also, sorry this never occurred
to me when I first added this new feature in 0.9.28.  Thanks for
pointing it out!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Rush, trying to improve speed

[Pere P. i C. <per...@gm...>]

Hi Bill,

El dl. 03 de 10 de 2022 a les 22:46 -0700, en/na Bill Kendrick va escriure:
> On Sun, Oct 02, 2022 at 02:13:30AM +0200, Pere Pujal i Carabantes wrote:
> > Hi all,
> > 
> > Trying to improve the speed of the Rush magic tool I've noticed that using rotozoomSurface() increases the speed of the tool to the double, while this is a great improvement, Rush is still too slow in
> > big drawings, so I've tried another approach to get a dynamic zoom, basically scaling and alpha blitting over, and now it gets a decent speed.
> > 
> > Please test the attached patch and see if it does what Rush is meant to do.
> 
> I think it's great.  It's worth the performance increase.
> Thanks so much!
> 
> 
> > The patch exposes rotozoomSurface as api->rotate_scale() to the magic tools and uses it in the Rush tool.
> > If adopted, I think we should also update the magic api version.
> 
> Yes, definitely.  I'll work on that now.  (I was planning on it,
> but currently cannot find any ticket for that.  Maybe it was a FIXME
> in the code somewhere?)

Don't know, I see you applied the patch, thanks :)
> 
> 
> > Please test, there are still some things to tweak, feel free to play around.
> 
> I think my main complaint is that things vanish into
> 'infinity' in the center a little too easily, when zooming out.
> When zooming in, it's very nice.  I can see some fun animations
> being made with that effect, too!

I've tweaked it and now you need to drag down all the canvas to get to the center.


Also got an idea about a swirl magic tool...

Pere

> 
> -bill!
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

Re: [Tuxpaint-devel] Rush, trying to improve speed

[Bill K. <nb...@so...>]

On Sun, Oct 02, 2022 at 02:13:30AM +0200, Pere Pujal i Carabantes wrote:
> Hi all,
> 
> Trying to improve the speed of the Rush magic tool I've noticed that using rotozoomSurface() increases the speed of the tool to the double, while this is a great improvement, Rush is still too slow in
> big drawings, so I've tried another approach to get a dynamic zoom, basically scaling and alpha blitting over, and now it gets a decent speed.
> 
> Please test the attached patch and see if it does what Rush is meant to do.

I think it's great.  It's worth the performance increase.
Thanks so much!


> The patch exposes rotozoomSurface as api->rotate_scale() to the magic tools and uses it in the Rush tool.
> If adopted, I think we should also update the magic api version.

Yes, definitely.  I'll work on that now.  (I was planning on it,
but currently cannot find any ticket for that.  Maybe it was a FIXME
in the code somewhere?)


> Please test, there are still some things to tweak, feel free to play around.

I think my main complaint is that things vanish into
'infinity' in the center a little too easily, when zooming out.
When zooming in, it's very nice.  I can see some fun animations
being made with that effect, too!

-bill!

[Tuxpaint-devel] Rush, trying to improve speed

[Pere P. i C. <per...@gm...>]

Hi all,

Trying to improve the speed of the Rush magic tool I've noticed that using rotozoomSurface() increases the speed of the tool to the double, while this is a great improvement, Rush is still too slow in
big drawings, so I've tried another approach to get a dynamic zoom, basically scaling and alpha blitting over, and now it gets a decent speed.

Please test the attached patch and see if it does what Rush is meant to do.

The patch exposes rotozoomSurface as api->rotate_scale() to the magic tools and uses it in the Rush tool.
If adopted, I think we should also update the magic api version.

Please test, there are still some things to tweak, feel free to play around.

Thanks
Pere

Re: [Tuxpaint-devel] Shortcut ([Del] key) for quick access to a small eraser

[Shin-ichi T. <dol...@wm...>]

Hi!

On Thu, 29 Sep 2022 23:22:46 -0700, Bill Kendrick wrote:
>On Thu, Sep 29, 2022 at 06:54:55PM -0400, Mark K. Kim wrote:
>> "x" works great on the Mac.
>> 
>> Fixed the quick eraser continuing to quick erase while the mouse is moving
>
>Thanks Mark (and Pere & Shin-ichi)!

Afterwhile, I realized that the issue Pere and I reported was different from Mark's one.

However, now I think it is all right to let current behavior (continue erasing after releasing "X" key) as it is.

-- 
Shin-ichi TOYAMA <dol...@wm...>

Re: [Tuxpaint-devel] Shortcut ([Del] key) for quick access to a small eraser

[Bill K. <nb...@so...>]

On Thu, Sep 29, 2022 at 06:54:55PM -0400, Mark K. Kim wrote:
> "x" works great on the Mac.
> 
> Fixed the quick eraser continuing to quick erase while the mouse is moving

Thanks Mark (and Pere & Shin-ichi)!

-bill!