tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] [Tuxpaint-i18n] Per-locale default font

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

On Mon, Jun 12, 2023 at 10:18:35PM -0700, Bill Kendrick wrote:
> On Mon, Jun 12, 2023 at 09:17:55PM -0700, Bill Kendrick wrote:
> <snip> 
> > Yeah, I think that's what's happening for me on Linux as well.
> > Ever since switching from SDL_ttf and attempting to load "<locale>.ttf"
> > files, to SDL_Pango (now SDL2_Pango), we basically lost the ability to
> > use those fonts, and have been shipping them meaninglessly.  :-D  Oops!
> <snip> 
> > Of course, going back to the beginning of this email, the main issue at
> > hand is Tux Paint, via SDL2_Pango, doesn't KNOW about these fonts yet.
> > At least, not for me, not on Linux!
> 
> Well, I tried to convince FontConfig to add Tux Paint's shipped fonts
> (hard-coding `/usr/local/share/tuxpaint/fonts/` for the moment) to
> the list of directories to look at, but it seems to be refusing to. :-/
> 
> Anyone out here have any experience with this stuff?

Argh, I think I figured it out, unless I'm hallucinating or testing
it all wrong. :)  (I was adding Tux Paint's font directory _after_
we tried loading the uifont.)

I'm going to further extend things a bit to allow for alternative
fonts (e.g., if you have a full font, use that rather than Tux Paint's
subset alternative; e.g. for Chinese Traditional).

And I'm also going to try and get Tux Paint Config. to do the same
thing (ask FontConfig to look at Tux Paint's font directory, before
Tux Paint Config. tries to load and list available fonts in its UI).

-bill!

Re: [Tuxpaint-devel] [Tuxpaint-i18n] Per-locale default font

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

On Mon, Jun 12, 2023 at 09:17:55PM -0700, Bill Kendrick wrote:
<snip> 
> Yeah, I think that's what's happening for me on Linux as well.
> Ever since switching from SDL_ttf and attempting to load "<locale>.ttf"
> files, to SDL_Pango (now SDL2_Pango), we basically lost the ability to
> use those fonts, and have been shipping them meaninglessly.  :-D  Oops!
<snip> 
> Of course, going back to the beginning of this email, the main issue at
> hand is Tux Paint, via SDL2_Pango, doesn't KNOW about these fonts yet.
> At least, not for me, not on Linux!

Well, I tried to convince FontConfig to add Tux Paint's shipped fonts
(hard-coding `/usr/local/share/tuxpaint/fonts/` for the moment) to
the list of directories to look at, but it seems to be refusing to. :-/

Anyone out here have any experience with this stuff?

I added a bit of (all-the-time, for now) debugging output to stdout
to have Tux Paint dump the directories where FontConfig is looking.
On my system, for example, I get:

FontConfigGetFontDirs():
 * /usr/share/fonts
 * /usr/local/share/fonts
 * /home/kendrick/.local/share/fonts
 * /home/kendrick/.fonts
 * /usr/share/fonts/croscore
 * /usr/share/fonts/crosextra
 * /usr/share/fonts/dejavu
 * /usr/share/fonts/ko-nanum
 * /usr/share/fonts/lohit-cros
...
 * /usr/share/fonts/woff
 * /home/kendrick/.fonts/a
 * /home/kendrick/.fonts/e
 * /home/kendrick/.fonts/h
 * /home/kendrick/.fonts/kfontinst
 * /home/kendrick/.fonts/m
 * /usr/share/fonts/X11/Type1
 * /usr/share/fonts/X11/encodings
...
 * /usr/share/fonts/woff/opendyslexic
 * /usr/share/fonts/X11/encodings/large
 * /usr/share/fonts/truetype/roboto/unhinted
 * /usr/share/fonts/truetype/roboto/unhinted/RobotoTTF

Nowhere in there do I see the directory I'm trying to add
(/usr/local/share/tuxpaint/fonts/ or "locales/" under it).

