DirectLabels, Fonts and "Point Size"

I’ve just encountered a bit of an odd issue: When a higher-than-default point-size is applied to a DynamicTextFont (such as for rendering crisp text at large sizes), text rendered with that font becomes squashed together, both vertically and in its horizontal space-characters.

To illustrate, here below is a screenshot of a simple test-program, showing two pieces of text, both displayed via DirectLabels, and both employing the same font.

The left-hand piece of text uses a DynamicTextFont with no point-size set (and is thus a little blurry). The right-hand piece of text uses a DynamicTextFont with a point-size of 24 set. The left-hand label has a larger scale and a smaller word-wrap value, in order that its text more-or-less match that of the right-hand label in letter-size and line-length.

And here is the program that generated the above. (Presuming that you don’t have the referenced font, just replace the name of the font-file with one that you do have.)

from direct.showbase.ShowBase import ShowBase

from panda3d.core import DynamicTextFont
from direct.gui.DirectGui import *

from panda3d import __version__ as pandaVersion
print (pandaVersion)

import sys
print (sys.version)

class Game(ShowBase):
    def __init__(self):

        self.accept("escape", base.userExit)

        font = DynamicTextFont("Aileron-Regular.otf", 0)

        font2 = DynamicTextFont("Aileron-Regular.otf", 0)

        mew = DirectLabel(text = "This is a longish text, designed to see how DirectLabel handles both spaces and multiple lines",
                          scale = 0.07,
                          text_font = font,
                          text_wordwrap = 15,
                          pos = (0.6, 0, 0.5)

        mew2 = DirectLabel(text = "This is a longish text, designed to see how DirectLabel handles both spaces and multiple lines",
                          scale = 0.168,
                          text_font = font2,
                          text_wordwrap = 7,
                           pos = (-0.6, 0, 0.5)

app = Game()

I’ve observed this issue with more than one font, I believe, so it doesn’t seem to be specific to the font being used.

Am I misusing my font-objects in some way? Or is this an engine issue?

I found that you can manually set the size between lines.
But maybe there is some way to determine an automatic height based on the size of the font.



Thank you–that may help. :slight_smile:

Still, it’s odd behaviour–and I daresay that this won’t help with the issue of spaces being too small!

1 Like

That might be fixed by setting the space-advance.

But you’re right that it would be convenient to have a way to have different size-related text properties updated automatically whenever one of them is changed.

Ah, I thought that I looked for something like that! But I was perhaps not at my best, and may have missed it!

Thank you for pointing this out! Between it and the previously-mentioned line-height setting, I should have a clunky-but-workable solution, then. :slight_smile:

I would suggest, rather, that the point-size be factored into the text-assembly process, I think.

1 Like

Glad I could help! :slight_smile:

Fair enough!

1 Like

I can’t set two posts as the solution, so let me note here that using both “setLineHeight” and “setSpaceAdvance”, as suggested above, does indeed seem to solve the problem. :slight_smile:

The point size setting is rarely used in Panda; it is arguably more valuable to leave it at the default (10 pt) and scale the text by a factor of 2.4, and to make it more crisp, increase the pixels-per-unit setting.

That said, this is arguably a bug.

Ah, I think that I’d missed the “pixels-per-unit” setting; that does indeed seem like the logical value to adjust! Thank you for that!

That said, it does seem odd to have two different ways of producing larger text: scaling and point-size. Why do we have both “pixels-per-unit” and “point-size”…?

That’s a good question—it probably comes down to the point size being a parameter to the font rendering library, freetype, and Panda merely exposing this parameter. But since scaling as an operation comes so naturally for Panda3D, an argument could be made for deprecating the point size parameter altogether and only relying on scaling.

The existence of pixels-per-unit is useful, since it allows adjusting the text rendering quality without affecting the font metrics (so it could be controlled by a game’s quality settings or tweaked during a game’s optimization process).

(On a sidenote, though, even in HTML/CSS a common practice is to set a global size for the font in points and set all other font sizes in the document scaling relative to this point size, usually using em or rem units. With Panda’s default point size, a scale of 1.0 just so happens to correspond to the equivalent of 1em.)

That does make sense.

Likewise, I can see this making good sense.

I will say that I could see some designers looking specifically for point-size and being confused at not finding it, come to think of it.

It’s tempting, then, to suggest that the “point-size” setting be changed to actually operate on “pixels-per-unit” and scale behind the scenes. But, conversely, I’m not convinced that simply deprecating “point-size”, as you suggest, isn’t still the best option.

Indeed, the “pixels-per-unit” setting makes a lot of sense to me to keep–and more so than the “point-size” setting in this context, I feel.

That is a neat correspondence, and I could see it being a useful one under certain circumstances!