After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 325767 - allow relative font sizes
allow relative font sizes
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Class: GtkStyleContext
unspecified
Other All
: Normal enhancement
: ---
Assigned To: Carlos Garnacho
gtk-bugs
: 390523 (view as bug list)
Depends on: 562252
Blocks: 325324
 
 
Reported: 2006-01-04 13:37 UTC by Sven Neumann
Modified: 2013-02-04 06:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Implement relative font sizes (1.77 KB, patch)
2008-11-11 17:45 UTC, Christian Dywan
reviewed Details | Review

Description Sven Neumann 2006-01-04 13:37:53 UTC
Currently the "font_name" field in the gtkrc file is the only way to change fonts and it only allows an absolute change. If a user wants to use a smaller font for certain widgets or if an application tries to provide a gtkrc file that results in a more compact dialog layout, it would be a lot nicer if the font could be specified relative to the desktop-wide configured font. This missing feature leads for example to bug #325324.

Not exactly sure how this would best be addressed. Perhaps allow the following syntax in gtkrc?

  font_name = "80%"       // default font, size reduced to 80%
  font_name = "-1"        // default font, one step smaller than the default size
  font_name = "+2"        // default font, two steps larger
  font_name = "Helvetica" // Helvetica in the default font size
Comment 1 Tim Janik 2006-01-05 12:41:52 UTC
this sounds sensible to me, mimicking the relative font size specification as supported for HTML (http://en.selfhtml.org/html/text/schrift.htm) is probably a good idea. gtkrc.c just parses the font name as a string though, the actual interpretation is performed in pango though.

so proper implementation of this feature may require modificaitons of pango_font_description_merge() and pango_font_description_from_string().

alternatively, a field font_size = "-1"/"+1"/"50%" could be introduced which is then copied/merged along side the font description in gtk rc-styles, and applied once the resulting font is created from the font_desc.

the second approach may result in code duplication (if other pango-using code wants relative font sizes), maybe make things more complex, and will be limited in scope to rc-files only. the first approach may require API modifications to pango which i'm not sure is a good idea. i think we really should get an opinion from owen/behdad on this.
Comment 2 Sven Neumann 2006-01-11 11:33:52 UTC
Should we reassign this report to Pango? Does the NEEDINFO status make sense (that does indicate that you need information from the bug reporter, doesn't it)?
Comment 3 Matthias Clasen 2006-01-11 17:28:13 UTC
Owen, any comment on these ideas ?
Comment 4 Behdad Esfahbod 2006-01-29 01:34:09 UTC
Dupping to Bug 170055 – Support relative font sizes in text markup.  Is that enough for Gtk+?  That's the only place that Pango parses font-size strings afterall.

*** This bug has been marked as a duplicate of 170055 ***
Comment 5 Michael Natterer 2006-01-29 11:07:48 UTC
Unfortunately it's not enough. What's needed is parsing of relative
font sizes in gtkrc files. Pango markup doesn't help here.
Comment 6 Behdad Esfahbod 2006-12-29 06:42:34 UTC
*** Bug 390523 has been marked as a duplicate of this bug. ***
Comment 7 Behdad Esfahbod 2007-05-03 01:54:52 UTC
ok, moving back to gtk+.  not sure how gtk+ will communicate the relative size to pango then.  maybe it should do the math itself.
Comment 8 Christian Dywan 2008-11-11 17:45:28 UTC
Created attachment 122436 [details] [review]
Implement relative font sizes

This patch imlements relative font sizes in resource files, see the following examples for how it works:

font_name = "Nimbus Sans Bold +2"

font_name = "Sans -1"

font_name = "-1"

All of those examples work, the last one is particularly useful if you don't want to conflict with the user's choice of font but need a relative size.

Basically +n or -n increases or decreases by 1.2.
Comment 9 Matthias Clasen 2008-11-12 19:39:04 UTC
Looks good to me (without actually trying it). 

Missing:
 
 - docs

 - demo/testcase


Comment 10 Matthias Clasen 2008-11-24 19:25:31 UTC
What do you think about the "80%" that Sven proposed initially ?
Comment 11 Behdad Esfahbod 2008-11-25 18:40:58 UTC
Humm, I don't like the fact that +/- numbers multiply by 1.2.  I'd rather you implement percents only, like PangoMarkup will do eventually, and perhaps support as special case "smaller" and "larger".

Other than that, I also don't like the fact that it messes with what is being passed down to pango.  Maybe just support things like "120%" and not "DejaVu Sans 120%"?  Or add a new key, font_size instead of font_desc, to make it clear?
Comment 12 Behdad Esfahbod 2008-11-25 19:09:36 UTC
I also believe that the patch doesn't fix the original issue reported.  That is, font_desc = "-1" loses all font properties from the system settings.  To fix that, you need to merge the font desc you got onto the one from parent.
Comment 13 Behdad Esfahbod 2008-11-25 19:15:10 UTC
Thinking more about it, this better be done using a new pango api that takes a font desc and modifies it according to a string.  Bug 562252.  Same function that can be used in pangomarkup and other places.
Comment 14 Christian Dywan 2008-11-26 07:40:25 UTC
(In reply to comment #11)
> Humm, I don't like the fact that +/- numbers multiply by 1.2.  I'd rather you
> implement percents only, like PangoMarkup will do eventually, and perhaps
> support as special case "smaller" and "larger".

The factor 1.2 is exactly the difference between the different levels of small and large fonts, it seemed natural to me to be able to specify relative font sizes that way.
I'm not opposed to percentages and it seems intuitive as well, but I'm not sure percentages would replace the relations either.

> Other than that, I also don't like the fact that it messes with what is being
> passed down to pango.  Maybe just support things like "120%" and not "DejaVu
> Sans 120%"?  Or add a new key, font_size instead of font_desc, to make it
> clear?

From an earlier comment concluding that Pango wouldn't support this feature, there was no choice but to modify the font description. And if you only accept a standalone size it becomes impossible to modify other attributes at the same time.

That leaves us with 'font_size' or 'font_variant'. But to me it seems akward to end up specifying a font_name and an additional string, since it leads to 'font_name = Nimbus Sans Bold' 'font_variant = Smaller Bold'.
Comment 15 Matthias Clasen 2013-02-04 06:06:10 UTC
relative font sizes work now, in css