tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] [Tuxpaint-users] Tux Paint 0.9.27 beta releases

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

On Fri, Nov 19, 2021 at 11:31:33PM -0800, Bill Kendrick wrote:
> On Sat, Nov 20, 2021 at 11:14:45AM +0800, ���� wrote:
> > Hi amazing release cycle!
> > 
> > 
> > May I know whether the flood fill issue fixed?
> > I just tested the windows installer 0.9.27 but still crashed. following is windows log:
> <snip>
> 
> Unfortunately, no.  I decided to leave things as-is,
> rather than overhaul the Fill routine and potentially
> break things for a while, and delay a new release. :)

Sorry, I lied! ;-D

  https://sourceforge.net/p/tuxpaint/tuxpaint/ci/5cfc185d77edd075e4ba3d3bb3255aa6c6185869/

First off, I started taking another approach: trying to
improve the existing recursive code.

 * be more conservative when recursively calling the
   flood fill above and below points on the current
   scanline; only do so if we hadn't already done it
   on the previous (to the left) pixel; if that color
   matched, then we'll have already scanned that row
   and found that (adjacent) the pixel anyway

 * reduce how much I drop onto the stack, each call of
   the recursive function sent a LOT of arguments that
   were never changing (or being modified in a global
   way, e.g. the (x1,y1)->(x2,y2) extent of how much
   of the canvas is being updated, or the `touched[]`
   array)

 * don't call the progress bar animation or sound-playing
   (in the end, SDL_Mixer) routines as frequently
   (when it was really busy filling, it did't sound
   right anyway!)

All of these changes allowed me to successfully fill the
starter image Yang and Pere reported as troublesome
("mosaic.svg") in a 3000x2000 window on my Linux laptop!

However, when I ~quadrupled the complexity of the image,
by using the new "Panels" magic tool to duplicate the
image four times, in a 2x2 grid (which of course ends up
overlaid with the original starter image), Tux Paint would
crash for me.  It was recursing about 70,000 times!

But, at this point, I realized the recursive call was
greatly simplified, and I could more easily apply a queue
to the process (versus recursion), aka the "span fill"
algorithm.

So instead of:

  call A(x, y)

  define A() as:
    fill as far left & right on this row as we can

    for each postion "i" we filled (from left to right)
      call A(i, y - 1)
      call A(i, y + 1)

I now do:

  add (x,y) to the queue

  while the queue isn't empty
    get an (x,y) from the queue
    call A(x,y)

  define A() as:
    fill as far left & right on this row as we can

    for each postion "i" we filled (from left to right)
      add (i, y - 1) to the queue
      add (i, y + 1) to the queue

(More or less)


Right now, it DOES eat up a bunch of heap space, by allocating
(and reallocating, to enlarge) the queue structure.  It only frees
it at the end of the fill process.

However, I'll see if I can get it to be smarter, and allow the queue
to shrink, probably by treating it as a stack.  (It doesn't actually
matter whether it's a queue or a stack, in the computer science
meaning of the terms.)

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] [Tuxpaint-i18n] Preparing to release Tux Paint 0.9.27

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

On Fri, Nov 19, 2021 at 09:45:51AM +0000, Sveinn í Felli wrote:
> Hi Bill,
> 
> Here are updated Icelandic files.

Committed, thanks!

-bill!

Re: [Tuxpaint-devel] [Tuxpaint-maintainers] Preparing to release Tux Paint 0.9.27

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

On Fri, Nov 19, 2021 at 2:57 AM Bill Kendrick <nb...@so...> wrote:

>  * Maintainers & developers, please build from Git master and let me
>    know if anything needs to be updated prior to a final release of
>    0.9.27.
>

macOS builds are here:

   - https://dl.cbreak.org/TuxPaint-0.9.27beta-20211119.dmg
   - https://dl.cbreak.org/TuxPaint-Config-0.0.18beta-20211119.dmg

Thanks,
Mark

Re: [Tuxpaint-devel] [Tuxpaint-i18n] Preparing to release Tux Paint 0.9.27

[Sveinn í F. <sv...@fe...>]

Hi Bill,

Here are updated Icelandic files.

Best regards,

Sveinn í Felli

Re: [Tuxpaint-devel] Preparing to release Tux Paint 0.9.27

[TOYAMA Shin-i. <sh...@wm...>]

Hi!

Test builds for windows and rpm-based linux distributions are 
ready.

Windows:

  https://z1.plala.jp/tuxpaint/testing/20211119/windows/

