Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Fonts, again. Different appearance on different platforms. Same font.



  • Two platforms, Windows laptop and Linux iMX8 boot2qt.
    LiberationSans is a resource of the application. It is loaded into the application font database in main.cpp.

    Debug statements printing out the application font family, and first substitution, both show LiberationSans as the font that is being used. (This is one of the latest releases of LiberationSans, 2.1.5.)

    But on Windows, the tail of the number nine (9) has virtually no upward hook to it. On the target, there is a significant upward turn to the end of the tail. So this is either a problem with the font rendering engine or a problem with font selection not working in a predictable manner.

    Anyone have a solution for this? An explanation? Is there another reason this is happening?



  • OK, I am really getting fed up with this QML crap.

    In main.cpp, we have loaded LiberationSans-Regular, Bold and Italics into the font database.

    I have set the font.family of a Text item to, "LiberationSans-Regular".

    On a, "onVisibleChanged", event, I print out the font.fontInfoFamily of that Text item.

    Do I get LiberationSans in any form? NO! Absolutely NOT!

    On Windows, I get, "fontInfoFamily=MS Shell Dlg 2". REALLY? Why is that even a possibility?

    On the target, boot2Qt Linux, I get, "fontInfoFamily=DejaVuSans".

    Reminder, I have set the application font to LiberationSans. I have set the Text item font.family to "LiberationSans-Regular".

    HOW? How am I getting ANYTHING other than LiberationSans of any kind?!?

    LiberationSans-Regular, Bold and Italics are assets of the program. They are loaded into the font database in main.cpp, they are designated as the font.family of the Text item.

    WHY am I getting anything other than LiberationSans for this Text item?!?


  • Qt Champions 2018

    As always, calm down.

    The font family name of the font is not the same as the filename of the font.
    The font family name here is "Liberation Sans".

    You can find it by opening the font in your OS font previewer, on the site you might have downloaded it from, with Qt font loader, and by other means.

    If you wanted your text as bold, changing the family name to "LiberationSans-Bold" won't be very practical. By just setting the name of the family (note the family term, it's a group of fonts, not just one), you can switch from regular to bold easily.



  • Figured it out myself. But really, why is it even necessary to have a fontInfoFamily function? Why doesn't font.family tell you that already? Why does font.family just show the string that was set? What is the point?

    Why not just make font.family a function? It could return the name of the font that was actually set.

    And how about providing some direct feedback when a value is set that doesn't match with any font known to the system. It should not be necessary to query an "info" object attached to the font to find out if the font was set correctly. Maybe get, exactMatch, to actually do something instead of just return, false?


  • Moderators

    You can suggest changes in Qt bugtracker: https://bugreports.qt.io


  • Qt Champions 2018

    That's how font works in every UI system, there is a fallback behavior.

    As for why there is both font.family and fontInfo.family, it's because it makes developers life easier. You can actually see if the chosen font differs from the one that was set without having to store the expected font somewhere else.
    For the font family you can also gives a very vague one like "serif", "sans-serif", "monospace" and seeing what the font matched with fontInfo might be important. It would be weird to do font.family = "sans-serif"; and then getting "DejaVu Sans" back when querying font.family, wouldn't it?

    QML is declarative, so making font.family a function won't be very practical and give much advantages.
    You already have your feedback in a declarative way, I really don't see how an imperative API would be any better? Do you have a pseudo code example of what your perfect API would look like?


Log in to reply