> ftstring -m can handle Unicode strings but I found it to be cumbersome as I > had to copy-paste sample strings from the browser.
Yeah, yeah, "ftstring -m" is not so easy. Some developers/users may invoke the ftstring/ftview under the environment which cannot pass UTF-8 string transparently to the program (e.g. legacy terminal emulators, legacy locale, etc etc). Therefore I suggested to use the file or stdin, it is not same with "-m" option. > I only want to cover languages natively spoken by more than 100 mln people. > This is just 10 languages and strings. Sorry, I'm not saying that there are so many languages. I'm saying that it is not easy to determine which is the best sample text to hardwire, even for the popular scripts written by 100 mln people. Regards, mpsuzuki Alexei Podtelezhnikov wrote: >>> I don't have Japanese or Chinese text handy, but I want it on my finger >>> tips for Freetype testing. What is bad about hard coding it into Freetype ? >> >> I'm not suggesting to change ftview/ftstring to use gettext framework >> (because it would be too much), but having the binary executable and the >> collection of text files for testing would not be so difficult solution for >> the developers automating the tests. In my personal impression, for some >> languages, it would be difficult to define the best sample text, so it would >> be difficult for us to choose the best text which is worthful to hardwire >> into the binary executable. > > ftstring -m can handle Unicode strings but I found it to be cumbersome as I > had to copy-paste sample strings from the browser. I can hard code Unicode > using c89 escaped strings byte by byte but it looks ugly, c99 \uhhhh escaped > Unicode looks more natural. > > I only want to cover languages natively spoken by more than 100 mln people. > This is just 10 languages and strings. _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
