[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