Linux RPMs: (including new dependency 'libunibreak' for tp-conf)

  https://z1.plala.jp/tuxpaint/testing/20211119/rpms/

Please give them a try!!

Bill Kendrick wrote in <202...@sh...>
>I'd like to release Tux Paint 0.9.27 soon.  A LOT of stuff has
>happened since 0.9.26 came out, less than 5 months ago!
>(And can you believe it?  We're only 7 months away from Tux Paint's
>_20th birthday!_)
>
>TL;DR:
>
> * Maintainers & developers, please build from Git master and let me
>   know if anything needs to be updated prior to a final release of
>   0.9.27.
>
> * Translators, please send me any updated PO files ASAP, so I can
>   include them in 0.9.27.  (Also, the website has some updates,
>   including text for a new Gallery (see below), and the press release
>   for 0.9.27 itself!)
>
>
>Here's an overview of all the great new stuff coming in 0.9.27:
>
>We've added 6 new Magic tools, updated 6 others, and split them all
>into groups.
>
>The Paint and Line tools now support brushes which can be drawn at any
>angle (not just 8 directions), and small badges/icons indicate when a
>brush supports direction/rotation and/or animation.
>
>The Line and Shapes tool tell you what angle you're drawing at (useful
>for simple geometry?).  And the Fill tool now offers an interactive
>freehand ("brush") mode.
>
>Tux Paint Config. has been overhauled, providing a better experience
>(larger text and widgets in a bigger window on modern displays),
>and options for how Tux Paint should behave when it comes across
>settings in both the system-wide ("All Users") config. file, and
>the user's local config. file.
>
>Tux Paint supports the Recycle Bin on Windows (it already supported
>Trash on Freedesktop platforms like Linux + GNOME or KDE), rather
>than deleting a picture immediately.
>
>Tux Paint's documentation has been further updated.  The Options docs
>has been reorganized to match where things appear in Tux Paint Config.,
>and the "--help" output, Unix manpage, and bash shell tab completion
>covers all available options.  Table of contents have been added to
>the HTML documentation, and the manpage and Magic tool docs are now
>translatable. (See the POT and PO files!)
>
>A number of bug fixes and build-related changes have also been made
>(special thanks to Mark K. Kim and TOYAMA Shin-ichi for lots of work
>in that department).  And we have very few warnings cluttering the
>output when compiling.
>
>Finally, I've created a completely new gallery section of the website,
>showcasing what I've picked as the most impressive and unique artwork.
>(It's a combination of things that were already in the old gallery;
>pictures submitted for, but never added to, the old gallery; plus new
>stuff I've come across on Twitter.)
>
>
>So, like I said up top -- please build and test things, and let me
>know if you have any issues.  And please update your translations
>and send them to me, if you can.
>
>Thanks, everyone, for all your support!

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

[Tuxpaint-devel] Preparing to release Tux Paint 0.9.27

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

I'd like to release Tux Paint 0.9.27 soon.  A LOT of stuff has
happened since 0.9.26 came out, less than 5 months ago!
(And can you believe it?  We're only 7 months away from Tux Paint's
_20th birthday!_)

TL;DR:

 * Maintainers & developers, please build from Git master and let me
   know if anything needs to be updated prior to a final release of
   0.9.27.

 * Translators, please send me any updated PO files ASAP, so I can
   include them in 0.9.27.  (Also, the website has some updates,
   including text for a new Gallery (see below), and the press release
   for 0.9.27 itself!)


Here's an overview of all the great new stuff coming in 0.9.27:

We've added 6 new Magic tools, updated 6 others, and split them all
into groups.

The Paint and Line tools now support brushes which can be drawn at any
angle (not just 8 directions), and small badges/icons indicate when a
brush supports direction/rotation and/or animation.

The Line and Shapes tool tell you what angle you're drawing at (useful
for simple geometry?).  And the Fill tool now offers an interactive
freehand ("brush") mode.

Tux Paint Config. has been overhauled, providing a better experience
(larger text and widgets in a bigger window on modern displays),
and options for how Tux Paint should behave when it comes across
settings in both the system-wide ("All Users") config. file, and
the user's local config. file.

Tux Paint supports the Recycle Bin on Windows (it already supported
Trash on Freedesktop platforms like Linux + GNOME or KDE), rather
than deleting a picture immediately.

Tux Paint's documentation has been further updated.  The Options docs
has been reorganized to match where things appear in Tux Paint Config.,
and the "--help" output, Unix manpage, and bash shell tab completion
covers all available options.  Table of contents have been added to
the HTML documentation, and the manpage and Magic tool docs are now
translatable. (See the POT and PO files!)

