Font buffering issue - "split personality"

All the fonts needed will be kept in a hashtable for quick future retrieval. So far, so good.
The problem that results from changing the global staff size from \book to \book is caused by a certain Pango-LilyPond duality:
-
Pango font size
Pango fonts always have an absolute Pango font size independent of any LilyPond staff-size/scaling factor. A Pango font in effective 11 pt output size (printed on the sheet) will always have the same Pango font size.

LilyPond font size
In contrast to Pango, LilyPond always works with relative font sizes (depending on the current global staff size) and everything (even "abs-fontsize") has to be scaled individually.

Hashtable keys and LilyPond scaling factors
All the fonts needed will be buffered in a hashtable for quick future retrieval.
The hashtable keys consist of an internal font name plus (!) the Pango size.
An \abs-fontsize #11 font (11 pt is the default fontsize) will always have the same Pango fontsize, regardless of the LilyPond global-staff-size.
Example for hashtable key: lilypond_serif_italic_3.8662109375

In addition to various Pango stuff, these two private poperties scale_ and output_scale_ will be stored (once and for all) in the fonts hash table, too.
They are crucial for the internal LilyPond spacing/scaling and they definitely will become wrong as soon as the global staff size changes.

After changing the global staff size, retrieving fonts from the hash table (All_font_metrics::find_pango_font, try_retrieve) will be successful for \abs-fontsize fonts, as their absolute fontsize did not change. But the relative LilyPond scaling factor, of course, will be completely wrong now and result in spacing/positioning/skyline errors.

Only if a font cannot be retrieved from the hash table, a fresh font will be added (always using the correct scaling for the current global staff size).

So, \fontsize fonts are just lucky, because global stave sizes will be set in pt, whereas \fontsize uses magsteps. These two practically never meet and so they will get a fresh, correctly scaled, font. Except for extremely rare casese like doubling global staff size from 20 pt to 40 pt while using \fontsizes of #0 and #6 or #-6 (also exaclty a factor of 2).
In this case, try_retrieve will pick up a font of the correct Pango size, but with an outdated LilyPond output_scale_ factor.
So, strictly speaking, even \fontsize fonts are not compeltely robust against changing the global staff size! In any case, it's not the "fault" of \abs-fontsize, it's the fault of retrieving outdated scaling factors from the hashtable.

Possible solutions

Simle solutioin
The easiest and most straight-forward remedy would probably be to just call #ly:reset-all-fonts from within #set-global-staff-size.
That way, all the buffering will get lost and every font will have to be freshly loaded into the hashtable, thus avoiding the unfortunate scaling problem.
This does no particular harm, because #set-global-staff-size is hardly ever called more than once, all the fonts needed will have to be initially loaded anyway. And after changing the global staff size, pracically all the existing hasthable keys will be useless anyway.

This also may serve as a workaround for the time being and oder versions: manually call #ly:reset-all-fonts after changing the global staff size.

Check and correct scaling factor
If we want to keep the existing hastable entries, it is quite easy to check whether the scaling factors are still correct after a successful try_retrieve. If not, it's easy to quickle re-calculate the output_scale_ factor. All the Pango stuff is still valid.
Using somthing in the lines of
unsmob<Pango_font> (val)->ensure_correct_scaling (output_scale);
will check whether the internal output_scale_ is still valid and eventually re-calculate the scale_ factor.

Which way to go?

On the one hand, changing global staff size practically makes all font data dragged around in the hash table completely useless (except for \abs-fontsize fonts, practically not a single \fontsize font will be needed anymore, because they all change their Pango size).
So, the vast majority of fonts will need new hash table entries, anyway, making the old ones obsolete.

On the other hand, the obsolete fonts carried around might be re-used after eventually setting back the global staff size to a previously used value, who knows.

What do you think?

All the best and thanks,
Torsten

[issues:#5324] \abs-fontsize and set-global-staff-size in books

Status: Started
Created: Sat May 19, 2018 06:22 PM UTC by Torsten Hämmerle
Last Updated: Sat May 19, 2018 06:22 PM UTC
Owner: Torsten Hämmerle
Attachments:

abs-fontsize-original.png (35.6 kB; image/png)

When creating several \books of different staff-sizes set by #(set-global-staff-size ...), markup in absolute font sizes (\abs-fontsize) will mess up spacing (font-metrics) in the subsecquent books.

(reported by David Sumbler: http://lilypond.1069038.n5.nabble.com/Maintaining-font-size-regardless-of-staff-size-td213007.html)

#(ly:set-option 'debug-skylines #t)

\header {
  title = \markup \concat {
        \abs-fontsize #21 "X let’s see how long X"
        \with-color #red \abs-fontsize #21 "XX"
      }
}

#(set-global-staff-size 18)
 \book { { b'1^\markup \abs-fontsize #14 "Test" } }

#(set-global-staff-size 26)
 \book { { b'1^\markup \abs-fontsize #14 "Test" } }

#(set-global-staff-size 10)
 \book { { b'1^\markup \abs-fontsize #14 "Test" } }

Sent from sourceforge.net because address@hidden is subscribed to https://sourceforge.net/p/testlilyissues/issues/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

From:	Auto mailings of changes to Lily Issues via Testlilyissues-auto
Subject:	[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #5324 \abs-fontsize and set-global-staff-size in books
Date:	Sat, 11 Aug 2018 10:00:56 -0000

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #5324 \abs-fon

Font buffering issue - "split personality"

Possible solutions

Which way to go?