;-(


On Sat, Jun 10, 2023 at 06:26:13PM -0400, Mark Kim wrote:
> Hi,
> 
> Tux Paint Config on macOS is also unable to list fonts bundled with Tux
> Paint.  This happens, at least on macOS, because the bundled fonts are not
> installed but stays bundled with Tux Paint, outside the purview of Tux
> Paint Config.

When/if we DO get this working in Tux Paint, I _think_ it should be
reasonable to just do the same thing in Tux Paint Config., to let it
find all the fonts Tux Paint ships with (wherever Tux Paint stores them,
e.g, in my case `/usr/local/share/tuxpaint/fonts/`), rather than having
to maintain a hard-coded list.

But... I dunno.  This stuff is maddeningly complicated. ;-(

Help wanted!!!

-bill!

Re: [Tuxpaint-devel] Per-locale default font

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

On Sat, Jun 10, 2023 at 06:26:13PM -0400, Mark Kim wrote:
> Hi,
> 
> Tux Paint Config on macOS is also unable to list fonts bundled with Tux
> Paint.  This happens, at least on macOS, because the bundled fonts are not
> installed but stays bundled with Tux Paint, outside the purview of Tux
> Paint Config.

Yeah, I think that's what's happening for me on Linux as well.
Ever since switching from SDL_ttf and attempting to load "<locale>.ttf"
files, to SDL_Pango (now SDL2_Pango), we basically lost the ability to
use those fonts, and have been shipping them meaninglessly.  :-D  Oops!


> I've made this commit
> <https://sourceforge.net/p/tuxpaint/tuxpaint-config/ci/4cfd3155c5282ffa3f260af05d2a30fa1027da95/>
> to ensure fonts bundled with Tux Paint are always listed in UI Fonts
> section of Tux Paint Config.  This is done by hard-coding the list of
> bundled fonts.  The change affects all OS in hope that it'll be beneficial
> to other OS, but let me know if it should be made into a macOS-specific
> change.

I think this is okay (though we'll need to make sure it stays sync'd up
with Tux Paint, if/when we ever change anything!)

Way back in the day (literally 20 years ago, +/- a few months!) we
packaged up various fonts that were too big to include directly inside
Tux Paint, three of which are still available here:

  https://tuxpaint.org/download/fonts/

They include:

 * Korean (~10MB)
   The "ko.ttf" font file is a copy of "gulim.ttf" from the "Baekmuk" collection
   of Korean TrueType fonts, (c) 1986-2000, Baekmuk Font 21 Inc.
   (Came from Debian package "ttf-baekmuk", at the time.)

 * Chinese Traditional (~14MB)
   HanWangKaiMediumChuIn is a registered trademark of HtWang Graphics Laboratory
   (C)Copyright Dr. Hann-Tzong Wang, 2004.
   (GPL v2+)

   [Note: What we ship directly inside Tux Paint is a subset of another GPL
   font, "wp010-05.ttf", containing only the characters used by Tux Paint;
   it weighs in at 1.1MB.  Unfortunately, the Python script that generates it
   doesn't run under Python3.  Fortunately, I refreshed it back in early 2022.]

 * Chinese Simplified (~5MB)
   The "zh_cn.ttf" font file is a copy of "AR PL SungtiL GB",
   a high-quality Chinese TrueType font (gbsn00lp.ttf)
   generously provided by Arphic Technology to the Free Software community
   under the "Arphic Public License".

We used to have others available for download as well, but eventually
rolled them into Tux Paint itself.  I wonder if in this day & age it'd
be fine to simply include these last tree fonts directly inside
Tux Paint, too.  (It looks like it'd add about 28MB to the install size.)

I have no clue whether the Windows installers or macOS DMG from way back
in 2002 & 2004 still work properly with current Tux Paint!!!  I'd rather
not continue maintaining these separate downloads. :-)


Of course, going back to the beginning of this email, the main issue at
hand is Tux Paint, via SDL2_Pango, doesn't KNOW about these fonts yet.
At least, not for me, not on Linux!

I'll poke around.

-bill!


> 
> Thanks,
> Mark
> 
> 
> On Sat, Jun 10, 2023 at 9:33 AM Shin-ichi TOYAMA <
> dol...@wm...> wrote:
> 
> > Hi!
> >
> > The behavior of the font seartch methods seem to work differently on
> > Linux and Windows.
> >
> > On linux, Tux Paint and Tux Paint Config seems not be able to find a
> > locale font shipped with Tux Paint.
> >
> > On the other hand, they *can* find the locale font on windows.
> >
> >
> > I think "noto sans" (pango's default on Rocky9?) looks good, but MS
> > Gothic (default on Windows) looks quite bad.
> >
> > Please see some examples I wrapped up.
> >
> >   https://z1.plala.jp/tuxpaint/tmp/uifonts2.html
> >
> > I confirmed pango's default (noto sans) on Rocky9 is good enough and
> > guess TkaoPGothick also would not be bad. Therefore, just specifing
> > "GJGothicPNSubset" as a default for Japanese would be O.K. at least
> > for Japanese.
> >
> > However, how is it on other distro's? How is it for other languages?
> >
> > I think it would be better if we could find a way to use locale fonts
> > also on Linux.
> >
> > Thanks!
> >
> > On Thu, 8 Jun 2023 00:52:07 -0700, Bill Kendrick wrote:
> > >
> > >For a long while now, Tux Paint has used "DejaVu Sans" as the
> > >preferred font for the UI (requested via Pango, though based on what I
> > >see in screenshots on Twitter, some folks don't have that font and
> > >some alternatives are used).
> > >
> > >Recently, Shin-ichi noted that we have a font tucked away in
> > >"fonts/locale/" that looks much better for use with Japanese text,
> > >but we're not using it (we no longer load TTF files directly and use
> > >SDL_ttf to render strings, it's all SDL2_Pango now).
> > >
> > >Therefore, I've added the ability for us (the Tux Paint developers)
> > >to specify a preferred font on a per-locale basis.  It's simply
> > >a language code (from our `src/i18n.h` file, e.g., "LANG_DE" for
> > >German, "LANG_ZH_CN" for Chinese (Simplified), etc.) and a string
> > >describing the font family we want Pango to load.
> > >(If left unspecified, we'll continue to ask for "DejaVu Sans".)
> > >
> > >This is now in the Git master branch over in the SourceForge project,
> > >and will be part of Tux Paint 0.9.31.
> > >
> > >I'm about to try to set fonts, as best I can, based on the collection
> > >of TTF files we have been shipping with Tux Paint.  Those files seem
> > >to be useless now, unless I'm mistaken!  However, I wonder if we could
> > >install them into the system where Pango can find them, when installing
> > >Tux Paint?  Or perhaps we could somehow point Pango to our directory
> > >of locale fonts as an extra place to look when scanning for fonts...?
> > >
> > >Thoughts?
> > >
> > >And also, if you have a preferred font for your favorite locale,
> > >please share and I can add it to the list!
> > >
> >
> >
> > --
> > Shin-ichi TOYAMA <dol...@wm...>
> >
> >
> > _______________________________________________
> > Tuxpaint-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> >

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Per-locale default font

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

Hi,

Tux Paint Config on macOS is also unable to list fonts bundled with Tux
Paint.  This happens, at least on macOS, because the bundled fonts are not
installed but stays bundled with Tux Paint, outside the purview of Tux
Paint Config.

I've made this commit
<https://sourceforge.net/p/tuxpaint/tuxpaint-config/ci/4cfd3155c5282ffa3f260af05d2a30fa1027da95/>
to ensure fonts bundled with Tux Paint are always listed in UI Fonts
section of Tux Paint Config.  This is done by hard-coding the list of
bundled fonts.  The change affects all OS in hope that it'll be beneficial
to other OS, but let me know if it should be made into a macOS-specific
change.

Thanks,
Mark


On Sat, Jun 10, 2023 at 9:33 AM Shin-ichi TOYAMA <
dol...@wm...> wrote:

> Hi!
>
> The behavior of the font seartch methods seem to work differently on
> Linux and Windows.
>
> On linux, Tux Paint and Tux Paint Config seems not be able to find a
> locale font shipped with Tux Paint.
>
> On the other hand, they *can* find the locale font on windows.
>
>
> I think "noto sans" (pango's default on Rocky9?) looks good, but MS
> Gothic (default on Windows) looks quite bad.
>
> Please see some examples I wrapped up.
>
>   https://z1.plala.jp/tuxpaint/tmp/uifonts2.html
>
> I confirmed pango's default (noto sans) on Rocky9 is good enough and
> guess TkaoPGothick also would not be bad. Therefore, just specifing
> "GJGothicPNSubset" as a default for Japanese would be O.K. at least
> for Japanese.
>
> However, how is it on other distro's? How is it for other languages?
>
> I think it would be better if we could find a way to use locale fonts
> also on Linux.
>
> Thanks!
>
> On Thu, 8 Jun 2023 00:52:07 -0700, Bill Kendrick wrote:
> >
> >For a long while now, Tux Paint has used "DejaVu Sans" as the
> >preferred font for the UI (requested via Pango, though based on what I
> >see in screenshots on Twitter, some folks don't have that font and
> >some alternatives are used).
> >
> >Recently, Shin-ichi noted that we have a font tucked away in
> >"fonts/locale/" that looks much better for use with Japanese text,
> >but we're not using it (we no longer load TTF files directly and use
> >SDL_ttf to render strings, it's all SDL2_Pango now).
> >
> >Therefore, I've added the ability for us (the Tux Paint developers)
> >to specify a preferred font on a per-locale basis.  It's simply
> >a language code (from our `src/i18n.h` file, e.g., "LANG_DE" for
> >German, "LANG_ZH_CN" for Chinese (Simplified), etc.) and a string
> >describing the font family we want Pango to load.
> >(If left unspecified, we'll continue to ask for "DejaVu Sans".)
> >
> >This is now in the Git master branch over in the SourceForge project,
> >and will be part of Tux Paint 0.9.31.
> >
> >I'm about to try to set fonts, as best I can, based on the collection
> >of TTF files we have been shipping with Tux Paint.  Those files seem
> >to be useless now, unless I'm mistaken!  However, I wonder if we could
> >install them into the system where Pango can find them, when installing
> >Tux Paint?  Or perhaps we could somehow point Pango to our directory
> >of locale fonts as an extra place to look when scanning for fonts...?
> >
> >Thoughts?
> >
> >And also, if you have a preferred font for your favorite locale,
> >please share and I can add it to the list!
> >
>
>
> --
> Shin-ichi TOYAMA <dol...@wm...>
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

Re: [Tuxpaint-devel] Per-locale default font

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

Hi!

The behavior of the font seartch methods seem to work differently on 
Linux and Windows.

On linux, Tux Paint and Tux Paint Config seems not be able to find a 
locale font shipped with Tux Paint.

On the other hand, they *can* find the locale font on windows.


I think "noto sans" (pango's default on Rocky9?) looks good, but MS 
Gothic (default on Windows) looks quite bad.

Please see some examples I wrapped up.

  https://z1.plala.jp/tuxpaint/tmp/uifonts2.html

I confirmed pango's default (noto sans) on Rocky9 is good enough and 
guess TkaoPGothick also would not be bad. Therefore, just specifing 
"GJGothicPNSubset" as a default for Japanese would be O.K. at least
for Japanese.

However, how is it on other distro's? How is it for other languages?

I think it would be better if we could find a way to use locale fonts 
also on Linux.

Thanks!

On Thu, 8 Jun 2023 00:52:07 -0700, Bill Kendrick wrote:
>
>For a long while now, Tux Paint has used "DejaVu Sans" as the
>preferred font for the UI (requested via Pango, though based on what I
>see in screenshots on Twitter, some folks don't have that font and
>some alternatives are used).
>
>Recently, Shin-ichi noted that we have a font tucked away in
>"fonts/locale/" that looks much better for use with Japanese text,
>but we're not using it (we no longer load TTF files directly and use
>SDL_ttf to render strings, it's all SDL2_Pango now).
>
>Therefore, I've added the ability for us (the Tux Paint developers)
>to specify a preferred font on a per-locale basis.  It's simply
>a language code (from our `src/i18n.h` file, e.g., "LANG_DE" for
>German, "LANG_ZH_CN" for Chinese (Simplified), etc.) and a string
>describing the font family we want Pango to load.
>(If left unspecified, we'll continue to ask for "DejaVu Sans".)
>
>This is now in the Git master branch over in the SourceForge project,
>and will be part of Tux Paint 0.9.31.
>
>I'm about to try to set fonts, as best I can, based on the collection
>of TTF files we have been shipping with Tux Paint.  Those files seem
>to be useless now, unless I'm mistaken!  However, I wonder if we could
>install them into the system where Pango can find them, when installing
>Tux Paint?  Or perhaps we could somehow point Pango to our directory
>of locale fonts as an extra place to look when scanning for fonts...?
>
>Thoughts?
>
>And also, if you have a preferred font for your favorite locale,
>please share and I can add it to the list!
>


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

Re: [Tuxpaint-devel] New "PACKAGE_ONLY" Makefile variable

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

On Wed, Jun 07, 2023 at 10:10:35AM +0100, Will Thompson wrote:
> Looks great. The Flatpak package has a workaround where it sets
> ARCH_INSTALL to 'install-man install-importscript' and then manually
> installs the icons etc. I haven't tested but it looks like I could remove
> this and replace it with PACKAGE_ONLY=yes.

Yay!


> I would suggest that the PACKAGE_ONLY behaviour should be the default –
> I've never seen any other software using the xdg-icon-resource or
> xdg-desktop-menu tools at build/install time. I don't know how common it is
> to manually install Tux Paint to a location that is not in the default XDG
> search path – i.e. with a prefix other than /usr, /usr/local, or
> $HOME/.local – all of which will work in the new PACKAGE_ONLY=yes path.

Sheesh, I dunno...  I guess it was probably my idea (or maybe someone
suggested it to me?) to use the XDG stuff to install all the icons.
It seemed like a smart move at the time... I'm surprised it turned out
to be such an annoyance.

The whole Makefile (like the whole codebase) needs a refactoring, I'm sure.
There's been a lot of additions & removals, in terms of requirements
(Pango & SVG stuff was awkward for a long time) and supported platforms
(Maemo & XO-1 no longer seem to be relevant?)

Only so many hours in the day, so I focus first on stuff that brings me joy.
(That's why we have things like "Fix XOR bug with blinking text cursor"
ticket from 2004. <anguish> ;-) )

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Per-locale default font

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

For a long while now, Tux Paint has used "DejaVu Sans" as the
preferred font for the UI (requested via Pango, though based on what I
see in screenshots on Twitter, some folks don't have that font and
some alternatives are used).

Recently, Shin-ichi noted that we have a font tucked away in
"fonts/locale/" that looks much better for use with Japanese text,
but we're not using it (we no longer load TTF files directly and use
SDL_ttf to render strings, it's all SDL2_Pango now).

Therefore, I've added the ability for us (the Tux Paint developers)
to specify a preferred font on a per-locale basis.  It's simply
a language code (from our `src/i18n.h` file, e.g., "LANG_DE" for
German, "LANG_ZH_CN" for Chinese (Simplified), etc.) and a string
describing the font family we want Pango to load.
(If left unspecified, we'll continue to ask for "DejaVu Sans".)

This is now in the Git master branch over in the SourceForge project,
and will be part of Tux Paint 0.9.31.

I'm about to try to set fonts, as best I can, based on the collection
of TTF files we have been shipping with Tux Paint.  Those files seem
to be useless now, unless I'm mistaken!  However, I wonder if we could
install them into the system where Pango can find them, when installing
Tux Paint?  Or perhaps we could somehow point Pango to our directory
of locale fonts as an extra place to look when scanning for fonts...?

Thoughts?

And also, if you have a preferred font for your favorite locale,
please share and I can add it to the list!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] New "PACKAGE_ONLY" Makefile variable

[Will T. <wj...@en...>]

Looks great. The Flatpak package has a workaround where it sets
ARCH_INSTALL to 'install-man install-importscript' and then manually
installs the icons etc. I haven't tested but it looks like I could remove
this and replace it with PACKAGE_ONLY=yes.

I would suggest that the PACKAGE_ONLY behaviour should be the default –
I've never seen any other software using the xdg-icon-resource or
xdg-desktop-menu tools at build/install time. I don't know how common it is
to manually install Tux Paint to a location that is not in the default XDG
search path – i.e. with a prefix other than /usr, /usr/local, or
$HOME/.local – all of which will work in the new PACKAGE_ONLY=yes path.

On Wed, 7 Jun 2023 at 08:46, Bill Kendrick <nb...@so...> wrote:

>
> For a while now, Tux Paint has been using XDG tools (like
> `xdg-icon-resource` and `xdg-desktop-menu`) to install & uninstall
> launcher icons in the user's desktop GUI.
>
> However, they apparently aren't flexible enough to play nicely with
> folks who are trying to put together a package -- specifically, it
> was Tim who helps maintain the Slackware Linux package, who pointed
> out some workarounds that have been necessary to prevent Tux Paint
> from 'polluting' their local environment.
>
> I received a Makefile patch today, which I applied to the master
> branch (what will become 0.9.31), and after making one slight
> adjustment, it _seems_ to work fine for me under Kubuntu.
>
> But, as usual, it's late and I need to be in bed. :)  So I'd
> appreciate if folks could put additional sets of eyes on things,
> and of course test to make sure that nothing breaks when you
> try to build & package Tux Paint on your favorite platforms.
>
> Here's the one commit related to this so far:
>
>
> https://sourceforge.net/p/tuxpaint/tuxpaint/ci/6b0bc390870da4fbdd8ff3d52cb2cdc270e55c5c/
>
> --
> -bill!
> Sent from my computer
>
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>

[Tuxpaint-devel] New "PACKAGE_ONLY" Makefile variable

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

For a while now, Tux Paint has been using XDG tools (like
`xdg-icon-resource` and `xdg-desktop-menu`) to install & uninstall
launcher icons in the user's desktop GUI.

However, they apparently aren't flexible enough to play nicely with
folks who are trying to put together a package -- specifically, it
was Tim who helps maintain the Slackware Linux package, who pointed
out some workarounds that have been necessary to prevent Tux Paint
from 'polluting' their local environment.

I received a Makefile patch today, which I applied to the master
branch (what will become 0.9.31), and after making one slight
adjustment, it _seems_ to work fine for me under Kubuntu.

But, as usual, it's late and I need to be in bed. :)  So I'd
appreciate if folks could put additional sets of eyes on things,
and of course test to make sure that nothing breaks when you
try to build & package Tux Paint on your favorite platforms.

Here's the one commit related to this so far:

  https://sourceforge.net/p/tuxpaint/tuxpaint/ci/6b0bc390870da4fbdd8ff3d52cb2cdc270e55c5c/

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] Tux Paint & Tux Paint Config. and quotes in config file settings

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

On Linux/Unix, Tux Paint uses "wordexp()" to do some word
expansion of config-file arguments, e.g. you can specify

  savedir=$HOME/tuxpaint/

and it will do what you'd expect.  However, if there are
spaces, things go bonkers.  I didn't notice this myself,
because I avoid spaces in file and directory names, and
also don't really fiddle with my Tux Paint settings much!

I DID notice it once I added the new "uifont" option,
because many font family names contain spaces
(e.g., "Ubuntu Condensed", "Open Sans Condensed",
"Nimbus Sans Narrow", "Bitstream Vera Sans Mono", etc.)

So I made sure Tux Paint Config. wrapped the font name in
quotes, which worked for me on Linux because Tux Paint is
using wordexp(), but Shin-ichi quickly pointed out that
Windows does NOT use wordexp(), so Tux Paint would try
to load non-existent fonts, due to the extraneous quotes!

In experimenting, I then discovered wordexp() was being
used unsafely, and Tux Paint could CRASH (segfault!) when
trying to read a config-file setting like:

  savedir=$HOME/dir with space/

It works fine with quotes:

  savedir="$HOME/dir with space/"

So I've simply made Tux Paint Config. ALWAYS put quotes
around these settings, when writing out a config. file
(and trimming them from the start/end, when reading in
from a config. file):

  uifont
  colorfile
  savedir
  exportdir
  datadir
  printcommand
  altprintcommand

Similarly, Tux Paint itself will not only run wordexp() on Linux,
but will now also trim beginning/end quotes from ALL settings,
on ALL [other] platforms.

If there are issues, or someone has a better idea, please
speak up!  As always, please test all this on your favorite
OSes to make sure things continue to work as expected.
Thanks!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] UI font configuration

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

On Sun, 4 Jun 2023 03:39:33 -0700, Bill Kendrick wrote:
>Hrm, this is not happening for me.  My config, for example:

Well, this might be a specific problem (at least?) on Windows.

>What's happening on my system is when we use wordexp() to expand
>the argument, it seems to be splitting things on spaces.  From the
>manpage:

This part is skipped on WIN32 because it does not have wordexp().
Therefore, no splitting here, and the result has double quotes like.

  Requested UI font described by ""DejaVu Sans""
  Actual UI font will be "ＭＳ ゴシック"

So, should we do some silly thing like

-----------------------------------
diff --git a/src/tuxpaint-config2.cxx b/src/tuxpaint-config2.cxx
index e72acac..dc74842 100644
--- a/src/tuxpaint-config2.cxx
+++ b/src/tuxpaint-config2.cxx
@@ -782,7 +782,11 @@ void save_conf(void)
     fprintf(fd, "alllocalefonts=yes\n");

   if ((TEXTINP_uifont_isdef()) == 0)
+#ifdef WIN32
+    fprintf(fd, "uifont=%s\n", BROWSER_uifont->text(BROWSER_uifont->value()));
+#else
     fprintf(fd, "uifont=\"%s\"\n", BROWSER_uifont->text(BROWSER_uifont->value()));
+#fi

   /* Printing: */
   /* --------- */
-----------------------------------

in tuxpaint-config ?

Re: [Tuxpaint-devel] UI font configuration

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

On Sun, Jun 04, 2023 at 09:02:33AM +0900, Shin-ichi TOYAMA wrote:
> Hi!
> 
> On Sat, 3 Jun 2023 13:49:34 -0700, Bill Kendrick wrote:
> >So please `git pull` the master branch of the "tuxpaint"
> >repo and rebuild.  If it still doesn't work, let me know,
> >and I'll blame it on another late-night coding session. ;)
> >
> >Tux Paint Config. does NOT use the same "parse" code, so
> >it will now trim quotes IF it finds them at the beginning
> >and end of the "uifont=" setting, but ALSO always ADD THEM.
> 
> Tux Paint Config adds quotes around the fontname and
> Tux Paint seems to consider those quotes as parts of the font
> name, then fall back to the default font.

Hrm, this is not happening for me.  My config, for example:

  # Generated by tuxpaint-config version 0.0.22
  uifont="DejaVu Sans"

When I run Tux Paint:

  kendrick@gambit:~/tuxpaint/tuxpaint$ tuxpaint --nosound 
  Requested UI font described by "DejaVu Sans"
  Actual UI font will be "DejaVu Sans"

The quotes seen in the output above are from the format
string, not the actual value of the string, e.g.:

  printf/*DEBUG_PRINTF*/("Requested UI font described by \"%s\"\n", tp_ui_font);


Compare to my config file if I remove the quotes:

  # Generated by tuxpaint-config version 0.0.22
  uifont=DejaVu Sans

...and then run Tux Paint:

  kendrick@gambit:~/tuxpaint/tuxpaint$ tuxpaint
  Requested UI font described by "DejaVu"
  Actual UI font will be "Noto Sans"

The "Sans" part of "DejaVu Sans" is missing, so Pango ends up using
a different font.


What's happening on my system is when we use wordexp() to expand
the argument, it seems to be splitting things on spaces.  From the
manpage:

  Field splitting is done using the environment variable $IFS.  If it
  is not set, the field separators are space, tab and newline.

If I add this line before the wordexp() call (in parse_file_options())
and then again after...

  printf("arg = <%s>\n", arg);

...I see this in tuxpaint's output:

  arg = <DejaVu Sans>
  arg = <DejaVu>
  Requested UI font described by "DejaVu"
  Actual UI font will be "Noto Sans"


> I removed the quotes manually from tuxpaint.cfg file, then
> it worked.

Can you show me the output?  Can you show me what 'arg' is before
and after wordexp() is called?


Thanks!

-bill!

> I think not adding quotes to the fontname in cfg file may
> solve this.
> 
> --- a/src/tuxpaint-config2.cxx
> +++ b/src/tuxpaint-config2.cxx
> @@ -782,7 +782,7 @@ void save_conf(void)
>      fprintf(fd, "alllocalefonts=yes\n");
> 
>    if ((TEXTINP_uifont_isdef()) == 0)
> -    fprintf(fd, "uifont=\"%s\"\n", BROWSER_uifont->text(BROWSER_uifont->value()));
> +    fprintf(fd, "uifont=%s\n", BROWSER_uifont->text(BROWSER_uifont->value()));
> 
>    /* Printing: */
>    /* --------- */
> 
> 
> However, it is not consistent with the fact that some other
> options needs quotes like printcommand for those who edit cfg
> file manually.
> 
> Hrm...
> 
> -- 
> Shin-ichi TOYAMA <dol...@wm...>

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] UI font configuration

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

Hi!

On Sat, 3 Jun 2023 13:49:34 -0700, Bill Kendrick wrote:
>So please `git pull` the master branch of the "tuxpaint"
>repo and rebuild.  If it still doesn't work, let me know,
>and I'll blame it on another late-night coding session. ;)
>
>Tux Paint Config. does NOT use the same "parse" code, so
>it will now trim quotes IF it finds them at the beginning
>and end of the "uifont=" setting, but ALSO always ADD THEM.

Tux Paint Config adds quotes around the fontname and
Tux Paint seems to consider those quotes as parts of the font
name, then fall back to the default font.

I removed the quotes manually from tuxpaint.cfg file, then
it worked.

I think not adding quotes to the fontname in cfg file may
solve this.

--- a/src/tuxpaint-config2.cxx
+++ b/src/tuxpaint-config2.cxx
@@ -782,7 +782,7 @@ void save_conf(void)
     fprintf(fd, "alllocalefonts=yes\n");

   if ((TEXTINP_uifont_isdef()) == 0)
-    fprintf(fd, "uifont=\"%s\"\n", BROWSER_uifont->text(BROWSER_uifont->value()));
+    fprintf(fd, "uifont=%s\n", BROWSER_uifont->text(BROWSER_uifont->value()));

   /* Printing: */
   /* --------- */


However, it is not consistent with the fact that some other
options needs quotes like printcommand for those who edit cfg
file manually.

Hrm...

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

Re: [Tuxpaint-devel] UI font configuration

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

On Sat, Jun 03, 2023 at 01:49:34PM -0700, Bill Kendrick wrote:
<snip>
> I should update OPTIONS docs to make this explicit.
> I also now wonder about other options that might need quotes
> (e.g., "printcmd", admittedly rarely, if ever, used in the
> wild, I assume) and never had them! :^o

Welp!  This in my .tuxpaintrc caused Tux Paint to CRASH on
startup!

  printcommand=echo > /tmp/print.ps

While this worked:

  printcommand="echo > /tmp/print.ps"

I've made sure it avoids crashing (oops, sorry!), and now
echos an error to stdout and recommends wrapping the
setting's value in quotes.

I'll need to update Tux Paint Config. to make sure it actually
deals with quotes for these other options, too! 8^o

-bill!

Re: [Tuxpaint-devel] UI font configuration

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

On Sat, Jun 03, 2023 at 11:07:34PM +0900, Shin-ichi TOYAMA wrote:
> Hi!
> 
> >> [Tux Paint Config]
> >> * It would be benefical if user could select a font from available font list.
> >
> >Done.  I opted for an Fl_Hold_Browser, which was much better
> >than trying to use a pulldown menu (Fl_Choice), as I have
> >around 450 fonts installed!  I couldn't get Fl_Input_Choice
> >to do what I want... not at <checks clock> 2am in the morning. :)
> 
> Now it looks perfect for me. Thanks!
> 
> But, unfortunately, it's uifont configuration has become no longer
> effective.
> 
> On the other hand, using --uifont option seems to has no problem.
> 
> I enabled debug message and saw the result as follows.
> 
> ----
> Requested UI font described by ""GJGothicPNSubset""
> Actual UI font will be "$B#M#S(B $B%4%7%C%/(B"
> ----
> 
> I think double "doube quatation" around the font name is suspicious.

Ah, I had to make sure font names were quoted, EVEN IN THE
CONFIG FILE, because I guess the `parse` code we use would
stop when it hit a space.

So e.g. if I had this in my ~/.tuxpaintrc

  uifont=DejaVu Sans

It was doing this:

  Requested UI font described by "DejaVu"
  Actual UI font will be "Noto Sans"

So please `git pull` the master branch of the "tuxpaint"
repo and rebuild.  If it still doesn't work, let me know,
and I'll blame it on another late-night coding session. ;)

Tux Paint Config. does NOT use the same "parse" code, so
it will now trim quotes IF it finds them at the beginning
and end of the "uifont=" setting, but ALSO always ADD THEM.

I should update OPTIONS docs to make this explicit.
I also now wonder about other options that might need quotes
(e.g., "printcmd", admittedly rarely, if ever, used in the
wild, I assume) and never had them! :^o

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] UI font configuration

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

Hi!

>> [Tux Paint Config]
>> * It would be benefical if user could select a font from available font list.
>
>Done.  I opted for an Fl_Hold_Browser, which was much better
>than trying to use a pulldown menu (Fl_Choice), as I have
>around 450 fonts installed!  I couldn't get Fl_Input_Choice
>to do what I want... not at <checks clock> 2am in the morning. :)

Now it looks perfect for me. Thanks!

But, unfortunately, it's uifont configuration has become no longer
effective.

On the other hand, using --uifont option seems to has no problem.

I enabled debug message and saw the result as follows.

----
Requested UI font described by ""GJGothicPNSubset""
Actual UI font will be "ＭＳ ゴシック"
----

I think double "doube quatation" around the font name is suspicious.


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

Re: [Tuxpaint-devel] UI font configuration

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

On Wed, May 31, 2023 at 11:09:56AM +0900, Shin-ichi TOYAMA wrote:
<snip>
> [Tux Paint]
> * I think "ja.ttf" shipped with Tux Paint is better than default font for Japanese locale.
>   Is it possible to change default font according to the locale?

> * It would be beneficail to get a list of available fonts (--uifont help ?)

tuxpaint --listfonts will do this for you :)


> [Tux Paint Config]
> * Apply button should be enabled after editting text box.

I added o->when(FL_WHEN_CHANGED) to a lot of things.  Let me
know if anything else needs it!


> * It would be benefical if user could select a font from available font list.

Done.  I opted for an Fl_Hold_Browser, which was much better
than trying to use a pulldown menu (Fl_Choice), as I have
around 450 fonts installed!  I couldn't get Fl_Input_Choice
to do what I want... not at <checks clock> 2am in the morning. :)

