tuxpaint-devel — General discussion list for Tux Paint developers

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

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

On Mon, Nov 15, 2021 at 03:05:42PM -0800, Bill Kendrick wrote:
> On Mon, Nov 15, 2021 at 09:36:29PM +0900, TOYAMA Shin-ichi wrote:
> <snip> 
> > libunibreak compiled easily and produced dll file on MinGW/MSYS2.
> > It also compiled on CentOS7.
> > 
> > Therefore, I will be able to provide binary release for windows 
> > and RHEL using it.
> 
> Awesome!
> 
> Mark, can you confirm that this library will build fine for you
> on macOS?

I'm hopeful it will work.  If not, we can just #ifdef the code
into oblivion on systems that don't support it, and (for now at least)
just state that Japanese (and any other affected locale that
Tux Paint Config. has been translated to) will not work right.

I've just gone in and re-re-re-written the code to implement
libunibreak to grab hints as to where a string may be broken,
and then I iterate over the string and add characters until
there are too many.  Then I rewind to the previous potential
breakpoint and introduce a space, thus allowing FLTK to word-wrap.

For example, using CamelCase English, since I don't know
Japanese, consider this text.

  TheQuickBrownFoxJumpedOverTheLazyDog

Unibreak would return a LINEBREAK_ALLOWBREAK value at the
end of each individual word ("e" in "The", "k" in "Quick", etc.)

If I needed to fit this within a space that could fit
18 characters here in Emacs on my terminal, the code I
just added to Tux Paint Config. would do this:

  T
  Th
  The (! -- keeping track of the end of a word, so we can rewind)
  TheQ
  TheQu
  TheQui
  TheQuic
  TheQuick (!)
  ...
  TheQuickBrownFox (!)
  TheQuickBrownFoxJ
  TheQuickBrownFoxJu
  TheQuickBrownFoxJum (X -- the string is too wide...)
  TheQuickBrownFox_   (go back to the last word, add a space)
  TheQuickBrownFox_J  (and continue...)
  TheQuickBrownFox_Ju
  TheQuickBrownFox_Jum
  ...
  TheQuickBrownFox_JumpedOverTheLaz
  TheQuickBrownFox_JumpedOverTheLazy (!)
  TheQuickBrownFox_JumpedOverTheLazyD
  TheQuickBrownFox_JumpedOverTheLazyDo (X)
  TheQuickBrownFox_JumpedOverTheLazy_
  TheQuickBrownFox_JumpedOverTheLazy_D
  TheQuickBrownFox_JumpedOverTheLazy_Do
  TheQuickBrownFox_JumpedOverTheLazy_Dog

And therefore, the text would word-wrap like so:

  123456789012345678
  ------------------
  TheQuickBrownFox
  JumpedOverTheLazy
  Dog
  ------------------

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.

Thanks!

-- 
-bill!
Sent from my computer

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

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

On Mon, Nov 15, 2021 at 09:36:29PM +0900, TOYAMA Shin-ichi wrote:
<snip> 
> libunibreak compiled easily and produced dll file on MinGW/MSYS2.
> It also compiled on CentOS7.
> 
> Therefore, I will be able to provide binary release for windows 
> and RHEL using it.

Awesome!

Mark, can you confirm that this library will build fine for you
on macOS?

Thanks!

-bill!

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

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

Bill Kendrick wrote in <202...@sh...>
>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. :)

libunibreak compiled easily and produced dll file on MinGW/MSYS2.
It also compiled on CentOS7.

Therefore, I will be able to provide binary release for windows 
and RHEL using it.

Just for your information.

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

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

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

On Mon, Nov 15, 2021 at 01:40:46AM -0800, Bill Kendrick wrote:
<snip>
> 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'm encouraged to see the code is still maintained (last commit was
> one week ago), and I'll play with it a little and see whether it
> seems to do what we need.

So I see that this library simply provides a 'map' of where
breaks would be possible.

I put together a little sample program that takes an input
string and constructs one that includes the "~" hints that
the current code is using for word-wrapping:

  $ gcc linebreak-test.c -o linebreak-test -l unibreak && ./linebreak-test 
  タックスペイントを、ウィンドウ内ではなく、画面全体に表示します。ABC 123
  3313313313313313313313313323313313313313313313313313313313323313313313313313313313313313313323312221220
  111111112111111111121111111111212221220
  タ~ッ~ク~ス~ペ~イ~ン~ト~を、~ウ~ィ~ン~ド~ウ~内~で~は~な~く、~画~面~全~体~に~表~示~し~ま~す。~ABC 123

So the good news is, there'll be no need to manually introduce
them into the translated strings.


Here's the code:

========================================================================
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <linebreak.h>

/* gcc linebreak-test.c -o linebreak-test -l unibreak */
// #define LINEBREAK_MUSTBREAK     0       /**< Break is mandatory */
// #define LINEBREAK_ALLOWBREAK    1       /**< Break is allowed */
// #define LINEBREAK_NOBREAK       2       /**< No break is possible */
// #define LINEBREAK_INSIDEACHAR   3       /**< A UTF-8/16 sequence is unfinished */

int main(int argc, char * argv[]) {
  char * str = "タックスペイントを、ウィンドウ内ではなく、画面全体に表示します。ABC 123";
  char * brks, * newstr;
  size_t i, j;
  int possible_split_count;

  brks = malloc(strlen(str) + 1);
  init_linebreak();
  set_linebreaks_utf8(str, strlen(str), "ja_JP.utf-8", brks);
  printf("%s\n", str);
  for (i = 0; i < strlen(str); i++) {
    printf("%d", brks[i]);
  }
  printf("\n");

  possible_split_count = 0;
  for (i = 0; i < strlen(str); i++) {
    if (brks[i] == LINEBREAK_ALLOWBREAK) {
      possible_split_count++;
    }
    if (brks[i] != LINEBREAK_INSIDEACHAR) {
      printf("%d", brks[i]);
    }
  };
  printf("\n");

  newstr = (char *) malloc(sizeof(char) * (strlen(str) + possible_split_count + 1));
  j = 0;
  for (i = 0; i < strlen(str); i++) {
    newstr[j++] = str[i];
    if (brks[i] == LINEBREAK_ALLOWBREAK && str[i] != ' ') {
      newstr[j++] = '~';
    }
  }
  printf("%s\n", newstr);
  return (0);
}
========================================================================

-- 
-bill!
Sent from my computer

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

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

On Mon, Nov 15, 2021 at 12:09:19PM +0300, Benson Muite wrote:
<snip>
> Could Pango be used for layouts since it supports a variety of
> different languages?

Well, I get the feeling we can't really combine Pango and FLTK.
However, my only experience with Pango is via SDL_Pango, within
Tux Paint itself.  (And, it turns out, we only got as far as
using it for the UI -- button labels, prompts, and help text --
and not the Text and Label tools.)


