tuxpaint-devel Mailing List for Tux Paint (Page 2)
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
(15) |
Apr
(5) |
May
(12) |
Jun
(15) |
Jul
(21) |
Aug
(2) |
Sep
(14) |
Oct
(32) |
Nov
(47) |
Dec
(39) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(33) |
Feb
(59) |
Mar
(17) |
Apr
(5) |
May
|
Jun
(6) |
Jul
(7) |
Aug
(19) |
Sep
(64) |
Oct
(161) |
Nov
(9) |
Dec
(23) |
2007 |
Jan
(6) |
Feb
(46) |
Mar
(55) |
Apr
(41) |
May
(43) |
Jun
(44) |
Jul
(46) |
Aug
(25) |
Sep
(16) |
Oct
(29) |
Nov
(50) |
Dec
(64) |
2008 |
Jan
(11) |
Feb
(18) |
Mar
(52) |
Apr
(37) |
May
(40) |
Jun
(78) |
Jul
(85) |
Aug
(31) |
Sep
(23) |
Oct
(13) |
Nov
(19) |
Dec
(37) |
2009 |
Jan
(36) |
Feb
(24) |
Mar
(86) |
Apr
(43) |
May
(36) |
Jun
(151) |
Jul
(23) |
Aug
(40) |
Sep
(11) |
Oct
(91) |
Nov
(68) |
Dec
(27) |
2010 |
Jan
|
Feb
(11) |
Mar
(79) |
Apr
(50) |
May
(26) |
Jun
(44) |
Jul
(31) |
Aug
(6) |
Sep
(2) |
Oct
(16) |
Nov
(11) |
Dec
(4) |
2011 |
Jan
(14) |
Feb
(5) |
Mar
(22) |
Apr
(1) |
May
(5) |
Jun
(5) |
Jul
(13) |
Aug
(1) |
Sep
(3) |
Oct
(18) |
Nov
(15) |
Dec
(25) |
2012 |
Jan
(1) |
Feb
(9) |
Mar
(41) |
Apr
(32) |
May
|
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2013 |
Jan
|
Feb
(5) |
Mar
(16) |
Apr
(21) |
May
(3) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(13) |
Nov
(1) |
Dec
(3) |
2014 |
Jan
|
Feb
(12) |
Mar
(6) |
Apr
(35) |
May
|
Jun
(12) |
Jul
(35) |
Aug
(98) |
Sep
(3) |
Oct
(8) |
Nov
(4) |
Dec
(1) |
2015 |
Jan
(4) |
Feb
(9) |
Mar
(58) |
Apr
(9) |
May
(15) |
Jun
(23) |
Jul
|
Aug
(32) |
Sep
(12) |
Oct
(21) |
Nov
(5) |
Dec
(14) |
2016 |
Jan
(6) |
Feb
(3) |
Mar
(37) |
Apr
(18) |
May
(5) |
Jun
(8) |
Jul
|
Aug
(21) |
Sep
(5) |
Oct
(20) |
Nov
(4) |
Dec
(6) |
2017 |
Jan
(2) |
Feb
|
Mar
|
Apr
(19) |
May
(8) |
Jun
(3) |
Jul
(3) |
Aug
(5) |
Sep
|
Oct
(4) |
Nov
(4) |
Dec
(6) |
2018 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(4) |
Sep
(4) |
Oct
|
Nov
|
Dec
(3) |
2019 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
(3) |
Sep
(14) |
Oct
(2) |
Nov
(1) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(3) |
Sep
(15) |
Oct
(9) |
Nov
(11) |
Dec
(7) |
2021 |
Jan
(12) |
Feb
(2) |
Mar
(16) |
Apr
|
May
|
Jun
(11) |
Jul
|
Aug
(4) |
Sep
(24) |
Oct
(68) |
Nov
(61) |
Dec
|
2022 |
Jan
(42) |
Feb
(17) |
Mar
(20) |
Apr
(2) |
May
(23) |
Jun
(4) |
Jul
(6) |
Aug
|
Sep
(27) |
Oct
(4) |
Nov
(10) |
Dec
(31) |
2023 |
Jan
(4) |
Feb
(18) |
Mar
(8) |
Apr
(11) |
May
(18) |
Jun
(47) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(2) |
2024 |
Jan
(10) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Bill K. <nb...@so...> - 2023-06-22 05:20:43
|
On Thu, Jun 22, 2023 at 08:24:41AM +0900, Shin-ichi TOYAMA wrote: > Just a brief report > > Current git tree fails to link due to an "undefined reference" error > to `rsvg_handle_get_intrinsic_size_in_pixels' on Rocky Linux 9 > > May be a library bug on the distro?? Hrm, that function was apparently added in RSVG 2.52. What version does Rocky Linux 9 have? Perhaps, for a while at least, we may need to support using either rsvg_handle_get_dimensions() (deprecated nowadays) or rsvg_handle_get_intrinsic_size_in_pixels(), depending on which version of RSVG is in use. I'll see if I can figure out an #ifdef test. Thanks for reporting! -bill! |
From: Shin-ichi T. <dol...@wm...> - 2023-06-21 23:24:49
|
Just a brief report Current git tree fails to link due to an "undefined reference" error to `rsvg_handle_get_intrinsic_size_in_pixels' on Rocky Linux 9 May be a library bug on the distro?? -- Shin-ichi TOYAMA <dol...@wm...> |
From: Shin-ichi T. <dol...@wm...> - 2023-06-18 23:26:56
|
On Sun, 18 Jun 2023 13:38:35 -0700, Bill Kendrick wrote: >It's doubtful I'll get to it today, as I've got an engagement in a >bit, but it's nice to get use closer to 'zero warnings' when >compiling. > >At least, that's what it looks like for ME, just doing a plain >`make` here on my Kubuntu 22.04 system. If anyone else is still >seeing compiler warnings, please share them so we can try and >clean up the codebase. It's nice for _real_ errors to not be >buried in a sea of warnings. :) Here are warnings on Windows so far. I will see them when I have time. src/tuxpaint.c:234:2: warning: #warning "Attempting to define strcasestr(); if errors, build with -DHAVE_STRCASESTR" [-Wcpp] 234 | #warning "Attempting to define strcasestr(); if errors, build with -DHAVE_STRCASESTR" | ^~~~~~~ src/tuxpaint.c: In function 'mainloop': src/tuxpaint.c:3747:21: warning: the comparison will always evaluate as 'true' for the address of 'sizes' will never be NULL [-Waddress] 3747 | if (magics[magic_group][cur_thing].sizes) | ^~~~~~ src/tuxpaint.c:1581:7: note: 'sizes' declared here 1581 | int sizes[MAX_MODES]; /* Whether magic tool accepts sizes */ | ^~~~~ src/tuxpaint.c:4369:23: warning: the comparison will always evaluate as 'true' for the address of 'sizes' will never be NULL [-Waddress] 4369 | if (magics[magic_group][cur_thing].sizes) | ^~~~~~ src/tuxpaint.c:1581:7: note: 'sizes' declared here 1581 | int sizes[MAX_MODES]; /* Whether magic tool accepts sizes */ | ^~~~~ src/tuxpaint.c:5109:21: warning: the comparison will always evaluate as 'true' for the address of 'sizes' will never be NULL [-Waddress] 5109 | if (magics[grp][cur].sizes) | ^~~~~~ src/tuxpaint.c:1581:7: note: 'sizes' declared here 1581 | int sizes[MAX_MODES]; /* Whether magic tool accepts sizes */ | ^~~~~ src/tuxpaint.c: In function '_load_svg': src/tuxpaint.c:21025:5: warning: 'rsvg_handle_close' is deprecated: Use 'rsvg_handle_read_stream_sync' instead [-Wdeprecated-declarations] 21025 | rsvg_handle_close(rsvg_handle, &gerr); | ^~~~~~~~~~~~~~~~~ In file included from src/tuxpaint.c:517: C:/msys64/mingw64/include/librsvg-2.0/librsvg/rsvg.h:605:10: note: declared here 605 | gboolean rsvg_handle_close (RsvgHandle *handle, GError **error); | ^~~~~~~~~~~~~~~~~ src/tuxpaint.c:21039:5: warning: 'rsvg_handle_close' is deprecated: Use 'rsvg_handle_read_stream_sync' instead [-Wdeprecated-declarations] 21039 | rsvg_handle_close(rsvg_handle, &gerr); | ^~~~~~~~~~~~~~~~~ C:/msys64/mingw64/include/librsvg-2.0/librsvg/rsvg.h:605:10: note: declared here 605 | gboolean rsvg_handle_close (RsvgHandle *handle, GError **error); | ^~~~~~~~~~~~~~~~~ src/tuxpaint.c:21053:5: warning: 'rsvg_handle_close' is deprecated: Use 'rsvg_handle_read_stream_sync' instead [-Wdeprecated-declarations] 21053 | rsvg_handle_close(rsvg_handle, &gerr); | ^~~~~~~~~~~~~~~~~ C:/msys64/mingw64/include/librsvg-2.0/librsvg/rsvg.h:605:10: note: declared here 605 | gboolean rsvg_handle_close (RsvgHandle *handle, GError **error); | ^~~~~~~~~~~~~~~~~ src/tuxpaint.c:21097:5: warning: 'rsvg_handle_close' is deprecated: Use 'rsvg_handle_read_stream_sync' instead [-Wdeprecated-declarations] 21097 | rsvg_handle_close(rsvg_handle, &gerr); | ^~~~~~~~~~~~~~~~~ C:/msys64/mingw64/include/librsvg-2.0/librsvg/rsvg.h:605:10: note: declared here 605 | gboolean rsvg_handle_close (RsvgHandle *handle, GError **error); | ^~~~~~~~~~~~~~~~~ src/tuxpaint.c:21113:5: warning: 'rsvg_handle_close' is deprecated: Use 'rsvg_handle_read_stream_sync' instead [-Wdeprecated-declarations] 21113 | rsvg_handle_close(rsvg_handle, &gerr); | ^~~~~~~~~~~~~~~~~ C:/msys64/mingw64/include/librsvg-2.0/librsvg/rsvg.h:605:10: note: declared here 605 | gboolean rsvg_handle_close (RsvgHandle *handle, GError **error); | ^~~~~~~~~~~~~~~~~ src/tuxpaint.c:21126:3: warning: 'rsvg_handle_close' is deprecated: Use 'rsvg_handle_read_stream_sync' instead [-Wdeprecated-declarations] 21126 | rsvg_handle_close(rsvg_handle, &gerr); | ^~~~~~~~~~~~~~~~~ C:/msys64/mingw64/include/librsvg-2.0/librsvg/rsvg.h:605:10: note: declared here 605 | gboolean rsvg_handle_close (RsvgHandle *handle, GError **error); | ^~~~~~~~~~~~~~~~~ src/tuxpaint.c: In function 'set_label_fonts': src/tuxpaint.c:26894:15: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] 26894 | ttffont = TTF_FontFaceFamilyName(getfonthandle(i)->ttf_font); | ^ src/tuxpaint.c: In function 'load_embedded_data': src/tuxpaint.c:27585:15: warning: pointer 'unc_buff' used after 'free' [-Wuse-after-free] 27585 | free(unc_buff); | ^~~~~~~~~~~~~~ src/tuxpaint.c:27581:15: note: call to 'free' here 27581 | free(unc_buff); | ^~~~~~~~~~~~~~ src/tuxpaint.c:27646:15: warning: pointer 'unc_buff' used after 'free' [-Wuse-after-free] 27646 | free(unc_buff); | ^~~~~~~~~~~~~~ src/tuxpaint.c:27642:15: note: call to 'free' here 27642 | free(unc_buff); | ^~~~~~~~~~~~~~ echo src/fonts.c: In function 'TuxPaint_Font_OpenFont': src/fonts.c:342:16: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] 342 | familyname = TTF_FontFaceFamilyName(ttf_font); /* N.B.: I don't believe we're supposed to free() this... -bjk 2021.10.26 */ | ^ src/fonts.c: In function 'getfonthandle': src/fonts.c:1357:20: warning: the comparison will always evaluate as 'true' for the address of 'filename' will never be NULL [-Waddress] 1357 | if (fi->filename != NULL) | ^~ In file included from src/fonts.c:60: src/fonts.h:152:9: note: 'filename' declared here 152 | char *filename[4]; | ^~~~~~~~ src/dirwalk.c: In function 'tp_ftw': src/dirwalk.c:436:2: warning: #warning Failed to see DT_UNKNOWN [-Wcpp] 436 | #warning Failed to see DT_UNKNOWN | ^~~~~~~ -- Shin-ichi TOYAMA <dol...@wm...> |
From: Bill K. <nb...@so...> - 2023-06-18 20:38:50
|
On Sun, Jun 18, 2023 at 01:29:55PM +0900, Shin-ichi TOYAMA wrote: > Hi! > > It builds on Windows with no problem. Thanks! > > On linux, it still did not use the fake inkscape. > > I set an executable flag to it and confirmed this seems to work. > > https://sourceforge.net/p/tuxpaint/tuxpaint/ci/76a2c5f3fdd8a2ff5c606f373fb134750844208d/ Thanks to you and Mark for testing! Tim also noticed the missing chmod (oops, sorry!). I've asked him to confirm whether it works as expected when doing a Slackware build (the goal was to avoid polluting the local system with fontcache stuff, which Inkscape was causing). So that leaves Luc confirming whether it still works alright when building on Haiku. (And possibly Pere for Android, but maybe not relevant?) Speaking of SVG, I've just replaced a couple of the deprecated libRSVG function calls we've been using, but I haven't dealt with how things are opened (and hence replacing the rsvg_handle_close() call). (See https://sourceforge.net/p/tuxpaint/bugs/278/) It's doubtful I'll get to it today, as I've got an engagement in a bit, but it's nice to get use closer to 'zero warnings' when compiling. At least, that's what it looks like for ME, just doing a plain `make` here on my Kubuntu 22.04 system. If anyone else is still seeing compiler warnings, please share them so we can try and clean up the codebase. It's nice for _real_ errors to not be buried in a sea of warnings. :) Thanks! -bill! |
From: Shin-ichi T. <dol...@wm...> - 2023-06-18 04:30:06
|
Hi! It builds on Windows with no problem. Thanks! On linux, it still did not use the fake inkscape. I set an executable flag to it and confirmed this seems to work. https://sourceforge.net/p/tuxpaint/tuxpaint/ci/76a2c5f3fdd8a2ff5c606f373fb134750844208d/ On Sat, 17 Jun 2023 11:46:28 -0700, Bill Kendrick wrote: > >Okay, I've created a kind of hybrid solution... >a shell script, `convert-wrapper.sh`, that Makefile will now >call (instead of `convert` directly). > >_It_ will do the trick of creating a dummy './inkscape' >and adding '.' (PWD) to $PATH so `convert` will see it. > >Please tell me whether this works (I've also asked Tim to test it >when doing the Slackware build) > > https://sourceforge.net/p/tuxpaint/tuxpaint/ci/8e9b33b22efa7c11efddc6c79910f26cf3730ab7/ > >Luc & Mark, can you check it too? WORST case, there can be >OS-specific values for the new $(CONVERT) variable in Makefile. >(I replaced direct calls to "convert" with that, a la $(CC), >and set the variable to "./convert-wrapper.sh"). > >Whew, I hope this solves it! Hoping to get back to fun stuff now! > >-bill! > >On Sat, Jun 17, 2023 at 10:01:17PM +0900, Shin-ichi TOYAMA wrote: >> Hi! >> >> On Sat, 17 Jun 2023 09:05:52 +0900, Shin-ichi TOYAMA wrote: >> >How do I check if the fake incscape method is working correctly? >> >> I tweaked the fake inkscape to write debug log as follows. >> >> ----------------------------------------------------------------------- >> echo-thumb-starters: >> @echo >> @echo "...Generating thumbnails for starters..." >> @echo "# Don't let ImageMagick use Inkscape; use rsvgconvert instead" > ./inkscape >> @echo "echo Fake inkscape invoked >> fake.log" >> ./inkscape >> @echo "exit 1" >> ./inkscape >> @chmod 755 ./inkscape >> @(eval export PATH="$(shell pwd)":"$(PATH)") >> ----------------------------------------------------------------------- >> >> At first, I tested it on Rocky 9 linux. >> >> It looks like the fake inkscape is not called because the "fake.log" file >> is not created. I guess modified PATH environment variable here affects only >> to the subshell. >> >> Next I replaced the "eval" line with the one Mark suggested, >> >> ----------------------------------------------------------------------- >> $(eval export PATH=$(shell pwd):$(PATH)) >> ----------------------------------------------------------------------- >> >> and *got* the "fake.log" file. >> >> On the other hand, both original code and Mark's one did not create the >> "fake.log" file on Windows. >> >> Therefore, I simply ran convert command on Linux and Windows. The result was >> >> [ Linux ] >> --------------- >> [toyama@rocky9 tuxpaint]$ convert -verbose starters/fish_icon.svg fish_icon2.svg >> 'inkscape' '/tmp/magick-LyWuJyZdCkEYr-nzgHilo5hNBUMB3sBv' --export-filename='/tmp/magick-F2sFztT4Ha-sp2e13FKriomVW_1aGFj6.png' --export-dpi='96' --export-background='rgb(100%,100%,100%)' --export-background-opacity='1' > '/tmp/magick-t-yhM4iKZM0BE1Ycg6r82LZpE5i9UoAT' 2>&1 >> /tmp/magick-F2sFztT4Ha-sp2e13FKriomVW_1aGFj6.png PNG 559x478 559x478+0+0 8-bit sRGB 49984B 0.020u 0:00.008 >> starters/fish_icon.svg SVG 559x478 559x478+0+0 8-bit sRGB 49984B 0.000u 0:00.000 >> starters/fish_icon.svg=>fish_icon2.svg PNM 559x478 559x478+0+0 8-bit sRGB 801621B 0.000u 0:00.022 >> --------------- >> >> [ Windows ] >> --------------- >> mingw64:$ convert -verbose starters/fish_icon.svg fish_icon2.svg >> starters/fish_icon.svg SVG 559x478 559x478+0+0 16-bit sRGB 5779B 0.000u 0:00.011 >> starters/fish_icon.svg=>fish_icon2.svg SVG 559x478 559x478+0+0 16-bit sRGB 31474B 0.031u 0:00.032 >> --------------- >> >> So, ImageMagick convert for Window is not likely to try inkscape even inkscape is installed. >> >> Judging from all above, I suppose we should adopt Mark's correction for "eval" line. >> >> Thanks. >> >> >> >> _______________________________________________ >> Tuxpaint-devel mailing list >> Tux...@li... >> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > -- Shin-ichi TOYAMA <dol...@wm...> |
From: Mark K. <mar...@gm...> - 2023-06-17 22:34:52
|
Hi Bill, On Sat, Jun 17, 2023 at 2:46 PM Bill Kendrick <nb...@so...> wrote: > Please tell me whether this works (I've also asked Tim to test it > when doing the Slackware build) > > > https://sourceforge.net/p/tuxpaint/tuxpaint/ci/8e9b33b22efa7c11efddc6c79910f26cf3730ab7/ > > Luc & Mark, can you check it too? It builds and runs fine on the macOS. Thanks, Mark |
From: Bill K. <nb...@so...> - 2023-06-17 18:46:36
|
Okay, I've created a kind of hybrid solution... a shell script, `convert-wrapper.sh`, that Makefile will now call (instead of `convert` directly). _It_ will do the trick of creating a dummy './inkscape' and adding '.' (PWD) to $PATH so `convert` will see it. Please tell me whether this works (I've also asked Tim to test it when doing the Slackware build) https://sourceforge.net/p/tuxpaint/tuxpaint/ci/8e9b33b22efa7c11efddc6c79910f26cf3730ab7/ Luc & Mark, can you check it too? WORST case, there can be OS-specific values for the new $(CONVERT) variable in Makefile. (I replaced direct calls to "convert" with that, a la $(CC), and set the variable to "./convert-wrapper.sh"). Whew, I hope this solves it! Hoping to get back to fun stuff now! -bill! On Sat, Jun 17, 2023 at 10:01:17PM +0900, Shin-ichi TOYAMA wrote: > Hi! > > On Sat, 17 Jun 2023 09:05:52 +0900, Shin-ichi TOYAMA wrote: > >How do I check if the fake incscape method is working correctly? > > I tweaked the fake inkscape to write debug log as follows. > > ----------------------------------------------------------------------- > echo-thumb-starters: > @echo > @echo "...Generating thumbnails for starters..." > @echo "# Don't let ImageMagick use Inkscape; use rsvgconvert instead" > ./inkscape > @echo "echo Fake inkscape invoked >> fake.log" >> ./inkscape > @echo "exit 1" >> ./inkscape > @chmod 755 ./inkscape > @(eval export PATH="$(shell pwd)":"$(PATH)") > ----------------------------------------------------------------------- > > At first, I tested it on Rocky 9 linux. > > It looks like the fake inkscape is not called because the "fake.log" file > is not created. I guess modified PATH environment variable here affects only > to the subshell. > > Next I replaced the "eval" line with the one Mark suggested, > > ----------------------------------------------------------------------- > $(eval export PATH=$(shell pwd):$(PATH)) > ----------------------------------------------------------------------- > > and *got* the "fake.log" file. > > On the other hand, both original code and Mark's one did not create the > "fake.log" file on Windows. > > Therefore, I simply ran convert command on Linux and Windows. The result was > > [ Linux ] > --------------- > [toyama@rocky9 tuxpaint]$ convert -verbose starters/fish_icon.svg fish_icon2.svg > 'inkscape' '/tmp/magick-LyWuJyZdCkEYr-nzgHilo5hNBUMB3sBv' --export-filename='/tmp/magick-F2sFztT4Ha-sp2e13FKriomVW_1aGFj6.png' --export-dpi='96' --export-background='rgb(100%,100%,100%)' --export-background-opacity='1' > '/tmp/magick-t-yhM4iKZM0BE1Ycg6r82LZpE5i9UoAT' 2>&1 > /tmp/magick-F2sFztT4Ha-sp2e13FKriomVW_1aGFj6.png PNG 559x478 559x478+0+0 8-bit sRGB 49984B 0.020u 0:00.008 > starters/fish_icon.svg SVG 559x478 559x478+0+0 8-bit sRGB 49984B 0.000u 0:00.000 > starters/fish_icon.svg=>fish_icon2.svg PNM 559x478 559x478+0+0 8-bit sRGB 801621B 0.000u 0:00.022 > --------------- > > [ Windows ] > --------------- > mingw64:$ convert -verbose starters/fish_icon.svg fish_icon2.svg > starters/fish_icon.svg SVG 559x478 559x478+0+0 16-bit sRGB 5779B 0.000u 0:00.011 > starters/fish_icon.svg=>fish_icon2.svg SVG 559x478 559x478+0+0 16-bit sRGB 31474B 0.031u 0:00.032 > --------------- > > So, ImageMagick convert for Window is not likely to try inkscape even inkscape is installed. > > Judging from all above, I suppose we should adopt Mark's correction for "eval" line. > > Thanks. > > > > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel -- -bill! Sent from my computer |
From: Shin-ichi T. <dol...@wm...> - 2023-06-17 13:01:29
|
Hi! On Sat, 17 Jun 2023 09:05:52 +0900, Shin-ichi TOYAMA wrote: >How do I check if the fake incscape method is working correctly? I tweaked the fake inkscape to write debug log as follows. ----------------------------------------------------------------------- echo-thumb-starters: @echo @echo "...Generating thumbnails for starters..." @echo "# Don't let ImageMagick use Inkscape; use rsvgconvert instead" > ./inkscape @echo "echo Fake inkscape invoked >> fake.log" >> ./inkscape @echo "exit 1" >> ./inkscape @chmod 755 ./inkscape @(eval export PATH="$(shell pwd)":"$(PATH)") ----------------------------------------------------------------------- At first, I tested it on Rocky 9 linux. It looks like the fake inkscape is not called because the "fake.log" file is not created. I guess modified PATH environment variable here affects only to the subshell. Next I replaced the "eval" line with the one Mark suggested, ----------------------------------------------------------------------- $(eval export PATH=$(shell pwd):$(PATH)) ----------------------------------------------------------------------- and *got* the "fake.log" file. On the other hand, both original code and Mark's one did not create the "fake.log" file on Windows. Therefore, I simply ran convert command on Linux and Windows. The result was [ Linux ] --------------- [toyama@rocky9 tuxpaint]$ convert -verbose starters/fish_icon.svg fish_icon2.svg 'inkscape' '/tmp/magick-LyWuJyZdCkEYr-nzgHilo5hNBUMB3sBv' --export-filename='/tmp/magick-F2sFztT4Ha-sp2e13FKriomVW_1aGFj6.png' --export-dpi='96' --export-background='rgb(100%,100%,100%)' --export-background-opacity='1' > '/tmp/magick-t-yhM4iKZM0BE1Ycg6r82LZpE5i9UoAT' 2>&1 /tmp/magick-F2sFztT4Ha-sp2e13FKriomVW_1aGFj6.png PNG 559x478 559x478+0+0 8-bit sRGB 49984B 0.020u 0:00.008 starters/fish_icon.svg SVG 559x478 559x478+0+0 8-bit sRGB 49984B 0.000u 0:00.000 starters/fish_icon.svg=>fish_icon2.svg PNM 559x478 559x478+0+0 8-bit sRGB 801621B 0.000u 0:00.022 --------------- [ Windows ] --------------- mingw64:$ convert -verbose starters/fish_icon.svg fish_icon2.svg starters/fish_icon.svg SVG 559x478 559x478+0+0 16-bit sRGB 5779B 0.000u 0:00.011 starters/fish_icon.svg=>fish_icon2.svg SVG 559x478 559x478+0+0 16-bit sRGB 31474B 0.031u 0:00.032 --------------- So, ImageMagick convert for Window is not likely to try inkscape even inkscape is installed. Judging from all above, I suppose we should adopt Mark's correction for "eval" line. Thanks. |
From: Shin-ichi T. <dol...@wm...> - 2023-06-17 00:06:01
|
Hi Mark, It stopped the error, thanks! Bill, Now I newly installed inkscape on the build system. How do I check if the fake incscape method is working correctly? On Fri, 16 Jun 2023 14:55:13 -0400, Mark Kim wrote: >Would this work? > >diff --git a/Makefile b/Makefile >index 331604b1..f5b1497f 100644 >--- a/Makefile >+++ b/Makefile >@@ -886,7 +886,7 @@ echo-thumb-starters: > @echo "# Don't let ImageMagick use Inkscape; use rsvgconvert >instead" > ./inkscape > @echo "exit 1" >> ./inkscape > @chmod 755 ./inkscape >- @(eval export PATH="$(shell pwd)":"$(PATH)") >+ $(eval export PATH=$(shell pwd):$(PATH)) > > # Create thumbnails for starters > .PHONY: thumb-starters > > >On Fri, Jun 16, 2023 at 2:00 PM Bill Kendrick <nb...@so...> wrote: > >> On Fri, Jun 16, 2023 at 06:01:02PM +0900, Shin-ichi TOYAMA wrote: >> > Hi! >> > >> > As a workaround on my build environment, I've purged paths containing >> > spaces and parentheses from the "$PATH" and added paths of symbolic >> > links from /usr/local/* to actual directories. >> > >> > It looks O.K. so far. >> >> Thanks. >> >> I was actually just thinking out loud in an email to Tim, suggesting >> perhaps >> we can just create our own tiny shell script that gets invoked >> (call it, say, `./convert-wrapper.sh`) rather than the `convert` in $PATH, >> so we can have full control over how it works... >> >> ...either by doing a similar "inkscape => exit 1", to convince >> ImageMagick's >> `convert` to fall back to using `rsvgconvert`... >> >> ...or by simply looking at the filename extension of what's being fed to >> the script by Makefile (we control these files, they are the ones that >> ship with the source .tar.gz), and either run ImageMagick's `convert` if >> it's a PNG file, or `rsvgconvert` _directly_ if it's an SVG file. >> >> Another idea I mulled over was somehow overriding ImageMagick's >> delegate for SVG, or adding a new delegate and using some kind of prefix, >> but (1) this is getting way over complicated (compared to a tiny .sh >> script), >> and (2) I'm not [very quickly] figuring out how to do that, or whether it's >> even possible. (Apparently, ImageMagick can look at a user's personal >> delegates file, but we'd want it to be even _more_ "local" than that, >> a file right inside the `tuxpaint` source tree somewhere.) >> (Basically, after a minute of Googling, I gave up trying to find out. ;) ) >> >> -bill! >> >> > >> > Thanks. >> > >> > On Thu, 15 Jun 2023 23:03:20 +0900, Shin-ichi TOYAMA wrote: >> > >On Tue, 13 Jun 2023 22:20:40 -0700, Bill Kendrick wrote: >> > >>> By the way, I had to revert the commit >> "cf94635713b9dc7977af131a6b3ec89cc872d0e1" >> > >>> to build Tux Paint on Windows from current git repo because of the >> error as follows. >> > >> >> > >>Ah, I wonder if adding quotes would help. (I get the feeling the "(" >> in question >> > >>might be from the "(x86)"?) >> > > >> > >Sure, I confirmed that the parentheses and whitespaces in the PATH, >> which are common >> > >on Windows, are the evil. >> > > >> > >>Does >> https://sourceforge.net/p/tuxpaint/tuxpaint/ci/7febf719d02e9c78d4554d2388d793726e19b0af/ >> > >>help? >> > > >> > >Unfortunately it doesn't. >> > > >> > >I confirmed that not using 'eval' causes no error after trial and error >> aproach, but >> > >I'm not sure if it is a right way or not. >> > > >> > >---------------------------------------------------- >> > >- @(eval export PATH="$(shell pwd)":"$(PATH)") >> > >+ @export PATH="$(shell pwd)":"$(PATH)" >> > >---------------------------------------------------- >> > > >> > > >> > >_______________________________________________ >> > >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 >> >> -- >> -bill! >> Sent from my computer >> >> >> _______________________________________________ >> Tuxpaint-devel mailing list >> Tux...@li... >> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel >> -- Shin-ichi TOYAMA <dol...@wm...> |
From: Mark K. <mar...@gm...> - 2023-06-16 18:55:33
|
Would this work? diff --git a/Makefile b/Makefile index 331604b1..f5b1497f 100644 --- a/Makefile +++ b/Makefile @@ -886,7 +886,7 @@ echo-thumb-starters: @echo "# Don't let ImageMagick use Inkscape; use rsvgconvert instead" > ./inkscape @echo "exit 1" >> ./inkscape @chmod 755 ./inkscape - @(eval export PATH="$(shell pwd)":"$(PATH)") + $(eval export PATH=$(shell pwd):$(PATH)) # Create thumbnails for starters .PHONY: thumb-starters On Fri, Jun 16, 2023 at 2:00 PM Bill Kendrick <nb...@so...> wrote: > On Fri, Jun 16, 2023 at 06:01:02PM +0900, Shin-ichi TOYAMA wrote: > > Hi! > > > > As a workaround on my build environment, I've purged paths containing > > spaces and parentheses from the "$PATH" and added paths of symbolic > > links from /usr/local/* to actual directories. > > > > It looks O.K. so far. > > Thanks. > > I was actually just thinking out loud in an email to Tim, suggesting > perhaps > we can just create our own tiny shell script that gets invoked > (call it, say, `./convert-wrapper.sh`) rather than the `convert` in $PATH, > so we can have full control over how it works... > > ...either by doing a similar "inkscape => exit 1", to convince > ImageMagick's > `convert` to fall back to using `rsvgconvert`... > > ...or by simply looking at the filename extension of what's being fed to > the script by Makefile (we control these files, they are the ones that > ship with the source .tar.gz), and either run ImageMagick's `convert` if > it's a PNG file, or `rsvgconvert` _directly_ if it's an SVG file. > > Another idea I mulled over was somehow overriding ImageMagick's > delegate for SVG, or adding a new delegate and using some kind of prefix, > but (1) this is getting way over complicated (compared to a tiny .sh > script), > and (2) I'm not [very quickly] figuring out how to do that, or whether it's > even possible. (Apparently, ImageMagick can look at a user's personal > delegates file, but we'd want it to be even _more_ "local" than that, > a file right inside the `tuxpaint` source tree somewhere.) > (Basically, after a minute of Googling, I gave up trying to find out. ;) ) > > -bill! > > > > > Thanks. > > > > On Thu, 15 Jun 2023 23:03:20 +0900, Shin-ichi TOYAMA wrote: > > >On Tue, 13 Jun 2023 22:20:40 -0700, Bill Kendrick wrote: > > >>> By the way, I had to revert the commit > "cf94635713b9dc7977af131a6b3ec89cc872d0e1" > > >>> to build Tux Paint on Windows from current git repo because of the > error as follows. > > >> > > >>Ah, I wonder if adding quotes would help. (I get the feeling the "(" > in question > > >>might be from the "(x86)"?) > > > > > >Sure, I confirmed that the parentheses and whitespaces in the PATH, > which are common > > >on Windows, are the evil. > > > > > >>Does > https://sourceforge.net/p/tuxpaint/tuxpaint/ci/7febf719d02e9c78d4554d2388d793726e19b0af/ > > >>help? > > > > > >Unfortunately it doesn't. > > > > > >I confirmed that not using 'eval' causes no error after trial and error > aproach, but > > >I'm not sure if it is a right way or not. > > > > > >---------------------------------------------------- > > >- @(eval export PATH="$(shell pwd)":"$(PATH)") > > >+ @export PATH="$(shell pwd)":"$(PATH)" > > >---------------------------------------------------- > > > > > > > > >_______________________________________________ > > >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 > > -- > -bill! > Sent from my computer > > > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > |
From: Bill K. <nb...@so...> - 2023-06-16 18:00:00
|
On Fri, Jun 16, 2023 at 06:01:02PM +0900, Shin-ichi TOYAMA wrote: > Hi! > > As a workaround on my build environment, I've purged paths containing > spaces and parentheses from the "$PATH" and added paths of symbolic > links from /usr/local/* to actual directories. > > It looks O.K. so far. Thanks. I was actually just thinking out loud in an email to Tim, suggesting perhaps we can just create our own tiny shell script that gets invoked (call it, say, `./convert-wrapper.sh`) rather than the `convert` in $PATH, so we can have full control over how it works... ...either by doing a similar "inkscape => exit 1", to convince ImageMagick's `convert` to fall back to using `rsvgconvert`... ...or by simply looking at the filename extension of what's being fed to the script by Makefile (we control these files, they are the ones that ship with the source .tar.gz), and either run ImageMagick's `convert` if it's a PNG file, or `rsvgconvert` _directly_ if it's an SVG file. Another idea I mulled over was somehow overriding ImageMagick's delegate for SVG, or adding a new delegate and using some kind of prefix, but (1) this is getting way over complicated (compared to a tiny .sh script), and (2) I'm not [very quickly] figuring out how to do that, or whether it's even possible. (Apparently, ImageMagick can look at a user's personal delegates file, but we'd want it to be even _more_ "local" than that, a file right inside the `tuxpaint` source tree somewhere.) (Basically, after a minute of Googling, I gave up trying to find out. ;) ) -bill! > > Thanks. > > On Thu, 15 Jun 2023 23:03:20 +0900, Shin-ichi TOYAMA wrote: > >On Tue, 13 Jun 2023 22:20:40 -0700, Bill Kendrick wrote: > >>> By the way, I had to revert the commit "cf94635713b9dc7977af131a6b3ec89cc872d0e1" > >>> to build Tux Paint on Windows from current git repo because of the error as follows. > >> > >>Ah, I wonder if adding quotes would help. (I get the feeling the "(" in question > >>might be from the "(x86)"?) > > > >Sure, I confirmed that the parentheses and whitespaces in the PATH, which are common > >on Windows, are the evil. > > > >>Does https://sourceforge.net/p/tuxpaint/tuxpaint/ci/7febf719d02e9c78d4554d2388d793726e19b0af/ > >>help? > > > >Unfortunately it doesn't. > > > >I confirmed that not using 'eval' causes no error after trial and error aproach, but > >I'm not sure if it is a right way or not. > > > >---------------------------------------------------- > >- @(eval export PATH="$(shell pwd)":"$(PATH)") > >+ @export PATH="$(shell pwd)":"$(PATH)" > >---------------------------------------------------- > > > > > >_______________________________________________ > >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 -- -bill! Sent from my computer |
From: Shin-ichi T. <dol...@wm...> - 2023-06-16 09:01:19
|
Hi! As a workaround on my build environment, I've purged paths containing spaces and parentheses from the "$PATH" and added paths of symbolic links from /usr/local/* to actual directories. It looks O.K. so far. Thanks. On Thu, 15 Jun 2023 23:03:20 +0900, Shin-ichi TOYAMA wrote: >On Tue, 13 Jun 2023 22:20:40 -0700, Bill Kendrick wrote: >>> By the way, I had to revert the commit "cf94635713b9dc7977af131a6b3ec89cc872d0e1" >>> to build Tux Paint on Windows from current git repo because of the error as follows. >> >>Ah, I wonder if adding quotes would help. (I get the feeling the "(" in question >>might be from the "(x86)"?) > >Sure, I confirmed that the parentheses and whitespaces in the PATH, which are common >on Windows, are the evil. > >>Does https://sourceforge.net/p/tuxpaint/tuxpaint/ci/7febf719d02e9c78d4554d2388d793726e19b0af/ >>help? > >Unfortunately it doesn't. > >I confirmed that not using 'eval' causes no error after trial and error aproach, but >I'm not sure if it is a right way or not. > >---------------------------------------------------- >- @(eval export PATH="$(shell pwd)":"$(PATH)") >+ @export PATH="$(shell pwd)":"$(PATH)" >---------------------------------------------------- > > >_______________________________________________ >Tuxpaint-devel mailing list >Tux...@li... >https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel -- Shin-ichi TOYAMA <dol...@wm...> |
From: Shin-ichi T. <dol...@wm...> - 2023-06-15 14:03:31
|
On Tue, 13 Jun 2023 22:20:40 -0700, Bill Kendrick wrote: >> By the way, I had to revert the commit "cf94635713b9dc7977af131a6b3ec89cc872d0e1" >> to build Tux Paint on Windows from current git repo because of the error as follows. > >Ah, I wonder if adding quotes would help. (I get the feeling the "(" in question >might be from the "(x86)"?) Sure, I confirmed that the parentheses and whitespaces in the PATH, which are common on Windows, are the evil. >Does https://sourceforge.net/p/tuxpaint/tuxpaint/ci/7febf719d02e9c78d4554d2388d793726e19b0af/ >help? Unfortunately it doesn't. I confirmed that not using 'eval' causes no error after trial and error aproach, but I'm not sure if it is a right way or not. ---------------------------------------------------- - @(eval export PATH="$(shell pwd)":"$(PATH)") + @export PATH="$(shell pwd)":"$(PATH)" ---------------------------------------------------- |
From: Bill K. <nb...@so...> - 2023-06-14 07:20:50
|
I've added a "[manual]" entry to the list of UI fonts in Tux Paint Config. If you select it, a type-in field appears below which allows you to enter a price font name. Useful in case Pango isn't showing you the font (perhaps you're using TPC on one machine to make a config to share on a set of other machines with different fonts installed?!) Also, as you type, if any fonts in the list DO match (basic strcasestr() comparison), they will be made visible, encouraging you to just click in the selection box, if they match what you're looking for. (e.g., type "free" and you'll see "FreeMono", "FreeSans", and "FreeSerif" appear.) It's not super complicated. It IS a lot better than trying to use Fl_Input_Choice pulldown menu for this. (On my system, any pulldown showing my fonts is a mile long!) Note: If the manually-entered font matches a font actually found by pango, then the next time you launch Tux Paint Config., it will be simply selected in the menu. However, if the "uifont" setting doesn't match any of the fonts found by pango, the menu will automatically have "[manual]" selected, and the font's name entered in the type-in field. Hope that all makes sense... I'm pretty beat & need to get to bed! -- -bill! Sent from my computer |
From: Bill K. <nb...@so...> - 2023-06-14 05:20:49
|
On Wed, Jun 14, 2023 at 12:00:10AM +0900, Shin-ichi TOYAMA wrote: <snip> > >Mark, Shin-ichi, and Luc, please bang on these things macOS, Windows, > >and Haiku! Thanks. > > I confirmed everything looks O.K. on Windows. Great, thanks! > Thank you for your great effort to handle this!! Glad I figured it out. I gave up at one point yesterday, then somehow had a breakthrough, heh. :) > By the way, I had to revert the commit "cf94635713b9dc7977af131a6b3ec89cc872d0e1" > to build Tux Paint on Windows from current git repo because of the error as follows. Ah, I wonder if adding quotes would help. (I get the feeling the "(" in question might be from the "(x86)"?) Does https://sourceforge.net/p/tuxpaint/tuxpaint/ci/7febf719d02e9c78d4554d2388d793726e19b0af/ help? -bill! > --------------- > ...Generating thumbnails for starters... > /bin/sh: -c: line 1: syntax error near unexpected token `(' > /bin/sh: -c: line 1: `(eval export PATH=/c/Users/shin1/home/tuxpaint/tuxpaint:/c/Program Files (x86)/Inno Setup 6:/c/Program Files/ImageMagick:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/c/bin/:/c/xyzzy/:/c/Program Files/nodejs/)' > make[1]: *** [Makefile:889: echo-thumb-starters] Error 2 > make[1]: Leaving directory '/c/Users/shin1/home/tuxpaint/tuxpaint' > make: *** [Makefile:689: bdist-win32] Error 2 > --------------- > > I will look into it when I have time. > > Thanks! |
From: Bill K. <nb...@so...> - 2023-06-14 05:05:20
|
On Tue, Jun 13, 2023 at 06:27:16PM -0400, Mark Kim wrote: > Confirmed it builds & runs fine on macOS! > > (More specifically, it has no effect on macOS so macOS still requires this > commit > <https://sourceforge.net/p/tuxpaint/tuxpaint-config/ci/4cfd3155c5282ffa3f260af05d2a30fa1027da95/> > .) Thanks! Okay, I won't remove it then, heh. I have a feeling this will also be useful for Tux Paint portable ZIP version on Windows, right Shin-ichi? I made a few tweaks, to help keep maintenance of the list easy. -- -bill! Sent from my computer |
From: Mark K. <mar...@gm...> - 2023-06-13 22:27:40
|
On Tue, Jun 13, 2023 at 3:53 AM Bill Kendrick <nb...@so...> wrote: > Mark, Shin-ichi, and Luc, please bang on these things macOS, Windows, > and Haiku! Thanks. > Confirmed it builds & runs fine on macOS! (More specifically, it has no effect on macOS so macOS still requires this commit <https://sourceforge.net/p/tuxpaint/tuxpaint-config/ci/4cfd3155c5282ffa3f260af05d2a30fa1027da95/> .) Thanks, Mark |
From: Shin-ichi T. <dol...@wm...> - 2023-06-13 15:00:20
|
On Tue, 13 Jun 2023 00:52:57 -0700, Bill Kendrick wrote: >And done. (This required adding a "TUXPAINT_DATA_PREFIX" to TPC's >Makefile, so there's a lot of assumptions going on here! I also have >no clue how this will play with, e.g., the macOS version :-/ ) > >It all seems to work for me on Linux, which is a start. > >And I _believe_ I've got the default locale fonts all rigged up >properly by giving their family names in `fonts.c` (whereas back >in the SDL_ttf days, we'd just try to load "<locale_code>.ttf"). > >*Whew!* > > >Mark, Shin-ichi, and Luc, please bang on these things macOS, Windows, >and Haiku! Thanks. I confirmed everything looks O.K. on Windows. Thank you for your great effort to handle this!! By the way, I had to revert the commit "cf94635713b9dc7977af131a6b3ec89cc872d0e1" to build Tux Paint on Windows from current git repo because of the error as follows. --------------- ...Generating thumbnails for starters... /bin/sh: -c: line 1: syntax error near unexpected token `(' /bin/sh: -c: line 1: `(eval export PATH=/c/Users/shin1/home/tuxpaint/tuxpaint:/c/Program Files (x86)/Inno Setup 6:/c/Program Files/ImageMagick:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/c/bin/:/c/xyzzy/:/c/Program Files/nodejs/)' make[1]: *** [Makefile:889: echo-thumb-starters] Error 2 make[1]: Leaving directory '/c/Users/shin1/home/tuxpaint/tuxpaint' make: *** [Makefile:689: bdist-win32] Error 2 --------------- I will look into it when I have time. Thanks! -- Shin-ichi TOYAMA <dol...@wm...> |
From: Bill K. <nb...@so...> - 2023-06-13 07:53:05
|
(Removing i18n list from this thread, since I've gotten us into the development weeds.) On Mon, Jun 12, 2023 at 11:55:37PM -0700, Bill Kendrick wrote: <snip> > 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). Done. > 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). And done. (This required adding a "TUXPAINT_DATA_PREFIX" to TPC's Makefile, so there's a lot of assumptions going on here! I also have no clue how this will play with, e.g., the macOS version :-/ ) It all seems to work for me on Linux, which is a start. And I _believe_ I've got the default locale fonts all rigged up properly by giving their family names in `fonts.c` (whereas back in the SDL_ttf days, we'd just try to load "<locale_code>.ttf"). *Whew!* Mark, Shin-ichi, and Luc, please bang on these things macOS, Windows, and Haiku! Thanks. -- -bill! Sent from my computer |
From: Bill K. <nb...@so...> - 2023-06-13 06:55:45
|
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! |
From: Bill K. <nb...@so...> - 2023-06-13 05:18:41
|
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! |
From: Bill K. <nb...@so...> - 2023-06-13 04:18:07
|
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 |
From: Mark K. <mar...@gm...> - 2023-06-10 22:26:37
|
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 > |
From: Shin-ichi T. <dol...@wm...> - 2023-06-10 13:33:16
|
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...> |
From: Bill K. <nb...@so...> - 2023-06-09 18:30:03
|
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 |