I think this will be suitable.  If anyone here REALLY wants something
more clever, then please propose something -- especially if you can
provide the code to go with it. ;)


Right now I've got one "ball in the air" (juggling terminology), which
is that the new "Erase" button in Tux Paint's "New" dialog is happy to
delete ANY personal template file, not just those exported from within
Tux Paint itself.  Once I wrap that up, what's in "master" could
actually be ready for a release, and will include a bunch of great
improvements!  It's only been 3 weeks since the last release, though,
so... I'll let things cool off for a bit. ;-D

-bill!

Re: [Tuxpaint-devel] UI font configuration

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

On Wed, May 31, 2023 at 11:09:56AM +0900, Shin-ichi TOYAMA wrote:
<snip>
> * It would be beneficail to get a list of available fonts (--uifont help ?)

I was just able to write a barebones function that causes Pango
to try and load a font, based on the description (string) given;
i.e., what's provided to the "uifont" argument.  It then returns
the description of the _actual_ font that was loaded.

So for example, if I do "tuxpaint --uifont bookman", Pango finds
"URW Bookman", and I see this on STDOUT:

  Requested UI font described by "bookman"
  Actual UI font will be "URW Bookman"

I need to get to bed, but hopefully tomorrow I can work on


> [Tux Paint Config]
> * Apply button should be enabled after editting text box.

