Re: Call for text size and style advice for Gnome 2

[Darin Adler <darin bentspoon com>]

On 1/7/02 5:32 PM, "Havoc Pennington" <hp redhat com> wrote:

> What we want to end up doing, for "bigger" or "bold", is to
> get a PangoAttrList applied to the PangoLayout for the text, with
> a PangoAttrScale (using PANGO_SCALE_* scale factors) for the sizes (rather
> than just picking sizes that look nice on most current X setups).

Sounds good. Note that Nautilus never used hard-wired sizes for the
particular cases I'm talking about. It was always "1 size bigger than the
default", or "1 size smaller than the default".

> Then the sizes used in various GNOME places will be consistent, and by
> modifying the global X font config we can make it nice. The problem
> with just picking sizes is that we are going to have at least two
> common X backends in use (Xft and the old one), and also different
> sets of available fonts, and different Xft configurations. So what
> looks nice on one computer won't on another. Already my GTK comes up
> with a different default font than Owen's, for example.

I agree that this is true, but I'm not sure what it means for Nautilus. I
definitely think it's best if we don't need to use different sizes for a lot
of different things.

> That means the focus for GNOME needs to be on consistency, and the
> focus for system integrators needs to be on making stuff look nice on
> a given system. Pango can also try to be smart, if GNOME is
> consistent, to the extent that it's possible. But if we have apps
> setting all kinds of random sizes and faces it's hard to fix
> centrally.

OK. My only quibble is that I have no idea how I can tell a legitimate need
to set the size larger from a "random size". I agree that it's less likely
to go awry in many ways if everything is as standard as possible.

> For font choices in the Nautilus prefs dialog, I don't know. For
> things like menus that are in no way special, nautilus prefs shouldn't
> affect them (I don't guess they do now). For the icon view, Nautilus
> should probably just ignore the global setting. Or perhaps you should
> introduce a boolean flag for "use standard font size" which would be
> on by default, and toggled off if you customize this.
> (The reason for the flag is that if someone customizes their font
> globally, they'd probably expect Nautilus to follow that, if they
> haven't previously adjusted Nautilus specifically.)

Ideally, I'd do an inventory and find out where Nautilus uses fonts, sizes,
and styles other than the default and reconsider each one.

>> Havoc told me that the old way it was done is not good for accessibility and
>> that instead I should be using gtk_label_set_markup.
>> ...  I don't understand how it
>> helps for accessibility either, so I am working in the dark here.
> 
> The reason is that markup for <large> gives you a PangoAttrScale, and
> calling gtk_widget_modify_font() gives you a fixed font size. The
> scale changes with the theme, so if someone can't see well they can
> crank up the font size. The hardcoded font size does not change with
> the global font size setting.

So to summarize: To apply a PangoAttrScale I need to use widget-specific
code. But I can easily modify the font in a widget-independent way. But
that's not good because it ends up requesting a specific font rather a size
relative to the default.

>> This has a few
>> problems, though. For one thing, if the label is one that has text that can
>> be changed, each place that changes the text has to use
>> gtk_label_set_markup. For another, if the label has arbitrary text in it,
>> there's no guarantee it won't have something that looks like markup. So this
>> seems like it might not be the right approach.
> 
> There are two solutions to this. One is to escape any text you're
> putting in the markup, with g_markup_escape_text(). (The convenience
> function here is hard since you want a printf clone that escapes the
> %s argument, but it would be nice to have.)

Ah! I thought that markup itself was the preferred thing. Now that I
understand it's about the PangoAttrList, I feel much better.

> The other solution is to instead set the PangoAttrList on your label
> with a PangoAttrScale or PangoAttrWeight. This only works if you want
> the attribute on the entire string. (You can use G_MAXINT for the end
> index in the attr list, and never change it even as your text
> changes.) If you want the attribute on a subportion of the string, you
> must use markup, so the position of the attribute can be translated by
> the i18n team when they translate the text itself.

Sounds fine. In the cases I'm talking about, we always want the attribute on
the entire string. Do you happen to knowof an example of code that sets a
PangoAttrList on a label that I can look at? I'm pretty ignorant about
properties and such, and these non-type-checked interfaces typically lead to
me doing lots of trial and error coding.

> So it's easy to imagine a gtk_label_make_larger convenience function
> that uses attr list. I think I patched make_larger at some point to
> use modify_font(), and I shouldn't have probably, the attr list
> approach might have been better. Note that attr lists and markup can't
> be mixed, since markup is just a different way to set the attr list.

Cool. I'll look into implementing the calls rather than removing all the
invocations.

>> (There's also code that selects the largest possible font that will fit up
>> to a certain size that and code that uses ellipses as needed. I could use
>> help or advice about how to do these with Pango and perhaps GtkLabel.)
> 
> I already sent you a non-working patch to do this, remember. ;-)

I remembered the patch, but I didn't remember the status of it.

> Anders says it crashes, I can look at fixing it, I just keep
> forgetting. In any case, it was one theory on how to rewrite the
> ellipsization.

Great! It's good that we at least have a start. At the moment, though, eel
doesn't even have a placeholder for this, so we can't insert the calls in
the appropriate places.

> The discussion of g_markup_escape_text() reminds me that I bet
> Nautilus needs to validate incoming text with g_utf8_validate() in
> about a zillion places. e.g. filenames all need to be validated.
> And probably their invalid form needs to be saved for manipulating
> them, in addition to the valid form used for display...

I am aware of this issue. I predict that it will be easy to find all the
places that need to be fixed. There's probably mainly one place we have to
validate the file names, the function nautilus_file_get_display_name. There
might be a few other places, but not a lot. But I don't know what to do when
g_utf8_validate returns false. Ideas?

(I also don't know whether there might be some circumstances where I want to
do a character set conversion rather than just a validate. The presence of
g_filename_to_utf8 in glib definitely creates some doubt in my mind, but I
do remember Owen saying that for Unix the most sane solution he could think
of was simply decreeing that filenames are UTF-8 and getting legacy file
names wrong.)

Thanks, Havoc. Informative and clear as usual.

    -- Darin