# 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](https://sourceforge.net/p/testlilyissues/issues/5324/attachment/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](http://))
~~~~
#(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 [email protected] 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.------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Testlilyissues-auto mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