This already happens for me.

Note that focus needs to leave the field.  This is also true with the
type-in values in the Joystick tab.

I agree that we probably want it to act differently (make "Apply" (and
"Reset") activate upon _modifying_ a field, since that's the friendliest.
We should do that with those Joystick fields as well.

A quick Google seems to indicate that FL_WHEN_CHANGED, vs FL_WHEN_RELEASE,
is what's wanted... somewhere.  I'm still a newbie with FLTK.


> * It would be benefical if user could select a font from available font list.

Hopefully I can duplicate the code I'll add to TP, to make this
possible within TPC.  (It will mean that it suddenly depends
on Pango library.  But since TP depends on SDL2_Pango, which in
turn depends on Pango, this shouldn't be the end of the world,
I hope!)

Then it sounds like it's possible by changing from an Fl_Input
to an Fl_Input_Choice widget.

-bill!

Re: [Tuxpaint-devel] UI font configuration

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

On Wed, May 31, 2023 at 11:09:56AM +0900, Shin-ichi TOYAMA wrote:
> Hi!
> 
> I think it is very nice to have this option!
> 
> Please see a few example tested on Windows.
> 
>  https://z1.plala.jp/tuxpaint/tmp/uifonts.html
> 
> In addition, let me make some comments.
> 
> [Tux Paint]
> * I think "ja.ttf" shipped with Tux Paint is better than default font for Japanese locale.
>   Is it possible to change default font according to the locale?

Ah, so basically we'd have a list of fonts that we
(Tux Paint team) decide are best, on a per-locale basis
(rather than _always_ using DejaVu Sans), unless overridden
by the new "--uifont" option?

I suppose we could do that.  Besides your suggestion, we'd need
other folks familiar with the other locales to suggest their
preferred fonts.  And of course, Tux Paint would need to fallback
if it cannot load them.


> * It would be beneficail to get a list of available fonts (--uifont help ?)

See below.


> [Tux Paint Config]
> * Apply button should be enabled after editting text box.

Oops, I'll fix that, thanks!


> * It would be benefical if user could select a font from available font list.

Right now I'm fighting with SDL2_Pango and pango itself,
but I'll see what I can do.  I agree. :)

Expect some new dependencies!

-bill!

Re: [Tuxpaint-devel] Template export from Open dialog

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

El dt. 30 de 05 de 2023 a les 16:57 -0700, en/na Bill Kendrick va escriure:
> On Tue, May 30, 2023 at 11:18:09PM +0200, Pere Pujal i Carabantes wrote:
> > Hi, works fine in my box
> 
> Thanks for testing it out!
> 
> 
> > the only thing I've noticed is that one has to go to the filesystem
> > to remove the no more needed templates.
> > 
> > Maybe add a way to remove added templates?
> 
> Would we want to allow users to delete ANY personal template?
> Or only the ones created within Tux Paint via the "Open" dialog?
> If the latter, I'd need a way to flag them (perhaps a datafile
> that sites alongside them).