A number of bug fixes and build-related changes have also been made
(special thanks to Mark K. Kim and TOYAMA Shin-ichi for lots of work
in that department).  And we have very few warnings cluttering the
output when compiling.

Finally, I've created a completely new gallery section of the website,
showcasing what I've picked as the most impressive and unique artwork.
(It's a combination of things that were already in the old gallery;
pictures submitted for, but never added to, the old gallery; plus new
stuff I've come across on Twitter.)


So, like I said up top -- please build and test things, and let me
know if you have any issues.  And please update your translations
and send them to me, if you can.

Thanks, everyone, for all your support!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] All control are disabled when starting TPCONF

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

On Fri, Nov 19, 2021 at 11:51:37AM +0900, TOYAMA Shin-ichi wrote:
> Hi!
> 
> While preparing beta RPM releases for tuxpaint-config, I noticed
> that and all controls in all tabs are initially disabled.
> 
> By default, it comes with 'Current User' selected for 'Settings 
> for:' and 'Merged with User Settings' selected for 'Effects of 
> "All Users" Settings'.

Okay, fixed, I think!  (Also added a lot of comments to try
and keep track fo what was happening.)

I also mended a bunch of places where widgets were not getting
reset to their defaults when you asked them to (my fault; I added
or moved around some settings in TPC, and forgot to make sure
they responded to the "Defaults" buttons being pushed).
Or, in a couple cases, a slider would be reset, but the label
below it would remain out-of-date (e.g., "Button size" didn't
reset to show the numbers "48x48" even though the slider reset.)

Feel free to test it out and let me know if anything is
still acting weird.

Thanks!

-bill!

Re: [Tuxpaint-devel] All control are disabled when starting TPCONF

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

Confirmed!  I'll investigate, thanks.  I guess it wasn't
happening for me since I had a ~/.tuxpaintrc.  After I deleted it,
I saw the same behavior.

Hopefully, this will be the last thing to sort out[*] and
we can make a new release at last!

Thanks,

-bill!
[*] I need to rework the Fill routine, but I don't want to
    risk overhauling it, breaking things, and delaying the
    release. :)


On Fri, Nov 19, 2021 at 11:51:37AM +0900, TOYAMA Shin-ichi wrote:
> Hi!
> 
> While preparing beta RPM releases for tuxpaint-config, I noticed
> that and all controls in all tabs are initially disabled.
> 
> By default, it comes with 'Current User' selected for 'Settings 
> for:' and 'Merged with User Settings' selected for 'Effects of 
> "All Users" Settings'.
> 
> Then, once I changed the selection 'Effects of "All Users"
> Settings' to one of others, thay all enabled and thay remain 
> enabled even if I change the selection to 'Merged with User 
> Settings'.
> 
> Might there be something wrong in initial settings ?
> 
> -- 
> TOYAMA Shin-ichi mailto:sh...@wm...
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] All control are disabled when starting TPCONF

[TOYAMA Shin-i. <sh...@wm...>]

Hi!

While preparing beta RPM releases for tuxpaint-config, I noticed
that and all controls in all tabs are initially disabled.

By default, it comes with 'Current User' selected for 'Settings 
for:' and 'Merged with User Settings' selected for 'Effects of 
"All Users" Settings'.

Then, once I changed the selection 'Effects of "All Users"
Settings' to one of others, thay all enabled and thay remain 
enabled even if I change the selection to 'Merged with User 
Settings'.

Might there be something wrong in initial settings ?

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] [Tuxpaint-maintainers] Moving from SDL 1.2 to SDL 2.0

[TOYAMA Shin-i. <sh...@wm...>]

Hi Bill,

Bill Kendrick wrote in <202...@sh...>
>My plan, however, is to release the NEXT version of Tux Paint,
>which includes a lot of new features (new Magic tools, and the
>Magic tool grouping functionality) using the SDL1.2 branch.
>This will be 0.9.27.
>
>Then, more-or-less immediately, we can try releasing an SDL2.0
>version, that adds no new features to Tux Paint itself.
>This will be 0.9.28.

Are you still on this track?

I tried to build current sdl2.0 blanch on windows.

It looks almost fine but I found that onscreen-keyboard does not 
work correctly with compose function.

Just a status report for now.

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Using libtextwrap in Tux Paint Config.

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

