Fonts

[bartbes]

It appears you too think that changing font size doesn't create a new font, IT DOES. (to everyone out there who is confused)

[Robin]

you

Who is "you"?

[bartbes]

kikito, not you (robin)

[kikito]

Robin, your example only works with fonts that are loaded from a file, and loaded in love via love.graphics.newFont.

But there are other ways. Let me list them all, for completeness' shake.

• The aforementioned newFont(filename, size).
• newImageFont(image, glyps) will also return a Font object
• newImageFont(filename, glyps) (I suspect this one just opens the file, loads the image and then call the previous one)
• setFont(filename, size) creates a new font, too.
• setFont(size) creates a new font, using the default one as a template

The function you wrote doesn't cover all this variety, I'm afraid. If I'm not mistaken, you will at least need to define 3 functions (newFont, newImageFont & newDefaultFont -they could be 4 if you separated newImageFont in two)

By the way, I discovered was mistaken. I thought I read a setFont(font, size), which created fonts from other fonts, on runtime. This got me a bit confused, so some of my latest posts might not make a lot of sense. Apologies.

Coming back to requests, I don't like too much having "loading" coupled with "sizing" in the current implementation. I'd rather have these two separated. For example, we could have a "FontDefinition" class, separated from the "Font" class.

• FontDefinition's subclasses would be TTFFontDef, ImageFontDef & DefaultFontDef.
• FontDefinition.newFont(size) would return a Font.
• Font.definition would give you the reference to the definition, in case you can "clone" the font with different sizes

Also, setFont(size) and setFont(filename, size) are too dangerous. I believe that they will bring more trouble than they are worth - I hereby request removing them, and leaving setFont(font) only.

[Robin]

The function you wrote doesn't cover all this variety, I'm afraid. If I'm not mistaken, you will at least need to define 3 functions (newFont, newImageFont & newDefaultFont -they could be 4 if you separated newImageFont in two)

Yes, I know. I didn't really mean to write a comprehensive solution, but just a working example.

Coming back to requests, I don't like too much having "loading" coupled with "sizing" in the current implementation. I'd rather have these two separated. For example, we could have a "FontDefinition" class, separated from the "Font" class.

• FontDefinition's subclasses would be TTFFontDef, ImageFontDef & DefaultFontDef.
• FontDefinition.newFont(size) would return a Font.
• Font.definition would give you the reference to the definition, in case you can "clone" the font with different sizes

Why? This seems needlessly complicated. (Remember that games rarely need more than 3 or 4 fonts/sizes)

Also, setFont(size) and setFont(filename, size) are too dangerous. I believe that they will bring more trouble than they are worth - I hereby request removing them, and leaving setFont(font) only.

Why are they dangerous?

[kikito]

Ok, second self-correction.

I thought that newImageFont allowed the creation of images of any size. Apparently it doesn't - it creates images of one size only. I think this might be a good addition, anyway.

Why? This seems needlessly complicated.

Well it was just an example. I could not think of a simpler way

Code: Select all

Remember that games rarely need more than 3 or 4 fonts/sizes

Well I can think of lots of games that need something like this. For example: using the font size as an effect, with a message "approaching the screen" from far away. Or in my case, a GUI that "pops" windows with text with a "Zoom effect". Or a game that zooms in/out (using love.camera, for example).

Code: Select all

Why are they dangerous?

They are dangerous because they allocate a new font every time they are invoked, no matter what. In other words, they are equivalent to calling f=newFont() and then setFont(f). Their names, however, suggest that they behave like setFont(f), which doesn't allocate anything.

I'd rather have them removed - if someone uses them (which I doubt) he can just replace them by one call to newFont and one call to setFont(f), so the newFont is explicit.

[Robin]

I don't think it's that bad. If you change fonts more than once in your code, you usually either:

1. use a .ttf anyway, because you care what the fonts look like
2. are mindbogglingly careless about performance anyway

[kikito]

Hi Robin,

I'm sorry, you lost me there. How is your comment related with setFont(filename, size) and setFont(size), zooming fonts in games or bitmap fonts with different sizes? Have we moved somewhere else? My mind is old and feeble.

[Robin]

I meant that anyone who uses many sizes of a font would usually precreate them anyway, except if they were too wasteful to make it matter.

[kikito]

Hi Robin,

I agree with the first part of your phrase (everyone should pre-create fonts) but not with the second (except if they are too wasteful).

The problem with setFont(n) isn't that it wastes resources; it's stability. Any program that uses them on every draw() call will fail (seg fault) in a couple minutes.

It is also a problem of "unclear interface". Nothing in the name of the functions suggests that a new font is created. Tutorials use these functions but don't specify that. This confuses people. Not only people learning LÖVE, but also from the love core team.

The only use these functions have is setting up a global function during the load phase. They should be invoked once per program. This saves exactly one line of code per program (as opposed to calling newFont and setFont) but opens up a "trap" for people learning LÖVE (which see the setFont(n) examples on the tutorials and then - logically - extrapolate that that is the way of changing fonts).

I think the risks are much higher than the benefits.

On other side of things, I've thought about your opinion regarding complexity, and I think you are right. Little will be gained by separating Font creation and sizing, at least on this stage, where they are so "coupled".

I'll do my GUI interface removing the possibility of setting the font size - fonts will have to be created on the load phase.