I'd allow just the created with Tux Paint ones, 
custom templates added via filesystem can be removed via filesystem.


> 
> Since the templates appear in the "New" dialog, we would need to add
> an "Erase" button there (perhaps only appearing, or only appearing as
> accessible) when a personal template is currently selected.
> That seems a little weird, but nowhere else really makes sense!

Maybe in a "manage data" tool that allows parents/teachers/big childs
to add/remove starters, templates, stamps, brushes, etc
Obviously, adding the "Erase" button in the "New" dialog
would do the job for now...

Best
Pere



> 
> And of course, I would probably want to be able to make the
> "New" -> "Erase [template]" feature something that could be
> deactivated via a simplification setting.
> 
> In fact, I already have a feature request (oof, from 2009!) to
> make the "Open" -> "Erase [saved drawing]" feature inaccessible
> via a simplification setting. [1]
> 
> While these kinds of simplifications may sound a little weird,
> my goal is for Tux Paint to be configurable in such a way that
> it's VERY difficult to accidentally clobber things, which can
> lead to tears in the youngest of users who might not be good
> at using a mouse yet.  (See, for example, the "saveover=new"
> option.)  Disk space is cheap. [3]
> 
> 
> [1] https://sourceforge.net/p/tuxpaint/feature-requests/129/
> 
> [2] https://tuxpaint.org/docs/en/html/OPTIONS.html#saving
> 
> [3] I know first-hand that data loss can be emotionally traumatic. ;-)
> 
>     When I was around 7 or 8 years old, I was writing a game in BASIC
>     on my Timex Sinclair 1000 (US version of ZX81), and had not yet
>     saved it (to audio cassette tape, of course!)  My dad was going to
>     work on something electrical and accidentally flipped the breaker
>     that powered my bedroom.  Snoopy pancake flipping game, lost forever.
> 
>     A few years later, I was making a reasonable facsimile of
>     Pac-Man in BASIC on my Atari 8-bit.  Unfortunately a bug in the
>     particular version of BASIC I had could cause files saved to
>     disk to go corrupt, after saving a certain number of times!
>     Blocky Pac-Man clone, lost forever.
> 
>     I somehow managed to make a pretty playable (if not visually
>     attractive, yet) clone of the game KLAX for Linux.  I was about
>     to roll a tarball and post it online as an alpha version, when
>     I decided to be clever and clean up my Makefile a bit.
>     I accidentally got some $@ or $< confused, and accidentally
>     overwrote my C source file with the executable.  KLAX clone,
>     lost forever.  (I have proof of its existence, at least! ;)
>     https://www.youtube.com/watch?v=mQpHdSIi2wc ... SIGH!)
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