> Firefox has its own layout engine [1], which
> minimizes dependencies. libtextwrap is well written and could also
> be updated to use only unicode dependencies so it builds easily on a
> variety of operating systems? Another option might be
> libunibreak[2].

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'm encouraged to see the code is still maintained (last commit was
one week ago), and I'll play with it a little and see whether it
seems to do what we need.


> SDL_Pango[3] has not had many updates, but could also be migrated to
> SDL2. Happy to look further into these options.

I believe Pere has been maintaining SDL_Pango for use with SDL2, which
is the basis of the Android port of Tux Paint (not Tux Paint Config.)

When I first decided we needed a user-friendly configuration tool for
parents and teachers (rather than expecting them to hand edit a config
text file), I actually thought it might be cool to use SDL and invent
our own GUI for it! :-)

On the one hand, I'm glad I didn't do that to myself.  On the other
hand, I've been a bit disappointed with FLTK. :-/  (That said, I
appreciate that TPC exists at all, and am thankful to my friends who
wrote the core of the code, 19 years ago this month!)

-- 
-bill!
Sent from my computer

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

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

On 11/15/21 12:42 AM, Bill Kendrick wrote:
> On Sun, Nov 14, 2021 at 05:22:59PM +0300, Benson Muite wrote:
> 
> I admit I did not look at the code.  I was it was readily available
> in Ubuntu 20.04, and it seemed to be the only C-based library I
> could track down in Ubuntu, so I went with it. :)
> 
> I'm glad it can be build for Fedora; I know we have maintained
> our own versions of some packages -- http://tuxpaint.org/download/linux-rpm/
> includes some SDL packages that people may need, for example.
> 
> Shin-ichi, what are your thoughts on this?
> 
> A bigger concern, of course, is whether we can build it on Windows
> and other platforms where `tuxpaint-config` is available.
> 
> 
>> The package author Tomohiro KUBOTA seems not to be reachable[5].
> 
> :(
> 
> 
>> Text wrapping is also important in Web browser[6][7][8], but may be
>> different if intended for children[9]
> 
> Keep in mind that Tux Paint Config. is NOT intended for children,
> but for adults who are adjusting Tux Paint's settings.
Thanks for the clarification.
> 
> I assume that SDL_Pango is doing a fine enough job word-wrapping
> for us, as this particular situation never came up in Tux Paint
> itself, that I'm aware.
> 
> It's just a failing of FLTK itself. :-/
> 
> 
Could Pango be used for layouts since it supports a variety of different 
languages? Firefox has its own layout engine [1], which minimizes 
dependencies. libtextwrap is well written and could also be updated to 
use only unicode dependencies so it builds easily on a variety of 
operating systems? Another option might be libunibreak[2]. SDL_Pango[3] 
has not had many updates, but could also be migrated to SDL2. Happy to 
look further into these options.

[1] 
https://searchfox.org/mozilla-central/source/intl/icu/source/common/dictbe.cpp
[2] https://github.com/adah1972/libunibreak
[3] https://sourceforge.net/projects/sdlpango/files/
[4] https://github.com/orgs/libsdl-org/repositories

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

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

On Mon, Nov 15, 2021 at 08:25:50AM +0900, TOYAMA Shin-ichi wrote:
> Hi!
> 
> I just tested it in a short time before going work, and from what 
> I can see, it seems to be working fine exept that some texts
> appears including extra unnecessary character (see attached).

Just spotted that myself.  I made a silly mistake -- if the
unaltered string fit, it would return it, even with the hints
included.  Now, it always AT THE VERY LEAST, removes the ~ hints,
even if it doesn't need to introduce any spaces for word-wrapping.

So I think it's better now.  It appears that Vim understands
Japanese words ([B] key moves back sometimes one character,
but sometimes a set), so I may be able to shove some more "~"
in the PO file until things render better for me.  Right now
it's a little awkward because it will look like this:

  [ ] XYZXYZXYZXYZXYZXYZ

  XYZXYZXYZXYZ,
  XYZXYZXYZXYZXYZ.

And with more hints it will at least look less... rugged :)

  [ ] XYZXYZXYZXYZXYZXYZ

  XYZXYZXYZXYZ,XYZXYZ
  XYZXYZ.


> I'll check tonight for details.

Thanks!  And thanks for your patience while I sort it out
and reinvent the wheel.  Whee :-P

-bill!

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

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

Hi!

I just tested it in a short time before going work, and from what 
I can see, it seems to be working fine exept that some texts
appears including extra unnecessary character (see attached).

I'll check tonight for details.

Thanks a lot!

Bill Kendrick wrote in <202...@sh...>
>On Mon, Nov 15, 2021 at 07:55:39AM +0900, TOYAMA Shin-ichi wrote:
>
><snip re: libtextwrap...> 
>
>> Anyway, I think it is OK for linux.
>> 
>> >A bigger concern, of course, is whether we can build it on Windows
>> >and other platforms where `tuxpaint-config` is available.
>> 
>> I'm also wondering if I can really build libtextwrap on windows.
>> 
>> Thanks.
>
>Take a look at what I attempted, committed to Git just moments
>ago, and tell me if you think it's an awful idea. :)
>
>-bill!
>
>
>_______________________________________________
>Tuxpaint-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

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

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

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

On Mon, Nov 15, 2021 at 07:55:39AM +0900, TOYAMA Shin-ichi wrote:

<snip re: libtextwrap...> 

> Anyway, I think it is OK for linux.
> 
> >A bigger concern, of course, is whether we can build it on Windows
> >and other platforms where `tuxpaint-config` is available.
> 
> I'm also wondering if I can really build libtextwrap on windows.
> 
> Thanks.

Take a look at what I attempted, committed to Git just moments
ago, and tell me if you think it's an awful idea. :)

-bill!

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

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

Bill Kendrick wrote in <202...@sh...>
>I'm glad it can be build for Fedora; I know we have maintained
>our own versions of some packages -- http://tuxpaint.org/download/linux-rpm/
>includes some SDL packages that people may need, for example.
>
>Shin-ichi, what are your thoughts on this?

When I tested libtextwrap on CentOS7 (Compatible to RHEL7), I 
created the RPM package in advance.
And I think I can build RPMs for other versions of RHEL.

Or, maybe we would be able to link tp-conf with libtextwrap 
statically (like fltk for current tp-conf RPMs).

Anyway, I think it is OK for linux.

>A bigger concern, of course, is whether we can build it on Windows
>and other platforms where `tuxpaint-config` is available.

I'm also wondering if I can really build libtextwrap on windows.

Thanks.

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

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

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

On Sun, Nov 14, 2021 at 01:42:12PM -0800, Bill Kendrick wrote:
<snip>
> Another thought is perhaps using ZERO WIDTH SPACE (U+200B)
> within the translation, as hints for where FLKT can word-wrap.
> 
> (1) That assumes that FLTK will even do the right thing; I'll
>     experiment with it a little.

It rendered them as a rectangle-with-an-X symbol.

Another thought, which would have the same problem as (2), below,
would be to invent our own "mark-up" for the translated labels,
and implement a very simple word-wrap, not relying on this
hard-to-get & unmaintained library.

