tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] Font scoring method

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

Thank you for your reply.

I understand adding locale characters to the existing criteria works.

However, I am a little at a loss where to put them, because;

 * Japanese has no upper/lower cases distinction.
 * No common/special Japanese panctuations is used in Tux Paint.
 * Numbers are not different to those in ASCII.
 * It has no line-like/circle-like characters.

In addition, I think it would be reasonable to give high priority to the
fonts supporting locale specific characters.

I've pushed the change already, and would like to keep it if this has no
side effect.

Thanks!

On Sat, 17 Dec 2022 14:24:53 -0500, Albert Cahalan wrote:
>> I've looked into the font scoring method in 'dirwalk.c' and 'fonts.c'.
>>
>> The function 'charset_works()' scores up the given font if ALL
>> characters passed to it are correctely rendered.
>>
>> However, it seems to have nothing to do with checking if the font
>> renders given characters distinctly. I was not able to understand what
>> qsort() in charset_works() do.
>>
>>
>> I confirmed that adding Japanese characters to the translations for the
>> strings used for scoring works to place the font supporting Japanese
>> characters on top.
>>
>> The result is good but I am not so confident it is a correct way as
>> originaly intended in font scoring method.
>
>That was the original intent when I wrote the code.
>You should not need to add any code for Japanese.
>Simply adjust the translation to contain a few Japanese
>characters, particularly ones that may be rendered
>indistinctly, and the scoring should work.
>
>
>_______________________________________________
>Tuxpaint-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel


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

Re: [Tuxpaint-devel] Font scoring method

[Albert C. <aca...@gm...>]

> I've looked into the font scoring method in 'dirwalk.c' and 'fonts.c'.
>
> The function 'charset_works()' scores up the given font if ALL
> characters passed to it are correctely rendered.
>
> However, it seems to have nothing to do with checking if the font
> renders given characters distinctly. I was not able to understand what
> qsort() in charset_works() do.
>
>
> I confirmed that adding Japanese characters to the translations for the
> strings used for scoring works to place the font supporting Japanese
> characters on top.
>
> The result is good but I am not so confident it is a correct way as
> originaly intended in font scoring method.

That was the original intent when I wrote the code.
You should not need to add any code for Japanese.
Simply adjust the translation to contain a few Japanese
characters, particularly ones that may be rendered
indistinctly, and the scoring should work.

Re: [Tuxpaint-devel] Font scoring method

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

Hi!

Thanks for your detailed explanation.

Committed it using "ABC...xyz"

Thanks!

On Sat, 17 Dec 2022 11:03:12 +0900, Shin-ichi TOYAMA wrote:
>Hi!
>
>I've looked into the font scoring method in 'dirwalk.c' and 'fonts.c'.
>
>The function 'charset_works()' scores up the given font if ALL 
>characters passed to it are correctely rendered.
>
>However, it seems to have nothing to do with checking if the font 
>renders given characters distinctly. I was not able to understand what 
>qsort() in charset_works() do.
>
>
>I confirmed that adding Japanese characters to the translations for the 
>strings used for scoring works to place the font supporting Japanese 
>characters on top.
>
>The result is good but I am not so confident it is a correct way as 
>originaly intended in font scoring method.
>
>I suppose it is more reasonable to have additional string for scoreing 
>to score up the fonts supporting locale specific characters.
>
>For example;
>
>   user_font_styles[num_font_styles]->score += 10 *
>     charset_works(
>       font,
>       /* put locale specific characters to the translation for this
>          string to score up the fonts supporting those characters. */
>       gettext("ABCXYZ")
>   );
>


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

Re: [Tuxpaint-devel] Font scoring method

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

El ds. 17 de 12 de 2022 a les 11:03 +0900, en/na Shin-ichi TOYAMA va escriure:
> Hi!
> 
> I've looked into the font scoring method in 'dirwalk.c' and 'fonts.c'.
> 
> The function 'charset_works()' scores up the given font if ALL 
> characters passed to it are correctely rendered.
> 
> However, it seems to have nothing to do with checking if the font 
> renders given characters distinctly. I was not able to understand what 
> qsort() in charset_works() do.

charset_works() passes or fails a font given all characters passed to 
it render and render different.
Sometimes a font substitutes lacking characters by "unknown rectangle", 
that dont count as a fail as the font renders the character, 
to catch this, you need to make 2 characters rendering as "unknow rectangle"


> 
> 
> I confirmed that adding Japanese characters to the translations for the 
> strings used for scoring works to place the font supporting Japanese 
> characters on top.
> 
> The result is good but I am not so confident it is a correct way as 
> originaly intended in font scoring method.

In plus of the font quality translation scoring, there is more score in 
fonts.c based on font name and bold/italic, so is harder for a font that 
has the needed character set but lacks bold/italic variants to raise on top.



> 
> I suppose it is more reasonable to have additional string for scoreing 
> to score up the fonts supporting locale specific characters.
> 
> For example;
> 
>    user_font_styles[num_font_styles]->score += 10 *
>      charset_works(
>        font,
>        /* put locale specific characters to the translation for this
>           string to score up the fonts supporting those characters. */
>        gettext("ABCXYZ")
>    );
> 

All in all I am for this addition, it would raise fonts supporting the locale charset
and left place for quality font scoring with the current system.

Pere

[Tuxpaint-devel] Font scoring method

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

Hi!

I've looked into the font scoring method in 'dirwalk.c' and 'fonts.c'.

The function 'charset_works()' scores up the given font if ALL 
characters passed to it are correctely rendered.

However, it seems to have nothing to do with checking if the font 
renders given characters distinctly. I was not able to understand what 
qsort() in charset_works() do.


I confirmed that adding Japanese characters to the translations for the 
strings used for scoring works to place the font supporting Japanese 
characters on top.

The result is good but I am not so confident it is a correct way as 
originaly intended in font scoring method.

I suppose it is more reasonable to have additional string for scoreing 
to score up the fonts supporting locale specific characters.

For example;

   user_font_styles[num_font_styles]->score += 10 *
     charset_works(
       font,
       /* put locale specific characters to the translation for this
          string to score up the fonts supporting those characters. */
       gettext("ABCXYZ")
   );

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

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