On Tue, Nov 16, 2021 at 6:21 PM Bill Kendrick <nb...@so...> wrote:

> On Wed, Nov 17, 2021 at 08:18:58AM +0900, TOYAMA Shin-ichi wrote:
> > Hi!
> >
> > Mark K. Kim wrote in <CADZCvhDbopRbYUD02UC86gdPfG+=
> ojW...@ma...>
> > >However, the latest build is cutting off the top half of the tabs.
> > >Screenshot below:
> > >[image: Screen Shot 2021-11-16 at 5.27.06 PM.png]
> >
> > Could you try changing the value of 'y' at line 2235 of
> > tuxpaint-config2.cxx ?
>
> Might it be suitable to just kill this whole __APPLE__ block?
>

That worked. It looks like Shin-ichi already commited the change. Thanks!


> #ifdef __APPLE__
>     o = WINDOW_tpc =
>       new Fl_Double_Window(width, height,
>                            gettext("Tux Paint Config v" VER_VERSION));
>     y = 20;                     /* vertical offset to account for lack of
> menu bar at top of window */
> #else
>     o = WINDOW_tpc =
>       new Fl_Double_Window(width - 6, height,
>                            gettext("Tux Paint Config v" VER_VERSION));
> #endif
>

Re: [Tuxpaint-devel] Using libtextwrap in Tux Paint Config.

[TOYAMA Shin-i. <sh...@wm...>]

Hi!

It looks perfect now.
Thanks!!

Bill Kendrick wrote in <202...@sh...>
>On Wed, Nov 17, 2021 at 12:06:05AM +0900, TOYAMA Shin-ichi wrote:
>> TOYAMA Shin-ichi wrote in <6193bf09.5035%sh...@wm...>
>> >I think there is no problem now.
>> 
>> Ah..
>> 
>> I've missed something.
>> 
>> Texts in the section "Keyboard" are not neccesarily wrapped after 
>> ascii characters. (see attached)
>> 
>> Sorry for bothering you again and again.
>
>No problem!
>
>I wrote up a bit long reply, as I was investigating things, then
>had a "bright idea" (read: "dumb solution") on how to fix it,
>and just committed it:
>
>  
>https://sourceforge.net/p/tuxpaint/tuxpaint-config/ci/0cdb8a961058f1ad1078dafecca69c8ccd612b8b/
>
>I hope the commit message and comments in the code are sufficient
>to explain what's happening, but let me know if you have any
>questions.  And, of course, it if seems to make things _worse_,
>let me know!

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Using libtextwrap in Tux Paint Config.

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

On Wed, Nov 17, 2021 at 08:18:58AM +0900, TOYAMA Shin-ichi wrote:
> Hi!
> 
> Mark K. Kim wrote in <CAD...@ma...>
> >However, the latest build is cutting off the top half of the tabs.
> >Screenshot below:
> >[image: Screen Shot 2021-11-16 at 5.27.06 PM.png]
> 
> Could you try changing the value of 'y' at line 2235 of 
> tuxpaint-config2.cxx ?

Might it be suitable to just kill this whole __APPLE__ block?


#ifdef __APPLE__
    o = WINDOW_tpc =
      new Fl_Double_Window(width, height,
                           gettext("Tux Paint Config v" VER_VERSION));
    y = 20;                     /* vertical offset to account for lack of menu bar at top of window */
#else
    o = WINDOW_tpc =
      new Fl_Double_Window(width - 6, height,
                           gettext("Tux Paint Config v" VER_VERSION));
#endif


-bill!

Re: [Tuxpaint-devel] Using libtextwrap in Tux Paint Config.

[TOYAMA Shin-i. <sh...@wm...>]

Hi!

Mark K. Kim wrote in <CAD...@ma...>
>However, the latest build is cutting off the top half of the tabs.
>Screenshot below:
>[image: Screen Shot 2021-11-16 at 5.27.06 PM.png]

Could you try changing the value of 'y' at line 2235 of 
tuxpaint-config2.cxx ?


-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Using libtextwrap in Tux Paint Config.

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

On Wed, Nov 17, 2021 at 12:06:05AM +0900, TOYAMA Shin-ichi wrote:
> TOYAMA Shin-ichi wrote in <6193bf09.5035%sh...@wm...>
> >I think there is no problem now.
> 
> Ah..
> 
> I've missed something.
> 
> Texts in the section "Keyboard" are not neccesarily wrapped after 
> ascii characters. (see attached)
> 
> Sorry for bothering you again and again.

No problem!

