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