#11341: Font very tiny on Ribbon (OSX)
-------------------------+--------------------------------------------------
Reporter: SnowLeopard | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: base | Version: 2.9-svn
Keywords: Ribbon, OSX | Blockedby:
Patch: 0 | Blocking:
-------------------------+--------------------------------------------------
Run the Ribbon sample on OSX. It looks great, but the font looks tiny and
is hard to see. Compare the Ribbon's text to the caption bar and log
window in my attached screenshot.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/11341>
#11341: Font very tiny on Ribbon (OSX)
--------------------------+-------------------------------------------------
Reporter: SnowLeopard | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: base | Version: 2.9-svn
Resolution: | Keywords: Ribbon, OSX
Blockedby: | Patch: 0
Blocking: |
--------------------------+-------------------------------------------------
Comment(by SnowLeopard):
I think I might know what the problem is--hard coded font sizes. I've
noticed that font sized mean different things between Mac and Windows and
it is best to instead get the default fonts via the system.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/11341#comment:1>
#11341: Font very tiny on Ribbon (OSX)
-------------------------+--------------------------------------------------
Reporter: SnowLeopard | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: base | Version: 2.9-svn
Keywords: Ribbon, OSX | Blockedby:
Patch: 1 | Blocking:
-------------------------+--------------------------------------------------
Changes (by SnowLeopard):
* patch: 0 => 1
Comment:
Attaching patch which fixes the MSW art provider to use the system default
font size instead of hard coded "8". Tested on Windows XP and OSX and
fixes my original issue on OSX. Looks you same as before on Windows.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/11341#comment:2>
#11341: Font very tiny on Ribbon (OSX)
-------------------------+--------------------------------------------------
Reporter: SnowLeopard | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: Ribbon, OSX | Blockedby:
Patch: 1 | Blocking:
-------------------------+--------------------------------------------------
Changes (by vadz):
* cc: csomor, corsix@… (added)
* component: base => wxOSX-Cocoa
Comment:
AFAICS this font was supposed to be a smaller version of the standard font
(otherwise it could just be set to `*wxNORMAL_FONT`) so maybe we should
use `*wxSMALL_FONT` here instead (using hard coded font size is, of
course, wrong)? Could you please check if it looks appropriately under
Mac?
Generally speaking the best would probably be to use the same font as in
the toolbars which is supposed to be
`wxToolBar::GetClassDefaultAttributes().font` but I see that this method
is not implemented under OS X.
Stefan, would you know by chance if we can retrieve the toolbar font
easily under Mac? I think NSFont has methods for doing this. Or maybe some
other font would be more appropriate here?
--
Ticket URL: <http://trac.wxwidgets.org/ticket/11341#comment:3>
#11341: Font very tiny on Ribbon (OSX)
-------------------------+--------------------------------------------------
Reporter: SnowLeopard | Owner:
Type: defect | Status: new
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: Ribbon, OSX | Blockedby:
Patch: 1 | Blocking:
-------------------------+--------------------------------------------------
Comment(by SnowLeopard):
I tried "*wxSMALL_FONT", but on both Windows and OSX it is...well...small.
Very tiny, hard to read.
*wxNORMAL_FONT looks OK on both platforms, but is a little too big (IMO).
Using the system default font size looks perfect (again, IMO).
I am attaching screenshots of using wxNORMAL_FONT and
"wxFont(wxSystemSettings::GetFont(wxSYS_DEFAULT_GUI_FONT).GetPointSize(),
wxDEFAULT, wxNORMAL, wxNORMAL, FALSE); " for you to compare.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/11341#comment:4>
#11341: Font very tiny on Ribbon (OSX)
-------------------------+--------------------------------------------------
Reporter: SnowLeopard | Owner:
Type: defect | Status: confirmed
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: Ribbon, OSX | Blockedby:
Patch: 1 | Blocking:
-------------------------+--------------------------------------------------
Changes (by pjc):
* status: new => confirmed
Comment:
Personally, I think that on Windows, wxNORMAL_FONT looks much better than
wxSYS_DEFAULT_GUI_FONT. Compared to MS Office, wxSYS_DEFAULT_GUI_FONT
gives a font which is quite noticeably larger, whereas wxNORMAL_FONT looks
a lot closer to what Office does.
Definitely, anything is better than a hard-coded font size, so as you
think wxNORMAL_FONT is OK on OSX, I'm committing that, at least for the
moment.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/11341#comment:5>
#11341: Font very tiny on Ribbon (OSX)
-------------------------+--------------------------------------------------
Reporter: SnowLeopard | Owner:
Type: defect | Status: confirmed
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: Ribbon, OSX | Blockedby:
Patch: 1 | Blocking:
-------------------------+--------------------------------------------------
Comment(by PJC):
(In [62573]) Replaced hard-coded font size in ribbon art provider with a
system defined font size (see #11341).
--
Ticket URL: <http://trac.wxwidgets.org/ticket/11341#comment:6>
#11341: Font very tiny on Ribbon (OSX)
-------------------------+--------------------------------------------------
Reporter: SnowLeopard | Owner:
Type: defect | Status: confirmed
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: 2.9-svn
Keywords: Ribbon, OSX | Blockedby:
Patch: 1 | Blocking:
-------------------------+--------------------------------------------------
Comment(by vadz):
Replying to [comment:5 pjc]:
> Personally, I think that on Windows, wxNORMAL_FONT looks much better
than wxSYS_DEFAULT_GUI_FONT.
There should be no difference between the two in current svn trunk (I
don't remember when exactly was this fixed but I think it might have been
after 2.9.0), please let me know if you still see any difference.
BTW, was this ticket supposed to be closed?
--
Ticket URL: <http://trac.wxwidgets.org/ticket/11341#comment:7>
#11341: Font very tiny on Ribbon (OSX)
--------------------------+-------------------------------------------------
Reporter: SnowLeopard | Owner:
Type: defect | Status: closed
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: 2.9-svn
Resolution: fixed | Keywords: Ribbon, OSX
Blockedby: | Patch: 1
Blocking: |
--------------------------+-------------------------------------------------
Changes (by pjc):
* status: confirmed => closed
* resolution: => fixed
Comment:
Replying to [comment:7 vadz]:
> There should be no difference between the two in current svn trunk (I
don't remember when exactly was this fixed but I think it might have been
after 2.9.0), please let me know if you still see any difference.
Using the latest svn trunk, I find that the following two lines give
noticeably different fonts:
m_tab_label_font = *wxNORMAL_FONT;
m_tab_label_font =
wxFont(wxSystemSettings::GetFont(wxSYS_DEFAULT_GUI_FONT).GetPointSize(),
wxDEFAULT, wxNORMAL, wxNORMAL, FALSE);
I've attached screenshots showing this.
> BTW, was this ticket supposed to be closed?
I'm not sure what the normal method for responding to tickets here is.
Personally I'm inclined to mark things as 'confirmed' when I'm happy that
there is an issue to address, but the discussion isn't completely finished
yet, then use 'closed'/'fixed'/whatever once the issue is definitely fixed
and there is nothing more to be said. If the normal behaviour here is to
mark things as fixed even if the fix might not be the final one, then I
should adopt that behaviour.
--
Ticket URL: <http://trac.wxwidgets.org/ticket/11341#comment:8>
#11341: Font very tiny on Ribbon (OSX)
--------------------------+-------------------------------------------------
Reporter: SnowLeopard | Owner:
Type: defect | Status: closed
Priority: normal | Milestone:
Component: wxOSX-Cocoa | Version: 2.9-svn
Resolution: fixed | Keywords: Ribbon, OSX
Blockedby: | Patch: 1
Blocking: |
--------------------------+-------------------------------------------------
Comment(by vadz):
Replying to [comment:8 pjc]:
> Replying to [comment:7 vadz]:
> > There should be no difference between the two in current svn trunk (I
don't remember when exactly was this fixed but I think it might have been
after 2.9.0), please let me know if you still see any difference.
> Using the latest svn trunk, I find that the following two lines give
noticeably different fonts:
> m_tab_label_font = *wxNORMAL_FONT;
> m_tab_label_font =
wxFont(wxSystemSettings::GetFont(wxSYS_DEFAULT_GUI_FONT).GetPointSize(),
wxDEFAULT, wxNORMAL, wxNORMAL, FALSE);
> I've attached screenshots showing this.
I see them but I don't understand them :-( This just should be impossible
and in fact it's not even a recent change (the recent change is that
`wxSYS_DEFAULT_GUI_FONT` is now the correct font, taken from
`NONCLIENTMETRICS::lfMessageFont` instead of
`GetObject(DEFAULT_GUI_FONT)`): `wxNORMAL_FONT` is initialized with
`wxFont(wxSystemSettings::GetFont(wxSYS_DEFAULT_GUI_FONT))` in
`src/common/gdicmn.cpp`. So I have really no idea what could explain the
difference.
> > BTW, was this ticket supposed to be closed?
> I'm not sure what the normal method for responding to tickets here is.
Personally I'm inclined to mark things as 'confirmed' when I'm happy that
there is an issue to address, but the discussion isn't completely finished
yet, then use 'closed'/'fixed'/whatever once the issue is definitely fixed
and there is nothing more to be said. If the normal behaviour here is to
mark things as fixed even if the fix might not be the final one, then I
should adopt that behaviour.
No, they should only be closed if the resolution is final, but I just
thought it was (i.e. that using `wxNORMAL_FONT` was the right thing to
do). Do you see anything else to improve here? It does seem like there is
another bug with the mismatch between the 2 fonts but it's a different
issue...
--
Ticket URL: <http://trac.wxwidgets.org/ticket/11341#comment:9>