I wrote up a bit long reply, as I was investigating things, then
had a "bright idea" (read: "dumb solution") on how to fix it,
and just committed it:

  https://sourceforge.net/p/tuxpaint/tuxpaint-config/ci/0cdb8a961058f1ad1078dafecca69c8ccd612b8b/

I hope the commit message and comments in the code are sufficient
to explain what's happening, but let me know if you have any
questions.  And, of course, it if seems to make things _worse_,
let me know!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Using libtextwrap in Tux Paint Config.

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

On Tue, Nov 16, 2021 at 5:14 PM Bill Kendrick <nb...@so...> wrote:

> On Tue, Nov 16, 2021 at 02:12:47PM -0800, Bill Kendrick wrote:
> <snip>
> > Thanks.  I'd be curious to know about any warnings you get while
> > compiling Tux Paint from source.
>
> And, of course, I meant "Tux Paint Config.", not "Tux Paint" :)
> Brain hiccup!


There are no warnings or errors during compilation. Good job!

However, the latest build is cutting off the top half of the tabs.
Screenshot below:
[image: Screen Shot 2021-11-16 at 5.27.06 PM.png]

Re: [Tuxpaint-devel] Using libtextwrap in Tux Paint Config.

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

On Tue, Nov 16, 2021 at 11:51:13PM +0900, TOYAMA Shin-ichi wrote:
> By the way, do we really need scroll bar on "Main device" section 
> in the "Joystick" tab?

Not always, but in a small window, under the Japanese locale, the
labels were so long that it was overflowing that top left box.

It's klugy, but I'm fine leaving it as-is for now.  I'd love to
get a new release out the door this year, heheh!

-bill!

Re: [Tuxpaint-devel] Using libtextwrap in Tux Paint Config.

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

On Tue, Nov 16, 2021 at 02:12:47PM -0800, Bill Kendrick wrote:
<snip>
> Thanks.  I'd be curious to know about any warnings you get while
> compiling Tux Paint from source.

And, of course, I meant "Tux Paint Config.", not "Tux Paint" :)
Brain hiccup!

> We cleaned up a lot of the codebase
> to avoid 'meaningless' warnings (like all of the unused func. arguments
> in a lot of Magic tools), and of course try to fix up the meaningful ones.

Most of the clean-up was in TP, but I'm sure we probably did
some in TPC as well.

-bill!

Re: [Tuxpaint-devel] Using libtextwrap in Tux Paint Config.

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

On Tue, Nov 16, 2021 at 08:51:10AM -0500, Mark K. Kim wrote:
> Hi Bill,
> 
> On Mon, Nov 15, 2021 at 03:05:42PM -0800, Bill Kendrick wrote:
> > Mark, can you confirm that this library will build fine for you
> > on macOS?
> 
> The library was built from https://github.com/adah1972/libunibreak without
> any trouble using autogen.sh.

Great!


> Compiling your test code, linebreak-test.c, though, required some extra
> flags.  Most of the flags are supplied by pkg-config, so using pkg-config
> in Makefile if we use this library in Tux Paint would be preferable to
> directly passing `-l unibreak`.

Ah whoops, I forgot to try that!  (I _did_ try with libtextwrap, but there
was nothing available via pkg-config)


>  `-l libiconv` also needed to be passed
> manually but I think we already do this in Tux Paint Makefile.  The
> resulting output is below.

Thanks.  I'd be curious to know about any warnings you get while
compiling Tux Paint from source.  We cleaned up a lot of the codebase
to avoid 'meaningless' warnings (like all of the unused func. arguments
in a lot of Magic tools), and of course try to fix up the meaningful ones.

I'll go add the pkg-config stuff to Makefile right now :)

-bill!

Re: [Tuxpaint-devel] Using libtextwrap in Tux Paint Config.

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

On Tue, Nov 16, 2021 at 07:57:06PM +0100, Karl Ove Hufthammer wrote:
> Bill Kendrick skreiv 15.11.2021 10:40:
> >Oh, libunibreak might be useful.  As with libtextwrap, I see it's
> >available in Ubuntu 20.04.  However, before I make any more tectonic
> >shifts in the Tux Paint Config. codebase, I'd better make sure it's
> >available everywhere.:)
> 
> I can confirm that libunibreak is available in openSUSE.

Excellent!

-bill!

Re: [Tuxpaint-devel] Using libtextwrap in Tux Paint Config.

[Karl O. H. <ka...@hu...>]

