UpdateFonts with Office2013 theme bug?

I seem to have a problem with the Office 2013 (white) ribbon theme paint code. I have support for Office 2007 and Office 2010 themes and I have for a long time now been able to increase the font size on the ribbon by calling SetFontHeight. I do this for high-res monitors (I also set the command bar paint manager's m_bAutoResizeIcons to TRUE). Works pretty well. I get a larger font and larger buttons, which works pretty well on my 4k monitor.

Now I am doing the same for Office 2013 White, which I have added to our app. The font and images scale just like with other themes. However the ribbon will display the text right over the buttons. I have tracked this down to a difference in the paint manager's m_nEditHeight variable. Basically, there is a difference in the height of the ribbon, with the white ribbon being too short.

The difference appears to me to be between CXTPPaintManager::UpdateFonts() used by CXTPCommandBarsOffice2013Theme (Office2013) and CXTPThemeRibbon::UpdateFonts() used by Office 2007/2010.

I should note that we set our own font by calling SetCommandBarsFontIndirect on the paint manager. And that seems to be the key.

In CXTPPaintManager::UpdateFonts(), there is a "m_bUseStandardFont" variable that is tested. And the m_nEditHeight is calculated using the m_nFontHeight but only if m_bUseStandardFont is true. Since we set our own font, that flag is false. It looks like to me there should be an "else" clause in the very least that calculates the m_nEditHeight (and probably m_nTextHeight too.)

However in CXTPRibbonTheme::UpdateFonts, m_nEditHeight is always calculated using the m_nFontHeight we set. The m_bUseStandardFont member is tested in this API, but the calculations needed to correctly display the ribbon by calculating m_nEditHeight are not avoided if the value is FALSE.

So to me, this appears to be a bug in the White theme's paint manager. Either that, or there is something basic I need to do when using Office2013 that we don't have to do with the other themes.

I have found some interesting code in CXTPCommandBarsOffice2013Theme::RefreshMetrics, which is also called (It calls UpdateFonts). If I have my system DPI set to 150% (>96 dpi), there is a call to compare DPI settings to the XTP_DEFAULT_DISPLAY_DPI value. If the system DPI is > XTP_DEFAULT_DISPLAY_DPI, the RefreshMetrics code correctly calculates the m_nEditHeight (using m_nFontHeight).

That is, if I have high DPI, the previous calculation issue is compensated for and the ribbon displays just fine. I can easily switch between themes on a high-res monitor with no issue - as long as the dpi is > 96.

Can someone at CJ take a look at the two sets of paint manager code and confirm if this is a problem? I'm thinking that I can subclass the 2013 PM and create that and set the PM using the command bars SetPaintManager. Then I'd have to copy the RefreshMetrics code and set the m_nEditHeight by just removing that test against the XTP_DEFAULT_DISPLAY_DPI value (just comment out the test).

We are using 16.3.x. Perhaps this is fixed in 16.4? I see the release notes mention a number of other issues we see with the Office2013 theme.

Indeed, I agree. Perhaps what is needed is some default behavior that can be turned on or off. As for my changes, they mostly work but testers just let me know yesterday that they can still cause issues. The claim now is that they have managed to cause the icons and text font to return to "normal" size but the ribbon height remains as if the larger icon and text size is still set So apparently I have more work to do.