tech@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: nabijaczleweli@nabijaczleweli.xyz
Cc: tech@mandoc.bsd.lv, 992002@bugs.debian.org
Subject: Re: [PATCH][Debian#992002] tbl: allow two-character fonts and format fonts in -Thtml
Date: Tue, 10 Aug 2021 15:43:58 +0200	[thread overview]
Message-ID: <20210810134358.GA19930@athene.usta.de> (raw)
In-Reply-To: <20210809230831.7lwnchffsqds42ax@tarta.nabijaczleweli.xyz>

Hi Nab,

Nab wrote on Tue, Aug 10, 2021 at 01:08:31AM +0200:
> On Mon, Aug 09, 2021 at 10:58:19AM +0200, Ingo Schwarze wrote:
>> Nab wrote on Sun, Aug 08, 2021 at 03:24:53PM +0200:

>>> tbl's -Thtml ignores font requests;

>> Not in CVS HEAD; see https://cvsweb.bsd.lv/mandoc/tbl_html.c revision 1.34,
>> committed on May 16 earlier this year.

> Oh, indeed. I tested and based my patch on 1.14.5 from Debian,
> didn't realise that's almost two years old by now.
> Will use the CVS next time.

Note that so far, everybody who contributed code to mandoc provided
their first and last names.  I'm not sure it is strictly required in
the legal sense, but i do consider it beneficial both for authors
and for users.  The benefit for authors is that it makes it easier
for them to exercise their rights under the Berne Convention, in
particular their moral rights under that Convention, for example
to protect themselves if somebody abuses their contribution for
slander.  The benefit for users of knowing who the Copyright holders
are is also obvious, even if the code is BSD or ISC licensed:
It makes Copyright and license audits easier and reduces the risk
of suddenly being sued by parties the users didn't even know existed.

In this case, it isn't needed because by mere chance, even though
several of your ideas remained in the committed patch, none of your
code did, because i switched from TBL_CELL_BOLD and TBL_CELL_ITALIC
to ESCAPE_FONT*.  Ideas aren't subject to Copyright, only text is,
and for crediting a person who provided bug reports, feature requests,
and ideas, a pseudonym is sufficient.

>>>     <td><span class="Li">text</span></td>
>>>     <td><b>text</b></td>
>>>     <td><i>text</i></td>

>> These become:
>>       <td><span class="Li"><b>text</b></span></td>
>>       <td><span class="Li"><i>text</i></span></td>

> This is great news! A bunch of my pages use C[BI] and the HTML renders
> look much better, thanks!

Note that i don't recommend using these fonts in manual pages.
Even with groff, typical installations don't prodide CB and CI
fonts for terminal output, which typically results in warnings
being thrown.  The details may vary among operating systems and
package managers even for the same version of groff.  Portability
to other formatters (like Heirloom, Plan 9, DWB, Solaris, neatroff)
is even more doubtful, but i don't know any details about that.

But as a rule, mandoc(1) even supports features if using them is
unwise, as long as that doesn't cause an undue burden.  One reason
to do so is making existing pages look better, no matter how good
or bad the style is that they are using.  Not supporting a feature
hurts end users - who aren't responsible for author's choices which
features to use.  But that a feature is supported by mandoc(1)
should not be misinterpreted by authors as a free pass to go on a
rampage and employ the most arcane and brittle features they manage
to find.

>>  * GNU tbl(1) appears to ignore space characters between the f
>>    modifier and the font name, so "lf   B" is the same as "lfB".

> Huh, so it does! That's not explicitly mentioned by the manual and so
> I didn't think to test it.

No, i'm not even convinced it is intentional, and relying on it in
any document would be a thoroughly bad idea.  But mandoc(1) aims to
be bug-compatible with groff unless there is a good reason to differ.

>   Now, tbl(1) says
>   Key characters can be separated by spaces or tabs.
> so consider the following document:
> -- >8 --
> .TS
> lfBI	lf BI	lf	BI	.
> a	b	c
> .TE
> -- >8 --
> (In order, none, space, tab follow 'f';
>  base64: LlRTCmxmQkkJbGYgQkkJbGYJQkkJLgphCWIJYwouVEUK)
> 
> groff renders it with a, b, and c as BI,
> but mandoc with your patch with a+b as BI and c as R, with -Tlint:
>   mandoc: ./q.1:2:14: WARNING: unknown font, \
>                       skipping request: TS f	BI	.
> 
> If you change tbl_layout.c L171 to match L75:
> -- >8 --
> -	while (p[*pos] == ' ')
> +	while (p[*pos] == ' ' || p[*pos] == '\t')
> -- >8 --
> and L187:
> -- >8 --
> -	if (strchr(" .", p[*pos + isz]) == NULL)
> +	if (strchr(" \t.", p[*pos + isz]) == NULL)
> -- >8 --
> The document renders correctly.

Done in the commit cited below, thanks for pointing out that quirk.

>> Could you please check out from CVS (instead of the last release),
>> apply the following patch, and tell me whether it looks reasonable
>> and works for you?

> Yeah, save for the tab thing above, I haven't managed to fault it,
> in tests or real pages.

Thank you very much for testing.  That patch ended up growing
tentacles into quite a number of files, so the additional testing
is highly appreciated.

Here is the committed patch:

https://inbox.vuxu.org/mandoc-source/c2aa6365c21bfcca@mandoc.bsd.lv/

Yours,
  Ingo
--
 To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv


      reply	other threads:[~2021-08-10 13:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210808111135.zisbfzlqqdsq35om@tarta.nabijaczleweli.xyz>
     [not found] ` <handler.992002.B.162842110127724.ack@bugs.debian.org>
     [not found]   ` <20210808124919.hevbw4gv6pis72pq@tarta.nabijaczleweli.xyz>
     [not found]     ` <CANnVG6k_czNfH5qNt9N3oOFF+v2i0eNfF92GO5vVK1sad9TRTw@mail.gmail.com>
2021-08-08 13:24       ` наб
2021-08-09  8:58         ` Ingo Schwarze
2021-08-09 23:08           ` наб
2021-08-10 13:43             ` Ingo Schwarze [this message]

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=20210810134358.GA19930@athene.usta.de \
    --to=schwarze@usta.de \
    --cc=992002@bugs.debian.org \
    --cc=nabijaczleweli@nabijaczleweli.xyz \
    --cc=tech@mandoc.bsd.lv \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).