Bill Kendrick skreiv 15.11.2021 10:40:
> Oh, libunibreak might be useful.  As with libtextwrap, I see it's
> available in Ubuntu 20.04.  However, before I make any more tectonic
> shifts in the Tux Paint Config. codebase, I'd better make sure it's
> available everywhere.:)

I can confirm that libunibreak is available in openSUSE.


-- 
Karl Ove Hufthammer

Re: [Tuxpaint-devel] Using libtextwrap in Tux Paint Config.

[TOYAMA Shin-i. <sh...@wm...>]

TOYAMA Shin-ichi wrote in <6193bf09.5035%sh...@wm...>
>I think there is no problem now.

Ah..

I've missed something.

Texts in the section "Keyboard" are not neccesarily wrapped after 
ascii characters. (see attached)

Sorry for bothering you again and again.

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Using libtextwrap in Tux Paint Config.

[TOYAMA Shin-i. <sh...@wm...>]

By the way, do we really need scroll bar on "Main device" section 
in the "Joystick" tab?

TOYAMA Shin-ichi wrote in <6193bf09.5035%sh...@wm...>
>Hi bill!
>
>Thank you for your enormous effort to impliment correct 
>word-wrapping for non-latain languages.
>
>Bill Kendrick wrote in <202...@sh...>
>>It seems to be working for me, but I'd like
>>Shin-Ichi to take a close look and make sure it's
>>actually rendering things properly.
>
>I think there is no problem now.
>Then, I refined various parameters so that current items to look 
>better and fit in each boxes.
>
>In addition, compared with tha case on linux, fonts looks too 
>small and line spacing are too tight on windows, italic text looks 
>too bad especially on windows, then I added #ifdef WIN32 part to 
>change the font size and appearance, which may not be a very good 
>idea though.
>
>I will let you decide if it is acceptable or not.
>
>Thanks!

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Using libtextwrap in Tux Paint Config.

[TOYAMA Shin-i. <sh...@wm...>]

Hi bill!

Thank you for your enormous effort to impliment correct 
word-wrapping for non-latain languages.

Bill Kendrick wrote in <202...@sh...>
>It seems to be working for me, but I'd like
>Shin-Ichi to take a close look and make sure it's
>actually rendering things properly.

I think there is no problem now.
Then, I refined various parameters so that current items to look 
better and fit in each boxes.

In addition, compared with tha case on linux, fonts looks too 
small and line spacing are too tight on windows, italic text looks 
too bad especially on windows, then I added #ifdef WIN32 part to 
change the font size and appearance, which may not be a very good 
idea though.

I will let you decide if it is acceptable or not.

Thanks!

-- 
TOYAMA Shin-ichi mailto:sh...@wm...

Re: [Tuxpaint-devel] Using libtextwrap in Tux Paint Config.

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

Hi Bill,

On Mon, Nov 15, 2021 at 03:05:42PM -0800, Bill Kendrick wrote:
> Mark, can you confirm that this library will build fine for you
> on macOS?

The library was built from https://github.com/adah1972/libunibreak without
any trouble using autogen.sh.

Compiling your test code, linebreak-test.c, though, required some extra
flags.  Most of the flags are supplied by pkg-config, so using pkg-config
in Makefile if we use this library in Tux Paint would be preferable to
directly passing `-l unibreak`.  `-l libiconv` also needed to be passed
manually but I think we already do this in Tux Paint Makefile.  The
resulting output is below.

$ gcc linebreak-test.c -o linebreak-test $(pkg-config --cflags --libs
libunibreak) -l iconv
linebreak-test.c:20:23: warning: passing 'char *' to parameter of type
'const utf8_t *' (aka 'const unsigned char *') converts between pointers to
integer types
      with different sign [-Wpointer-sign]
  set_linebreaks_utf8(str, strlen(str), "ja_JP.utf-8", brks);
                      ^~~
/opt/local/include/linebreak.h:67:23: note: passing argument to parameter
's' here
        const utf8_t *s, size_t len, const char *lang, char *brks);
                      ^
1 warning generated.
$ ./linebreak-test
タックスペイントを、ウィンドウ内ではなく、画面全体に表示します。ABC 123
3313313313313313313313313323313313313313313313313313313313323313313313313313313313313313313323312221224
111111112111111111121111111111212221224
タ~ッ~ク~ス~ペ~イ~ン~ト~を、~ウ~ィ~ン~ド~ウ~内~で~は~な~く、~画~面~全~体~に~表~示~し~ま~す。~ABC 123
$


Best,
Mark