On Tue, Feb 14, 2006 at 10:10:11PM -0500, Albert Cahalan wrote:
> On 2/14/06, John Popplewell <john@...> wrote:
> > Hi all,
> > I've been looking at the causes of this problem:
> > http://www.johnnypops.demon.co.uk/tp-russian.png
> > where the font buttons on the right display garbage.
> The translator forgot to translate "Aa".
Hmmm. Your various test strings are in there but they don't seem to have
been translated - just empty strings :-(=20
"Aa" is in there as well, but is set to the string "Aa".
> Actually, "Aa" is a poor choice. It is best to choose characters that
> vary greatly between fonts. English users would be best served by
> > All but the first 3 buttons are the 'locale' fonts in e.g.
> > '/usr/local/share/tuxpaint/fonts/locale/' ones like 'el.ttf' and
> > 'he.ttf' etc.
> > The font loading code tries to filter out 'broken' fonts in the
> > function charset_works() but this doesn't actually check that 'Aa'
> > renders correctly when the locale is set.
> I don't think that "Aa" should need to work.
Well, it would be nice if the font UI displayed correctly :-)
I know what you mean though.
> > I've made up a simple patch that starts the font scanner (by calling
> > run_font_scanner()) *after* the command-line parameters have been
> > handled and the locale set, and includes and extra test for 'Aa'.
> > This also stops the font scanner running when and all you did was
> > 'tuxpaint --help'.
> This hurts. The font scanner should start as early as possible
> to give it lots of time. It really should start immediately. If it
> starts late, then the user is more likely to try to use the text
> tool before the font scanner is done.
Sure, but after parsing the command-line parameters doesn't seem that
late. I only moved it so that gettext() would be intialised (based on
the command-line arguments) when your code uses it.
> > Fonts that can't display 'Aa' when --lang is, say, Russian, no longer
> > appear but unfortunately it doesn't stop fonts showing up that can't
> > display characters that the user might type in.
> > Eg if I set lang to Spanish, then all 10 font buttons appear with 'Aa'
> > on them, but when I type in n-tilde and c-cedilla and then try each of
> > them, some of them display garbage or the wrong characters :-(
> The intent is that such fonts would be ranked poorly, and thus
> be placed at the bottom of the list. Spanish-capable fonts would
> go near the top.
I see. OK.
> I've seen plenty of neat fonts that don't cover all of ASCII, but
> they are still fun to use. A few of these fonts are kind of an
> abuse of the font system, providing stuff like astrological
> symbols for "A" to "Z".
My nieces favorite is the font with all the Egyptian hieroglyphs in :-)
> The important thing is that a user with scroll buttons disabled
> will get only the best fonts for his language. If scroll buttons
> work OK, then stuff like that astrological font ought to show up
> at the bottom of the list.
Yes, that would be good.
> > Excluding these 'locale' fonts from the font enumeration (unless they
> > match the current locale) would help in this particular case, but in the
> > general case of user and system fonts, this will come back to haunt us.
> Put the lame fonts at the bottom instead of excluding them.
> Only exclude a font if it will crash SDL_ttf or if it won't render
> distinct characters.
That would be good. Why isn't it working? Is it the missing
translations? Is it because gettext isn't initialised in the child
process? Something else?
It's your baby Albert, I was just taking a look. That's why I didn't
commit the changes.
> > Any ideas? Do we need to dump SDL_ttf and use freetype2 itself?
> If we want platforms without fork() to do background font
> scanning, yes. SDL_ttf is not thread-safe. (grrrr...)
Can't say I've noticed a speed problem, but I don't have 1000's of fonts
installed, and I know some do :-)
> BTW, please make a unified diff next time you send a patch.
> If you are generating diffs via CVS, try adding the following to
> your ~/.cvsrc file:
> diff -uN
> rdiff -u
Oh, right, will do. Thanks for that,
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> Tuxpaint-devel mailing list