Re: [Tuxpaint-devel] UI font configuration

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

Hi!

I think it is very nice to have this option!

Please see a few example tested on Windows.

 https://z1.plala.jp/tuxpaint/tmp/uifonts.html

In addition, let me make some comments.

[Tux Paint]
* I think "ja.ttf" shipped with Tux Paint is better than default font for Japanese locale.
  Is it possible to change default font according to the locale?
* It would be beneficail to get a list of available fonts (--uifont help ?)

[Tux Paint Config]
* Apply button should be enabled after editting text box.
* It would be benefical if user could select a font from available font list.


On Mon, 29 May 2023 22:33:38 -0700, Bill Kendrick wrote:
>
>It was a holiday from work and school today, so I also got some other
>Tux Paint development done. :)  I'm adding a new "--uifont" option that
>will allow you to specify a different font (than "DejaVu Sans", as
>#defined in `fonts.h`) for Tux Paint's UI -- button labels, pop-up
>dialog box text, and Tux's tips/instructions at the bottom.
>
>So far so good (was a bit more trivial than I expected), and I'm
>hoping to wrap up the last bits of it now... that being exposing
>the option in Tux Paint Config.
>
>Do try it out & let me know what you think.  Some examples can be
>seen here [sorry for the evil Twitter link]:
>
>  https://twitter.com/TuxPaintTweets/status/1663285854847275008
>


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

Re: [Tuxpaint-devel] Template export from Open dialog

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

On Tue, 30 May 2023 16:57:47 -0700, Bill Kendrick wrote:
>On Tue, May 30, 2023 at 11:18:09PM +0200, Pere Pujal i Carabantes wrote:
>Would we want to allow users to delete ANY personal template?
>Or only the ones created within Tux Paint via the "Open" dialog?
>If the latter, I'd need a way to flag them (perhaps a datafile
>that sites alongside them).

