-Brading Software Message Board
+--Forum: Mp3/Tag Studio Support and Bug Reports
+---Topic: 120/96 DPI problem with user-interface started by dsperber
Posted by: dsperber on Jan. 04 2008,02:02
I'd like to report a bug. This is actually a very common bug that I've seen in many many products, but I am still obliged to report it to you:
RMB on Windows desktop -> Properties on menu->
Display Properties dialog -> Settings tab -> Advanced button
General tab -> Display box "DPI Setting"
Windows default is "normal fonts (96DPI)". But with large monitors and very high resolution (e.g. 1152x864, 1280x960, etc.) the displayed size of text characters at "normal fonts (96DPI)" is very very tiny.
Windows provides an alternative of "large fonts (120DPI)", which I have always selected. This provides significantly larger and clearer text characters (i.e. the font looks like it has "more ink" and is thus darker and sharper, and much more readable).
Unfortunately, many software developers generally do not take into account the 120/96 factor when drawing user interface dialogs. Placement of text strings, the amount of room allowed for text strings, controls, etc., all are affected by the 120/96 factor but only a few savvy developers compensate accordingly.
In the case of MP3 Tag Studio 3, unfortunately this very problem is seen. I am attaching two screenshots... one at "normal fonts (96DPI)" and the second at "large fonts (120DPI)".
If you look at the right side of the two windows can see the difference in how your controls are drawn and placed in the two versions. Specifically the right side of the window is chopped off at "large fonts (120DPI)", though fortunately this appears to be mostly cosmetic in that you really haven't chopped off any text or mis-drawn something serious, which is quite common in other products. In fact, the "WRITE CHANGES" button still works... even though the control itself is truncated on the right (it is not truncated at "normal fonts (96DPI)".
Notice that even the painting of the Title Bar of the window is different at the two font sizes. Don't know how to explain it, but it's true.
However what makes your 120/96 problem more serious is that the major functions of the window do not work when "large fonts (120DPI)" is in effect! It cannot be resized (horizontally or vertically).
Furthermore, if I try to change the width of the Explorer tree on the left it will in fact change, but the rest of the window does not resize and redraw accordingly. Instead, the right side of the window remains unaltered but the widened Explorer tree is now partially obscured by the right side of the window which has not moved accordingly. If I make the Explore tree narrower it works, but again the right side of the window remains unaltered.
In contrast, in "normal fonts (96DPI)" mode resizing of the Explorer tree causes the rest of the window to redraw and resize appropriately so that there is never any wasted space and everything is always correctly visible. Also the program window as a whole can be resized horizontally and vertically by dragging the edges. Unfortunately, none of this works in "large fonts (120DPI)" mode. I am forced to temporarily go back to "normal fonts (96DPI)" and re-boot to make changes to the size of the window, and then go back to my "large fonts (120DPI)" and re-boot again to see the results of that change.
I think you'll agree this is undesirable, and broken.
I first started using MP3-Tag Studio back in 2003, and this problem was there EVEN THEN! I even sent an email about it (but did not know about this forum to report bugs), though I got no response. And now, four years later, I see that the problem still exists.
Again, these user-interface issues are very common in many software products. It's as if the developers never even knew (or anticipated in the software) about "normal fonts" vs. "large fonts" or that resulting 120/96 issues need to be supported in user-interface dialog programming.
Hopefully you can address this issue in a future release of the product.
Thanks.
P.S. - sorry for the small attachments, as 51200 is the limit.
Posted by: dsperber on Jan. 04 2008,02:03
Here's the second screenshot, of "normal fonts (96DPI)".
Sorry, but the Forum software only allows adding one attachment per post.
Posted by: Magnus Brading on Jan. 04 2008,11:43
Thanks for your feedback and detailed bug report. You can find more info about this problem e.g. here:
< http://www.magnusbrading.com/cgi-bin....;t=1111 >
As you can see in that thread, this is sadly a little problematic to fix in a "perfect" way. :-/ But as you say, it should work mostly ok in the current 3.5 betas, even though it might look a little off at some places.
Also, you can try the "-resize" command-line switch to enable the window resizing feature in large fonts mode, even though it might make the GUI issues worse in some cases (and that's why it's auto-disabled for large fonts setups in the first place).
Posted by: dsperber on Jan. 04 2008,20:54
Thanks for the response.
I think I will just "live with it", since it appears nothing significantly functional is actually lost by the current GUI limitations or anomalies in large fonts mode.
Setting up the size and dimensions of both the MTS window and internal Explorer tree area can be done in small fonts mode and carries over when rebooted back to large fonts mode, and since this is pretty much a one-time task that never really needs to be done again once I find an overall sizing that I'm satisfied with, I'll can live with this approach.
Also, when in large fonts mode and editing tags manually I can still either push the "write changes" button (which does work) or simply press the ENTER key, so that functionality is not hampered either.
As to why the Title Bar is painted differently based on the size of fonts, well I don't know but it affects nothing functional either.
All in all, the program does everything I need or even want... even with its very minor GUI issues (especially compared to some other programs which are REALLY impacted negatively by inadequate space allocated for text and controls in large fonts mode).
Mostly I just want to be able to clean a few things up when I discover problems in the tags I generally have created properly back at rip/encode time. The various different organizer/player products that I use support display/edit of tag data, and sometimes that's ID3v1 and sometimes ID3v2 so problems of non-sync between the two, or of the underlying common tag data fields themself, are readily visible and trigger my desire to clean things up.
But MTS allows me to manually edit ID3v1 and ID3v2 tag data, force values into specific tag fields, rename files, etc. Because I create my tags back at rip/encode time I don't need to perform "mass" tagging edit operations, but the capabilities offered by MTS are superb.
All in all, though a number of products provide similar or related tag display/editing capability, I think MTS is the MOST CAPABLE and EASY TO USE, and also has the most user-friendly and informative presentation of tag data (including "advanced ID3V2 tag data" fields, which I haven't seen in other products).
Posted by: Magnus Brading on Jan. 05 2008,17:37
I'm glad you like Mp3/Tag Studio, and that you will be able to use it in Large Fonts mode dispite of the GUI glitches that comes with it.
Thanks for the info about your workarounds too.
end