Need larger display font size for Thunderbird message list/pane and folder list/pane
Categories
(Thunderbird :: Mail Window Front End, defect)
Tracking
(Not tracked)
People
(Reporter: hyperrog, Assigned: aleca)
References
(Blocks 1 open bug)
Details
(Keywords: access)
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/531.22.7 (KHTML, like Gecko) Version/4.0.5 Safari/531.22.7 Build Identifier: 3.0.4 See bug #471231 for FireFox which describes the issue perfectly. For both older users, visually impaired users, and displays with high resolution, the main window font for the message list is just too small. Even old fashioned Eudora let you set the font size for the message list. Reproducible: Always Steps to Reproduce: 1. Open Thunderbird with screen resolution of 1440 x 900 on MacBook Pro. 2. Find someone over 50 to read it, or just try to read through the last month's email to find something. 3. Actual Results: It's very difficult to read on higher resolution screens for this over-50 person. Expected Results: There is a "display" preference, which should have a font size control for the message list and mailboxes, etc. in the main display.
Comment 1•14 years ago
|
||
workaround |
layout.css.devPixelsPerPx=1.1 can be used for your purpose. It's known as simple workaround of problem around system DPI value setting on MS Win. See bug 549919 and bug 426788 for the problems. The prefs is similar to value internally used in tab zooming of Fx. If the prefs is changed, it's applied to all dots including UI part such as menu. Because the prefs is defined as "integer" in Tb 3.0, it's imposible to set 1.1 or 1.05 with Tb 3.0.x. However, the prefs is already defined as "string" in Tb 3.1 or later as Fx 3.6 already done, value like 1.05 or 1.1 can be specified on Tb. AFAIK, Mac already abandoned "always 72DPI at physical display" and Mac also lies on "physical DPI value of physical display" as MS Win does since initial(AFAIK, chosen value by Apple is fortunately same as or near to Win's 96DPI). I think similar workaround on MS Win is possible on Mac.
Comment 2•14 years ago
|
||
> Expected Results:
> There is a "display" preference, which should have a font size control for
> the message list and mailboxes, etc. in the main display.
As Fx/Tb uses Px in font size setting, easy to use magnifier is better to be provided by application. But, I believe responsible person of too small glyph size/too small image size problem due to mismatch between "higher than before physical DPI of physical display" and "unchanged internal system DPI value" is mainly OS.
Updated•13 years ago
|
Comment 5•13 years ago
|
||
Marco shall this bug block 396347 ?
Updated•10 years ago
|
Comment 9•10 years ago
|
||
Sorry I posted another duplicate, for some reason this one didnt come up when searching. BUT ... the number of duplicates would suggest how much this feature is wanted. Wada's suggestion is not applicable for several reasons 1: Most people can't figure out config editor - hiding an important setting in a "warranty voiding" section of a product is a non-starter for 99% of TB users. 2: Its really dangerous to set that one, I set it to +2 which seemed obvious to me (I presumed it meant 2 points bigger, this screwed up config editor so bad i had to hack prefs.js to get it back - 99.99% of TB users wouldnt have figured that out. 3: Even knowing the setting existed I didnt guess it could be fractional, again noone will figure that out. The setting actually does a reasonable job of improving the interface, I've adjusted mine so now - as a TB expert - I'm fine, but please lets get a UI fix into Preferences/Display for the 99% of TB users who dont read this, shouldn't touch Config Editor editor and of whom a sizable fraction can't read TB's display.
Comment 10•10 years ago
|
||
A problem in layout.css.devPixelsPerPx=1.2 like solution : icon is usually larger than we want when text size is good for us. A simplest/popular solution in such case, which was used by many browser users for long time : "Theme & Font Size Changer" Addon
Comment 11•10 years ago
|
||
The layout.css.devPixelsPerPx=1.2 solution has many many UI bugs, (apart from the high risk of completely bricking TB) there are far too many UI bugs to list here, it seems UI elements randomly pay attention to it or not, so sub-menus appear in the middle of the screen and so on. The most important requirment is being able to turn it on or off. Theme & Font Size Changer only works for a change of a couple of points, any bigger than that and the text overflows the boxes it is in. Its main advantage is that you can turn it on or off (as you switch between working with and without glasses), while layout.css.devPixelsPerPx requires running config editor - with the risk of bricking TB.
Comment 12•10 years ago
|
||
I've added bug #1017625 for the worst case where once devPixels is set (correctly) the Preferences editor is made unusable so you cant change it back (or change any other preferences).
Comment 13•10 years ago
|
||
(In reply to Mitra Ardron from comment #12) > I've added bug #1017625 for the worst case where once devPixels is set (correctly) > the Preferences editor is made unusable so you cant change it back (or change any other preferences). It looks that "Panel Hight" attribute etc. is not relative to other attribute such as font-size, line-hight, window size etc. And, scrollbar/window-resize-small-box-at-corner like element is never defined for element which represent a panel or box in UI. It's never fault in feature such as layout.css.devPixelsPerPx. It's merely fault in UI design and implementatin especially in CSS setting.
Comment 15•9 years ago
|
||
see also bug 541379
Comment 16•9 years ago
|
||
One can accomplish this via Chromedit with the following code: tree > treechildren { font-size: value-larger-than-default !important; } That being said, I think we should investigate adding a way to increase font size. We have a couple options: 1. Allow *all* font to be increased. (Pros: Universally better accessibility. Cons: May totally trash the UI) 2. Allow certain, more important elements to have increased font size (For example my line of CSS code above). (Pros: Better accessibility for the important information, not as damaging to the UI. Cons: Part of the UI will still be hard to read, inconsistency in font size.) 3. Keep this as an add-on. I'm leaning towards #2 myself, which will also be a lot easier to implement.
Comment 17•6 years ago
|
||
Theme Font and Size Changer stopped working in Thunderbird 52.5. The Chromeedit workaround is still kinda-sorta working. However, a Chromedit size which fits in the message list, and the narrow rows there, is still uncomfortably small for reaing messages. An integrated setting might work better than add-ons and crude hacks for when the add-ons fail.
Comment 18•6 years ago
|
||
(In reply to MarjaE from comment #17) > Theme Font and Size Changer stopped working in Thunderbird 52.5. Yeah, someone reported the same thing in bug 1428440. Highly doubtful it was caused by anything changed in Thunderbird - rather, that addon just seems to stop working on a regular basis because of some policy the author has in place.
Comment 22•6 years ago
|
||
This seems like something that shouldn't need an (unsupported) add-on to address. A pretty reasonable solution was proposed in Comment 16 four years ago. Is it still a reasonable solution? As-is, the user interface is less than usable for nearly everyone who doesn't have eyes like a hawk. The population of email users is steadily aging, and that makes readability an increasingly important attribute. This issue probably should be considered higher priority than it has been treated to this point.
Comment 23•6 years ago
|
||
Totally agree, as someone making that transition to needing glasses, TB is one of the few things that I cannot use without them, almost everything else (especially anything browser based) allows a key combination or gesture to expand the text. TB only allows it within the message pain, but not with the critical list of subjects. The extension was entirely useless, I had to disable it - I'd go back and check why, but its incompatible with current TB anyway. <RANT>but unfortunately that is the norm for TB extensions (with notable exceptions - they rarely work properly, and fail as TB is revised (5 out of 7 of my extensions are currently disabled as incompatible), but are used as an reason for not doing anything about the actual issue. </RANT>
Comment 24•6 years ago
|
||
I am the owner of one duplicate. I really hope to see this implemented. Judging by the number of duplicate tickets this is a really needed feature, right now the only solution is changing layout.css.devPixelsPerPx which is something the average user doesn't know how to do, or to use an add-on (with 15,000 users) that breaks regularly every 90 days..
Comment 26•5 years ago
|
||
@Wayne - that extension doesnt just stop working - as in incompatible, it generally doesn't work anyway, its always been an essentially unusable extension, mucking up the display badly enough to make it an absolute last resort. It beats me that noone has been able to fix this for 8 years, given that EVERY other application I use on the Mac has had a way to zoom in and out for ever. - Mitra
Comment 27•5 years ago
|
||
We're now at 6k people using the last resort of the last resort ;) Wayne might have actually sped up the approval of the TB58+ fixed version. I never intended to actually debug or even develop this ****, but given that my blog visitor count casually DOUBLED after August 6th, the release day of TB60, there's clear demand of this functionality. I guess I could hard code that into some stylesheet for myself, but there are people that are unable to install a XPI file locally or even rename a ZIP file to XPI. This needs to be core functionality of Thunderbird, not a fragile addon.
Comment hidden (metoo) |
Comment hidden (metoo) |
Comment hidden (metoo) |
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 34•4 years ago
|
||
I think this bug highlights an important issue of Thunderbird in terms of accessibility, which is the fact that font-sizes are hard coded via CSS and it's not possible to zoom in/out the whole interface at once.
The entire UI should be fluid, allowing users to increase/decrease font-size, alongside icons, and all the other scalable elements.
Let's discuss a plan of action and implement this into core in a sane and maintainable way.
I think this could be done in various steps.
- Implement a global pref to allow users controlling the global font-size. This could be achieved by adding a
font-size
attribute to the window style, and all the elements will follow along. - Adapt the various hard coded font-sizes to use
em
orrem
values instead of pixels. - Make the icons and other elements scale alongside the text to maintain a balanced UI.
Thoughts?
Comment 35•4 years ago
|
||
Looks (very) good for me!
Thanks Alessandro
Comment 36•4 years ago
|
||
The hard coded font sizes aren't coded like font-size: 16px;
but with font: message-box
this sets the system default font with its family, size etc.
It should be possible that we either set globally something like font-size: 1.2em;
or this only set on single elements like #folderTree
or #threadTree
. Mac may be a bit special as we set a special font on #folderTree to look more like Finder.
Comment 37•4 years ago
|
||
(In reply to Richard Marti (:Paenglab) from comment #36)
The hard coded font sizes aren't coded like
font-size: 16px;
but withfont: message-box
this sets the system default font with its family, size etc.It should be possible that we either set globally something like
font-size: 1.2em;
or this only set on single elements like#folderTree
or#threadTree
. Mac may be a bit special as we set a special font on #folderTree to look more like Finder.
You may also have a look of the official Apple mail application on Mac OS, which provides larger font for trees and lists.
Comment 38•4 years ago
|
||
The noticable thing is that on a mac Command-= gets a font increase (for content) in pretty much any app EXCEPT TB's message lists. It even works for the lower message pane in TB, so the critical outcome is using some measure that is susceptible to that mechanism of indicating quickly that the text is too small to read.
If that works, then many, if not all, the accessibility issues of making a bad choice are fixed, because people can zoom in to what is comfortable for them. (depending for example on ambient light/screen reflexions, whether they have their glasses on, even time of day )
Comment 39•4 years ago
|
||
First, thanks for taking this.
I don't have any thoughts on the technical approach. I do offer the following
- Readability areas most important to me, and perhaps for others, is where content changes - message list, folder list and message preview - but mostly the first two. I personally don't need larger text in column headers and menus, and places that have icons - though I do understand it may be desirable to have the entire UI zoom at the same rate by default. If it does, then we may need to be able to control individual panes independently?
- I would like the default keyboard zoom functionality to remain unchanged, which is to say it should only zoom the message preview, not the entire UI. If there is a desire to zoom the entire UI with a key combo then create a new one (with shift?) [interesting, on Mac command+shift+= zooms in, but command+shift+- does not zoom out - ditto on firefox]
- Many, and perhaps most, of support requests for size control come from older and handicapped users. And based on personal experience I'd guess that in recent years many more older users are using laptops with modest sized screens, not full screen monitors.
- To echo Mitra's comment, users are understandably surprised/disappointed that Thunderbird doesn't offer size control when most other apps do - we're way behind the curve in usability here
- I don't know if it is wanted or needed, but toolbar has no zoom widget
- I am concerned that larger font sizes not unduly increase whitespace between lines because vertical space is at a premium on laptops (obviously, I highly values screen real estate)
FWIW, on my MacBook Air 2012 at default resolution the message list is horribly small. I currently use the following to make it readable with screen 24" from my eyes (on Firefox I use something larger, 16, to comfortably read for hours at a time and I zoom in to 110% for example as needed)
/* Threads Pane font */
#threadTree >treechildren::-moz-tree-cell-text {
font-size: 10pt !important;
}
Comment 40•4 years ago
|
||
(In reply to Alessandro Castellani (:aleca) from comment #34)
The entire UI should be fluid, allowing users to increase/decrease font-size, alongside icons, and all the other scalable elements.
Agreed.
- Implement a global pref to allow users controlling the global font-size. This could be achieved by adding a
font-size
attribute to the window style, and all the elements will follow along.- Adapt the various hard coded font-sizes to use
em
orrem
values instead of pixels.
I'm not sure px vs em/rem changes things. If it does, sure. (It used to be an issue, but I think now pxs are also zoomed).
- Make the icons and other elements scale alongside the text to maintain a balanced UI.
Yup, many icons are already svg.
Updated•2 years ago
|
Comment 42•2 years ago
|
||
Folder list text may only be a couple mm high, not sure who can read that or how.
Comment 43•2 years ago
|
||
I think we have really provided the scaling of fonts requested in this bug. With the layout.css.devPixelsPerPx preference.
Sure we still have a delineation for zoom of content and scaling of the chrome, but that is a good thing in my opinion.
What is missing and has been missing for years is a user interface to allow the user to actually manage these preferences. Bug 1708595 for providing a UI for scaling user interface and something more obvious than expecting the user to know about Ctrl + and - to scale content.
Comment 44•2 years ago
|
||
How does this "pixels per pixel" setting differ from full-page zoom, with all its bugs?
For example, full-page zoom affects every single object in the same proportion. So if it doubles or triples the height of body text, it also doubles or triples the height of header text, icons, images, etc. In Firefox, by the time body text is a good readable size, header text would often be awkwardly or unreadably large, images would introduce horizontal scrolling, etc. In Thunderbird, it might work for the lists we're discussing here, but create trouble elsewhere.
Reporter | ||
Comment 45•2 years ago
|
||
Is it my imagination, or did recent updates to Thunderbird (I'm using 91.2.0 (64-bit) at this moment) make the main text display font a pixel smaller?
I notice that I originally commented on this 12 years ago, and as I am now well past "50", perhaps it is just me, but this seems to be a more important issue than ever, not just to me, but to the now much-more relevant issue of accessibility.
Why is it so difficult to have a font size setting for the main window with the list of messages?
Assignee | ||
Comment 46•2 years ago
|
||
Is it my imagination, or did recent updates to Thunderbird (I'm using 91.2.0 (64-bit) at this moment) make the main text display font a pixel smaller?
We didn't decrease the font size, but what do you mean by "main text display"? Is the font in the message body, or the message threads, or the folder pane, or the whole UI in general?
Would you be able to share a screenshot without any sensitive information?
Why is it so difficult to have a font size setting for the main window with the list of messages?
That's because every section of Thunderbird has its own style, with its own hardcoded CSS font size, and its own CSS file.
That's not a great situation and it makes it very hard to achieve visual consistency.
We're working towards that, we're cleaning up our styling, we implemented global UI density controls, and we're slowly expanding those options to affect the entire UI.
We have the feature to offer a global font size control for the whole UI in the roadmap.
Comment 47•2 years ago
|
||
Please do add some kind of global font size control - its been desperately needed for 12 years now, its pretty much the only app that I use that doesn't have simple keyboard control of font size.
Assignee | ||
Comment 48•2 years ago
|
||
I started working on it in this bug 1715364.
Closing this as a duplicate.
Description
•