So for example, instead of a ZWS Unicode character, a
string like "{zws}" or maybe even just "{}" or some other symbol
not regularly used in the labels, like "~".

We would normally strip them all out, but replace them with spaces
(to allow FLTK to word-wrap) or "\n" (as Shin-ichi had done manually)
only when they are useful to word-wrap.

So for example

  X~YZ~X~Y~ZXYZ.

And this would allow us to word wrap AS IF the text was:

  X YZ X Y ZXYZ.

But render it more appropriately (with no spaces), say either:

  XYZXY
  ZXYZ.

or:

  XYZXYZXYZ.

depending on the space available.


For this, we would still need the new "measure_and_softwrap()",
but it would be 100% our own code, rather than relying on
`libtextwrap`.


> (2) This will require inserting a LOT of these characters
>     within the translated text itself.  Shin-ichi and others
>     that might maintain the Japanese translation of Tux Paint Config.,
>     and maintainers of other similarly-affected languages
>     (e.g., Thai), may not appreciate having to do this. :-)

I suppose one wouldn't have to introduce them EVERYWHERE,
but only where it seems useful, based on how things look in the UI
(not unlike how "\n" had been used, but a bit more liberally).

-bill!

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

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

On Sun, Nov 14, 2021 at 05:22:59PM +0300, Benson Muite wrote:
> libtextwrap was last updated in 2013 [1][2] and there is a similar
> library available in Perl[3]
> 
> libtextwrap seems not to be available in many other repositories,
> such as Fedora[4]. The code does build on Fedora linux though, and
> could likely be packaged.

I admit I did not look at the code.  I was it was readily available
in Ubuntu 20.04, and it seemed to be the only C-based library I
could track down in Ubuntu, so I went with it. :)

I'm glad it can be build for Fedora; I know we have maintained
our own versions of some packages -- http://tuxpaint.org/download/linux-rpm/
includes some SDL packages that people may need, for example.

Shin-ichi, what are your thoughts on this?

A bigger concern, of course, is whether we can build it on Windows
and other platforms where `tuxpaint-config` is available.


> The package author Tomohiro KUBOTA seems not to be reachable[5].

:(


> Text wrapping is also important in Web browser[6][7][8], but may be
> different if intended for children[9]

Keep in mind that Tux Paint Config. is NOT intended for children,
but for adults who are adjusting Tux Paint's settings.

I assume that SDL_Pango is doing a fine enough job word-wrapping
for us, as this particular situation never came up in Tux Paint
itself, that I'm aware.

It's just a failing of FLTK itself. :-/


> A Python textwrapping library is [10], but it does not seem as
> detailed as the W3C recommendations. A markdown plugin[11], which
> also seems not as detailed as the W3C recommendations.

Thanks for digging up all these links!  It's a bit overwhelming,
and I'm hoping we don't need to write something ourselves.
But I suppose it wouldn't be the first time. :-D


> Questions:
> 1) What is needed to ensure Japanese version gets built?

In this case, it's not that there's a Japanese _version_ of
Tux Paint Config., it's that TPC checks your locale and uses
gettext() to present a translated version of its interface.

Prior to this -- and I was not really aware of what was going
on until we started toying with the UI layout, and ability
to use larger fonts and resizable window in Tux Paint Config. --
it seems that Shin-ichi was introducing linebreaks ("\n")
directly in the translations.  This is of course sub-optimal. :)


> 2) Might it be more efficient to implement a wrapping algorithm
> directly rather than import a dependency? Some rules available in
> [12]. The utility seems useful though, but maybe something else is
> more commonly used.

Another thought is perhaps using ZERO WIDTH SPACE (U+200B)
within the translation, as hints for where FLKT can word-wrap.

(1) That assumes that FLTK will even do the right thing; I'll
    experiment with it a little.

(2) This will require inserting a LOT of these characters
    within the translated text itself.  Shin-ichi and others
    that might maintain the Japanese translation of Tux Paint Config.,
    and maintainers of other similarly-affected languages
    (e.g., Thai), may not appreciate having to do this. :-)

-bill!

