If I open a manual page in a maximized terminal and then increase the font size ("zoom in"), the text is still readable, but the formatting is distorted. Namely, the paragraph indentation and margin are lost.

man less in xterm: No zoom

man less after font size increase in xterm (done with Shift+KeyPad +): With zoom

That harms readability. Quitting the manpage and opening it again solves the problem (the text becomes properly formatted), but it is a clumsy workaround and it usually implies that I need to navigate back to the text I was reading.

Is there any way to recover the proper formatting after changing font size? Additional information:

  • man uses less as the pager. more as the pager does not help. It does not even wrap the lines after zooming, thus causing parts of the text to disappear.

  • Bash's checkwinsize option is on.

  • Same issue in other terminals (xfce4-terminal, terminator).

  • None of less repainting keybindings (r, R, Ctrl-R, Ctrl-L) help.

  • The man page is formatted to fit the window when you run it. If you change the font size after the fact --- thereby changing what will fit in the window --- the only way that I know of to get what you want is to re-run man to re-render the content. – Andy Dalton Jul 1 '20 at 17:41
  • I found that the most pager default mode does not wrap the text but permits the user scroll left and right with < >. Not what I was looking for, but may be helpful for anyone who stumbles accross this question. – Quasímodo Jul 2 '20 at 15:53
  • Setting a lower number for the manual page width also helps (for example export MANWIDTH=80 in .bashrc), so that when the font is increased it the characters won't get out of the screen/window size. – Quasímodo Sep 25 '20 at 20:44

Manual pages, in précis and largely ignoring the preprocessing stages, work like this:

  • troff source, with one of a number of macro sets, is turned into ditroff ("device-independent troff") output format, also known in the GNU world as intermediate output format
  • ditroff output is rendered into a final output format for a specific device (or device family) by a postprocessor such as (from the GNU toolset) grotty, gropdf, grohtml, and so forth. The actual Unix postprocessors for the original ditroff were called things like devps, devX75, and devlp and there were third-party ones such as TextWare's tplus.
  • The output of the post-processor for a terminal device (grotty in the GNU toolset) is fed into one's chosen pager.

It isn't known well enough as it should be, but the input to a Unix pager is what one would feed to a Teletype Model 37 paper terminal in 1968, complete with overstriking for underscore, boldface, and fancy bullets in bulleted lists. The pager then turns this into the control sequences appropriate to the actual terminal type. (Most Unix pagers cannot handle the fancy overstruck bullets, and they don't come out as the crossed circles, a + overstruck by an o, that they actually are in 7-bit mode.)

Some pagers, such as less can sort of handle the "new" terminal encoding from ECMA-48, first published in 1976 and used on video terminals, but they aren't particularly smart about it and can go wrong if one uses anything but the most basic ECMA-48 functionality.

grotty can output either of these. Sad to say, it is usually forced by some local configuration file to use the old 1968 paper terminal output format.

By the time that things reach the pager, the document has already been formatted to a particular device width, by the post-processor (which converts "device-independent" into "device-specific" remember). less, more, and most aren't responsible for the wrapping, and don't re-wrap. The best that you will get is, as you have discovered, sideways scrolling from these pagers if the terminal width is reduced below what width was used to format the document.

You can possibly get closer to a reflowing manual page by using one of the other output formats, but this will obviously not involve a Unix pager as the final document viewer.

Further reading

  • Thank you for your thorough answer, quite a time travel! I am only usure about the statement "less, more, and most aren't responsible for the wrapping, and don't re-wrap". It can be seen in my second screenshot that less does re-wrap after zooming in, even though the final output format had already been rendered at that time. Am I missing some vocabulary distinction there? – Quasímodo Jul 3 '20 at 13:36
  • Quite the opposite can actually be seen. The line breaks have remained exactly where they were and no re-wrapping has happened at all. – JdeBP Jul 3 '20 at 14:31
  • True, then it is a vocabulary distinction indeed. I used the term "re-wrap" to indicate those extra line breaks that showed up after zooming in. – Quasímodo Jul 3 '20 at 14:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.