Follow-up Comment #1, bug #68671 (group groff): Hi Deri,
[comment #0 original submission:]
> The issue is that groff has 2 ways of setting the line width:-
>
> Mode 1 (the original - used by tbl if you include linesize(n)) is to make
> lines proportional to the current font size.
This is a dusty corner for me, but as I understand it, that is supposed to be
what a negative line thickness means. This quantity is not tracked in the
formatter _except_ as a drawing command parameter.
_groff_(7):
Drawing commands
...
Circles, ellipses, and polygons can be drawn stroked or filled.
These are independent properties; if you want a filled, stroked
figure, you must draw the same figure twice using each drawing
command. A filled figure is always smaller than an outlined one
because the former is drawn only within its defined area, whereas
strokes have a line thickness (set with \D't').
...
\D't n'
Set stroke thickness of geometric objects to to n basic
units. A zero n selects the minimum supported thickness. A
negative n selects a thickness proportional to the type
size; this is the default.
...
(I see a doubled word typo. Fixing in my working copy.)
> Mode 2 (a groff extension) is to use the drawing command \D't n'
> (millipoints).
>
> grops starts up in mode 1 (lines are proportional to current font size) the
> first time you used \D't nnn' it switched to mode 2 and font size changes do
> not affect line width. The only way to switch back to mode 1 is to issue \D't
> -1'.
I don't think GNU _troff_ has any notion of "mode 1" or "mode 2".
I think what you are observing is the product of a few interacting phenomena:
1. The formatter doesn't even _have_ a "line thickness" property; this is a
property of some (not all) output drivers, exposed only via the 't' drawing
command.
[https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/input.cpp?h=1.24.1#n10406
You can see here that GNU _troff_ has no special logic to interpret a 't'
drawing
command]--[https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/src/roff/troff/input.cpp?h=1.24.1#n10523
the formatter blindly passes it to the output device, the same as any
extension.] And `t` **is** in fact an extension; CSTR #54 makes no mention of
it (screenshot attached).
I perceive a possible documentation gap here; I suspect that the man page of
every output driver that implements the `t` drawing extension command should
document its semantics, and those semantics should be as described above for
internal consistency.
2. GNU _tbl_ does not bother to configure a line thickness unless the user
specifies the `linesize()` region option.
_tbl_(1):
linesize(n) Draw lines or rules (e.g., from box) with a
thickness of n points. The default is the current
type size when the region begins. This option has
no effect on terminal devices.
There may be a problem here. The default isn't in fact the **formatter**'s
default (what is described here), but the formatter's **current state**. Even
more precisely, it's the **output driver**'s current state, which, if it
supports the `t` drawing extension command at all, we expect it to absorb and
interpret as we document.
As evidence, here's a simple boxed table as prepared by GNU _tbl_, with all
the drawing commands filtered:
$ printf '.sp 1i\n.TS\nbox;\nL.\nfoo\n.TE\n' | tbl | grep D
\h'|\n[3cd0]u'\D'l |\n[3cd1]u 0'\c
\v'.25m'\h'\n[3cd1]u'\s[\n[3lps]]\D'l 0 |\n[3rt0]u-1v'\s0
\v'.25m'\h'\n[3cd0]u'\s[\n[3lps]]\D'l 0 |\n[3rt0]u-1v'\s0
\h'|\n[3cd0]u'\D'l |\n[3cd1]u 0'\c
Not a `\D't'` in sight.
If the user throws down a `\D't 24'` right before a `.TS`, and does not use
the `linesize()` region option, any rules in the ensuing table gonna be
thicc.
I tentatively conclude that GNU _tbl_'s implementation is correct and the
documentation wrong. But we could change tbl to save the configured line
thickness when entering the table region, explicitly set it (to '-1' if not
user-specified), and then restore the saved line thickness when exiting the
table region.
3. Judging by your file #58940 LineThk-examples2.pdf exhibit, it appears to
me that the vinculum in an _eqn_ fraction is thicker when the equation is set
inside a _pic_ box than when the equation is not thus wrapped. That seems
inconsistent, and potentially a bug (or a "NEWS"-worthy feature change if we
alter it).
4. GNU _pic_ steps on the line thickness, explicitly setting it to '-1'.
Like GNU _tbl_, it performs no save/restore dance.
$ printf '.PS\ncircle "dig here";\n.PE' | pic | grep D
\D't -1.000p'\h'1.000p'
\h'0.000i'\v'0.250i'\D'c 0.500i'
These 4 items are all potentially future tickets. I welcome views and other
feedback on them.
> gropdf starts up in mode 2.
>
> The attached patch fixes gropdf to behave like grops.
I think this is a sound change.
> The attached pdf shows the result of tests with postscript and pdf side by
> side after the patch applied.
Looks good to me!
> As we are currently in code freeze it will be applied after 1.24.0.
The 1.25 RC process has been hard on our code freeze, and a code freeze
doesn't categorically prohibit bug fixes.
Since this defect (a) has low transitive fallout (a _gropdf_ bug can't create
many problems elsewhere, unlike a formatter or preprocessor change); (b) is a
long-standing problem affecting several _groff_ releases; and (c) has had real
users complaining about it vs. being detected only by internal auditing, I
think it's well worth committing to the master branch before 1.25 final.
Preferably before 1.25.0.rc3, which I **hope** to tag this weekend, so that we
can get it into folks' hot sweaty hands and increase our odds of catching any
undesired side effects. (Hard to imagine, though--at least none that aren't
already in play due to the ill-definedness outlined by the 4 potential new
tickets I listed.)
But if you want to be more conservative than that with _gropdf_, I'll
understand.
Want to go for it?
(file #58941)
_______________________________________________________
Additional Item Attachment:
Name: cstr_54_drawing_command_summary.png Size: 153KiB
<https://file.savannah.gnu.org/file/cstr_54_drawing_command_summary.png?file_id=58941>
AGPL NOTICE
These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://savannah.gnu.org/source/savane-16e566e40609935a34195c2fa79072f4115fb9b6.tar.gz
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68671>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
