[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] Horizontal positioning, .nr vs \R

From: Werner LEMBERG
Subject: Re: [Groff] Horizontal positioning, .nr vs \R
Date: Mon, 19 Apr 2010 06:48:45 +0200 (CEST)

>> Can you please adjust my `R' file to trigger the bug or problem?
> Use a line length of 1.6 inches.


> By the way: instead of \h'0' you can also use \v'0', \X'', or
> probably a lot of other things that put "something else" in the
> output.

Exactly.  After some debugging I now wonder whether this is a bug at
all but rather a consequence of how \R is implemented.  An

  If you have this input

    .ll 1.6i
    aaa bbb ccc ddd eee fff ggg hhh\R':c \n[.k]'

  there will be eventually a line break after `ggg'.  However, after
  processing the space after `ggg', the line is not overfull yet, so
  troff continues to collect input until it sees the space (or in this
  case, the newline) after `hhh'.  At this point, the input line is
  longer than the line length, and the line gets broken.

  If you say

    aaa bbb ccc ddd eee fff ggg hhh
    .nr :c \n[.k]

  there has been a space right before the `.nr', so troff triggers a
  check whether we have an overfull line, breaks the line, and the
  value of \n[.k] is always correct.

  On the other hand, the \R escape sequence works completely
  transparent, this is, it leaves no traces that it has been called at
  all.  In other words, at the point \R is processed, the check for
  the overfull line hasn't been done yet and you get a value for
  \n[.k] which is even greater than the current line length.

In my opinion, it's best not to change the whole issue but to add a
warning in the documentation that you need \h'0' or something similar
in front of \R so that \n[.k] is correct within \R.

BTW, other registers like \n[.ll] are affected similarly.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]