Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-65037

Need for more internal QFont consistency

    XMLWordPrintable

Details

    • Suggestion
    • Resolution: Unresolved
    • P3: Somewhat important
    • None
    • 5.8, 5.9, 5.10
    • GUI: Font handling
    • None
    • My experience concerns Qt on Mac (Cocoa and X11) and Linux (X11).

      My font tinkering tool/demonstrator: github.com/RJVB/fontweightissue-qt5.git

    • macOS

    Description

      A few observations and suggestions related to QTBUG-63792; some have already been mentioned there but it might be constructive to give them their own ticket here.

       

      I think there are a number of (consistency) issues with what QFont has become, resulting in breaking user expectations and a requirement to implement workarounds to fix "trivial" things like "make this part of the text Bold". They're probably all related to the recent changes to the effect of `setStyleName` which now basically turns a QFont object into something else.

       

      • `QfontDialog::getFont()` will now set the styleName property in addition to setting all other properties to their appropriate values (as far as I could check).
      • `QFont::setStyleName()` does not set/update the other properties, leading to inappropriate font keys and string representations
      • Setting a style name renders most other properties useless and cannot be undone except by recreating a "clone" from scratch. While that can be OK on a case-by-case basis it is IMHO not OK as a new side-effect (read: regression) of the only GUI font selection method.
      • `QFontDatabase::styleString()` isn't necessarily identical to the font's effective stylename. E.g. "Segoe UI weight=63" has a styleString "Demi Bold" but corresponds to "Segoe UI Semibold" according to the font selection dialog. The style strings will synchronise after calling setStyleName"(Semibold").
      • `QFont::setStyleName()` won't check if a style actually exists (it should return a bool?) and must be called with a case-sensitive string
      • The same typeface (font file) can have platform dependent style names (e.g. Segoe UI's Italic and Bold are called Cursiva and Negreta on my Mac). This means that documents storing font names in Qt jargon can render differently on different platforms.

       

      The 2 main issues I'd address are the internal QFont inconsistency after calling setStyleName(), and the font dialog setting the stylename unconditionally. That internal state should always be as consistent as possible, including the style string (esp. that one as it comes from the font database). If consistency is not possible the font key and toString representations should drop the useless properties. (This could apply to fonts that cannot be represented in the PANOSE system?)

      I would guess that maintaining consistency will make it easier to implement a style name *un*set but also to allow other calls like "setWeight" or "setBold" to override the style name.

       

      I have been testing different ways to strip the style name; the cheapest solution I have found to date is

       

      QFont stripStyleName(const QFont &f) 
      { 
         if (f.styleName().isEmpty()) { 
             return f; 
         } else { 
             QFont g(f.family(), f.pointSize(), f.weight()); 
             if (auto s = f.pixelSize() > 0) { 
                 g.setPixelSize(s); 
             } 
             g.setStyleHint(f.styleHint(), f.styleStrategy()); 
             g.setStyle(f.style()); 
             if (f.underline()) { 
                 g.setUnderline(true); 
             } 
             if (f.strikeOut()) { 
                 g.setStrikeOut(true); 
             } 
             if (f.fixedPitch()) { 
                 g.setFixedPitch(true); 
             } 
             return g; 
         } 
      }
      

       

      which is still significantly more expensive than just `QFont new(old)`, yet it's now an obligatory step if you want to be able to use `QFont::setBold()` or the like and you are not 100% certain that you're dealing with a font that does NOT have a stylename set.

      And evidently the result of that function will only be as correct as the degree of consistency of the input font (= it strips the style name and may return a different font from the same family).

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          People

            esabraha Eskil Abrahamsen Blomfeldt
            rjvbertin René Bertin
            Votes:
            1 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

              Created:
              Updated:

              Gerrit Reviews

                There are no open Gerrit changes