I think the latter would be better so far.
It would make such users who deleted some templates irritate if they appear
again after updating Tux Paint.

Re: [Tuxpaint-devel] Template export from Open dialog

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

On Tue, May 30, 2023 at 11:18:09PM +0200, Pere Pujal i Carabantes wrote:
> Hi, works fine in my box

Thanks for testing it out!


> the only thing I've noticed is that one has to go to the filesystem
> to remove the no more needed templates.
> 
> Maybe add a way to remove added templates?

Would we want to allow users to delete ANY personal template?
Or only the ones created within Tux Paint via the "Open" dialog?
If the latter, I'd need a way to flag them (perhaps a datafile
that sites alongside them).

Since the templates appear in the "New" dialog, we would need to add
an "Erase" button there (perhaps only appearing, or only appearing as
accessible) when a personal template is currently selected.
That seems a little weird, but nowhere else really makes sense!

And of course, I would probably want to be able to make the
"New" -> "Erase [template]" feature something that could be
deactivated via a simplification setting.

In fact, I already have a feature request (oof, from 2009!) to
make the "Open" -> "Erase [saved drawing]" feature inaccessible
via a simplification setting. [1]

While these kinds of simplifications may sound a little weird,
my goal is for Tux Paint to be configurable in such a way that
it's VERY difficult to accidentally clobber things, which can
lead to tears in the youngest of users who might not be good
at using a mouse yet.  (See, for example, the "saveover=new"
option.)  Disk space is cheap. [3]


