Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#459 text fonts in notation come out all wrong with Qt 3.2

notation (282)
Chris Cannam

When printing notation from Rosegarden built with KDE 3.2 /
Qt 3.2, the text items on the page do not print correctly,
even though they appeared correctly in the screen version.

An example screenshot (from Print Preview, but the effect
is the same when actually printed) is attached. Note that
some of the fonts appear to be simply too small (e.g. the
staff name font); in most cases however the font is the
right size but drawn with the font metrics (e.g. the tempo
and dynamic indications). The time signature font also
almost certainly has the wrong metric (that's why the
item following the time signature is so close to it).

This example works fine in my KDE 3.1 / Qt 3.1 build.

Can you reproduce, and if so, any idea what might cause
it? Most of the fonts are constructed in NotePixmapFactory's
getTextFont method.


  • Chris Cannam
    Chris Cannam

    Print Preview screenshot exhibiting mis-drawn fonts

  • Logged In: YES

    Can't reproduce with Qt 3.3...

  • Logged In: YES

    Qt: 3.2.3

    It's definitely happening here. Not that that gives me any idea what I
    might do about it, mind you.

  • Chris Cannam
    Chris Cannam

    Logged In: YES

    Guillaume, I can actually reproduce something like this with Qt3.3
    as well. It's not quite the same problem: the font metrics appear
    to be consistent with the fonts shown, but instead the fonts shown
    are themselves wrong, and change in the course of the piece.
    For example if I print glazunov.rg, I get large bold fonts (similar
    to the one used for the first direction above the start of the piece)
    for the dynamic texts under the staff for much of the first page,
    but by the time we get to the ones on the second page they've
    switched to the (correct) smaller italic. Either we have a font
    cacheing problem or Qt does.

  • Chris Cannam
    Chris Cannam

    Logged In: YES

    Raising priority. This is a pretty serious bug. I wonder if it's
    related to the Print Preview hang when loading fonts reported
    by plcl on rg-devel recently?

  • Logged In: YES

    Chris: the problems I was reporting in rg-devel were on
    KDE 3.1 only, with both Qt 3.1.2 and Qt 3.2.1, tested on
    Mandrake 9.2 and Knoppix 3.3

    I've also tried Knoppix 3.4, having KDE 3.2.2 and Qt
    3.2.3, and the problem was solved. Well, in fact the
    italic attribute was ignored for Vera Serif font, but at
    least the preview function doesn't stall.

    As i've said, the workaround for my problem was to remap
    the family fonts "Times" and "Serif" to another font
    (Nimbus Roman) instead of Vera Serif.

  • Logged In: YES

    It's looking very likely that Debian will go stable with QT 3.2.3 and KDE
    3.2.3, and the attached file demonstrates what Debian users currently
    enjoy in the way of notation previews. (Printing comes out exactly the
    same way.)

    This is that new "notation for string orchestra" testfile, since you probably
    can't tell from looking at it.

  • Logged In: YES

    I currently have QT 3.3.3 and KDE 3.3.0, and print/preview is just as
    broken as it has been for the last while.

    I've overlayed the original (QT 3.2.3 KDE 3.2.2 I think) screenshot with the
    new (QT 3.3.3 KDE 3.3.0) one, and used a difference filter on the new
    layer. It shows some minor changes at the fringes of both images, but
    the notation preview itself is identical pixel for pixel.

  • Logged In: YES

    It's not a problem with our font cache since disabling it doesn't
    change anything. I'm not sure it's a font problem either, I've
    traced the fonts that Qt returns and the same font can be
    used for different Text types with either correct or broken
    results :

    these are correct :

    NotePixmapFactory::getTextFont: returning font
    'times,-1,70,1,50,1,0,0,0,0' for type dynamic text : mp
    NotePixmapFactory::getTextFont: returning font
    'times,-1,70,1,50,1,0,0,0,0' for type dynamic text : p

    these are broken :

    NotePixmapFactory::getTextFont: returning font
    'times,-1,70,1,75,0,0,0,0,0' for type local_tempo text :
    allargando poco
    NotePixmapFactory::getTextFont: returning font
    'times,-1,70,1,75,0,0,0,0,0' for type local_tempo text :

    the differring 6th argument (1 or 0) is for italic or not. Forcing
    italic doesn't change the problem either. So I'm wondering if
    the problem is not how we compute the length of the space in
    which the text is printed or something like this.

  • Chris Cannam
    Chris Cannam

    Logged In: YES

    Um, we don't compute the length of the space in which the
    text is printed, do we? Not when printing anyway.

    If you look at the borked output (e.g. from the attached
    screenshots from Michael) it's apparent that Qt is using a
    font metric for a much smaller font than the one it's
    actually drawing. That is, regardless of whether the font
    is the right one or not, Qt is laying out the letters in each
    piece of text incorrectly with respect to one another.

    This effect is not in theory possible to achieve using
    the Qt font API, is it? It surely has to be a Qt bug. The
    reason I mused about our font cache was that I wondered
    whether the Qt font shallow-copy mechanism might be
    associating one font's outlines with another's metrics in
    certain situations where two (or many, or too many) fonts
    were in use at the same time.

    These are of course pretty large fonts we're using here,
    which might make a difference.

  • Logged In: YES

    Apparently the problem comes from the fact that Qt's font
    matching algorithm uses the font family as the main criteria,
    see :
    It seems the requested size for the misprinted strings is 70
    or 122. We try to find a font of this size in the Times family,
    but largest size for this family, at least on my setup, is 34.
    Simply letting Qt choose the font family solves the problem,
    except for the fact that the choosen font is probably not
    appropriate (it uses bitstream vera sans here, surprising
    given that I've also a bitstream vera serif and it should prefer
    serif fonts).

  • Logged In: YES

    More test seem to narrow the problem to fonts with a max.
    size of 34, which is the case for Times and New Century
    Schoolbook, both of which are heavily used in notation. If I
    change the family to a font with a larger max size (64 is
    common), then the problem disappears.

    I won't do anything until Chris comes back from vacation, but
    IMHO we should have actual font choosers in the 'Font' tab of
    the notation settings page, and let users choose fonts among
    the "suitable" (max size >= 64) ones.

  • Logged In: YES

    I don't object to having a font chooser, but I do think we should somehow
    have sensible defaults too. If it's possible to restrict a font picker to a
    suitable base of fonts, it must be possible to do this ahead of time as well.
    I'd like to see the default behavior on every system be one of not coming
    up broken. The idea of a FAQ entry saying "if your fonts are completely
    borked when you try to print, go to config -> blah and twiddle them"
    doesn't quite sit right.

    I definitely don't know enough about fonts in X to have any
    well-considered thoughts to offer in the way of solutions. On the user
    side, I find fonts in Linux a horrible PITA, and I am definitely keen to have
    my software solve all of these problems for me.

    Hrm. One thought I just had, though it's definitely a bit much in the way
    of tall orders this late in the game. If there's no practical way to solve the
    font problem beforehand, what about some kind of first-time configurator
    like the GIMP and KDE itself have? Present them the viable fonts at that
    time, and allow them to choose the ones they want, with a reminder how
    they can come back and diddle it later.

    Hopefully the issue can be put to rest without resorting to such extremes.
    It was just a thought. I'll go play somewhere else now and leave it to you
    brilliant people to sort out the font issues. I'm definitely a mental midget
    when it comes to this kind of thing.

  • Logged In: YES

    Sheepish attempt at fixing, simply using other font families. Please test
    and report.

  • Logged In: YES

    It's not going to be that easy. The result of the fix is that all the affected
    text simply disappears now. No title/author/composer stuff, no track
    labels, and perhaps other things missing as well. No space is allocated for
    this missing text. These elements are completely absent in the result.

  • Chris Cannam
    Chris Cannam

    Logged In: YES

    OK, so to recap from this and the corresponding email

    The problem essentially was that Qt couldn't deal with
    bitmap fonts that wouldn't scale large enough, namely
    the Times and New Century Schoolbook families that we
    had hardcoded. Also, the font selection can't be left
    entirely up to Qt because it comes up with sans-serif
    fonts even when you ask for serif ones. (Aside: I did
    try specifying serif style and then requesting a known
    nonexistent family in the hope that it'd choose a serif
    replacement -- didn't work.)

    The trivial fix (from Guillaume, currently in CVS) is to
    specify a different pair of font families that are known to
    be scalable: in this case Times New Romand and Century
    Schoolbook. This oughtn't to be reliable, but actually I
    haven't seen it fail anywhere -- even this machine which
    has neither font installed and while failed to find a serif
    font without help earlier, manages mysteriously to come
    up with sensible scalable serifed alternatives.

    The remaining bit also in CVS from G is to add a font
    selector so that the user can change the selection if the
    default is not OK. I'm in two minds about this. It's
    certainly a desirable feature regardless, but it is a
    feature, and it's incomplete (it includes a font size
    selection which is disregarded, and it doesn't allow
    you control over the fact that not all types of text are
    the same size or necessarily want the same font).

    So to summarise the summary: this does appear to
    be an effective fix -- thank you for sorting it out,
    Guillaume. I would be happier with it if we could
    (preferably) eliminate the font-size part of the font
    selection widgets, or else complete the feature by
    making the font size actually be taken into account
    and allowing selection of more than one "purpose"
    of font (at the same time presumably moving to a
    separate tab from the notation fonts to avoid making
    the dialog a zillion miles tall).

  • Chris Cannam
    Chris Cannam

    Logged In: YES

    Closing original bug.