On Wed 14 Sep 2016 at 05:43:24 (-0400), Felix Miata wrote: > David Wright composed on 2016-09-13 13:36 (UTC-0500): > > Rather curious to see a regular participant here with a .co.uk > mailing address apparently in a university environment in a UTC-0500 > time zone. Curiosity makes it for me a recurring distraction, > wondering just what part of the world this might be, somewhere north > of Wisconsin, Minnesota or North Dakota? :-p
Three states south of ND...Kansas. > >On Thu 08 Sep 2016 at 12:53:49 (-0400), Felix Miata wrote: > >>David Wright composed on 2016-09-08 09:08 (UTC-0500): > > >>>You can play with framebuffers and kernel drivers all you like. > >>>What you cannot do is alter the layout of pixels on the screen. > > >>Absolutely true. > > >>>If you don't use a resolution that matches those pixels exactly, > >>>nothing you do can compensate. > > >>False. The difference from one resolution to the next is easily lost > >>if the screen resolution is beyond the resolving power of the eyes. > > >>>You are deluding yourself if you think you can. > > >>Been doing it for years. One factor is called natural optical > >>deterioration. There's a limit to resolving power that typically > >>gets worse with age. It's a primary reason why complaints are ever > >>made about tiny fonts accompanying increased pixel density. > > >The main reason people complain about tiny fonts > > I'd like to see a cite for the assertion of this "main" reason. > > >? is because they're > >often difficult to change, or changing them leads to undesirable > >effects, like web pages that don't re-wrap lines to take account > >of the change. > > I rather think the *main* reason is difficulty reading them, closely > followed by, or in conjunction with, their pervasiveness, which is > almost as commonly coupled with gray color instead of best contrast > black. I can't see the point of arguing about this; we're just looking down opposite ends of a telescope. From my end... The person to complain to about not being able to *read* small fonts is your optician. Small fonts exist, are useful in the right context when designed (or modified, see Knuth's metafont writings) with care, and aren't going to go away by being complained about. :) The people to complain to about inappropriate use of small screen fonts are the web designers who serve them up. However, is this practical? How many people are you going to complain to? How will you reach them? Where do they work now? So you're better off aiming for the single point of "failure": ones inability to change (enlarge) them. The main thrust of *my* posts has been aimed at the VC user, in which case the people to complain to are those serving up the small fonts: the computer manufacturer (if you can't read the CMOS screens) or the Debian installation team, not web designers. > Probably for most people, most of computing any more is within the > confines of a browser window. Now that ≤IE6 support is history, more > and more websites have taken to defining all sizes in px, with text > sizes most commonly those suited for the lowest pixel density > screens, rather rarely as large as 16px, which on a larger than > average size but also higher than average density 2560x1440 screen > is only 9.8pt, while a much more common 13px is <8pt and a not > uncommon 10px is 6.1pt. > > Others with poorer than it used to be eyesight, like myself, or at > least poorer than average, and/or higher density screens, surely get > rather tired as do I of the need to either zoom on entry to every > previously unvisited domain, or suffer the ill effects of either > configuring use of a minimum text size or disabling site styles > altogether. > > >But with an armoury of font sizes, six in my case from tiny to vast, > >there's no difficulty changing at all, as long as one is prepared > >to visit the bash prompt (or use a shell-escape). > > Easy for you to say. Do you have a realistic idea how hard it is to > do anything when the defaults start difficult to manage in the first > place, the proverbial chicken and egg problem? It's a whole lot > easier to make too big text smaller than it is to make too small > text bigger. Maybe size 6 isn't so vast when density is double the > reference standard and the acuity is below average. Good point. Perhaps it would be worth submitting a feature request to the d-i bug list to add an optional installer step that requests a larger default font size after the the keyboard language/layout etc. This could write lines in locations like /etc/default/console-setup and /boot/grub/grub.cfg. My smallest font gives me 213x66 characters on this laptop, and would be very uncomfortable to read for any length of time. But I can't claim that it's too difficult for me to be able to type in commands to investigate and change it. Some others probably would. > >It's easy to be misled by just considering the means to resolve two > >dots of lines from each other as the only function of display > >resolution. The crispness of a font depends on the angles of edges > >to which the eye is very sensitive, even when it can't resolve the > >actual dots themselves that make up that edge. > > Maybe it's time to emulate some senior eyeballs. Hang some > cheesecloth in front of your face, turn screen brightness down below > 33%, let plenty of bright sunlight into the area where the display > faces, and double or triple the normal distance between screen and > face, then try to discern any difference in crispness between the > vtty's default 9x16 font at 1280x720, and larger pixel size fonts on > the same display at a native 1920x1080. Once the threshhold is > reached, more px density is wasted. Back in the '60s or '70s, the UK often had periods of low voltage which would shrink the picture size on TVs. The Evening News would reduce the picture to demonstrate the effect to those watching on full power, and our picture would almost disappear... But I don't understand why you're worrying about a screen font being over-crisp. If you really object to paying for a higher pixel density, then why not buy a cheaper screen (if that's an option, which is unlikely with a laptop). > >>Another factor has to do with screen size and distance, not > >>necessarily caused by deterioration, but because of eyes never that > >>good to begin with, and corrective lenses that do a better job at > >>particular focal lengths. Too close and pixels can become apparent > >>and bothersome. More distance can work better. > > >If the pixels are as large as to be bothersome, then make them > >smaller, ie use a higher resolution on the screen! Why would you > >ever use a lower resolution in that case? > > Visual threshhold vs. ease of (re)configuring. For a lot of people, > the only way they know to deal with everything being too small is to > reduce resolution. Is it ideal? Of course not! Do people do it? It's > common among the simple minded and the elderly. That's why I posted https://lists.debian.org/debian-user/2016/09/msg00135.html I used to play with console-setup, both the file and dpkg-reconfigure console-setup (which requires root), and it works fine but is tedious. It's best used just for initial configuration, and would be the target of that d-i bug suggestion above. But using setfont (through aliases, to avoid having to remember font names) is so much better: instant, and affects each VC individually, so you can trade clarity with screen real-estate merely by using Ctrl-Alt-Fn switching if you have several VCs running side by side. > >>IOW: > > >>1-Don't knock it if you haven't tried it. By this I don't mean tried > >>only on Debian installations either. The default framebuffer font of > >>Debian and its derivatives is very commonly different from > >>non-Debian distros, represented by the spindly ugly thing used by > >>Ubuntu. Without Plymouth, one can typically see the initial font > >>during post is much bolder, changing somewhere along the way to the > >>desktop or login prompt to a much lighter stroked variety. If all > >>you've ever seen is the lightweight, try a (Debian) Knoppix CD or > >>DVD and you'll see what Fedora and openSUSE users see by default > >>(TerminusBold?) on their framebuffers, a font that's nicely bold and > >>forgiving of non-optimal screen resolution. > > >Well, I'm up for that. Tell me what I have to do: it's quite involved. > > Which "that" are you up for that's "quite involved"? You wrote "Don't knock it if you haven't tried it" so I'm up for trying it. > >I can blacklist my i915 module; should I replace it in /etc/modules > >with, say, the i810fb module. > > I don't diddle with any modules in tweaking vtty behavior to my satisfaction. > > >Or should I just add > >video=intelfb:mode=640x480@60,accel,hwcursor,vram=8 > >to grub's boot line? > > Dunno. What's your goal? I run all my computer displays at their maximum resolution. They are all LCD displays. (My last CRT monitor went to the tip in October 2011, the last CRT TV in February 2014.) https://lists.debian.org/debian-user/2016/09/msg00235.html suggests changing character size by changing the resolution because it's meant to be easy. I'm curious to see what happens when you run a display at sub-optimal resolution. Where does the change from the, say, 640x480 buffer to the screen's 1280x800 red/green/blue-pixels occur? Does the kernel do this in the video driver module, or does the non-linux (Dell?/Intel?) firmware on the laptop circuit boards do it? If it's any help in telling me, I know that the laptop can expand the "dots" itself to a certain extent. The POST screen and the CMOS screen has a resolution of xxxxxxx and there is an option to live with this or enlarge to full-screen. But you choose one or the other, nothing in between. You get an 80x25 character console. The enlarged characters are noticeably blurred at the edges; nothing like my crisp my-font-huge="setfont Lat15-Terminus28x14" which gives me 91x28 characters at native resolution. https://lists.debian.org/debian-user/2016/09/msg00133.html told me to remove the video driver (i915) that I normally use. I did that and found I could add an explicit framebuffer module (i810fb) which looks like it might match my hardware. I don't know where this is going. https://lists.debian.org/debian-user/2016/09/msg00235.html told me to include a video= parameter on the kernel cmdline so I modified the example on the linux kernel framebuffer page. I don't know where this is going either. That's why I need a bit of handholding. It must be easy...? > >When I want to change resolution, which keys should I press to do that? > > In which context? Grub menu? Plymouth-free vttys? Vttys with > Plymouth? Different fonts for different vttys? Well, to make an easy comparison, in the VCs. Imagine a scenario where you boot into a console with a small/medium font giving you 128x40 chars, then the sun comes out and you decide you need larger characters to compensate for the loss of contrast. I'd want more like 106x33 or even 91x28 chars. What do I press? > >And last, but not least, I need a surefire method of determining what > >resolution I have succeeded in running. With native resolution, that's > >very simple. I put some text on the screen such that the bottom line > >and rightmost character are both used, determine the pixels used in > >the character grid, multiply each with $LINES and $COLUMNS, and then > >add the unused pixels at the bottom and right edges. All done with > >a handlens. > > Or more simply, just see what fbset reports. I was talking native resolution, ie hardware. There's no arguing with the uninterpreted numbers you get by counting the little flecks of light. But I've installed fbset and will try that; thanks. I'm not sure what I type and when. Having loaded i810fb and set a video= line I found that I now lack a /dev/fb0 file so fbset just prints an error message. So I'm going down the wrong alley at the moment. > >>2-Don't expect just because you decide it's not for you that it > >>can't be for anyone else. > > >I've made no such decision. I'm just trying to understand your > >statements in terms of the physics. If you take a font with an > >x-height of 8 pixels and decrease the resolution to make it 50% > >taller and wider, why would making the font with 8 bigger pixels be > >clearer than making it with 12 pixels of the original size? You've now > >got over twice as many pixels to manipulate. > > Again, it's about reaching the resolving power threshold, or not. > More pixels in a given space is higher resolution, is higher > quality, but wasted if the resolving power limit is already reached > at 8. I'm not asserting that higher pixel density is bad, only that > past a certain point, a given set of eyeballs may not be able to > make use of more. But why throw resolution away to increase character size when you can just increase the font size instead? > >>3-Lowered resolution for the framebuffers does not necessarily > >>dictate resolution for Xorg. For the past couple of years or so, if > >>using the Intel Xorg driver, Xorg will default to the cmdline video= > >>directive, in contrast to nouveau and radeon sticking to native by > >>default, but this can be overcome via xrandr or xorg.con* or the DE. > >>I normally configure them differently, native for Xorg, reduced for > >>framebuffer. > > >Irrelevant. We're talking about linux consoles here. > > We're talking about how we get where we want to go, and the > ramifications of the various methods of getting there that depend on > which driver and/or gfx hardware is used. We're on a VC using a CLI; what has Xorg or a DE got to do with it? I'm trying to reduce the resolution of the VC so I can test your method of increasing character size and compare it with mine. > >>4-I'm not suggesting font reconfiguration can't be appropriate, only > >>that there may be an easier way that is quite suitable, particularly > >>for a machine that is shared among people with diverse visual > >>acuity. > > >I need to try your method to have an opinion about that. I've > >explained how easy it is with my method to have each VC at a different > >font size simultaneously and independently. > > You haven't to degree that I can grok how it is that you find your > method easy/fast/convenient/other. What did I omit from https://lists.debian.org/debian-user/2016/09/msg00135.html Switching is as easy as: $ my-font-vast $ echo $COLUMNS $LINES 80 25 $ my-font-tiny $ echo $COLUMNS $LINES 213 66 $ with the aliases described in the link. > >So I need to know > >your keystrokes for comparison. > > Again, which context? I boot using Grub with Gfxboot versions that > display a substantial tail of the selected stanza. The way I > configure, there's typically little stroking, typically limited to > one or more instances of Left, then holding down the BS key until > what I want removed is gone. You're not serious!? With my method, I can change the font size instantly by typing, say, $ my-font-large which is aliased to $ setfont Lat15-Terminus24x12 and you're suggesting that that might not be as easy/fast/convenient as rebooting and editing the kernel command line in the grub menu to change the display resolution! Is that a correct interpretation of what you're suggesting? Or have I got hold of the wrong end of the stick? Cheers, David.