[1] https://sourceforge.net/p/tuxpaint/feature-requests/129/

[2] https://tuxpaint.org/docs/en/html/OPTIONS.html#saving

[3] I know first-hand that data loss can be emotionally traumatic. ;-)

    When I was around 7 or 8 years old, I was writing a game in BASIC
    on my Timex Sinclair 1000 (US version of ZX81), and had not yet
    saved it (to audio cassette tape, of course!)  My dad was going to
    work on something electrical and accidentally flipped the breaker
    that powered my bedroom.  Snoopy pancake flipping game, lost forever.

    A few years later, I was making a reasonable facsimile of
    Pac-Man in BASIC on my Atari 8-bit.  Unfortunately a bug in the
    particular version of BASIC I had could cause files saved to
    disk to go corrupt, after saving a certain number of times!
    Blocky Pac-Man clone, lost forever.

    I somehow managed to make a pretty playable (if not visually
    attractive, yet) clone of the game KLAX for Linux.  I was about
    to roll a tarball and post it online as an alpha version, when
    I decided to be clever and clean up my Makefile a bit.
    I accidentally got some $@ or $< confused, and accidentally
    overwrote my C source file with the executable.  KLAX clone,
    lost forever.  (I have proof of its existence, at least! ;)
    https://www.youtube.com/watch?v=mQpHdSIi2wc ... SIGH!)

Re: [Tuxpaint-devel] Template export from Open dialog

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

Hi, works fine in my box, the only thing I've noticed is that 
one has to go to the filesystem to remove the no more needed templates.

Maybe add a way to remove added templates?

HTH
Pere


El dl. 29 de 05 de 2023 a les 11:11 -0700, en/na Bill Kendrick va escriure:
> For a while now we've had the ability to export drawings to a location
> 'outside' of Tux Paint, and easier to access (e.g., on Linux, under
> $HOME/Pictures/TuxPaint/) -- via the "Export" button in the "Open"
> dialog.  (There's also an animated GIF export feature, if you drill
> down into the "Slides" slideshow section, that arrived at the same time.)
> 
> I've now added the ability to export a saved image into the user's
> personal Templates directory (e.g., on Linux, $HOME/.tuxpaint/templates/)
> 
> This way, together with the Eraser tool (which now has a set of
> fuzzy-edged options), you can make a new picture in layers.
> It's obviously not as sophisticated as real Layers (capital-L) in apps
> like Photoshop & GIMP, but it will be helpful to some users.
> 
> I can also see it being utilized for animations.  Right now, you can
> create a background, and save it (let's call this picture #0).
> Then add your foreground options, and save out to a new drawing
> (picture #1; the first frame of the animation).  Then you need to
> reload picture #0, redraw EVERYTHING in its new place, and save out to
> another new drawing (picture #2).  Repeat.
> 
> With a template, you can create a new picture using the background,
> draw things, and save it (picture #1).  Then use the eraser, clone
> tool, etc. to make adjustments, and the save to a new drawing
> (picture #2).
> 
> Anyway, along with the new feature, I've updated the docs (README,
> EXTENDING, manpage, etc.).  This feature can be disabled with a new
> "notemplateexport" option.  I'm about to add that to Tux Paint Config.
> 
> Note - Tux Paint will do its best to avoid saving the same unmodified
> picture out to multiple new Templates.  Each template's filename uses
> the original drawing's filename (which was the timestamp of the moment
> it was _first_ saved) as a prefix.  For any image which matches that
> name, it will check if the files are an identical size (via stat()).
> If they happen to be, then it will check the image's dimensions
> (via libPNG).  In the likely event that they are identical, it will
> then calculate a CRC checksum (via zlib) of the images to see if the
> file contents are the same.  If they are, it will avoid exporting a
> new template, and state as much to the end user.
> 
> Please try it out (`git pull` master branch), and let me know if there
> are any issues!  Thanks!
> 

[Tuxpaint-devel] UI font configuration

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

It was a holiday from work and school today, so I also got some other
Tux Paint development done. :)  I'm adding a new "--uifont" option that
will allow you to specify a different font (than "DejaVu Sans", as
#defined in `fonts.h`) for Tux Paint's UI -- button labels, pop-up
dialog box text, and Tux's tips/instructions at the bottom.

So far so good (was a bit more trivial than I expected), and I'm
hoping to wrap up the last bits of it now... that being exposing
the option in Tux Paint Config.

Do try it out & let me know what you think.  Some examples can be
seen here [sorry for the evil Twitter link]:

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

-- 
-bill!
Sent from my computer