From: Ingo Schwarze <schwarze@usta.de> To: "Anthony J. Bentley" <anthony@anjbe.name> Cc: tech@mandoc.bsd.lv Subject: Re: Improper formatting of table with T& Date: Sun, 28 Mar 2021 22:36:56 +0200 [thread overview] Message-ID: <YGDo6DpTQu0p3fDY@asta-kit.de> (raw) In-Reply-To: <36636-1615006453.870094@W8oS.rk2z.-A1C> Hi Anthony, Anthony J. Bentley wrote on Fri, Mar 05, 2021 at 09:54:13PM -0700: > mairix(1) contains this table: > > .TS > box tab(&); > lb | lb | lb | lb. > letter & short for & example & meaning > = > .T& > l | l | l | l. > d & days & 3d & 3 days > w & weeks & 2w & 2 weeks (14 days) > m & months & 5m & 5 months (150 days) > y & years & 4y & 4 years (4*365 days) > .TE > > groff renders it like so: > > +--------+-------------+-----------+-----------------------+ > |letter | short for | example | meaning | > +--------+-------------+-----------+-----------------------+ I consider this line a bug in groff; it should be +========+=============+===========+=======================+ like with mandoc. The groff tbl(1) manual page says: If a data line consists of only ‘_’ or ‘=’, a single or double line, respectively, is drawn across the table at that point; ... If you actually wanted "+--------+------ ...", you would have to specify letter & short for & example & meaning - i.e. a dash rather than an equal sign after the header data. Do you agree? > |d | days | 3d | 3 days | > |w | weeks | 2w | 2 weeks (14 days) | > |m | months | 5m | 5 months (150 days) | > |y | years | 4y | 4 years (4*365 days) | > +--------+-------------+-----------+-----------------------+ > > mandoc renders it similarly, but bolds both the header's bottom > border and the first line following (the 'days' line): > > +--------+-------------+-----------+-----------------------+ > |letter | short for | example | meaning | > +========+=============+===========+=======================+ > |d | days | 3d | 3 days | The text in this line being bold looks like a mandoc bug to me. The author's intention clearly is to use the "l | l | ..." format without the b modifiers. > |w | weeks | 2w | 2 weeks (14 days) | > |m | months | 5m | 5 months (150 days) | > |y | years | 4y | 4 years (4*365 days) | > +--------+-------------+-----------+-----------------------+ > > I couldn't find any explanation in our tbl(7) page of what T& does, > although it's mentioned briefly in the "Layout" section. We should > probably document it somewhere. I admit the documentation is terse, it says in our tbl(7): The table layout follows an Options line or a roff(7) TS or T& macro. So "l | l | l | l" is not data but a layout line even though it occurs after the first data line. How do you think should the wording be improved for additional clarity, such that it doesn't remain too terse but doesn't turn wordy and cumbersome either? I guess an improvement is likely possible. Writing the table as .TS box tab(&); lb | lb | lb | lb l | l | l | l. letter & short for & example & meaning = d & days & 3d & 3 days [...] would be equivalent, shorter and simpler, but that's no excuse for mandoc misrendering. So, here is a candidate patch. When looking for the last layout row used, we need to look at the layout row used for the previous data line containing data, not at the previous data line outright, which might be a horizontal ruler (as it is in this case). If it is, do not restart from the first layout row but still proceed to the next data row, which in this case was just read from T&. Does it work for you? If so, is it currently OK to commit to OpenBSD, or is there something i should pay attention to, such as release preparations or anything else that might be relevant? I must admit i'm a bit out of the loop right now - my fault, sorry for that. Some many insects - winter must be fading. Yours, Ingo Index: tbl_data.c =================================================================== RCS file: /cvs/src/usr.bin/mandoc/tbl_data.c,v retrieving revision 1.40 diff -u -p -r1.40 tbl_data.c --- tbl_data.c 11 Jan 2020 20:48:13 -0000 1.40 +++ tbl_data.c 28 Mar 2021 20:25:35 -0000 @@ -242,10 +242,11 @@ tbl_data(struct tbl_node *tbl, int ln, c struct tbl_cell *cp; struct tbl_span *sp; - rp = (sp = tbl->last_span) == NULL ? tbl->first_row : - sp->pos == TBL_SPAN_DATA && sp->layout->next != NULL ? - sp->layout->next : sp->layout; - + for (sp = tbl->last_span; sp != NULL; sp = sp->prev) + if (sp->pos == TBL_SPAN_DATA) + break; + rp = sp == NULL ? tbl->first_row : + sp->layout->next == NULL ? sp->layout : sp->layout->next; assert(rp != NULL); if (p[1] == '\0') { -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv
next prev parent reply other threads:[~2021-03-28 20:37 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-06 4:54 Anthony J. Bentley 2021-03-28 20:36 ` Ingo Schwarze [this message] 2021-03-29 0:33 ` Ingo Schwarze 2021-04-07 9:34 ` Anthony J. Bentley
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YGDo6DpTQu0p3fDY@asta-kit.de \ --to=schwarze@usta.de \ --cc=anthony@anjbe.name \ --cc=tech@mandoc.bsd.lv \ --subject='Re: Improper formatting of table with T&' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).