Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. QML and Qt Quick
  4. Fonts, again. Different appearance on different platforms. Same font.
Forum Updated to NodeBB v4.3 + New Features

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

Scheduled Pinned Locked Moved Solved QML and Qt Quick
6 Posts 3 Posters 1.3k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • V Offline
    V Offline
    VFCraig
    wrote on last edited by
    #1

    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?

    1 Reply Last reply
    0
    • V Offline
      V Offline
      VFCraig
      wrote on last edited by
      #2

      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?!?

      1 Reply Last reply
      0
      • GrecKoG Offline
        GrecKoG Offline
        GrecKo
        Qt Champions 2018
        wrote on last edited by GrecKo
        #3

        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.

        1 Reply Last reply
        0
        • V Offline
          V Offline
          VFCraig
          wrote on last edited by
          #4

          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?

          GrecKoG 1 Reply Last reply
          0
          • sierdzioS Offline
            sierdzioS Offline
            sierdzio
            Moderators
            wrote on last edited by
            #5

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

            (Z(:^

            1 Reply Last reply
            0
            • V VFCraig

              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?

              GrecKoG Offline
              GrecKoG Offline
              GrecKo
              Qt Champions 2018
              wrote on last edited by
              #6

              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?

              1 Reply Last reply
              0

              • Login

              • Login or register to search.
              • First post
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • Users
              • Groups
              • Search
              • Get Qt Extensions
              • Unsolved