Cut off lines

[moneytoo]

When I open lvm(8) page in Chrome on Android phone, some lines are cut off.

Same issue is with few other pages, like dmsetup(8):

Enabling "Request desktop site" in Chrome just moves cut off lines elsewhere.

Same on desktop:

The culprit seems to be the use of text-indent in mandoc output and there is significant number of those.

[stapelberg]

@ischwarze, the use of negative text-indent seems to not play nice with overflow: hidden, see above. Are we doing something wrong in our layout, or should we change mandoc to use a different technique?

[ischwarze]

@stapelberg First, i can't reproduce the issue with Firefox 54.0. I don't claim it is a bug in Chrome, but it might possibly be.

Second point, i don't see overflow:hidden anywhere in the official mandoc codebase or in the official mandoc.css file, neither in the current version, nor can i find it in the history by grepping the CVS ",v" files. So maybe you added "hidden" yourself, and the result is that sometimes, something gets hidden? Maybe that's not what happened, but if it is not, where did the "hidden" come from?

Third point, i'm anything but a CSS expert, and your CSS and Javascript are way too complicated for me to understand, so i really cannot usefully comment on how you should change it, beyond saying that it might possibly be beneficial to radically simplify it.

Fourth point, if you have any specific suggestions on how to make the mandoc CSS support better, i'll gladly evaluate them. If somebody finds a way to get rid of negative indents, i would be glad about that in particular. But i suspect it won't be easy. The official mandoc.css took a long time and much tuning to get it to work at all, and the trick with the negative indent is crucial to get hanging paragraphs and lists to format as intended.

[stapelberg]

Thanks for the details. The overflow: hidden indeed is in our CSS, but its interaction with the negative text-indent is still surprising.

I’ll have to distill this to a minimum working example and possibly ask people for help, as I’m not a CSS expert either. If anyone has any pointers, that’d be very welcome.

[ischwarze]

Hi Michael,

Michael Stapelberg wrote on Sun, Jul 02, 2017 at 04:36:08PM +0000:

I'll have to distill this to a minimum working example and possibly ask people for help, as I'm not a CSS expert either.

That sounds like a reasonable plan.

Please be sure to tell me about any findings that might help to improve the quality or portability of mandoc CSS support, in particular if they can be implemented without complicating the code in any major way.

Thanks, Ingo

[moneytoo]

Looking for example at the lvm(8) page, both .TP and .HP macros result in the save visual.

.TP
.B lvscan
Scan (all disks) for Logical Volumes.
.PD
.P

...

.HP
.BR \-h | \-? | \-\-help
.br
Display the help text.
.

<dl class="Bl-tag">
  <dt class="It-tag"><b>lvscan</b></dt>
  <dd class="It-tag">Scan (all disks) for Logical Volumes.</dd>
</dl>

...

<div class="Pp" style="margin-left: 5.00ex; text-indent: -5.00ex;"><b>-h</b>|<b>-?</b>|<b>--help</b>
<div style="height: 0.00em;"> </div>
Display the help text.</div>

The mandoc output with the mandoc shipped CSS has different indent widths.

This is just something I noticed. I'm not familiar with the formatting at all. Thanks both of you guys for your interest.

[ischwarze]

@moneytoo regarding "The mandoc output with the mandoc shipped CSS has different indent widths." - three answers:

1. The source code of the lvm(8) manual requests different indent widths. In the COMMANDS section, the first .TP explicitly requests an indent width of 14 en units. Subsequent .TP macros in that section, including the one for lvscan, do not specify the indent width, which means that they reuse the previously set value of 14n. An .SH, .SS, or .PP macro resets the indent width to the default of 5n; this happens at the beginning of the OPTIONS section. The .HP macros in the OPTIONS section, including the one for --help, do not specify an indent width, so they use the default of 5n.

2. In mandoc -Tlint, .TP and .IP width specifications are unimplemented. That's a missing feature which i should implement. So mandoc falls back to the mdoc(7) .Bl -tag default width of (6+2)n = 8n, which is certainly unexpected in a man(7) document.

3. The style of the lvm(8) manual page is quite crappy. Nobody should use .PD, which is officially deprecated and cannot reasonably be rendered in HTML at all. Mixing .HP with .br to fake tagged lists is also bad style. And so on. But sure, the missing feature mentioned in item 2 would also affect a properly written manual page.

[hayubeker19]

On Jul 12, 2017 8:28 PM, "Ingo Schwarze" notifications@github.com wrote:

@moneytoo regarding "The mandoc output with the mandoc shipped CSS has different indent widths." - three answers:

The source code of the lvm(8) manual requests different indent widths. In the COMMANDS section, the first .TP explicitly requests an indent width of 14 en units. Subsequent .TP macros in that section, including the one for lvscan, do not specify the indent width, which means that they reuse the previously set value of 14n. An .SH, .SS, or .PP macro resets the indent width to the default of 5n; this happens at the beginning of the OPTIONS section. The .HP macros in the OPTIONS section, including the one for --help, do not specify an indent width, so they use the default of 5n.

In mandoc -Tlint, .TP and .IP width specifications are unimplemented. That's a missing feature which i should implement. So mandoc falls back to the mdoc(7) .Bl -tag default width of (6+2)n = 8n, which is certainly unexpected in a man(7) document.

The style of the lvm(8) manual page is quite crappy. Nobody should use .PD, which is officially deprecated and cannot reasonably be rendered in HTML at all. Mixing .HP with .br to fake tagged lists is also bad style. And so on. But sure, the missing feature mentioned in item 2 would also affect a properly written manual page.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.