> 
> [1]https://sourceforge.net/projects/libtextwrap/
> [2]https://ubuntu.pkgs.org/21.10/ubuntu-main-arm64/libtextwrap-dev_0.1-14.2build3_arm64.deb.html
> [3]https://metacpan.org/dist/Text-WrapI18N/source/WrapI18N.pm
> [4] https://koji.fedoraproject.org/koji/search?match=glob&type=package&terms=textwrap
> [5] https://www.debian.org/doc/manuals/intro-i18n/ch-languages.en.html
> [6] https://www.w3.org/International/articles/typography/linebreak
> [7] https://developer.mozilla.org/en-US/docs/Web/CSS/line-break
> [8] https://github.com/w3c/jlreq
> [9] https://drafts.csswg.org/css-text-4/
> [10] https://github.com/fgallaire/cjkwrap
> [11] https://github.com/markdown-it/markdown-it-cjk-breaks
> [12] https://github.com/fuka/asciidoctor-pdf-linewrap-ja/blob/master/lib/asciidoctor/pdf/linewrap/ja/converter.rb
> 
> On 11/14/21 12:34 PM, TOYAMA Shin-ichi wrote:
> >Hi bill,
> >
> >Thank you for taking wordwrapping problem with Japanese into
> >account!!
> >
> >I've tried to build libtextwrap on MinGW/MSYS.
> >
> >It failed blaiming that langinfo.h is missing.
> >
> >Next, I downloaded langinfo.h from
> >
> >https://github.com/dscho/msys/tree/master/catgets/repl/include
> >
> >Then, it says nl_types.h is lacking....
> >
> >On CentOS7, configure fails with following error;
> >
> >checking how to run the C++ preprocessor... /lib/cpp
> >configure: error: C++ preprocessor "/lib/cpp" fails sanity check
> >See `config.log' for more details.
> >
> >Hrm ... it seems not very easy for me to use libtextwrap so far.
> >
> >
> >Bill Kendrick wrote in <202...@sh...>
> >>While playing with tuxpaint-config, I noticed that some
> >>of Shin-ichi's translations were wrapping oddly.
> >>I discovered the translated strings contained "\n" within
> >>them, meaning they were hard-wrapping.  I discovered FLTK
> >>did NOT soft-wrap such strings if they were too wide.
> >>
> >>Unlike an English string that contains spaces, e.g.:
> >>
> >>  XXX YYY ZZZ. XXX YYY ZZZ.
> >>
> >>Which would wrap like this to fit in a narrow width:
> >>
> >>  XXX YYY
> >>  ZZZ. XXX
> >>  YYY ZZZ.
> >>
> >>A wide Japanese string, like:
> >>
> >>  XYZXYZXYZXYZXYZXYZ.
> >>
> >>Would not word wrap at all, and be cut off:
> >>
> >>  XYZXYZXYZ
> >>
> >>So I Googled around, and discovered libtextwrap
> >>(http://libtextwrap.sourceforge.net/) which can handle this.
> >>Since we're using a GUI, and some text in the Japanese translation
> >>include non-Japanese characters (e.g., "Control-S", or "0-32766"),
> >>rather than attempt to determine the proper column width to wrap at,
> >>I have Tux Paint Config. brute-force it, by wrapping one character
> >>earlier and earlier until everything fits (per `fl_measure()`).
> >>
> >>I created a helper function that wraps many of our calls to
> >>`fl_measure()`, and in most cases simply calls it and returns.
> >>But whenever there's a string that's too wide (e.g., the Japanese
> >>text -- now that I removed the hard-coded "\n"), it will run a
> >>while() loop that calls the text wrap functions, and `fl_measure()`
> >>over and over again until it fits.
> >>
> >>Shin-ichi, this seems to be working pretty well for me.
> >>Can you try it out?  Don't forget to build the PO -> MO and
> >>install it, as I've removed those hard-coded "\n"s.
> >>
> >>And please try in both large and small windows, and on both
> >>Windows and Linux, if you can!  Thanks!
> >>
> >>Maintainers -- this obviously adds a new dependency.
> >>On Ubuntu, I was simply able to `apt-get install libtextwrap-dev`
> >>and I was all set.
> >>
> >>Thanks,
> >
> 
> 
> 
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

-- 
-bill!
Sent from my computer

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

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

libtextwrap was last updated in 2013 [1][2] and there is a similar 
library available in Perl[3]

libtextwrap seems not to be available in many other repositories, such 
as Fedora[4]. The code does build on Fedora linux though, and could 
likely be packaged.

The package author Tomohiro KUBOTA seems not to be reachable[5].

Text wrapping is also important in Web browser[6][7][8], but may be 
different if intended for children[9]

A Python textwrapping library is [10], but it does not seem as detailed 
as the W3C recommendations. A markdown plugin[11], which also seems not 
as detailed as the W3C recommendations.

Questions:
1) What is needed to ensure Japanese version gets built?
2) Might it be more efficient to implement a wrapping algorithm directly 
rather than import a dependency? Some rules available in [12]. The 
utility seems useful though, but maybe something else is more commonly used.

[1]https://sourceforge.net/projects/libtextwrap/
[2]https://ubuntu.pkgs.org/21.10/ubuntu-main-arm64/libtextwrap-dev_0.1-14.2build3_arm64.deb.html
[3]https://metacpan.org/dist/Text-WrapI18N/source/WrapI18N.pm
[4] 
https://koji.fedoraproject.org/koji/search?match=glob&type=package&terms=textwrap
[5] https://www.debian.org/doc/manuals/intro-i18n/ch-languages.en.html
[6] https://www.w3.org/International/articles/typography/linebreak
[7] https://developer.mozilla.org/en-US/docs/Web/CSS/line-break
[8] https://github.com/w3c/jlreq
[9] https://drafts.csswg.org/css-text-4/
[10] https://github.com/fgallaire/cjkwrap
[11] https://github.com/markdown-it/markdown-it-cjk-breaks
[12] 
https://github.com/fuka/asciidoctor-pdf-linewrap-ja/blob/master/lib/asciidoctor/pdf/linewrap/ja/converter.rb

On 11/14/21 12:34 PM, TOYAMA Shin-ichi wrote:
> Hi bill,
> 
> Thank you for taking wordwrapping problem with Japanese into
> account!!
> 
> I've tried to build libtextwrap on MinGW/MSYS.
> 
> It failed blaiming that langinfo.h is missing.
> 
> Next, I downloaded langinfo.h from
> 
> https://github.com/dscho/msys/tree/master/catgets/repl/include
> 
> Then, it says nl_types.h is lacking....
> 
> On CentOS7, configure fails with following error;
> 
> checking how to run the C++ preprocessor... /lib/cpp
> configure: error: C++ preprocessor "/lib/cpp" fails sanity check
> See `config.log' for more details.
> 
> Hrm ... it seems not very easy for me to use libtextwrap so far.
> 
> 
> Bill Kendrick wrote in <202...@sh...>
>> While playing with tuxpaint-config, I noticed that some
>> of Shin-ichi's translations were wrapping oddly.
>> I discovered the translated strings contained "\n" within
>> them, meaning they were hard-wrapping.  I discovered FLTK
>> did NOT soft-wrap such strings if they were too wide.
>>
>> Unlike an English string that contains spaces, e.g.:
>>
>>   XXX YYY ZZZ. XXX YYY ZZZ.
>>
>> Which would wrap like this to fit in a narrow width:
>>
>>   XXX YYY
>>   ZZZ. XXX
>>   YYY ZZZ.
>>
>> A wide Japanese string, like:
>>
>>   XYZXYZXYZXYZXYZXYZ.
>>
>> Would not word wrap at all, and be cut off:
>>
>>   XYZXYZXYZ
>>
>> So I Googled around, and discovered libtextwrap
>> (http://libtextwrap.sourceforge.net/) which can handle this.
>> Since we're using a GUI, and some text in the Japanese translation
>> include non-Japanese characters (e.g., "Control-S", or "0-32766"),
>> rather than attempt to determine the proper column width to wrap at,
>> I have Tux Paint Config. brute-force it, by wrapping one character
>> earlier and earlier until everything fits (per `fl_measure()`).
>>
>> I created a helper function that wraps many of our calls to
>> `fl_measure()`, and in most cases simply calls it and returns.
>> But whenever there's a string that's too wide (e.g., the Japanese
>> text -- now that I removed the hard-coded "\n"), it will run a
>> while() loop that calls the text wrap functions, and `fl_measure()`
>> over and over again until it fits.
>>
>> Shin-ichi, this seems to be working pretty well for me.
>> Can you try it out?  Don't forget to build the PO -> MO and
>> install it, as I've removed those hard-coded "\n"s.
>>
>> And please try in both large and small windows, and on both
>> Windows and Linux, if you can!  Thanks!
>>
>> Maintainers -- this obviously adds a new dependency.
>> On Ubuntu, I was simply able to `apt-get install libtextwrap-dev`
>> and I was all set.
>>
>> Thanks,
> 

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

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

TOYAMA Shin-ichi wrote in <6190d83d.5029%sh...@wm...>
>On CentOS7, configure fails with following error;
>
>checking how to run the C++ preprocessor... /lib/cpp
>configure: error: C++ preprocessor "/lib/cpp" fails sanity check
>See `config.log' for more details.

libtextwrap compiled just by executing "bootstrap" before
"configure", which is written in README ;-p

I see there are a few boxes which have to be corrected, maybe 
because of that the width for measurements are little wider than
those of rendering spaces.

I will correct parameters for such boxes.

Otherwize, it looks perfect!

However, still I can not find the way how to use this library on 
windows.

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 taking wordwrapping problem with Japanese into 
account!!

I've tried to build libtextwrap on MinGW/MSYS.

It failed blaiming that langinfo.h is missing.

Next, I downloaded langinfo.h from

https://github.com/dscho/msys/tree/master/catgets/repl/include

Then, it says nl_types.h is lacking....

On CentOS7, configure fails with following error;

checking how to run the C++ preprocessor... /lib/cpp
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.

Hrm ... it seems not very easy for me to use libtextwrap so far.


Bill Kendrick wrote in <202...@sh...>
>While playing with tuxpaint-config, I noticed that some
>of Shin-ichi's translations were wrapping oddly.
>I discovered the translated strings contained "\n" within
>them, meaning they were hard-wrapping.  I discovered FLTK
>did NOT soft-wrap such strings if they were too wide.
>
>Unlike an English string that contains spaces, e.g.:
>
>  XXX YYY ZZZ. XXX YYY ZZZ.
>
>Which would wrap like this to fit in a narrow width:
>
>  XXX YYY
>  ZZZ. XXX
>  YYY ZZZ.
>
>A wide Japanese string, like:
>
>  XYZXYZXYZXYZXYZXYZ.
>
>Would not word wrap at all, and be cut off:
>
>  XYZXYZXYZ
>
>So I Googled around, and discovered libtextwrap
>(http://libtextwrap.sourceforge.net/) which can handle this.
>Since we're using a GUI, and some text in the Japanese translation
>include non-Japanese characters (e.g., "Control-S", or "0-32766"),
>rather than attempt to determine the proper column width to wrap at,
>I have Tux Paint Config. brute-force it, by wrapping one character
>earlier and earlier until everything fits (per `fl_measure()`).
>
>I created a helper function that wraps many of our calls to
>`fl_measure()`, and in most cases simply calls it and returns.
>But whenever there's a string that's too wide (e.g., the Japanese
>text -- now that I removed the hard-coded "\n"), it will run a
>while() loop that calls the text wrap functions, and `fl_measure()`
>over and over again until it fits.
>
>Shin-ichi, this seems to be working pretty well for me.
>Can you try it out?  Don't forget to build the PO -> MO and
>install it, as I've removed those hard-coded "\n"s.
>
>And please try in both large and small windows, and on both
>Windows and Linux, if you can!  Thanks!
>
>Maintainers -- this obviously adds a new dependency.
>On Ubuntu, I was simply able to `apt-get install libtextwrap-dev`
>and I was all set.
>
>Thanks,

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

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

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

Tuxpaint-devel only...

On Sun, Nov 14, 2021 at 12:29:39AM -0800, Bill Kendrick wrote:
> 
> While playing with tuxpaint-config, I noticed that some
> of Shin-ichi's translations were wrapping oddly.
> I discovered the translated strings contained "\n" within
> them, meaning they were hard-wrapping.  I discovered FLTK
> did NOT soft-wrap such strings if they were too wide.
<snip>
> 
> So I Googled around, and discovered libtextwrap
> (http://libtextwrap.sourceforge.net/) which can handle this.
> Since we're using a GUI, and some text in the Japanese translation
> include non-Japanese characters (e.g., "Control-S", or "0-32766"),
> rather than attempt to determine the proper column width to wrap at,
> I have Tux Paint Config. brute-force it, by wrapping one character
> earlier and earlier until everything fits (per `fl_measure()`).
<snip>

Oh, one other thing to point out...  Since we're setting the
labels' strings once, at launch, this means the Japanese
(and any other locales affected by this) will NOT automatically
respond to changes in the window size, like they do for other
locales.

Of course, this was already the case, so it's not a regression.
It's just something we COULD handle ourselves, but do not at
this time.

In the end, because the app was not originally written to be
"responsive", we're having to deal with a lot of this junk
ourselves.  I should buy a book on Qt or GTK+ and rewrite
this poor old thing.  (It just had it's 19th birthday
a couple days ago! :^D )

-bill!

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

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

While playing with tuxpaint-config, I noticed that some
of Shin-ichi's translations were wrapping oddly.
I discovered the translated strings contained "\n" within
them, meaning they were hard-wrapping.  I discovered FLTK
did NOT soft-wrap such strings if they were too wide.

Unlike an English string that contains spaces, e.g.:

  XXX YYY ZZZ. XXX YYY ZZZ.

Which would wrap like this to fit in a narrow width:

  XXX YYY
  ZZZ. XXX
  YYY ZZZ.

A wide Japanese string, like:

  XYZXYZXYZXYZXYZXYZ.

Would not word wrap at all, and be cut off:

  XYZXYZXYZ

So I Googled around, and discovered libtextwrap
(http://libtextwrap.sourceforge.net/) which can handle this.
Since we're using a GUI, and some text in the Japanese translation
include non-Japanese characters (e.g., "Control-S", or "0-32766"),
rather than attempt to determine the proper column width to wrap at,
I have Tux Paint Config. brute-force it, by wrapping one character
earlier and earlier until everything fits (per `fl_measure()`).

I created a helper function that wraps many of our calls to
`fl_measure()`, and in most cases simply calls it and returns.
But whenever there's a string that's too wide (e.g., the Japanese
text -- now that I removed the hard-coded "\n"), it will run a
while() loop that calls the text wrap functions, and `fl_measure()`
over and over again until it fits.

Shin-ichi, this seems to be working pretty well for me.
Can you try it out?  Don't forget to build the PO -> MO and
install it, as I've removed those hard-coded "\n"s.

And please try in both large and small windows, and on both
Windows and Linux, if you can!  Thanks!

Maintainers -- this obviously adds a new dependency.
On Ubuntu, I was simply able to `apt-get install libtextwrap-dev`
and I was all set.

Thanks,

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Crash of Tuxpaint

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

Hrm!  The "sysfonts" option is used to allow Tux Paint to
search around and try to open other fonts (TTF files)
you've installed on your OS.  If any of them cause
problems, the ability to disable it is provided (or, on
some platforms, is the default, I think?)

I wonder if you could try re-instating that file, but
with "sysfonts=yes" removed (or set to "no"), and see
whether it still crashes.

This doesn't appear to be a case of a bogus line in
the config file causing a crash (which was a bag bug on
our part, but I imagine very uncommon to come across! :) )

Thanks,

-bill!

On Fri, Nov 05, 2021 at 12:33:03PM +0100, Marie Verdeil wrote:
> Hello, 
> find attached the config file which was faulty. 
> Here are the actions i took before noticing the crash: 
> - downloaded Tux-paint  0.9.26 for Mac OS Big Sur  + the config software and stamps. 
> -opened tuxpaint config and change some settings like bigger window, full screen, print, etc. (settings changed for “all users”, though there is anyway only one user on my laptop) 
> -opened and installed the stamps. 
> -opened Tuxpaint and realise the crash. 
> -reset the settings to default. still crashing. 
> -dis-installed and reinstalled TUx paint. still crashing. 
> -installed the 0.9.25 version: still crashing. 
> -deleted tux paint config file (there was only one: /Library/Application Support/TuxPaint/tuxpaint.cfg)
> -everything works again! 
> 
> best
> M 
> > On 5 Nov 2021, at 05:34, Bill Kendrick <nb...@so...> wrote:
> > 
> > On Thu, Nov 04, 2021 at 10:32:32PM +0900, TOYAMA Shin-ichi wrote:
> >> Thank you Marie for reporting back!
> >> 
> >> By the way, could you shere the config file which caused this 
> >> crash?
> > 
> > Yes, it'd be very interesting to see what's in there, and how it
> > got there!
> > 
> > 
> >> Seeing your report, I reproduced crash just by adding meeningless 
> >> text in the config file.
> >> So, your case might be something like this, but I am not sure why 
> >> such error has contaminated in your config file.
> >> 
> >> Of course we should review the code to avoid this kind of crash by
> >> ignoring unexpected data in the config file, your sample will be 
> >> great help for us to fix the problem.
> > 
> > I've made an attempt to do so.  Unlike the config parsing part
> > of the code, where it aborts when it sees an unknown "whatever=something"
> > combo, it currently just emits a warning to STDERR, and proceeds.
> > 
> > Here's what I put in mine, for example:
> > 
> >  # Generated by tuxpaint-config version 0.0.18  <<< ignored, as a comment (as before)
> >  sysconfig=no   <<< accepted (as before)
> >  _roor=oror     <<< ignored (as before), now with a warning
> >  roro=roro      <<< eventually quits with an error (as before)
> >  roror          <<< ignored, with a warning (rather than crashing)
> > 
> > https://sourceforge.net/p/tuxpaint/tuxpaint/ci/0a529cea96548f1609981ea17073a780d45f8389/ <https://sourceforge.net/p/tuxpaint/tuxpaint/ci/0a529cea96548f1609981ea17073a780d45f8389/>
> > 
> > -bill!
> > 
> > 
> >> Thanks.
> >> 
> >> 
> >> Marie Verdeil wrote in <F4E...@gm...>
> >>> Hello, 
> >>> I have done this and it worked! Thank you :)
> >>> Marie Verdeil
> >>> mar...@gm...
> >>> http://verdeil.net/
> >>> 
> >>> 
> >>> 
> >>>> On 1 Nov 2021, at 15:54, Mark K. Kim <mar...@gm...> wrote:
> >>>> 
> >>>> Hi Marie,
> >>>> 
> >>>> Can you try deleting the config files?
> >>>> 
> >>>> There are two config files:
> >>>> /Users/<Username>/Library/Application Support/TuxPaint/tuxpaint.cfg
> >>>> /Library/Application Support/TuxPaint/tuxpaint.cfg
> >>>> Thanks!
> >>>> 
> >>>> 
> >>>> On Mon, Nov 1, 2021 at 5:30 AM Marie Verdeil <mar...@gm... 
> >>> <mailto:mar...@gm...>> wrote:
> >>>> hello,
> >>>> 
> >>>> I am running it in english, right out of the download, with default presets 
> >>> (i did try to change some config with tuxpaint config but as it was crashing, i 
> >>> disinstalled it and downloaded it again). It launches and crashes after 2 
> >>> seconds on the loading screen. 
> >>>> 
> >>>> 
> >>>> 
> >>>>> On 31 Oct 2021, at 19:24, Mark K. Kim <mar...@gm... 
> >>> <mailto:mar...@gm...>> wrote:
> >>>>> 
> >>>>> 
> >>>>> Hi Marie,
> >>>>> 
> >>>>> I noticed it crashes sometimes in Japanese or Korean mode. In what language 
> >>> are you running Tux Paint in?
> >>>>> 
> >>>>> 
> >>>>> On Sun, Oct 31, 2021 at 12:25 PM Marie Verdeil <mar...@gm... 
> >>> <mailto:mar...@gm...>> wrote:
> >>>>> Hello, 
> >>>>> I just download the latest version of Tux paint 0.9.26 for Mac OS Big Sur 
> >>> but it crashes immediately when I launch it…Has anyone had the same issue? I 
> >>> used no config and no added stamps… Any lead as of what could the issue be? 
> >>>>> 
> >>>>> Thankyou 
> >>>>> Marie 
> >>>>> 
> >>>>> 
> >>>>> _______________________________________________
> >>>>> Tuxpaint-devel mailing list
> >>>>> Tux...@li... 
> >>> <mailto:Tux...@li...>
> >>>>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel 
> >>> <https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>
> >>>>> _______________________________________________
> >>>>> Tuxpaint-devel mailing list
> >>>>> Tux...@li... 
> >>> <mailto:Tux...@li...>
> >>>>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel 
> >>> <https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>
> >>>> _______________________________________________
> >>>> Tuxpaint-devel mailing list
> >>>> Tux...@li... 
> >>> <mailto:Tux...@li...>
> >>>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel 
> >>> <https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>
> >>>> _______________________________________________
> >>>> Tuxpaint-devel mailing list
> >>>> Tux...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> >>> ---- inline file
> >>> ---- inline file
> >>> _______________________________________________
> >>> Tuxpaint-devel mailing list
> >>> Tux...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> >> 
> >> -- 
> >> 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 mailing list
> > Tux...@li... <mailto:Tux...@li...>
> > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel <https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>


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


-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Crash of Tuxpaint

[Marie V. <mar...@gm...>]

Hello, 
find attached the config file which was faulty. 
Here are the actions i took before noticing the crash: 
- downloaded Tux-paint  0.9.26 for Mac OS Big Sur  + the config software and stamps. 
-opened tuxpaint config and change some settings like bigger window, full screen, print, etc. (settings changed for “all users”, though there is anyway only one user on my laptop) 
-opened and installed the stamps. 
-opened Tuxpaint and realise the crash. 
-reset the settings to default. still crashing. 
-dis-installed and reinstalled TUx paint. still crashing. 
-installed the 0.9.25 version: still crashing. 
-deleted tux paint config file (there was only one: /Library/Application Support/TuxPaint/tuxpaint.cfg)
-everything works again! 

best
M 
> On 5 Nov 2021, at 05:34, Bill Kendrick <nb...@so...> wrote:
> 
> On Thu, Nov 04, 2021 at 10:32:32PM +0900, TOYAMA Shin-ichi wrote:
>> Thank you Marie for reporting back!
>> 
>> By the way, could you shere the config file which caused this 
>> crash?
> 
> Yes, it'd be very interesting to see what's in there, and how it
> got there!
> 
> 
>> Seeing your report, I reproduced crash just by adding meeningless 
>> text in the config file.
>> So, your case might be something like this, but I am not sure why 
>> such error has contaminated in your config file.
>> 
>> Of course we should review the code to avoid this kind of crash by
>> ignoring unexpected data in the config file, your sample will be 
>> great help for us to fix the problem.
> 
> I've made an attempt to do so.  Unlike the config parsing part
> of the code, where it aborts when it sees an unknown "whatever=something"
> combo, it currently just emits a warning to STDERR, and proceeds.
> 
> Here's what I put in mine, for example:
> 
>  # Generated by tuxpaint-config version 0.0.18  <<< ignored, as a comment (as before)
>  sysconfig=no   <<< accepted (as before)
>  _roor=oror     <<< ignored (as before), now with a warning
>  roro=roro      <<< eventually quits with an error (as before)
>  roror          <<< ignored, with a warning (rather than crashing)
> 
> https://sourceforge.net/p/tuxpaint/tuxpaint/ci/0a529cea96548f1609981ea17073a780d45f8389/ <https://sourceforge.net/p/tuxpaint/tuxpaint/ci/0a529cea96548f1609981ea17073a780d45f8389/>
> 
> -bill!
> 
> 
>> Thanks.
>> 
>> 
>> Marie Verdeil wrote in <F4E...@gm...>
>>> Hello, 
>>> I have done this and it worked! Thank you :)
>>> Marie Verdeil
>>> mar...@gm...
>>> http://verdeil.net/
>>> 
>>> 
>>> 
>>>> On 1 Nov 2021, at 15:54, Mark K. Kim <mar...@gm...> wrote:
>>>> 
>>>> Hi Marie,
>>>> 
>>>> Can you try deleting the config files?
>>>> 
>>>> There are two config files:
>>>> /Users/<Username>/Library/Application Support/TuxPaint/tuxpaint.cfg
>>>> /Library/Application Support/TuxPaint/tuxpaint.cfg
>>>> Thanks!
>>>> 
>>>> 
>>>> On Mon, Nov 1, 2021 at 5:30 AM Marie Verdeil <mar...@gm... 
>>> <mailto:mar...@gm...>> wrote:
>>>> hello,
>>>> 
>>>> I am running it in english, right out of the download, with default presets 
>>> (i did try to change some config with tuxpaint config but as it was crashing, i 
>>> disinstalled it and downloaded it again). It launches and crashes after 2 
>>> seconds on the loading screen. 
>>>> 
>>>> 
>>>> 
>>>>> On 31 Oct 2021, at 19:24, Mark K. Kim <mar...@gm... 
>>> <mailto:mar...@gm...>> wrote:
>>>>> 
>>>>> 
>>>>> Hi Marie,
>>>>> 
>>>>> I noticed it crashes sometimes in Japanese or Korean mode. In what language 
>>> are you running Tux Paint in?
>>>>> 
>>>>> 
>>>>> On Sun, Oct 31, 2021 at 12:25 PM Marie Verdeil <mar...@gm... 
>>> <mailto:mar...@gm...>> wrote:
>>>>> Hello, 
>>>>> I just download the latest version of Tux paint 0.9.26 for Mac OS Big Sur 
>>> but it crashes immediately when I launch it…Has anyone had the same issue? I 
>>> used no config and no added stamps… Any lead as of what could the issue be? 
>>>>> 
>>>>> Thankyou 
>>>>> Marie 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Tuxpaint-devel mailing list
>>>>> Tux...@li... 
>>> <mailto:Tux...@li...>
>>>>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel 
>>> <https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>
>>>>> _______________________________________________
>>>>> Tuxpaint-devel mailing list
>>>>> Tux...@li... 
>>> <mailto:Tux...@li...>
>>>>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel 
>>> <https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>
>>>> _______________________________________________
>>>> Tuxpaint-devel mailing list
>>>> Tux...@li... 
>>> <mailto:Tux...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel 
>>> <https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>
>>>> _______________________________________________
>>>> Tuxpaint-devel mailing list
>>>> Tux...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>>> ---- inline file
>>> ---- inline file
>>> _______________________________________________
>>> Tuxpaint-devel mailing list
>>> Tux...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>> 
>> -- 
>> 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 mailing list
> Tux...@li... <mailto:Tux...@li...>
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel <https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>

[Tuxpaint-devel] New Magic tool: Reflection

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

It's not great, but it'll do for now I think...
this new tool lets you make a mirror reflection
of part of your image.

If you click and drag down (or simply click & release),
a reflection of whatever's above the spot you clicked
will appear below where you clicked.

So for example, click at the bottom of a drawing of
a house to make it look like a lake or pond is in
front of it, making a reflection.

You can also drag up, left, or right, to make
reflections that go in those directions.

It's a little glitchy (it stretches a lot more)
when going up or left, than down or right.
And I'd love it to be much more mathmatically
impressive, and allow for arbitrary angles
(think of the new Linear Gradient mode of the Fill tool,
but instead of filling in that direction, it will
make a reflection!)

Too hard for my sore face (wisdom tooth extraction)
and tired brain (6hrs of sleep last night).

But I think it's good for the time being!  It's in the Git repo.
Videos are on Twitter:

  https://twitter.com/TuxPaintTweets/status/1456541738667954181
  https://twitter.com/TuxPaintTweets/status/1456542229376294924

Enjoy!

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Some character is not rendered on windows.

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

On Fri, Nov 05, 2021 at 04:57:48PM +0900, TOYAMA Shin-ichi wrote:
> TOYAMA Shin-ichi wrote in <6184d80e.5012%sh...@wm...>
> 
> >Hrm...
> >Do I have to write private iswprint() ?
> 
> Done & committed.

Hah, thank you! :)

As I joked with a coworker today, I think the machines are
winning.  (Terminator.gif)

-bill!

Re: [Tuxpaint-devel] Some character is not rendered on windows.

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

TOYAMA Shin-ichi wrote in <6184d80e.5012%sh...@wm...>

>Hrm...
>Do I have to write private iswprint() ?

Done & committed.

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

[Tuxpaint-devel] Some character is not rendered on windows.

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

Hi,

TOYAMA Shin-ichi wrote in <6183db00.5009%sh...@wm...>
>Bill Kendrick wrote in <202...@sh...>
>>Regarding those characters that did not appear in the OSK for you,
>>I made the above discover by simply replacing the code that converts
>>any >= 0x00010000 values in str[] to UTF-8, for sending to SDL_Pango,
>>and just doing this:
>>
>>  utfstr[j++] = 'X';
>>
>>...But I could still see the symbols (and not an "X"). :)
>>
>>Perhaps that's a font issue?  Can you play around with it?
>
>In my understanding, we shoud have rectangle shape instead of the 
>correct symbol if it is a font issue, wright?
>
>However, nothing appears this case by clicking those simbols on 
>the OSK.
>
>I guess this might not be caused by render_text_w(), but by 
>something else in the OSK codes.

It was not in the OSK codes.

Taking the "EuroSign (U+20AC)" as an example, iswprint() returns 0
to it but it is actually printable.

I confirmed it by disabling the check by iswprint() around the line 3018
in tuxpaint.c as follows.

---
  - else if (iswprint(*im_cp) && (cur_tool == TOOL_TEXT || cur_label == LABEL_LABEL))
  + else if ((cur_tool == TOOL_TEXT || cur_label == LABEL_LABEL))
---

Hrm...
Do I have to write private iswprint() ?

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

Re: [Tuxpaint-devel] Crash of Tuxpaint

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

On Thu, Nov 04, 2021 at 10:32:32PM +0900, TOYAMA Shin-ichi wrote:
> Thank you Marie for reporting back!
> 
> By the way, could you shere the config file which caused this 
> crash?

Yes, it'd be very interesting to see what's in there, and how it
got there!


> Seeing your report, I reproduced crash just by adding meeningless 
> text in the config file.
> So, your case might be something like this, but I am not sure why 
> such error has contaminated in your config file.
> 
> Of course we should review the code to avoid this kind of crash by
> ignoring unexpected data in the config file, your sample will be 
> great help for us to fix the problem.

I've made an attempt to do so.  Unlike the config parsing part
of the code, where it aborts when it sees an unknown "whatever=something"
combo, it currently just emits a warning to STDERR, and proceeds.

Here's what I put in mine, for example:

  # Generated by tuxpaint-config version 0.0.18  <<< ignored, as a comment (as before)
  sysconfig=no   <<< accepted (as before)
  _roor=oror     <<< ignored (as before), now with a warning
  roro=roro      <<< eventually quits with an error (as before)
  roror          <<< ignored, with a warning (rather than crashing)

https://sourceforge.net/p/tuxpaint/tuxpaint/ci/0a529cea96548f1609981ea17073a780d45f8389/

-bill!


> Thanks.
> 
> 
> Marie Verdeil wrote in <F4E...@gm...>
> >Hello, 
> >I have done this and it worked! Thank you :)
> >Marie Verdeil
> >mar...@gm...
> >http://verdeil.net/
> >
> >
> >
> >> On 1 Nov 2021, at 15:54, Mark K. Kim <mar...@gm...> wrote:
> >> 
> >> Hi Marie,
> >> 
> >> Can you try deleting the config files?
> >> 
> >> There are two config files:
> >> /Users/<Username>/Library/Application Support/TuxPaint/tuxpaint.cfg
> >> /Library/Application Support/TuxPaint/tuxpaint.cfg
> >> Thanks!
> >> 
> >> 
> >> On Mon, Nov 1, 2021 at 5:30 AM Marie Verdeil <mar...@gm... 
> ><mailto:mar...@gm...>> wrote:
> >> hello,
> >> 
> >> I am running it in english, right out of the download, with default presets 
> >(i did try to change some config with tuxpaint config but as it was crashing, i 
> >disinstalled it and downloaded it again). It launches and crashes after 2 
> >seconds on the loading screen. 
> >> 
> >> 
> >> 
> >>> On 31 Oct 2021, at 19:24, Mark K. Kim <mar...@gm... 
> ><mailto:mar...@gm...>> wrote:
> >>> 
> >>> 
> >>> Hi Marie,
> >>> 
> >>> I noticed it crashes sometimes in Japanese or Korean mode. In what language 
> >are you running Tux Paint in?
> >>> 
> >>> 
> >>> On Sun, Oct 31, 2021 at 12:25 PM Marie Verdeil <mar...@gm... 
> ><mailto:mar...@gm...>> wrote:
> >>> Hello, 
> >>> I just download the latest version of Tux paint 0.9.26 for Mac OS Big Sur 
> >but it crashes immediately when I launch it$B!D(BHas anyone had the same issue? I 
> >used no config and no added stamps$B!D(B Any lead as of what could the issue be? 
> >>> 
> >>> Thankyou 
> >>> Marie 
> >>> 
> >>> 
> >>> _______________________________________________
> >>> Tuxpaint-devel mailing list
> >>> Tux...@li... 
> ><mailto:Tux...@li...>
> >>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel 
> ><https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>
> >>> _______________________________________________
> >>> Tuxpaint-devel mailing list
> >>> Tux...@li... 
> ><mailto:Tux...@li...>
> >>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel 
> ><https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>
> >> _______________________________________________
> >> Tuxpaint-devel mailing list
> >> Tux...@li... 
> ><mailto:Tux...@li...>
> >> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel 
> ><https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>
> >> _______________________________________________
> >> Tuxpaint-devel mailing list
> >> Tux...@li...
> >> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> >---- inline file
> >---- inline file
> >_______________________________________________
> >Tuxpaint-devel mailing list
> >Tux...@li...
> >https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> 
> -- 
> 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

Re: [Tuxpaint-devel] Crash of Tuxpaint

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

Thank you Marie for reporting back!

By the way, could you shere the config file which caused this 
crash?

Seeing your report, I reproduced crash just by adding meeningless 
text in the config file.
So, your case might be something like this, but I am not sure why 
such error has contaminated in your config file.

Of course we should review the code to avoid this kind of crash by
ignoring unexpected data in the config file, your sample will be 
great help for us to fix the problem.

Thanks.


Marie Verdeil wrote in <F4E...@gm...>
>Hello, 
>I have done this and it worked! Thank you :)
>Marie Verdeil
>mar...@gm...
>http://verdeil.net/
>
>
>
>> On 1 Nov 2021, at 15:54, Mark K. Kim <mar...@gm...> wrote:
>> 
>> Hi Marie,
>> 
>> Can you try deleting the config files?
>> 
>> There are two config files:
>> /Users/<Username>/Library/Application Support/TuxPaint/tuxpaint.cfg
>> /Library/Application Support/TuxPaint/tuxpaint.cfg
>> Thanks!
>> 
>> 
>> On Mon, Nov 1, 2021 at 5:30 AM Marie Verdeil <mar...@gm... 
><mailto:mar...@gm...>> wrote:
>> hello,
>> 
>> I am running it in english, right out of the download, with default presets 
>(i did try to change some config with tuxpaint config but as it was crashing, i 
>disinstalled it and downloaded it again). It launches and crashes after 2 
>seconds on the loading screen. 
>> 
>> 
>> 
>>> On 31 Oct 2021, at 19:24, Mark K. Kim <mar...@gm... 
><mailto:mar...@gm...>> wrote:
>>> 
>>> 
>>> Hi Marie,
>>> 
>>> I noticed it crashes sometimes in Japanese or Korean mode. In what language 
>are you running Tux Paint in?
>>> 
>>> 
>>> On Sun, Oct 31, 2021 at 12:25 PM Marie Verdeil <mar...@gm... 
><mailto:mar...@gm...>> wrote:
>>> Hello, 
>>> I just download the latest version of Tux paint 0.9.26 for Mac OS Big Sur 
>but it crashes immediately when I launch it…Has anyone had the same issue? I 
>used no config and no added stamps… Any lead as of what could the issue be? 
>>> 
>>> Thankyou 
>>> Marie 
>>> 
>>> 
>>> _______________________________________________
>>> Tuxpaint-devel mailing list
>>> Tux...@li... 
><mailto:Tux...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel 
><https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>
>>> _______________________________________________
>>> Tuxpaint-devel mailing list
>>> Tux...@li... 
><mailto:Tux...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel 
><https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>
>> _______________________________________________
>> Tuxpaint-devel mailing list
>> Tux...@li... 
><mailto:Tux...@li...>
>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel 
><https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>
>> _______________________________________________
>> Tuxpaint-devel mailing list
>> Tux...@li...
>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>---- inline file
>---- inline file
>_______________________________________________
>Tuxpaint-devel mailing list
>Tux...@li...
>https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

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