discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
* Broken tables in HTML output
@ 2018-07-16 11:03 Pali Rohár
  2018-07-16 15:29 ` Ingo Schwarze
  0 siblings, 1 reply; 25+ messages in thread
From: Pali Rohár @ 2018-07-16 11:03 UTC (permalink / raw)
  To: discuss

Hi!

It seems that mandoc is not able to format tables in HTML output
correctly. Output is rather ugly which makes it less readable.

First thing is that in HTML output is fully missing specified border
even when in table section is box or | specified. This makes hard to
understand meaning of some table when borders are important.

Note that in ASCII output borders are rendered by '-', '+', '|' and '='
characters, so seems that mandoc already support borders, just HTML
generator is buggy or does not support them at all.

Second problem is with text alignment in table. When cell spanning is
used (e.g. via s or via \^) then text is not correctly aligned and it
looks "ugly". This problem is in both HTML and ASCII output.

Third thing which I observed is that mandoc is in UTF-8 output does not
use Unicode Box Drawing characters, but rather ugly ASCII.

On following line is (simplified) manpage table:

$ cat test.man
.TS
box;
c s|c s
c|c|c|c
l|l|c|c.
Very long text	Another very long text
_
Short	shrt	val1	val2
=
Name	1	value1	value2
\^	2	value3	\^
\^	3	value4	\^
_
Name2	1	v1	v2
_
Name3	1	vv1	vv2
\^	2	\^	vv4
.TE

And output from groff man in UTF-8 mode is:

$ man -Tutf8 ./test.man
┌───────────────┬────────────────────────┐
│Very long text │ Another very long text │
├───────┬───────┼────────────┬───────────┤
│Short  │ shrt  │   val1     │   val2    │
├───────┼───────┼────────────┼───────────┤
│       │ 1     │  value1    │           │
│Name   │ 2     │  value3    │  value2   │
│       │ 3     │  value4    │           │
├───────┼───────┼────────────┼───────────┤
│Name2  │ 1     │    v1      │    v2     │
├───────┼───────┼────────────┼───────────┤
│Name3  │ 1     │    vv1     │   vv2     │
│       │ 2     │            │   vv4     │
└───────┴───────┴────────────┴───────────┘

Table has nice design, text is properly centered (both horizontally and
vertically) and can be easily read. Only one error is missing double
line between Short and Name rows.

Output from mandoc in UTF-8 mode is ugly:

$ mandoc -Tutf8 ./test.man
+----------------------+---------------------------------+
|   Very long text     |     Another very long text      |
+---------------+------+------------------------+--------+
|    Short      | shrt |          val1          |  val2  |
+===============+======+========================+========+
|Name           | 1    |         value1         | value2 |
|               | 2    |         value3         |        |
|               | 3    |         value4         |        |
+---------------+------+------------------------+--------+
|Name2          | 1    |           v1           |   v2   |
+---------------+------+------------------------+--------+
|Name3          | 1    |          vv1           |  vv2   |
|               | 2    |                        |  vv4   |
+---------------+------+------------------------+--------+

It looks like it is no UTF-8, but rather ASCII.

Column for val1 is enormously wide and val2 is too short without any
reason. Both val1 and val2 columns have members of same sizes...

Alignment is wrong. "Name" should be centered and not on top. Same for
"value2".

And now HTML output from mandoc:

$ mandoc -Thtml ./test.man > test.html

In web browser test.html file looks like this:

   Very long text      Another very long text
   Short          shrt val1                   val2
   Name           1    value1                 value2
                  2    value3
                  3    value4
   Name2          1    v1                     v2
   Name3          1    vv1                    vv2
                  2                           vv4

All borders are missing, cell spanning is broken, text is not aligned at
all. Basically nothing is working and it hard to read and understood
what this table means.

So can you fix HTML generator in mandoc to produce better formatted HTML
text. Because now ASCII version is better then what produce HTML.

-- 
Pali Rohár
pali.rohar@gmail.com
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-07-16 11:03 Broken tables in HTML output Pali Rohár
@ 2018-07-16 15:29 ` Ingo Schwarze
  2018-07-16 16:36   ` Pali Rohár
                     ` (3 more replies)
  0 siblings, 4 replies; 25+ messages in thread
From: Ingo Schwarze @ 2018-07-16 15:29 UTC (permalink / raw)
  To: Pali Rohár; +Cc: discuss

Hi Pali,

i'm rearranging your text while quoting because you address
most of the issues twice.


Pali Rohar wrote on Mon, Jul 16, 2018 at 01:03:35PM +0200:

> It seems that mandoc is not able to format tables in HTML output
> correctly.  Output is rather ugly which makes it less readable.

You have designed a very complicated table for testing, exercising
many advanced features of the tbl(7) language: horizontal and
vertical table spanning with a mixture of option, layout, and data
borders.  So it is not very surprising that some aspects of the
rendering are not perfect yet.  In particular, the tbl(7) HTML
formatter is still relatively simplistic.

> First thing is that in HTML output is fully missing specified border
> even when in table section is box or | specified. This makes hard to
> understand meaning of some table when borders are important.
>
> Note that in ASCII output borders are rendered by '-', '+', '|' and '='
> characters, so seems that mandoc already support borders, just HTML
> generator is buggy or does not support them at all.

Indeed, the tbl(7) parser fully supports borders and the terminal
formatter supports them in most respects.  But you are right that
they are not yet implemented in the HTML formatter.  So i have added
an entry to the TODO file:

 - implement table borders in HTML output
   pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
   loc *  exist *  algo **  size **  imp **

I'm not completely sure that fully implementing all aspects of table
borders in conjunction with cell spanning is possible in HTML output,
but i think it is likely that it can be done in some way.  Priority
of the basic parts of the task (borders at all) seems moderate,
priority of the advanced parts low.

> cell spanning is broken,

More precisely, it is not implemented.  I added an entry to the TODO
file, priority is moderate:

 - implement cell spanning in HTML output
   pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
   loc *  exist *  algo **  size **  imp **

> text is not aligned at all.

I added an entry to the TODO file, priority is relatively high:

 - implement horizontal and vertical alignment in HTML output
   pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
   loc *  exist *  algo *  size *  imp ***

> Basically nothing is working and it hard to read and understood
> what this table means.

That seems like a serious overstatement.  The parser is fully
functional even for all the very advanced features you are using,
and even though the HTML formatter is relatively simplistic compared
to the terminal formatter, i think the meaning can still be understood.

> So can you fix HTML generator in mandoc to produce better formatted
> HTML text.

Probably, i can fix this, but it may take some time.  It will
certainly not be completed during the next few months.  Most of the
features you are asking for are not quite easy to implement, and
there are many other things to do in mandoc, some of equal or higher
priority.  Definely, some of the features you are asking for will
appear more quickly than others of these features.  For example,
vertical alignment on the terminal is particularly hard and may get
delayed for a long time.

> Because now ASCII version is better then what produce HTML.

Absolutely.  ASCII output is always better than HTML.  We consider
terminal output by far the most important output mode in OpenBSD.
But lately, HTML has also be improved in many respects, and that
work will continue.  The importance of HTML output is increasing.


> Second problem is with text alignment in table. When cell spanning is
> used (e.g. via s or via \^) then text is not correctly aligned and it
> looks "ugly". This problem is in both HTML and ASCII output.
[...]
> Alignment is wrong. "Name" should be centered and not on top.
> Same for "value2".

Horizontal alignment is correct in terminal output, i think you are
exclusively talking about vertical alignment here.

In the past, i chose to not implement vertical alignment in the
tbl(1) terminal formatter because it is hard to implement and rather
unimportant.  But it was not yet mentioned in the TODO file, so i
just added this entry:

 - vertical centering in cells vertically spanned with ^
   pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
   loc *  exist ***  algo ***  size **  imp *


> Third thing which I observed is that mandoc is in UTF-8 output does
> not use Unicode Box Drawing characters, but rather ugly ASCII.
[...]
> Output from mandoc in UTF-8 mode is ugly:
> 
> $ mandoc -Tutf8 ./test.man
> +----------------------+---------------------------------+
> |   Very long text     |     Another very long text      |
> +---------------+------+------------------------+--------+
> |    Short      | shrt |          val1          |  val2  |
> +===============+======+========================+========+
> |Name           | 1    |         value1         | value2 |
> |               | 2    |         value3         |        |
> |               | 3    |         value4         |        |
> +---------------+------+------------------------+--------+
> |Name2          | 1    |           v1           |   v2   |
> +---------------+------+------------------------+--------+
> |Name3          | 1    |          vv1           |  vv2   |
> |               | 2    |                        |  vv4   |
> +---------------+------+------------------------+--------+
> 
> It looks like it is no UTF-8, but rather ASCII.

Well, if you use non-ASCII characters in the input, you will see
that it is indeed UTF-8 output, not ASCII output.

The TODO file already has the following entry of moderate priority:

 - use Unicode U+2500 to U+256C for table borders
   in tbl(7) -Tutf-8 output
   suggested by bentley@  Tue, 14 Oct 2014 04:10:55 -0600
   loc *  exist **  algo *  size *  imp **


> Column for val1 is enormously wide

That's an important known issue listed in the TODO file:

 - the "s" layout column specifier is used for placement of data
   into columns, but ignored during column width calculations
   synaptics(4) found by tedu@  Mon, 17 Aug 2015 21:17:42 -0400
   loc *  exist **  algo ***  size *  imp **

Priority is only moderate because solving it will require
quite some work.


> and val2 is too short without any reason.
> Both val1 and val2 columns have members of same sizes...

The val2 column is not too short, all values fit into the column.
The reason it is wider with GNU tbl(1) is that the width
of "Another very long text" is greater than the width needed for
both val* columns together, so GNU tbl(1) distributes some additional
width across both val* columns.

This extension is part of what makes column width calculations
non-trivial in the presence of spanned columns.


Thanks for all your input,
  Ingo


Log Message:
-----------
new todos, mostly from Pali Rohar, mostly tbl(7)

Modified Files:
--------------
    mandoc:
        TODO

Revision Data
-------------
Index: TODO
===================================================================
RCS file: /home/cvs/mandoc/mandoc/TODO,v
retrieving revision 1.254
retrieving revision 1.255
diff -LTODO -LTODO -u -p -r1.254 -r1.255
--- TODO
+++ TODO
@@ -180,6 +180,10 @@ are mere guesses, and some may be wrong.
   synaptics(4) found by tedu@  Mon, 17 Aug 2015 21:17:42 -0400
   loc *  exist **  algo ***  size *  imp **
 
+- vertical centering in cells vertically spanned with ^
+  pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
+  loc *  exist ***  algo ***  size **  imp *
+
 - support mdoc(7) and man(7) macros inside tbl(7) code;
   probably requires the parser reorg and letting tbl(7)
   use roff_node such that macro sets can mix;
@@ -198,6 +202,18 @@ are mere guesses, and some may be wrong.
   suggested by bentley@  Tue, 14 Oct 2014 04:10:55 -0600
   loc *  exist **  algo *  size *  imp **
 
+- implement horizontal and vertical alignment in HTNL output
+  pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
+  loc *  exist *  algo *  size *  imp ***
+
+- implement cell spanning in HTML output
+  pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
+  loc *  exist *  algo **  size **  imp **
+
+- implement table borders in HTML output
+  pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
+  loc *  exist *  algo **  size **  imp **
+
 --- missing eqn features -----------------------------------------------
 
 - In a matrix, break the output line after each matrix line.
@@ -228,6 +244,8 @@ are mere guesses, and some may be wrong.
   bentley@  Thu, 13 Jul 2017 23:14:20 -0600
 
 --- missing misc features ----------------------------------------------
+
+- man -ks 1,8 route; kn@ Jul 13, 2018 orally
 
 - italic correction (\/) in PostScript mode
   Werner LEMBERG on groff at gnu dot org  Sun, 10 Nov 2013 12:47:46
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-07-16 15:29 ` Ingo Schwarze
@ 2018-07-16 16:36   ` Pali Rohár
  2018-07-16 17:44     ` Ingo Schwarze
  2018-11-24 23:15   ` Ingo Schwarze
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 25+ messages in thread
From: Pali Rohár @ 2018-07-16 16:36 UTC (permalink / raw)
  To: Ingo Schwarze; +Cc: discuss

[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]

Hi! Thanks for quick reply.

On Monday 16 July 2018 17:29:19 Ingo Schwarze wrote:
> Hi Pali,
> 
> i'm rearranging your text while quoting because you address
> most of the issues twice.
> 
> 
> Pali Rohar wrote on Mon, Jul 16, 2018 at 01:03:35PM +0200:
> 
> > It seems that mandoc is not able to format tables in HTML output
> > correctly.  Output is rather ugly which makes it less readable.
> 
> You have designed a very complicated table for testing, exercising
> many advanced features of the tbl(7) language:

Complicated? This is just simplified version of real used table in man
page. E.g.: https://github.com/pali/udftools/blob/master/doc/mkudffs.8

> > Because now ASCII version is better then what produce HTML.
> 
> Absolutely.  ASCII output is always better than HTML.  We consider
> terminal output by far the most important output mode in OpenBSD.
> But lately, HTML has also be improved in many respects, and that
> work will continue.  The importance of HTML output is increasing.

I was told that mandoc has support for formatting manpages to HTML and
it is really good, therefore I tested it on some manpages (like above).
And I had to say that no. ASCII of mandoc is better. And when I compared
table ASCII table generated by mandoc and groff, groff output is better.

So based on your reply, all those reports are not supported by mandoc
yet and marked as TODO...

I hope that they will be resolved, specially now when e.g. Arch Linux
and Debian started to generate HTML versions of manpages by mandoc.
Because otherwise it would be better to stick with UTF-8 output from
groff and do some HTMLization of plain text output...

About borders in html tables, I think that all is possible to describe
via CSS properties like buttom-border, left-border, etc, ...

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-07-16 16:36   ` Pali Rohár
@ 2018-07-16 17:44     ` Ingo Schwarze
  0 siblings, 0 replies; 25+ messages in thread
From: Ingo Schwarze @ 2018-07-16 17:44 UTC (permalink / raw)
  To: Pali Rohar; +Cc: discuss

Hi Pali,

Pali Rohar wrote on Mon, Jul 16, 2018 at 06:36:56PM +0200:
> On Monday 16 July 2018 17:29:19 Ingo Schwarze wrote:
>> Pali Rohar wrote on Mon, Jul 16, 2018 at 01:03:35PM +0200:

>>> It seems that mandoc is not able to format tables in HTML output
>>> correctly.  Output is rather ugly which makes it less readable.

>> You have designed a very complicated table for testing, exercising
>> many advanced features of the tbl(7) language:

> Complicated? This is just simplified version of real used table in man
> page. E.g.: https://github.com/pali/udftools/blob/master/doc/mkudffs.8

As i already said in my EuroBSDCon 2014 tutorial "Let's make manuals
more useful!" (slide 54, Handling manual pages in ports):

  The Law of Feature Creep
    If a software offers some feature,
    sooner or later somebody will use it.

  Porting corollary
    For every feature of the roff language (and for every groff
    extension), no matter how arcane and how obviously irrelevant
    for manual pages, sooner or later somebody will want to port a
    third-party software abusing that feature to format its manual
    pages.

In my recent BSDCan 2018 slides, you can see many of the recent
improvements in mandoc to cope with this awful effect.  They were
mostly related to low-level roff - and also to quite some tbl(7).

If a feature is used by a real-world manual page, that doesn't mean
much, in particular not that it is a feature normally used in manual
pages.  So yes, the features you are asking for are very unusual
in manual pages, and they are very advanced, complicated features.

Consequently, that manual page is totally non-portable.
Here is, for example, what Heirloom Roff does with it:

   $ export PATH="/usr/local/heirloom-doctools/bin:$PATH"
   $ tbl -Tutf8 tmp.man | nroff -man -Tutf8
[...]
       _________________________________________
        Very long text   Another very long text
       _________________________________________
         Short    shrt       val1         val2
       _________________________________________
                  1         value1
                  2         value3
ame
                  3         value4alue2

       _________________________________________
        Name2     1           v1           v2
       _________________________________________
                  1                       vv2
        Name3     2           vv1         vv4
       _________________________________________

All that said, ultimately, i do want to add these features, it just
can't happen overnight.  As opposed to many other non-standard
features that had to be implemented (many of which are used more
frequently), these are actually somewhat useful for unusually
complicated manual pages, as long as authors are aware that their
manual pages will not be portable.

>>> Because now ASCII version is better then what produce HTML.

>> Absolutely.  ASCII output is always better than HTML.  We consider
>> terminal output by far the most important output mode in OpenBSD.
>> But lately, HTML has also be improved in many respects, and that
>> work will continue.  The importance of HTML output is increasing.

> I was told that mandoc has support for formatting manpages to HTML
> and it is really good,

The correct statement is: mandoc HTML output is much better than
groff HTML output.

> therefore I tested it on some manpages (like above).
> And I had to say that no. ASCII of mandoc is better.

Absolutely.  I never said HTML output is better than ASCII output -
neither for mandoc nor for groff.

> And when I compared table ASCII table generated by mandoc and groff,
> groff output is better.

Yes, for complicated tables, groff terminal output is still better
than mandoc terminal output, though the gap is slowly narrowing.

> So based on your reply, all those reports are not supported by mandoc
> yet and marked as TODO...
> 
> I hope that they will be resolved, specially now when e.g. Arch Linux
> and Debian started to generate HTML versions of manpages by mandoc.
> Because otherwise it would be better to stick with UTF-8 output from
> groff and do some HTMLization of plain text output...

Sacrifice hyperlinking and semantic markup on all pages for some
arcane tbl(7) features used by very few pages?  I don't think that
would be an improvement.

Besides, Debian cannot easily switch back because groff is simply
too slow.

> About borders in html tables, I think that all is possible to describe
> via CSS properties like buttom-border, left-border, etc, ...

Very probably, yes.

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-07-16 15:29 ` Ingo Schwarze
  2018-07-16 16:36   ` Pali Rohár
@ 2018-11-24 23:15   ` Ingo Schwarze
  2018-11-25 19:34   ` Ingo Schwarze
  2018-11-26 21:27   ` Ingo Schwarze
  3 siblings, 0 replies; 25+ messages in thread
From: Ingo Schwarze @ 2018-11-24 23:15 UTC (permalink / raw)
  To: Pali Rohar; +Cc: discuss

Hi,

Ingo Schwarze wrote on Mon, Jul 16, 2018 at 05:29:19PM +0200:
> Pali Rohar wrote on Mon, Jul 16, 2018 at 01:03:35PM +0200:
 
>> It seems that mandoc is not able to format tables in HTML output
>> correctly.  Output is rather ugly which makes it less readable.

I just implemented the first one of the many missing features you
reported.  Please bear with me, as i said, getting this all done
will not happen quickly.

[...]
>> text is not aligned at all.

> I added an entry to the TODO file, priority is relatively high:
> 
>  - implement horizontal and vertical alignment in HTML output
>    pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
>    loc *  exist *  algo *  size *  imp ***

I think this is fixed by the commit below (not handling spanned
cells yet).

Yours,
  Ingo


Log Message:
-----------
Implement horizontal and vertical alignment of tbl(7) cell content
in -T html output.  This does not handle spanned cells yet.
Missing feature reported by Pali dot Rohar at gmail dot com.

Modified Files:
--------------
    mandoc:
        TODO
        mandoc.css
        tbl_html.c

Revision Data
-------------
Index: mandoc.css
===================================================================
RCS file: /home/cvs/mandoc/mandoc/mandoc.css,v
retrieving revision 1.37
retrieving revision 1.38
diff -Lmandoc.css -Lmandoc.css -u -p -r1.37 -r1.38
--- mandoc.css
+++ mandoc.css
@@ -9,7 +9,7 @@ html {		max-width: 65em; }
 body {		font-family: Helvetica,Arial,sans-serif; }
 table {		margin-top: 0em;
 		margin-bottom: 0em; }
-td {		vertical-align: top; }
+td {		vertical-align: middle; }
 ul, ol, dl {	margin-top: 0em;
 		margin-bottom: 0em; }
 li, dt {	margin-top: 1em; }
Index: tbl_html.c
===================================================================
RCS file: /home/cvs/mandoc/mandoc/tbl_html.c,v
retrieving revision 1.24
retrieving revision 1.25
diff -Ltbl_html.c -Ltbl_html.c -u -p -r1.24 -r1.25
--- tbl_html.c
+++ tbl_html.c
@@ -1,7 +1,7 @@
 /*	$Id$ */
 /*
  * Copyright (c) 2011 Kristaps Dzonsons <kristaps@bsd.lv>
- * Copyright (c) 2014, 2015, 2017 Ingo Schwarze <schwarze@openbsd.org>
+ * Copyright (c) 2014, 2015, 2017, 2018 Ingo Schwarze <schwarze@openbsd.org>
  *
  * Permission to use, copy, modify, and distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -103,6 +103,7 @@ print_tbl(struct html *h, const struct t
 {
 	const struct tbl_dat *dp;
 	struct tag	*tt;
+	const char	*halign, *valign;
 	int		 ic;
 
 	/* Inhibit printing of spaces: we do padding ourselves. */
@@ -126,10 +127,40 @@ print_tbl(struct html *h, const struct t
 		dp = sp->first;
 		for (ic = 0; ic < sp->opts->cols; ic++) {
 			print_stagq(h, tt);
-			print_otag(h, TAG_TD, "");
-
-			if (dp == NULL || dp->layout->col > ic)
+			if (dp == NULL || dp->layout->col > ic) {
+				print_otag(h, TAG_TD, "");
 				continue;
+			}
+			switch (dp->layout->pos) {
+			case TBL_CELL_CENTRE:
+				halign = "center";
+				break;
+			case TBL_CELL_RIGHT:
+			case TBL_CELL_NUMBER:
+				halign = "right";
+				break;
+			default:
+				halign = NULL;
+				break;
+			}
+			if (dp->layout->flags & TBL_CELL_TALIGN)
+				valign = "top";
+			else if (dp->layout->flags & TBL_CELL_BALIGN)
+				valign = "bottom";
+			else
+				valign = NULL;
+			if (halign == NULL && valign == NULL)
+				print_otag(h, TAG_TD, "");
+			else if (halign == NULL)
+				print_otag(h, TAG_TD, "s",
+				    "vertical-align", valign);
+			else if (valign == NULL)
+				print_otag(h, TAG_TD, "s",
+				    "text-align", halign);
+			else
+				print_otag(h, TAG_TD, "ss",
+				    "vertical-align", valign,
+				    "text-align", halign);
 			if (dp->layout->pos != TBL_CELL_DOWN)
 				if (dp->string != NULL)
 					print_text(h, dp->string);
@@ -148,5 +179,4 @@ print_tbl(struct html *h, const struct t
 		h->tbl.cols = NULL;
 		print_tblclose(h);
 	}
-
 }
Index: TODO
===================================================================
RCS file: /home/cvs/mandoc/mandoc/TODO,v
retrieving revision 1.274
retrieving revision 1.275
diff -LTODO -LTODO -u -p -r1.274 -r1.275
--- TODO
+++ TODO
@@ -195,10 +195,6 @@ are mere guesses, and some may be wrong.
   suggested by bentley@  Tue, 14 Oct 2014 04:10:55 -0600
   loc *  exist **  algo *  size *  imp **
 
-- implement horizontal and vertical alignment in HTML output
-  pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
-  loc *  exist *  algo *  size *  imp ***
-
 - implement cell spanning in HTML output
   pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
   loc *  exist *  algo **  size **  imp **
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-07-16 15:29 ` Ingo Schwarze
  2018-07-16 16:36   ` Pali Rohár
  2018-11-24 23:15   ` Ingo Schwarze
@ 2018-11-25 19:34   ` Ingo Schwarze
  2018-11-25 21:25     ` Ingo Schwarze
  2018-11-26 21:27   ` Ingo Schwarze
  3 siblings, 1 reply; 25+ messages in thread
From: Ingo Schwarze @ 2018-11-25 19:34 UTC (permalink / raw)
  To: Pali Rohar; +Cc: discuss

Hi Pali,

Ingo Schwarze wrote on Mon, Jul 16, 2018 at 05:29:19PM +0200:
> Pali Rohar wrote on Mon, Jul 16, 2018 at 01:03:35PM +0200:

>> cell spanning is broken,

> More precisely, it is not implemented.  I added an entry to the TODO
> file, priority is moderate:
> 
>  - implement cell spanning in HTML output
>    pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
>    loc *  exist *  algo **  size **  imp **

Implemented in the commit below.

Yours,
  Ingo


Log Message:
-----------
In tbl(7) -T html output, 
span cells horizontally and vertically as requested by the layout.  
Does not handle spans requested in the data section yet.

To be able to do this, record the number of rows spanned 
in the first data cell (struct tbl_dat) of a vertical span.

Missing feature reported by Pali dot Rohar at gmail dot com.

Modified Files:
--------------
    mandoc:
        TODO
        mandoc.h
        out.c
        tbl_data.c
        tbl_html.c
        tbl_term.c
        tree.c

Revision Data
-------------
Index: tbl_term.c
===================================================================
RCS file: /home/cvs/mandoc/mandoc/tbl_term.c,v
retrieving revision 1.60
retrieving revision 1.61
diff -Ltbl_term.c -Ltbl_term.c -u -p -r1.60 -r1.61
--- tbl_term.c
+++ tbl_term.c
@@ -77,7 +77,7 @@ term_tbl(struct termp *tp, const struct 
 	const struct tbl_dat	*dp;
 	static size_t		 offset;
 	size_t			 coloff, tsz;
-	int			 ic, horiz, spans, vert, more;
+	int			 ic, horiz, hspans, vert, more;
 	char			 fc;
 
 	/* Inhibit printing of spaces: we do padding ourselves. */
@@ -157,9 +157,9 @@ term_tbl(struct termp *tp, const struct 
 		/* Set up the data columns. */
 
 		dp = sp->first;
-		spans = 0;
+		hspans = 0;
 		for (ic = 0; ic < sp->opts->cols; ic++) {
-			if (spans == 0) {
+			if (hspans == 0) {
 				tp->tcol++;
 				tp->tcol->offset = coloff;
 			}
@@ -167,13 +167,13 @@ term_tbl(struct termp *tp, const struct 
 			tp->tcol->rmargin = coloff;
 			if (ic + 1 < sp->opts->cols)
 				coloff += tp->tbl.cols[ic].spacing;
-			if (spans) {
-				spans--;
+			if (hspans) {
+				hspans--;
 				continue;
 			}
 			if (dp == NULL)
 				continue;
-			spans = dp->spans;
+			hspans = dp->hspans;
 			if (ic || sp->layout->first->pos != TBL_CELL_SPAN)
 				dp = dp->next;
 		}
@@ -193,14 +193,14 @@ term_tbl(struct termp *tp, const struct 
 		tp->tcol = tp->tcols;
 		cp = cpn = sp->layout->first;
 		dp = sp->first;
-		spans = 0;
+		hspans = 0;
 		for (ic = 0; ic < sp->opts->cols; ic++) {
 			if (cpn != NULL) {
 				cp = cpn;
 				cpn = cpn->next;
 			}
-			if (spans) {
-				spans--;
+			if (hspans) {
+				hspans--;
 				continue;
 			}
 			tp->tcol++;
@@ -208,7 +208,7 @@ term_tbl(struct termp *tp, const struct 
 			tbl_data(tp, sp->opts, cp, dp, tp->tbl.cols + ic);
 			if (dp == NULL)
 				continue;
-			spans = dp->spans;
+			hspans = dp->hspans;
 			if (cp->pos != TBL_CELL_SPAN)
 				dp = dp->next;
 		}
@@ -249,7 +249,7 @@ term_tbl(struct termp *tp, const struct 
 			cpp = sp->prev == NULL ? NULL :
 			    sp->prev->layout->first;
 			dp = sp->first;
-			spans = 0;
+			hspans = 0;
 			for (ic = 0; ic < sp->opts->cols; ic++) {
 
 				/*
@@ -304,12 +304,12 @@ term_tbl(struct termp *tp, const struct 
 				 * and advance to next data cell.
 				 */
 
-				if (spans) {
-					spans--;
+				if (hspans) {
+					hspans--;
 					continue;
 				}
 				if (dp != NULL) {
-					spans = dp->spans;
+					hspans = dp->hspans;
 					if (ic || sp->layout->first->pos
 					    != TBL_CELL_SPAN)
 						dp = dp->next;
@@ -592,14 +592,14 @@ tbl_literal(struct termp *tp, const stru
 		const struct roffcol *col)
 {
 	size_t		 len, padl, padr, width;
-	int		 ic, spans;
+	int		 ic, hspans;
 
 	assert(dp->string);
 	len = term_strlen(tp, dp->string);
 	width = col->width;
 	ic = dp->layout->col;
-	spans = dp->spans;
-	while (spans--)
+	hspans = dp->hspans;
+	while (hspans--)
 		width += tp->tbl.cols[++ic].width + 3;
 
 	padr = width > len ? width - len : 0;
Index: tbl_html.c
===================================================================
RCS file: /home/cvs/mandoc/mandoc/tbl_html.c,v
retrieving revision 1.25
retrieving revision 1.26
diff -Ltbl_html.c -Ltbl_html.c -u -p -r1.25 -r1.26
--- tbl_html.c
+++ tbl_html.c
@@ -101,10 +101,10 @@ print_tblclose(struct html *h)
 void
 print_tbl(struct html *h, const struct tbl_span *sp)
 {
-	const struct tbl_dat *dp;
-	struct tag	*tt;
-	const char	*halign, *valign;
-	int		 ic;
+	const struct tbl_dat	*dp;
+	struct tag		*tt;
+	const char		*hspans, *vspans, *halign, *valign;
+	char			 hbuf[4], vbuf[4];
 
 	/* Inhibit printing of spaces: we do padding ourselves. */
 
@@ -124,13 +124,31 @@ print_tbl(struct html *h, const struct t
 		print_otag(h, TAG_TD, "?", "colspan", "0");
 		break;
 	default:
-		dp = sp->first;
-		for (ic = 0; ic < sp->opts->cols; ic++) {
+		for (dp = sp->first; dp != NULL; dp = dp->next) {
 			print_stagq(h, tt);
-			if (dp == NULL || dp->layout->col > ic) {
-				print_otag(h, TAG_TD, "");
+			switch (dp->layout->pos) {
+			case TBL_CELL_SPAN:
+			case TBL_CELL_DOWN:
 				continue;
+			default:
+				break;
 			}
+
+			/* Determine the attribute values. */
+
+			if (dp->hspans > 0) {
+				(void)snprintf(hbuf, sizeof(hbuf),
+				    "%d", dp->hspans + 1);
+				hspans = hbuf;
+			} else
+				hspans = NULL;
+			if (dp->vspans > 0) {
+				(void)snprintf(vbuf, sizeof(vbuf),
+				    "%d", dp->vspans + 1);
+				vspans = vbuf;
+			} else
+				vspans = NULL;
+
 			switch (dp->layout->pos) {
 			case TBL_CELL_CENTRE:
 				halign = "center";
@@ -149,22 +167,27 @@ print_tbl(struct html *h, const struct t
 				valign = "bottom";
 			else
 				valign = NULL;
+
+			/* Print the element and the attributes. */
+
 			if (halign == NULL && valign == NULL)
-				print_otag(h, TAG_TD, "");
+				print_otag(h, TAG_TD, "??",
+				    "colspan", hspans, "rowspan", vspans);
 			else if (halign == NULL)
-				print_otag(h, TAG_TD, "s",
+				print_otag(h, TAG_TD, "??s",
+				    "colspan", hspans, "rowspan", vspans,
 				    "vertical-align", valign);
 			else if (valign == NULL)
-				print_otag(h, TAG_TD, "s",
+				print_otag(h, TAG_TD, "??s",
+				    "colspan", hspans, "rowspan", vspans,
 				    "text-align", halign);
 			else
-				print_otag(h, TAG_TD, "ss",
+				print_otag(h, TAG_TD, "??ss",
+				    "colspan", hspans, "rowspan", vspans,
 				    "vertical-align", valign,
 				    "text-align", halign);
-			if (dp->layout->pos != TBL_CELL_DOWN)
-				if (dp->string != NULL)
-					print_text(h, dp->string);
-			dp = dp->next;
+			if (dp->string != NULL)
+				print_text(h, dp->string);
 		}
 		break;
 	}
Index: tbl_data.c
===================================================================
RCS file: /home/cvs/mandoc/mandoc/tbl_data.c,v
retrieving revision 1.45
retrieving revision 1.46
diff -Ltbl_data.c -Ltbl_data.c -u -p -r1.45 -r1.46
--- tbl_data.c
+++ tbl_data.c
@@ -1,7 +1,7 @@
 /*	$Id$ */
 /*
  * Copyright (c) 2009, 2010, 2011 Kristaps Dzonsons <kristaps@bsd.lv>
- * Copyright (c) 2011, 2015, 2017 Ingo Schwarze <schwarze@openbsd.org>
+ * Copyright (c) 2011, 2015, 2017, 2018 Ingo Schwarze <schwarze@openbsd.org>
  *
  * Permission to use, copy, modify, and distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -40,8 +40,9 @@ static void
 getdata(struct tbl_node *tbl, struct tbl_span *dp,
 		int ln, const char *p, int *pos)
 {
-	struct tbl_dat	*dat;
+	struct tbl_dat	*dat, *pdat;
 	struct tbl_cell	*cp;
+	struct tbl_span	*pdp;
 	int		 sv;
 
 	/* Advance to the next layout cell, skipping spanners. */
@@ -73,15 +74,51 @@ getdata(struct tbl_node *tbl, struct tbl
 		}
 	}
 
-	dat = mandoc_calloc(1, sizeof(*dat));
+	dat = mandoc_malloc(sizeof(*dat));
 	dat->layout = cp;
+	dat->next = NULL;
+	dat->string = NULL;
+	dat->hspans = 0;
+	dat->vspans = 0;
+	dat->block = 0;
 	dat->pos = TBL_DATA_NONE;
-	dat->spans = 0;
+
+	/*
+	 * Increment the number of vertical spans in a data cell above,
+	 * if this cell vertically extends one or more cells above.
+	 * The iteration must be done over data rows,
+	 * not over layout rows, because one layout row
+	 * can be reused for more than one data row.
+	 */
+
+	if (cp->pos == TBL_CELL_DOWN) {
+		pdp = dp;
+		while ((pdp = pdp->prev) != NULL) {
+			pdat = pdp->first;
+			while (pdat != NULL &&
+			    pdat->layout->col < dat->layout->col)
+				pdat = pdat->next;
+			if (pdat == NULL)
+				break;
+			if (pdat->layout->pos != TBL_CELL_DOWN) {
+				pdat->vspans++;
+				break;
+			}
+		}
+	}
+
+	/*
+	 * Count the number of horizontal spans to the right of this cell.
+	 * This is purely a matter of the layout, independent of the data.
+	 */
+
 	for (cp = cp->next; cp != NULL; cp = cp->next)
 		if (cp->pos == TBL_CELL_SPAN)
-			dat->spans++;
+			dat->hspans++;
 		else
 			break;
+
+	/* Append the new data cell to the data row. */
 
 	if (dp->last == NULL)
 		dp->first = dat;
Index: out.c
===================================================================
RCS file: /home/cvs/mandoc/mandoc/out.c,v
retrieving revision 1.73
retrieving revision 1.74
diff -Lout.c -Lout.c -u -p -r1.73 -r1.74
--- out.c
+++ out.c
@@ -112,7 +112,7 @@ tblcalc(struct rofftbl *tbl, const struc
 	const struct tbl_dat	*dp;
 	struct roffcol		*col;
 	size_t			 ewidth, xwidth;
-	int			 spans;
+	int			 hspans;
 	int			 icol, maxcol, necol, nxcol, quirkcol;
 
 	/*
@@ -129,17 +129,17 @@ tblcalc(struct rofftbl *tbl, const struc
 	for (maxcol = -1; sp; sp = sp->next) {
 		if (TBL_SPAN_DATA != sp->pos)
 			continue;
-		spans = 1;
+		hspans = 1;
 		/*
 		 * Account for the data cells in the layout, matching it
 		 * to data cells in the data section.
 		 */
 		for (dp = sp->first; dp; dp = dp->next) {
 			/* Do not used spanned cells in the calculation. */
-			if (0 < --spans)
+			if (0 < --hspans)
 				continue;
-			spans = dp->spans;
-			if (1 < spans)
+			hspans = dp->hspans;
+			if (1 < hspans)
 				continue;
 			icol = dp->layout->col;
 			while (maxcol < icol)
Index: TODO
===================================================================
RCS file: /home/cvs/mandoc/mandoc/TODO,v
retrieving revision 1.276
retrieving revision 1.277
diff -LTODO -LTODO -u -p -r1.276 -r1.277
--- TODO
+++ TODO
@@ -168,6 +168,10 @@ are mere guesses, and some may be wrong.
 
 --- missing tbl features -----------------------------------------------
 
+- vertically spanning cells by \^ in the data section
+  pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
+  loc *  exist *  algo *  size *  imp ***
+
 - the "s" layout column specifier is used for placement of data
   into columns, but ignored during column width calculations
   synaptics(4) found by tedu@  Mon, 17 Aug 2015 21:17:42 -0400
@@ -194,10 +198,6 @@ are mere guesses, and some may be wrong.
   in tbl(7) -Tutf-8 output
   suggested by bentley@  Tue, 14 Oct 2014 04:10:55 -0600
   loc *  exist **  algo *  size *  imp **
-
-- implement cell spanning in HTML output
-  pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
-  loc *  exist *  algo **  size **  imp **
 
 - implement table borders in HTML output
   pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
Index: mandoc.h
===================================================================
RCS file: /home/cvs/mandoc/mandoc/mandoc.h,v
retrieving revision 1.254
retrieving revision 1.255
diff -Lmandoc.h -Lmandoc.h -u -p -r1.254 -r1.255
--- mandoc.h
+++ mandoc.h
@@ -320,7 +320,8 @@ struct	tbl_dat {
 	struct tbl_cell	 *layout; /* layout cell */
 	struct tbl_dat	 *next;
 	char		 *string; /* data (NULL if not TBL_DATA_DATA) */
-	int		  spans; /* how many spans follow */
+	int		  hspans; /* how many horizontal spans follow */
+	int		  vspans; /* how many vertical spans follow */
 	int		  block; /* T{ text block T} */
 	enum tbl_datt	  pos;
 };
Index: tree.c
===================================================================
RCS file: /home/cvs/mandoc/mandoc/tree.c,v
retrieving revision 1.79
retrieving revision 1.80
diff -Ltree.c -Ltree.c -u -p -r1.79 -r1.80
--- tree.c
+++ tree.c
@@ -379,35 +379,41 @@ print_span(const struct tbl_span *sp, in
 	switch (sp->pos) {
 	case TBL_SPAN_HORIZ:
 		putchar('-');
-		return;
+		putchar(' ');
+		break;
 	case TBL_SPAN_DHORIZ:
 		putchar('=');
-		return;
-	default:
+		putchar(' ');
 		break;
-	}
-
-	for (dp = sp->first; dp; dp = dp->next) {
-		switch (dp->pos) {
-		case TBL_DATA_HORIZ:
-		case TBL_DATA_NHORIZ:
-			putchar('-');
-			continue;
-		case TBL_DATA_DHORIZ:
-		case TBL_DATA_NDHORIZ:
-			putchar('=');
-			continue;
-		default:
-			break;
+	default:
+		for (dp = sp->first; dp; dp = dp->next) {
+			switch (dp->pos) {
+			case TBL_DATA_HORIZ:
+			case TBL_DATA_NHORIZ:
+				putchar('-');
+				putchar(' ');
+				continue;
+			case TBL_DATA_DHORIZ:
+			case TBL_DATA_NDHORIZ:
+				putchar('=');
+				putchar(' ');
+				continue;
+			default:
+				break;
+			}
+			printf("[\"%s\"", dp->string ? dp->string : "");
+			if (dp->hspans)
+				printf(">%d", dp->hspans);
+			if (dp->vspans)
+				printf("v%d", dp->vspans);
+			if (dp->layout == NULL)
+				putchar('*');
+			else if (dp->layout->pos == TBL_CELL_DOWN)
+				putchar('^');
+			putchar(']');
+			putchar(' ');
 		}
-		printf("[\"%s\"", dp->string ? dp->string : "");
-		if (dp->spans)
-			printf("(%d)", dp->spans);
-		if (NULL == dp->layout)
-			putchar('*');
-		putchar(']');
-		putchar(' ');
+		break;
 	}
-
 	printf("(tbl) %d:1\n", sp->line);
 }
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-11-25 19:34   ` Ingo Schwarze
@ 2018-11-25 21:25     ` Ingo Schwarze
  2018-11-26  8:53       ` Pali Rohár
  0 siblings, 1 reply; 25+ messages in thread
From: Ingo Schwarze @ 2018-11-25 21:25 UTC (permalink / raw)
  To: Pali Rohar; +Cc: discuss

Hi Pali,

Ingo Schwarze wrote on Sun, Nov 25, 2018 at 08:34:34PM +0100:
> Ingo Schwarze wrote on Mon, Jul 16, 2018 at 05:29:19PM +0200:
>> Pali Rohar wrote on Mon, Jul 16, 2018 at 01:03:35PM +0200:

>>> cell spanning is broken,

>> More precisely, it is not implemented.  I added an entry to the TODO
>> file, priority is moderate:
>> 
>>  - implement cell spanning in HTML output
>>    pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
>>    loc *  exist *  algo **  size **  imp **

> Implemented in the commit below.
[...]
> Log Message:
> -----------
> In tbl(7) -T html output, 
> span cells horizontally and vertically as requested by the layout.  
> Does not handle spans requested in the data section yet.

This feature - \^ in data cells - is now also implemented,
see the following commit.

Yours,
  Ingo


Log Message:
-----------
Let cells containing nothing but \^ extend the cell above.
Missing feature reported by Pali dot Rohar at gmail dot com.

Modified Files:
--------------
    mandoc:
        TODO
        tbl.7
        tbl_data.c
        tbl_html.c

Revision Data
-------------
Index: tbl.7
===================================================================
RCS file: /home/cvs/mandoc/mandoc/tbl.7,v
retrieving revision 1.29
retrieving revision 1.30
diff -Ltbl.7 -Ltbl.7 -u -p -r1.29 -r1.30
--- tbl.7
+++ tbl.7
@@ -1,7 +1,7 @@
 .\"	$Id$
 .\"
 .\" Copyright (c) 2010, 2011 Kristaps Dzonsons <kristaps@bsd.lv>
-.\" Copyright (c) 2014, 2015, 2017 Ingo Schwarze <schwarze@openbsd.org>
+.\" Copyright (c) 2014, 2015, 2017, 2018 Ingo Schwarze <schwarze@openbsd.org>
 .\"
 .\" Permission to use, copy, modify, and distribute this software for any
 .\" purpose with or without fee is hereby granted, provided that the above
@@ -147,9 +147,9 @@ The combined cell as a whole consumes on
 of the corresponding data line.
 .It Cm a
 Left-justify a string and pad with one space.
-.It Cm ^
+.It Cm \(ha
 Vertically span rows from the last
-.Pf non- Cm ^
+.Pf non- Cm \(ha
 layout cell.
 It is an error to invoke a vertical span on the first layout line.
 Unlike a horizontal span, a vertical span consumes a data cell
@@ -231,7 +231,13 @@ Each data line consists of one or more d
 .Cm tab
 characters.
 .Pp
-If a data cells contains only the single character
+If a data cell contains only the two bytes
+.Ql \e\(ha ,
+the cell above spans to this row, as if the layout specification
+of this cell were
+.Cm \(ha .
+.Pp
+If a data cell contains only the single character
 .Ql _
 or
 .Ql = ,
@@ -332,8 +338,8 @@ Spans and skipping width calculations:
 \&.TS
 box tab(:);
 lz  s | rt
-lt| cb| ^
-^ | rz  s.
+lt| cb| \(ha
+\(ha | rz  s.
 left:r
 l:center:
 :right
Index: tbl_data.c
===================================================================
RCS file: /home/cvs/mandoc/mandoc/tbl_data.c,v
retrieving revision 1.46
retrieving revision 1.47
diff -Ltbl_data.c -Ltbl_data.c -u -p -r1.46 -r1.47
--- tbl_data.c
+++ tbl_data.c
@@ -45,6 +45,15 @@ getdata(struct tbl_node *tbl, struct tbl
 	struct tbl_span	*pdp;
 	int		 sv;
 
+	/*
+	 * Determine the length of the string in the cell
+	 * and advance the parse point to the end of the cell.
+	 */
+
+	sv = *pos;
+	while (p[*pos] != '\0' && p[*pos] != tbl->opts.tab)
+		(*pos)++;
+
 	/* Advance to the next layout cell, skipping spanners. */
 
 	cp = dp->last == NULL ? dp->layout->first : dp->last->layout->next;
@@ -67,8 +76,8 @@ getdata(struct tbl_node *tbl, struct tbl
 			dp->layout->last = cp;
 		} else {
 			mandoc_msg(MANDOCERR_TBLDATA_EXTRA, tbl->parse,
-			    ln, *pos, p + *pos);
-			while (p[*pos])
+			    ln, sv, p + sv);
+			while (p[*pos] != '\0')
 				(*pos)++;
 			return;
 		}
@@ -91,7 +100,8 @@ getdata(struct tbl_node *tbl, struct tbl
 	 * can be reused for more than one data row.
 	 */
 
-	if (cp->pos == TBL_CELL_DOWN) {
+	if (cp->pos == TBL_CELL_DOWN ||
+	    (*pos - sv == 2 && p[sv] == '\\' && p[sv + 1] == '^')) {
 		pdp = dp;
 		while ((pdp = pdp->prev) != NULL) {
 			pdat = pdp->first;
@@ -100,7 +110,8 @@ getdata(struct tbl_node *tbl, struct tbl
 				pdat = pdat->next;
 			if (pdat == NULL)
 				break;
-			if (pdat->layout->pos != TBL_CELL_DOWN) {
+			if (pdat->layout->pos != TBL_CELL_DOWN &&
+			    strcmp(pdat->string, "\\^") != 0) {
 				pdat->vspans++;
 				break;
 			}
@@ -126,10 +137,6 @@ getdata(struct tbl_node *tbl, struct tbl
 		dp->last->next = dat;
 	dp->last = dat;
 
-	sv = *pos;
-	while (p[*pos] && p[*pos] != tbl->opts.tab)
-		(*pos)++;
-
 	/*
 	 * Check for a continued-data scope opening.  This consists of a
 	 * trailing `T{' at the end of the line.  Subsequent lines,
@@ -143,7 +150,7 @@ getdata(struct tbl_node *tbl, struct tbl
 
 	dat->string = mandoc_strndup(p + sv, *pos - sv);
 
-	if (p[*pos])
+	if (p[*pos] != '\0')
 		(*pos)++;
 
 	if ( ! strcmp(dat->string, "_"))
Index: tbl_html.c
===================================================================
RCS file: /home/cvs/mandoc/mandoc/tbl_html.c,v
retrieving revision 1.26
retrieving revision 1.27
diff -Ltbl_html.c -Ltbl_html.c -u -p -r1.26 -r1.27
--- tbl_html.c
+++ tbl_html.c
@@ -126,13 +126,18 @@ print_tbl(struct html *h, const struct t
 	default:
 		for (dp = sp->first; dp != NULL; dp = dp->next) {
 			print_stagq(h, tt);
-			switch (dp->layout->pos) {
-			case TBL_CELL_SPAN:
-			case TBL_CELL_DOWN:
+
+			/*
+			 * Do not generate <td> elements for continuations
+			 * of spanned cells.  Larger <td> elements covering
+			 * this space were already generated earlier.
+			 */
+
+			if (dp->layout->pos == TBL_CELL_SPAN ||
+			    dp->layout->pos == TBL_CELL_DOWN ||
+			    (dp->string != NULL &&
+			     strcmp(dp->string, "\\^") == 0))
 				continue;
-			default:
-				break;
-			}
 
 			/* Determine the attribute values. */
 
Index: TODO
===================================================================
RCS file: /home/cvs/mandoc/mandoc/TODO,v
retrieving revision 1.277
retrieving revision 1.278
diff -LTODO -LTODO -u -p -r1.277 -r1.278
--- TODO
+++ TODO
@@ -168,10 +168,6 @@ are mere guesses, and some may be wrong.
 
 --- missing tbl features -----------------------------------------------
 
-- vertically spanning cells by \^ in the data section
-  pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
-  loc *  exist *  algo *  size *  imp ***
-
 - the "s" layout column specifier is used for placement of data
   into columns, but ignored during column width calculations
   synaptics(4) found by tedu@  Mon, 17 Aug 2015 21:17:42 -0400
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-11-25 21:25     ` Ingo Schwarze
@ 2018-11-26  8:53       ` Pali Rohár
  0 siblings, 0 replies; 25+ messages in thread
From: Pali Rohár @ 2018-11-26  8:53 UTC (permalink / raw)
  To: Ingo Schwarze; +Cc: discuss

On Sunday 25 November 2018 22:25:16 Ingo Schwarze wrote:
> Hi Pali,
> 
> Ingo Schwarze wrote on Sun, Nov 25, 2018 at 08:34:34PM +0100:
> > Ingo Schwarze wrote on Mon, Jul 16, 2018 at 05:29:19PM +0200:
> >> Pali Rohar wrote on Mon, Jul 16, 2018 at 01:03:35PM +0200:
> 
> >>> cell spanning is broken,
> 
> >> More precisely, it is not implemented.  I added an entry to the TODO
> >> file, priority is moderate:
> >> 
> >>  - implement cell spanning in HTML output
> >>    pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
> >>    loc *  exist *  algo **  size **  imp **
> 
> > Implemented in the commit below.
> [...]
> > Log Message:
> > -----------
> > In tbl(7) -T html output, 
> > span cells horizontally and vertically as requested by the layout.  
> > Does not handle spans requested in the data section yet.
> 
> This feature - \^ in data cells - is now also implemented,
> see the following commit.

Hi! Thanks for implementation. Now I checked cvs version of mandoc on
mkudffs.8 and HTML table was now generated correctly! So now there is
missing only table border.

-- 
Pali Rohár
pali.rohar@gmail.com
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-07-16 15:29 ` Ingo Schwarze
                     ` (2 preceding siblings ...)
  2018-11-25 19:34   ` Ingo Schwarze
@ 2018-11-26 21:27   ` Ingo Schwarze
  2018-11-26 21:58     ` Pali Rohár
  2018-11-29  2:15     ` Ingo Schwarze
  3 siblings, 2 replies; 25+ messages in thread
From: Ingo Schwarze @ 2018-11-26 21:27 UTC (permalink / raw)
  To: Pali Rohar; +Cc: discuss

Hi Pali,

Ingo Schwarze wrote on Mon, Jul 16, 2018 at 05:29:19PM +0200:
> Pali Rohar wrote on Mon, Jul 16, 2018 at 01:03:35PM +0200:

>> First thing is that in HTML output is fully missing specified border
>> even when in table section is box or | specified. This makes hard to
>> understand meaning of some table when borders are important.
>>
>> Note that in ASCII output borders are rendered by '-', '+', '|' and '='
>> characters, so seems that mandoc already support borders, just HTML
>> generator is buggy or does not support them at all.

> Indeed, the tbl(7) parser fully supports borders and the terminal
> formatter supports them in most respects.  But you are right that
> they are not yet implemented in the HTML formatter.  So i have added
> an entry to the TODO file:
> 
>  - implement table borders in HTML output
>    pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
>    loc *  exist *  algo **  size **  imp **
> 
> I'm not completely sure that fully implementing all aspects of table
> borders in conjunction with cell spanning is possible in HTML output,
> but i think it is likely that it can be done in some way.

It turned out combination with cell spanning wasn't a problem;
support for most border features went in with the commit below.

What i didn't implement yet is drawing horizontal borders through
the *middle* of table cells, in particular in table rows that
contain text in other columns of the same row.

I'm not quite sure how to tell HTML (or CSS?) "draw a horizontal
line through the *middle* of this table cell".

But maybe that feature isn't all that important.

[...]
>> cell spanning is broken,

Fixed earlier.

[...]
>> text is not aligned at all.

Fixed earlier.

[...]
>> Second problem is with text alignment in table. When cell spanning is
>> used (e.g. via s or via \^) then text is not correctly aligned and it
>> looks "ugly". This problem is in both HTML and ASCII output.
> [...]
>> Alignment is wrong. "Name" should be centered and not on top.
>> Same for "value2".

Vertical alignment in ASCII output is a tough problem and not likely
to get fixed soon; the rest should be fixed now, i think.

[...]
>> Third thing which I observed is that mandoc is in UTF-8 output does
>> not use Unicode Box Drawing characters, but rather ugly ASCII.

That is still open.

>> Column for val1 is enormously wide
> 
> That's an important known issue listed in the TODO file:
> 
>  - the "s" layout column specifier is used for placement of data
>    into columns, but ignored during column width calculations
>    synaptics(4) found by tedu@  Mon, 17 Aug 2015 21:17:42 -0400
>    loc *  exist **  algo ***  size *  imp **
> 
> Priority is only moderate because solving it will require
> quite some work.

That is still open, too.

So about half of this is fixed now, the most important remaining
items being column width calculations in the presence of spans, and
box drawing characters.

Yours,
  Ingo


Log Message:
-----------
Implement tbl(7) lines in -T html output, 
as far as they are on the edges of table cells 
rather than going through the middle of cells:

* the box, doublebox, and allbox options; 
* the | and || layout modifiers;
* and the _ and = data lines;
- but not yet _ and = in individual layout and data cells.

Missing feature reported by Pali dot Rohar at gmail dot com.

Modified Files:
--------------
    mandoc:
        mandoc.css
        tbl_html.c

Revision Data
-------------
Index: tbl_html.c
===================================================================
RCS file: /home/cvs/mandoc/mandoc/tbl_html.c,v
retrieving revision 1.28
retrieving revision 1.29
diff -Ltbl_html.c -Ltbl_html.c -u -p -r1.28 -r1.29
--- tbl_html.c
+++ tbl_html.c
@@ -86,7 +86,15 @@ html_tblopen(struct html *h, const struc
 		tblcalc(&h->tbl, sp, 0, 0);
 	}
 	assert(NULL == h->tblt);
-	h->tblt = print_otag(h, TAG_TABLE, "c", "tbl");
+	h->tblt = print_otag(h, TAG_TABLE, "c?ss", "tbl",
+	    "border",
+		sp->opts->opts & TBL_OPT_ALLBOX ? "1" : NULL,
+	    "border-style",
+		sp->opts->opts & TBL_OPT_DBOX ? "double" :
+		sp->opts->opts & TBL_OPT_BOX ? "solid" : NULL,
+	    "border-top-style",
+		sp->pos == TBL_SPAN_DHORIZ ? "double" :
+		sp->pos == TBL_SPAN_HORIZ ? "solid" : NULL);
 }
 
 void
@@ -102,87 +110,135 @@ void
 print_tbl(struct html *h, const struct tbl_span *sp)
 {
 	const struct tbl_dat	*dp;
+	const struct tbl_cell	*cp;
+	const struct tbl_span	*psp;
 	struct tag		*tt;
 	const char		*hspans, *vspans, *halign, *valign;
+	const char		*bborder, *lborder, *rborder;
 	char			 hbuf[4], vbuf[4];
-
-	/* Inhibit printing of spaces: we do padding ourselves. */
+	int			 i;
 
 	if (h->tblt == NULL)
 		html_tblopen(h, sp);
 
-	assert(h->tblt);
+	/*
+	 * Horizontal lines spanning the whole table
+	 * are handled by previous or following table rows.
+	 */
+
+	if (sp->pos != TBL_SPAN_DATA)
+		return;
+
+	/* Inhibit printing of spaces: we do padding ourselves. */
 
 	h->flags |= HTML_NONOSPACE;
 	h->flags |= HTML_NOSPACE;
 
-	tt = print_otag(h, TAG_TR, "");
+	/* Draw a vertical line left of this row? */
 
-	switch (sp->pos) {
-	case TBL_SPAN_HORIZ:
-	case TBL_SPAN_DHORIZ:
-		print_otag(h, TAG_TD, "?", "colspan", "0");
+	switch (sp->layout->vert) {
+	case 2:
+		lborder = "double";
+		break;
+	case 1:
+		lborder = "solid";
 		break;
 	default:
-		for (dp = sp->first; dp != NULL; dp = dp->next) {
-			print_stagq(h, tt);
+		lborder = NULL;
+		break;
+	}
 
-			/*
-			 * Do not generate <td> elements for continuations
-			 * of spanned cells.  Larger <td> elements covering
-			 * this space were already generated earlier.
-			 */
-
-			if (dp->layout->pos == TBL_CELL_SPAN ||
-			    dp->layout->pos == TBL_CELL_DOWN ||
-			    (dp->string != NULL &&
-			     strcmp(dp->string, "\\^") == 0))
-				continue;
-
-			/* Determine the attribute values. */
-
-			if (dp->hspans > 0) {
-				(void)snprintf(hbuf, sizeof(hbuf),
-				    "%d", dp->hspans + 1);
-				hspans = hbuf;
-			} else
-				hspans = NULL;
-			if (dp->vspans > 0) {
-				(void)snprintf(vbuf, sizeof(vbuf),
-				    "%d", dp->vspans + 1);
-				vspans = vbuf;
-			} else
-				vspans = NULL;
-
-			switch (dp->layout->pos) {
-			case TBL_CELL_CENTRE:
-				halign = "center";
-				break;
-			case TBL_CELL_RIGHT:
-			case TBL_CELL_NUMBER:
-				halign = "right";
-				break;
-			default:
-				halign = NULL;
-				break;
-			}
-			if (dp->layout->flags & TBL_CELL_TALIGN)
-				valign = "top";
-			else if (dp->layout->flags & TBL_CELL_BALIGN)
-				valign = "bottom";
-			else
-				valign = NULL;
-
-			/* Print the element and the attributes. */
-
-			print_otag(h, TAG_TD, "??ss",
-			    "colspan", hspans, "rowspan", vspans,
-			    "vertical-align", valign,
-			    "text-align", halign);
-			if (dp->string != NULL)
-				print_text(h, dp->string);
+	/* Draw a horizontal line below this row? */
+
+	bborder = NULL;
+	if ((psp = sp->next) != NULL) {
+		switch (psp->pos) {
+		case TBL_SPAN_DHORIZ:
+			bborder = "double";
+			break;
+		case TBL_SPAN_HORIZ:
+			bborder = "solid";
+			break;
+		default:
+			break;
 		}
-		break;
+	}
+
+	tt = print_otag(h, TAG_TR, "ss",
+	    "border-left-style", lborder,
+	    "border-bottom-style", bborder);
+
+	for (dp = sp->first; dp != NULL; dp = dp->next) {
+		print_stagq(h, tt);
+
+		/*
+		 * Do not generate <td> elements for continuations
+		 * of spanned cells.  Larger <td> elements covering
+		 * this space were already generated earlier.
+		 */
+
+		cp = dp->layout;
+		if (cp->pos == TBL_CELL_SPAN || cp->pos == TBL_CELL_DOWN ||
+		    (dp->string != NULL && strcmp(dp->string, "\\^") == 0))
+			continue;
+
+		/* Determine the attribute values. */
+
+		if (dp->hspans > 0) {
+			(void)snprintf(hbuf, sizeof(hbuf),
+			    "%d", dp->hspans + 1);
+			hspans = hbuf;
+		} else
+			hspans = NULL;
+		if (dp->vspans > 0) {
+			(void)snprintf(vbuf, sizeof(vbuf),
+			    "%d", dp->vspans + 1);
+			vspans = vbuf;
+		} else
+			vspans = NULL;
+
+		switch (cp->pos) {
+		case TBL_CELL_CENTRE:
+			halign = "center";
+			break;
+		case TBL_CELL_RIGHT:
+		case TBL_CELL_NUMBER:
+			halign = "right";
+			break;
+		default:
+			halign = NULL;
+			break;
+		}
+		if (cp->flags & TBL_CELL_TALIGN)
+			valign = "top";
+		else if (cp->flags & TBL_CELL_BALIGN)
+			valign = "bottom";
+		else
+			valign = NULL;
+
+		for (i = dp->hspans; i > 0; i--)
+			cp = cp->next;
+		switch (cp->vert) {
+		case 2:
+			rborder = "double";
+			break;
+		case 1:
+			rborder = "solid";
+			break;
+		default:
+			rborder = NULL;
+			break;
+		}
+
+		/* Print the element and the attributes. */
+
+		print_otag(h, TAG_TD, "??sss",
+		    "colspan", hspans, "rowspan", vspans,
+		    "vertical-align", valign,
+		    "text-align", halign,
+		    "border-right-style", rborder);
+		if (dp->string != NULL)
+			print_text(h, dp->string);
 	}
 
 	print_tagq(h, tt);
Index: mandoc.css
===================================================================
RCS file: /home/cvs/mandoc/mandoc/mandoc.css,v
retrieving revision 1.39
retrieving revision 1.40
diff -Lmandoc.css -Lmandoc.css -u -p -r1.39 -r1.40
--- mandoc.css
+++ mandoc.css
@@ -13,8 +13,11 @@
 html {		max-width: 65em; }
 body {		font-family: Helvetica,Arial,sans-serif; }
 table {		margin-top: 0em;
-		margin-bottom: 0em; }
-td {		vertical-align: middle; }
+		margin-bottom: 0em;
+		border-collapse: collapse; }
+td {		vertical-align: middle;
+		padding-left: 0.2em;
+		padding-right: 0.2em; }
 ul, ol, dl {	margin-top: 0em;
 		margin-bottom: 0em; }
 li, dt {	margin-top: 1em; }
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-11-26 21:27   ` Ingo Schwarze
@ 2018-11-26 21:58     ` Pali Rohár
  2018-11-26 22:01       ` Pali Rohár
  2018-11-29  2:15     ` Ingo Schwarze
  1 sibling, 1 reply; 25+ messages in thread
From: Pali Rohár @ 2018-11-26 21:58 UTC (permalink / raw)
  To: Ingo Schwarze; +Cc: discuss


[-- Attachment #1.1: Type: text/plain, Size: 1006 bytes --]

Hi!

I tested new cvs changes for following table:

.TS
box;
c|c|c.
A	A1	A_
\^	A2	\^
_
B	B1	B_
_
C	C1	C_
\^	C2	\^
_
E	E1	E_
\^	E2	\^
\^	E3	\^
_
F	F1	F_
.TE

And in chromium browser 70 there is missing horizontal line between
A and B; and also between C and D. See attachment how it looks like.

It is really suspicious that horizontal line is just between A2 and B1.
And not across whole line.

Below is output from GNU man, which I believe is correct:

┌──┬────┬────┐
│A │ A1 │ A_ │
│  │ A2 │    │
├──┼────┼────┤
│B │ B1 │ B_ │
├──┼────┼────┤
│C │ C1 │ C_ │
│  │ C2 │    │
├──┼────┼────┤
│  │ E1 │    │
│E │ E2 │ E_ │
│  │ E3 │    │
├──┼────┼────┤
│F │ F1 │ F_ │
└──┴────┴────┘

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #1.2: chrome_output.png --]
[-- Type: image/png, Size: 3613 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-11-26 21:58     ` Pali Rohár
@ 2018-11-26 22:01       ` Pali Rohár
  2018-11-26 22:05         ` Pali Rohár
  0 siblings, 1 reply; 25+ messages in thread
From: Pali Rohár @ 2018-11-26 22:01 UTC (permalink / raw)
  To: Ingo Schwarze; +Cc: discuss

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

On Monday 26 November 2018 22:58:26 Pali Rohár wrote:
> Hi!
> 
> I tested new cvs changes for following table:
> 
> .TS
> box;
> c|c|c.
> A	A1	A_
> \^	A2	\^
> _
> B	B1	B_
> _
> C	C1	C_
> \^	C2	\^
> _
> E	E1	E_
> \^	E2	\^
> \^	E3	\^
> _
> F	F1	F_
> .TE
> 
> And in chromium browser 70 there is missing horizontal line between
> A and B; and also between C and D. See attachment how it looks like.
> 
> It is really suspicious that horizontal line is just between A2 and B1.
> And not across whole line.
> 
> Below is output from GNU man, which I believe is correct:
> 
> ┌──┬────┬────┐
> │A │ A1 │ A_ │
> │  │ A2 │    │
> ├──┼────┼────┤
> │B │ B1 │ B_ │
> ├──┼────┼────┤
> │C │ C1 │ C_ │
> │  │ C2 │    │
> ├──┼────┼────┤
> │  │ E1 │    │
> │E │ E2 │ E_ │
> │  │ E3 │    │
> ├──┼────┼────┤
> │F │ F1 │ F_ │
> └──┴────┴────┘

Now I tested Firefox and Konqueror browsers too. And they rendered those
missing horizontal lines... Output is exactly same as like GNU man
terminal output.

So it is just problem in Chromium 70?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-11-26 22:01       ` Pali Rohár
@ 2018-11-26 22:05         ` Pali Rohár
  2018-12-01 17:20           ` Ingo Schwarze
  0 siblings, 1 reply; 25+ messages in thread
From: Pali Rohár @ 2018-11-26 22:05 UTC (permalink / raw)
  To: Ingo Schwarze; +Cc: discuss

[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]

On Monday 26 November 2018 23:01:33 Pali Rohár wrote:
> On Monday 26 November 2018 22:58:26 Pali Rohár wrote:
> > Hi!
> > 
> > I tested new cvs changes for following table:
> > 
> > .TS
> > box;
> > c|c|c.
> > A	A1	A_
> > \^	A2	\^
> > _
> > B	B1	B_
> > _
> > C	C1	C_
> > \^	C2	\^
> > _
> > E	E1	E_
> > \^	E2	\^
> > \^	E3	\^
> > _
> > F	F1	F_
> > .TE
> > 
> > And in chromium browser 70 there is missing horizontal line between
> > A and B; and also between C and D. See attachment how it looks like.
> > 
> > It is really suspicious that horizontal line is just between A2 and B1.
> > And not across whole line.
> > 
> > Below is output from GNU man, which I believe is correct:
> > 
> > ┌──┬────┬────┐
> > │A │ A1 │ A_ │
> > │  │ A2 │    │
> > ├──┼────┼────┤
> > │B │ B1 │ B_ │
> > ├──┼────┼────┤
> > │C │ C1 │ C_ │
> > │  │ C2 │    │
> > ├──┼────┼────┤
> > │  │ E1 │    │
> > │E │ E2 │ E_ │
> > │  │ E3 │    │
> > ├──┼────┼────┤
> > │F │ F1 │ F_ │
> > └──┴────┴────┘
> 
> Now I tested Firefox and Konqueror browsers too. And they rendered those
> missing horizontal lines... Output is exactly same as like GNU man
> terminal output.
> 
> So it is just problem in Chromium 70?

And in all browsers I see another suspicious thing. Vertical lines in
the middle of the table are black and horizontal lines are gray or
rather dark gray (but not black). Border around whole table is also
gray.

Is this intended?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-11-26 21:27   ` Ingo Schwarze
  2018-11-26 21:58     ` Pali Rohár
@ 2018-11-29  2:15     ` Ingo Schwarze
  1 sibling, 0 replies; 25+ messages in thread
From: Ingo Schwarze @ 2018-11-29  2:15 UTC (permalink / raw)
  To: Pali Rohar; +Cc: discuss

Hi Pali,

i'm only keeping the unresolved items, deleting the resolved ones.

Ingo Schwarze wrote on Mon, Nov 26, 2018 at 10:27:28PM +0100:
> Ingo Schwarze wrote on Mon, Jul 16, 2018 at 05:29:19PM +0200:
>> Pali Rohar wrote on Mon, Jul 16, 2018 at 01:03:35PM +0200:

[...]
>>> Second problem is with text alignment in table. When cell spanning is
>>> used (e.g. via s or via \^) then text is not correctly aligned and it
>>> looks "ugly". This problem is in both HTML and ASCII output.
>> [...]
>>> Alignment is wrong. "Name" should be centered and not on top.
>>> Same for "value2".

> Vertical alignment in ASCII output is a tough problem and not likely
> to get fixed soon; the rest should be fixed now, i think.

Still open.

> [...]
>>> Third thing which I observed is that mandoc is in UTF-8 output does
>>> not use Unicode Box Drawing characters, but rather ugly ASCII.
 
> That is still open.

Now, it is resolved, see my earlier mail - which you already replied to,
thanks for that, i'll look at the feedback later.

>>> Column for val1 is enormously wide
>> 
>> That's an important known issue listed in the TODO file:
>> 
>>  - the "s" layout column specifier is used for placement of data
>>    into columns, but ignored during column width calculations
>>    synaptics(4) found by tedu@  Mon, 17 Aug 2015 21:17:42 -0400
>>    loc *  exist **  algo ***  size *  imp **
>> 
>> Priority is only moderate because solving it will require
>> quite some work.

> That is still open, too.

That's now implemented, too, see the commit below.

So, according to my bookkeeping, the only item remaining is the
tough and relatively low-priority vertical alignment in terminal
output.

Yours,
  Ingo


Log Message:
-----------
Better handle automatic column width assignments in the presence of
horizontal spans, by implementing a moderately difficult iterative
algoritm.  The benefit is that spans containing long text no longer
cause an excessive width of their starting column.

The result is likely not optimal, in particular in the presence
of many spans overlapping in complicated ways nor when spans
interact with equalizing or maximizing colums.  But i doubt the
practical usefulness of making this more complicated.

Issue originally reported in synaptics(4), which now looks better,
by tedu@ three years ago, and reminded by Pali Rohar this summer.

Modified Files:
--------------
    mandoc:
        TODO
        out.c

Revision Data
-------------
Index: TODO
===================================================================
RCS file: /home/cvs/mandoc/mandoc/TODO,v
retrieving revision 1.279
retrieving revision 1.280
diff -LTODO -LTODO -u -p -r1.279 -r1.280
--- TODO
+++ TODO
@@ -168,11 +168,6 @@ are mere guesses, and some may be wrong.
 
 --- missing tbl features -----------------------------------------------
 
-- the "s" layout column specifier is used for placement of data
-  into columns, but ignored during column width calculations
-  synaptics(4) found by tedu@  Mon, 17 Aug 2015 21:17:42 -0400
-  loc *  exist **  algo ***  size *  imp **
-
 - vertical centering in cells vertically spanned with ^
   pali dot rohar at gmail dot com 16 Jul 2018 13:03:35 +0200
   loc *  exist ***  algo ***  size **  imp *
Index: out.c
===================================================================
RCS file: /home/cvs/mandoc/mandoc/out.c,v
retrieving revision 1.74
retrieving revision 1.75
diff -Lout.c -Lout.c -u -p -r1.74 -r1.75
--- out.c
+++ out.c
@@ -30,12 +30,19 @@
 #include "mandoc.h"
 #include "out.h"
 
-static	void	tblcalc_data(struct rofftbl *, struct roffcol *,
+struct	tbl_colgroup {
+	struct tbl_colgroup	*next;
+	size_t			 wanted;
+	int			 startcol;
+	int			 endcol;
+};
+
+static	size_t	tblcalc_data(struct rofftbl *, struct roffcol *,
 			const struct tbl_opts *, const struct tbl_dat *,
 			size_t);
-static	void	tblcalc_literal(struct rofftbl *, struct roffcol *,
+static	size_t	tblcalc_literal(struct rofftbl *, struct roffcol *,
 			const struct tbl_dat *, size_t);
-static	void	tblcalc_number(struct rofftbl *, struct roffcol *,
+static	size_t	tblcalc_number(struct rofftbl *, struct roffcol *,
 			const struct tbl_opts *, const struct tbl_dat *);
 
 
@@ -104,16 +111,18 @@ a2roffsu(const char *src, struct roffsu 
  * used for the actual width calculations.
  */
 void
-tblcalc(struct rofftbl *tbl, const struct tbl_span *sp,
+tblcalc(struct rofftbl *tbl, const struct tbl_span *sp_first,
     size_t offset, size_t rmargin)
 {
 	struct roffsu		 su;
 	const struct tbl_opts	*opts;
+	const struct tbl_span	*sp;
 	const struct tbl_dat	*dp;
 	struct roffcol		*col;
-	size_t			 ewidth, xwidth;
-	int			 hspans;
-	int			 icol, maxcol, necol, nxcol, quirkcol;
+	struct tbl_colgroup	*first_group, **gp, *g;
+	size_t			*colwidth;
+	size_t			 ewidth, min1, min2, wanted, width, xwidth;
+	int			 done, icol, maxcol, necol, nxcol, quirkcol;
 
 	/*
 	 * Allocate the master column specifiers.  These will hold the
@@ -121,33 +130,34 @@ tblcalc(struct rofftbl *tbl, const struc
 	 * must be freed and nullified by the caller.
 	 */
 
-	assert(NULL == tbl->cols);
-	tbl->cols = mandoc_calloc((size_t)sp->opts->cols,
+	assert(tbl->cols == NULL);
+	tbl->cols = mandoc_calloc((size_t)sp_first->opts->cols,
 	    sizeof(struct roffcol));
-	opts = sp->opts;
+	opts = sp_first->opts;
 
-	for (maxcol = -1; sp; sp = sp->next) {
-		if (TBL_SPAN_DATA != sp->pos)
+	maxcol = -1;
+	first_group = NULL;
+	for (sp = sp_first; sp != NULL; sp = sp->next) {
+		if (sp->pos != TBL_SPAN_DATA)
 			continue;
-		hspans = 1;
+
 		/*
 		 * Account for the data cells in the layout, matching it
 		 * to data cells in the data section.
 		 */
-		for (dp = sp->first; dp; dp = dp->next) {
-			/* Do not used spanned cells in the calculation. */
-			if (0 < --hspans)
-				continue;
-			hspans = dp->hspans;
-			if (1 < hspans)
-				continue;
+
+		gp = &first_group;
+		for (dp = sp->first; dp != NULL; dp = dp->next) {
 			icol = dp->layout->col;
-			while (maxcol < icol)
+			while (icol > maxcol)
 				tbl->cols[++maxcol].spacing = SIZE_MAX;
 			col = tbl->cols + icol;
 			col->flags |= dp->layout->flags;
 			if (dp->layout->flags & TBL_CELL_WIGN)
 				continue;
+
+			/* Handle explicit width specifications. */
+
 			if (dp->layout->wstr != NULL &&
 			    dp->layout->width == 0 &&
 			    a2roffsu(dp->layout->wstr, &su, SCALE_EN)
@@ -160,15 +170,164 @@ tblcalc(struct rofftbl *tbl, const struc
 			    (col->spacing == SIZE_MAX ||
 			     col->spacing < dp->layout->spacing))
 				col->spacing = dp->layout->spacing;
-			tblcalc_data(tbl, col, opts, dp,
+
+			/*
+			 * Calculate an automatic width.
+			 * Except for spanning cells, apply it.
+			 */
+
+			width = tblcalc_data(tbl,
+			    dp->hspans == 0 ? col : NULL,
+			    opts, dp,
 			    dp->block == 0 ? 0 :
 			    dp->layout->width ? dp->layout->width :
 			    rmargin ? (rmargin + sp->opts->cols / 2)
 			    / (sp->opts->cols + 1) : 0);
+			if (dp->hspans == 0)
+				continue;
+
+			/*
+			 * Build an ordered, singly linked list
+			 * of all groups of columns joined by spans,
+			 * recording the minimum width for each group.
+			 */
+
+			while (*gp != NULL && ((*gp)->startcol < icol ||
+			    (*gp)->endcol < icol + dp->hspans))
+				gp = &(*gp)->next;
+			if (*gp == NULL || (*gp)->startcol > icol ||
+                            (*gp)->endcol > icol + dp->hspans) {
+				g = mandoc_malloc(sizeof(*g));
+				g->next = *gp;
+				g->wanted = width;
+				g->startcol = icol;
+				g->endcol = icol + dp->hspans;
+				*gp = g;
+			} else if ((*gp)->wanted < width)
+				(*gp)->wanted = width;
 		}
 	}
 
 	/*
+	 * Column spacings are needed for span width calculations,
+	 * so set the default values now.
+	 */
+
+	for (icol = 0; icol <= maxcol; icol++)
+		if (tbl->cols[icol].spacing == SIZE_MAX || icol == maxcol)
+			tbl->cols[icol].spacing = 3;
+
+	/*
+	 * Replace the minimum widths with the missing widths,
+	 * and dismiss groups that are already wide enough.
+	 */
+
+	gp = &first_group;
+	while ((g = *gp) != NULL) {
+		done = 0;
+		for (icol = g->startcol; icol <= g->endcol; icol++) {
+			width = tbl->cols[icol].width;
+			if (icol < g->endcol)
+				width += tbl->cols[icol].spacing;
+			if (g->wanted <= width) {
+				done = 1;
+				break;
+			} else
+				(*gp)->wanted -= width;
+		}
+		if (done) {
+			*gp = g->next;
+			free(g);
+		} else
+			gp = &(*gp)->next;
+	}
+
+	colwidth = mandoc_reallocarray(NULL, maxcol + 1, sizeof(*colwidth));
+	while (first_group != NULL) {
+
+		/*
+		 * Rebuild the array of the widths of all columns
+		 * participating in spans that require expansion.
+		 */
+
+		for (icol = 0; icol <= maxcol; icol++)
+			colwidth[icol] = SIZE_MAX;
+		for (g = first_group; g != NULL; g = g->next)
+			for (icol = g->startcol; icol <= g->endcol; icol++)
+				colwidth[icol] = tbl->cols[icol].width;
+
+		/*
+		 * Find the smallest and second smallest column width
+		 * among the columns which may need expamsion.
+		 */
+
+		min1 = min2 = SIZE_MAX;
+		for (icol = 0; icol <= maxcol; icol++) {
+			if (min1 > colwidth[icol]) {
+				min2 = min1;
+				min1 = colwidth[icol];
+			} else if (min1 < colwidth[icol] &&
+			    min2 > colwidth[icol])
+				min2 = colwidth[icol];
+		}
+
+		/*
+		 * Find the minimum wanted width
+		 * for any one of the narrowest columns,
+		 * and mark the columns wanting that width.
+		 */
+
+		wanted = min2;
+		for (g = first_group; g != NULL; g = g->next) {
+			necol = 0;
+			for (icol = g->startcol; icol <= g->endcol; icol++)
+				if (tbl->cols[icol].width == min1)
+					necol++;
+			if (necol == 0)
+				continue;
+			width = min1 + (g->wanted - 1) / necol + 1;
+			if (width > min2)
+				width = min2;
+			if (wanted > width)
+				wanted = width;
+			for (icol = g->startcol; icol <= g->endcol; icol++)
+				if (colwidth[icol] == min1 ||
+				    (colwidth[icol] < min2 &&
+				     colwidth[icol] > width))
+					colwidth[icol] = width;
+		}
+
+		/* Record the effect of the widening on the group list. */
+
+		gp = &first_group;
+		while ((g = *gp) != NULL) {
+			done = 0;
+			for (icol = g->startcol; icol <= g->endcol; icol++) {
+				if (colwidth[icol] != wanted ||
+				    tbl->cols[icol].width == wanted)
+					continue;
+				if (g->wanted <= wanted - min1) {
+					done = 1;
+					break;
+				}
+				g->wanted -= wanted - min1;
+			}
+			if (done) {
+				*gp = g->next;
+				free(g);
+			} else
+				gp = &(*gp)->next;
+		}
+
+		/* Record the effect of the widening on the columns. */
+
+		for (icol = 0; icol <= maxcol; icol++)
+			if (colwidth[icol] == wanted)
+				tbl->cols[icol].width = wanted;
+	}
+	free(colwidth);
+
+	/*
 	 * Align numbers with text.
 	 * Count columns to equalize and columns to maximize.
 	 * Find maximum width of the columns to equalize.
@@ -183,8 +342,6 @@ tblcalc(struct rofftbl *tbl, const struc
 			col->decimal += (col->width - col->nwidth) / 2;
 		else
 			col->width = col->nwidth;
-		if (col->spacing == SIZE_MAX || icol == maxcol)
-			col->spacing = 3;
 		if (col->flags & TBL_CELL_EQUAL) {
 			necol++;
 			if (ewidth < col->width)
@@ -257,7 +414,7 @@ tblcalc(struct rofftbl *tbl, const struc
 	}
 }
 
-static void
+static size_t
 tblcalc_data(struct rofftbl *tbl, struct roffcol *col,
     const struct tbl_opts *opts, const struct tbl_dat *dp, size_t mw)
 {
@@ -269,26 +426,24 @@ tblcalc_data(struct rofftbl *tbl, struct
 	case TBL_CELL_HORIZ:
 	case TBL_CELL_DHORIZ:
 		sz = (*tbl->len)(1, tbl->arg);
-		if (col->width < sz)
+		if (col != NULL && col->width < sz)
 			col->width = sz;
-		break;
+		return sz;
 	case TBL_CELL_LONG:
 	case TBL_CELL_CENTRE:
 	case TBL_CELL_LEFT:
 	case TBL_CELL_RIGHT:
-		tblcalc_literal(tbl, col, dp, mw);
-		break;
+		return tblcalc_literal(tbl, col, dp, mw);
 	case TBL_CELL_NUMBER:
-		tblcalc_number(tbl, col, opts, dp);
-		break;
+		return tblcalc_number(tbl, col, opts, dp);
 	case TBL_CELL_DOWN:
-		break;
+		return 0;
 	default:
 		abort();
 	}
 }
 
-static void
+static size_t
 tblcalc_literal(struct rofftbl *tbl, struct roffcol *col,
     const struct tbl_dat *dp, size_t mw)
 {
@@ -297,11 +452,12 @@ tblcalc_literal(struct rofftbl *tbl, str
 	char		*end;	/* End of the current line. */
 	size_t		 lsz;	/* Length of the current line. */
 	size_t		 wsz;	/* Length of the current word. */
+	size_t		 msz;   /* Length of the longest line. */
 
 	if (dp->string == NULL || *dp->string == '\0')
-		return;
+		return 0;
 	str = mw ? mandoc_strdup(dp->string) : dp->string;
-	lsz = 0;
+	msz = lsz = 0;
 	for (beg = str; beg != NULL && *beg != '\0'; beg = end) {
 		end = mw ? strchr(beg, ' ') : NULL;
 		if (end != NULL) {
@@ -314,14 +470,17 @@ tblcalc_literal(struct rofftbl *tbl, str
 			lsz += 1 + wsz;
 		else
 			lsz = wsz;
-		if (col->width < lsz)
-			col->width = lsz;
+		if (msz < lsz)
+			msz = lsz;
 	}
 	if (mw)
 		free((void *)str);
+	if (col != NULL && col->width < msz)
+		col->width = msz;
+	return msz;
 }
 
-static void
+static size_t
 tblcalc_number(struct rofftbl *tbl, struct roffcol *col,
 		const struct tbl_opts *opts, const struct tbl_dat *dp)
 {
@@ -330,7 +489,11 @@ tblcalc_number(struct rofftbl *tbl, stru
 	char		 buf[2];
 
 	if (dp->string == NULL || *dp->string == '\0')
-		return;
+		return 0;
+
+	totsz = (*tbl->slen)(dp->string, tbl->arg);
+	if (col == NULL)
+		return totsz;
 
 	/*
 	 * Find the last digit and
@@ -353,11 +516,10 @@ tblcalc_number(struct rofftbl *tbl, stru
 
 	/* Not a number, treat as a literal string. */
 
-	totsz = (*tbl->slen)(dp->string, tbl->arg);
 	if (lastdigit == NULL) {
-		if (col->width < totsz)
+		if (col != NULL && col->width < totsz)
 			col->width = totsz;
-		return;
+		return totsz;
 	}
 
 	/* Measure the width of the integer part. */
@@ -387,4 +549,5 @@ tblcalc_number(struct rofftbl *tbl, stru
 
 	if (totsz > col->nwidth)
 		col->nwidth = totsz;
+	return totsz;
 }
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-11-26 22:05         ` Pali Rohár
@ 2018-12-01 17:20           ` Ingo Schwarze
  2018-12-01 19:35             ` Pali Rohár
                               ` (2 more replies)
  0 siblings, 3 replies; 25+ messages in thread
From: Ingo Schwarze @ 2018-12-01 17:20 UTC (permalink / raw)
  To: Pali Rohar; +Cc: discuss

Hi Pali,

Pali Rohar wrote on Mon, Nov 26, 2018 at 11:05:16PM +0100:
> On Monday 26 November 2018 23:01:33 Pali Rohar wrote:
>> On Monday 26 November 2018 22:58:26 Pali Rohar wrote:

>>> I tested new cvs changes for following table:

>>> .TS
>>> box;
>>> c|c|c.
>>> A	A1	A_
>>> \^	A2	\^
>>> _
>>> B	B1	B_
>>> _
>>> C	C1	C_
>>> \^	C2	\^
>>> _
>>> E	E1	E_
>>> \^	E2	\^
>>> \^	E3	\^
>>> _
>>> F	F1	F_
>>> .TE

The table syntax looks sane to me.

>>> And in chromium browser 70 there is missing horizontal line between
>>> A and B; and also between C and D. See attachment how it looks like.
>>>
>>> It is really suspicious that horizontal line is just between A2 and B1.
>>> And not across whole line.

The rendering in the PNG file you attached seems broken in multiple
respects:

 * The outer border of the table as a whole is rendered as "double",
   even though the mandoc HTML output clearly says:

   <table class="tbl" style="border-style: solid;">

 * Same for the horizontal line between B and C:

   <tr style="border-bottom-style: solid;">
     <td style="text-align: center; border-right-style: solid;">B</td>

 * Same for the horizontal line between A and B:

   <tr style="border-bottom-style: solid;">
     <td style="text-align: center; border-right-style: solid;">A2</td>
   </tr>

So whatever produced that PNG file seems quite broken.

Oh, one among the bugs in that software could be that for deciding
where to draw the borders of a row, it only looks at the <td>
elements contained in that <tr> element itself.

On https://www.w3.org/TR/html/tabular-data.html
the algorithm for processing rows says in step 13:

  Let the slots with coordinates (x, y)
  such that xcurrent <= x < xcurrent+colspan
  and ycurrent <= y < ycurrent+rowspan be covered by a new cell c,
  anchored at (xcurrent, ycurrent), which has width colspan and
  height rowspan, corresponding to the current cell element.

That implies that all slots in the second row of the table -
the row that contains A2 - are covered.  The first slot is
covered by the cell A, the third slot by the cell A_.

And right below "4.9.12. Processing model" it says:

  A row is a complete set of slots from x=0 to x=xwidth-1,
  for a particular value of y.

And https://www.w3.org/TR/CSS2/tables.html says
below "17.6.2 The collapsing border model":

  In the collapsing border model, it is possible to specify borders
  that surround all or part of a cell, row, row group, column, and
  column group.

Note that mandoc.css says "table { border-collapse: collapse; }",
so the above applies.  The whole *row* is supposed to be surrounded,
not just the <td> elements that happen to be contained in the
associated <tr> element.

Also, https://validator.w3.org/nu/ does not show any warnings
except asking for a "lang" attribute of the <html> element.

So, i believe what mandoc emits is correct and unambiguous -
if it is not, i'd appreciate clues what is wrong and how to fix it.

>>> Below is output from GNU man, which I believe is correct:
[...]

I agree that rendering is correct.
It also matches what mandoc -Tutf8 and -Tascii produce now.

>> Now I tested Firefox and Konqueror browsers too. And they rendered those
>> missing horizontal lines... Output is exactly same as like GNU man
>> terminal output.

Yes, i think Firefox renders the mandoc output correctly.

>> So it is just problem in Chromium 70?

It seems so to me, but i'm not a specialist for web technologies,
so if anyone here knows better, please speak up.

> And in all browsers I see another suspicious thing. Vertical lines in
> the middle of the table are black and horizontal lines are gray or
> rather dark gray (but not black). Border around whole table is also
> gray.
> 
> Is this intended?

No, it is not intended, all lines seem black and of equal width to me
in Firefox 62.0.2 on OpenBSD-current.

Neither the HTML emitted by mandoc nor mandoc.css makes any statement
about the color or width of the lines.  That is intentional: neither
does the tbl(7) input code, and i believe that when styling, it is
best to only style what you intend to style and leave the rest at
the default or user settings.

I don't see why any browser would render any of the lines in gray,
though, and even less so in two different colors.

  https://www.w3.org/TR/CSS2/tables.html

doesn't seem to say anything specific about color, so i'd expect

  https://www.w3.org/TR/CSS2/colors.html

to apply, which says:

  'color'
    Value:  	<color> | inherit
    Initial:  	depends on user agent 

but whatever the initial value for a root element, it should be inherited
by all children alike, as far as i can see, so the borders should be
the same color as the text.

Firing up "Web Developer >> Inspector" in Firefox 62.0.2 and enabling
"Browser Styles", i do indeed see "border-bottom-color: rgb(0, 0, 0);"
for the <table> and all its children, as expected.

So i fear i do not know how i could improve the mandoc output...

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-12-01 17:20           ` Ingo Schwarze
@ 2018-12-01 19:35             ` Pali Rohár
  2018-12-03 20:46             ` Pali Rohár
  2018-12-03 22:01             ` Pali Rohár
  2 siblings, 0 replies; 25+ messages in thread
From: Pali Rohár @ 2018-12-01 19:35 UTC (permalink / raw)
  To: Ingo Schwarze; +Cc: discuss

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

On Saturday 01 December 2018 18:20:57 Ingo Schwarze wrote:
> Hi Pali,
> 
> Pali Rohar wrote on Mon, Nov 26, 2018 at 11:05:16PM +0100:
> > On Monday 26 November 2018 23:01:33 Pali Rohar wrote:
> >> On Monday 26 November 2018 22:58:26 Pali Rohar wrote:
> 
> >>> I tested new cvs changes for following table:
> 
> >>> .TS
> >>> box;
> >>> c|c|c.
> >>> A	A1	A_
> >>> \^	A2	\^
> >>> _
> >>> B	B1	B_
> >>> _
> >>> C	C1	C_
> >>> \^	C2	\^
> >>> _
> >>> E	E1	E_
> >>> \^	E2	\^
> >>> \^	E3	\^
> >>> _
> >>> F	F1	F_
> >>> .TE
> 
> The table syntax looks sane to me.
> 
> >>> And in chromium browser 70 there is missing horizontal line between
> >>> A and B; and also between C and D. See attachment how it looks like.
> >>>
> >>> It is really suspicious that horizontal line is just between A2 and B1.
> >>> And not across whole line.
> 
> The rendering in the PNG file you attached seems broken in multiple
> respects:
> 
>  * The outer border of the table as a whole is rendered as "double",
>    even though the mandoc HTML output clearly says:
> 
>    <table class="tbl" style="border-style: solid;">
> 
>  * Same for the horizontal line between B and C:
> 
>    <tr style="border-bottom-style: solid;">
>      <td style="text-align: center; border-right-style: solid;">B</td>
> 
>  * Same for the horizontal line between A and B:
> 
>    <tr style="border-bottom-style: solid;">
>      <td style="text-align: center; border-right-style: solid;">A2</td>
>    </tr>
> 
> So whatever produced that PNG file seems quite broken.

That PNG file is "printscreen" of Chromium browser window. I just wanted
to show how output looks in Chromium.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-12-01 17:20           ` Ingo Schwarze
  2018-12-01 19:35             ` Pali Rohár
@ 2018-12-03 20:46             ` Pali Rohár
  2018-12-04  5:33               ` Ingo Schwarze
  2018-12-03 22:01             ` Pali Rohár
  2 siblings, 1 reply; 25+ messages in thread
From: Pali Rohár @ 2018-12-03 20:46 UTC (permalink / raw)
  To: Ingo Schwarze; +Cc: discuss

[-- Attachment #1: Type: text/plain, Size: 2942 bytes --]

On Saturday 01 December 2018 18:20:57 Ingo Schwarze wrote:
> > And in all browsers I see another suspicious thing. Vertical lines in
> > the middle of the table are black and horizontal lines are gray or
> > rather dark gray (but not black). Border around whole table is also
> > gray.
> > 
> > Is this intended?
> 
> No, it is not intended, all lines seem black and of equal width to me
> in Firefox 62.0.2 on OpenBSD-current.
> 
> Neither the HTML emitted by mandoc nor mandoc.css makes any statement
> about the color or width of the lines.  That is intentional: neither
> does the tbl(7) input code, and i believe that when styling, it is
> best to only style what you intend to style and leave the rest at
> the default or user settings.
> 
> I don't see why any browser would render any of the lines in gray,
> though, and even less so in two different colors.
> 
>   https://www.w3.org/TR/CSS2/tables.html
> 
> doesn't seem to say anything specific about color, so i'd expect
> 
>   https://www.w3.org/TR/CSS2/colors.html
> 
> to apply, which says:
> 
>   'color'
>     Value:  	<color> | inherit
>     Initial:  	depends on user agent 
> 
> but whatever the initial value for a root element, it should be inherited
> by all children alike, as far as i can see, so the borders should be
> the same color as the text.
> 
> Firing up "Web Developer >> Inspector" in Firefox 62.0.2 and enabling
> "Browser Styles", i do indeed see "border-bottom-color: rgb(0, 0, 0);"
> for the <table> and all its children, as expected.

Hi! I played with colors and seems that browsers do not inherit table
border color to td border color. And by default my chrome and firefox
uses gray color for table (if not specified).

E.g. when you set "table { border-color: yellow; }" and border of
"table" and "tr" elements are yellow, but "td" elements in black.

Following patch "fixes" or rather workaround that problem. It inherits
color also for "td" elements.

Index: mandoc.css
===================================================================
RCS file: /cvs/mandoc/mandoc.css,v
retrieving revision 1.40
diff -u -r1.40 mandoc.css
--- mandoc.css	26 Nov 2018 21:06:02 -0000	1.40
+++ mandoc.css	3 Dec 2018 20:41:19 -0000
@@ -17,7 +17,8 @@
 		border-collapse: collapse; }
 td {		vertical-align: middle;
 		padding-left: 0.2em;
-		padding-right: 0.2em; }
+		padding-right: 0.2em;
+		border-color: inherit; }
 ul, ol, dl {	margin-top: 0em;
 		margin-bottom: 0em; }
 li, dt {	margin-top: 1em; }

With this patch all border colors are now gray (which comes from user
agent style).

What do you think about this patch? In troff/tbl you does not specify
color, but I think that HTML output should have consistent colors -- not
different color for horizontal lines and different for vertical lines.
Just because browsers have different defaults.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-12-01 17:20           ` Ingo Schwarze
  2018-12-01 19:35             ` Pali Rohár
  2018-12-03 20:46             ` Pali Rohár
@ 2018-12-03 22:01             ` Pali Rohár
  2018-12-03 22:14               ` Ingo Schwarze
  2 siblings, 1 reply; 25+ messages in thread
From: Pali Rohár @ 2018-12-03 22:01 UTC (permalink / raw)
  To: Ingo Schwarze; +Cc: discuss

[-- Attachment #1: Type: text/plain, Size: 4384 bytes --]

On Saturday 01 December 2018 18:20:57 Ingo Schwarze wrote:
> Hi Pali,
> 
> Pali Rohar wrote on Mon, Nov 26, 2018 at 11:05:16PM +0100:
> > On Monday 26 November 2018 23:01:33 Pali Rohar wrote:
> >> On Monday 26 November 2018 22:58:26 Pali Rohar wrote:
> 
> >>> I tested new cvs changes for following table:
> 
> >>> .TS
> >>> box;
> >>> c|c|c.
> >>> A	A1	A_
> >>> \^	A2	\^
> >>> _
> >>> B	B1	B_
> >>> _
> >>> C	C1	C_
> >>> \^	C2	\^
> >>> _
> >>> E	E1	E_
> >>> \^	E2	\^
> >>> \^	E3	\^
> >>> _
> >>> F	F1	F_
> >>> .TE
> 
> The table syntax looks sane to me.
> 
> >>> And in chromium browser 70 there is missing horizontal line between
> >>> A and B; and also between C and D. See attachment how it looks like.
> >>>
> >>> It is really suspicious that horizontal line is just between A2 and B1.
> >>> And not across whole line.
> 
> The rendering in the PNG file you attached seems broken in multiple
> respects:
> 
>  * The outer border of the table as a whole is rendered as "double",
>    even though the mandoc HTML output clearly says:
> 
>    <table class="tbl" style="border-style: solid;">
> 
>  * Same for the horizontal line between B and C:
> 
>    <tr style="border-bottom-style: solid;">
>      <td style="text-align: center; border-right-style: solid;">B</td>
> 
>  * Same for the horizontal line between A and B:
> 
>    <tr style="border-bottom-style: solid;">
>      <td style="text-align: center; border-right-style: solid;">A2</td>
>    </tr>
> 
> So whatever produced that PNG file seems quite broken.
> 
> Oh, one among the bugs in that software could be that for deciding
> where to draw the borders of a row, it only looks at the <td>
> elements contained in that <tr> element itself.
> 
> On https://www.w3.org/TR/html/tabular-data.html
> the algorithm for processing rows says in step 13:
> 
>   Let the slots with coordinates (x, y)
>   such that xcurrent <= x < xcurrent+colspan
>   and ycurrent <= y < ycurrent+rowspan be covered by a new cell c,
>   anchored at (xcurrent, ycurrent), which has width colspan and
>   height rowspan, corresponding to the current cell element.
> 
> That implies that all slots in the second row of the table -
> the row that contains A2 - are covered.  The first slot is
> covered by the cell A, the third slot by the cell A_.
> 
> And right below "4.9.12. Processing model" it says:
> 
>   A row is a complete set of slots from x=0 to x=xwidth-1,
>   for a particular value of y.
> 
> And https://www.w3.org/TR/CSS2/tables.html says
> below "17.6.2 The collapsing border model":
> 
>   In the collapsing border model, it is possible to specify borders
>   that surround all or part of a cell, row, row group, column, and
>   column group.
> 
> Note that mandoc.css says "table { border-collapse: collapse; }",
> so the above applies.  The whole *row* is supposed to be surrounded,
> not just the <td> elements that happen to be contained in the
> associated <tr> element.
> 
> Also, https://validator.w3.org/nu/ does not show any warnings
> except asking for a "lang" attribute of the <html> element.
> 
> So, i believe what mandoc emits is correct and unambiguous -
> if it is not, i'd appreciate clues what is wrong and how to fix it.
> 
> >>> Below is output from GNU man, which I believe is correct:
> [...]
> 
> I agree that rendering is correct.
> It also matches what mandoc -Tutf8 and -Tascii produce now.
> 
> >> Now I tested Firefox and Konqueror browsers too. And they rendered those
> >> missing horizontal lines... Output is exactly same as like GNU man
> >> terminal output.
> 
> Yes, i think Firefox renders the mandoc output correctly.
> 
> >> So it is just problem in Chromium 70?
> 
> It seems so to me, but i'm not a specialist for web technologies,
> so if anyone here knows better, please speak up.

Seems that it is needed to put "border-bottom-style: solid" for
rowspanned td element. At least this is working in chrome. And after
playing a bit I was not able to achieve visible border when was
specified for tr element.

It is possible such change in mandoc generator? I understand that
current HTML output is (or you think) correct, but is unusable in chrome
browser. And chrome is one of the major browsers, so it should not be
ignored.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-12-03 22:01             ` Pali Rohár
@ 2018-12-03 22:14               ` Ingo Schwarze
  2018-12-03 22:20                 ` Pali Rohár
  0 siblings, 1 reply; 25+ messages in thread
From: Ingo Schwarze @ 2018-12-03 22:14 UTC (permalink / raw)
  To: Pali Rohar; +Cc: discuss

Hi Pali,

Pali Rohar wrote on Mon, Dec 03, 2018 at 11:01:42PM +0100:

> Seems that it is needed to put "border-bottom-style: solid"
> for rowspanned td element.  At least this is working in chrome.

That would further degrade the quality of the HTML code written by
mandoc.  As a rule, "style=" attributes should be avoided and CSS
should instead by used.  Unfortunately, that's not possible here
because the hard-coded presentational decisions like "draw a border
right here" are already contained in the tbl(7) input, and there
is no way to convert those purely presentational decisions of the
author into semantic or structural markup that could be handled
with CSS.

But at least the amount of "style=" attributes written should be
minimized.  Only those "style=" attributes should be written that
are required to correctly express the author's intent.

> And after playing a bit I was not able to achieve visible border
> when was specified for tr element.
> 
> It is possible such change in mandoc generator? I understand that
> current HTML output is (or you think) correct, but is unusable in
> chrome browser.  And chrome is one of the major browsers, so it
> should not be ignored.

If you think chrome is important, please report the bug with chrome,
because right now, it looks like mandoc output is correct and
chrome rendering is buggy.

Alternatively, please explain why you think that chrome rendering
is correct, and please explain in which way mandoc is violating
the HTML standard, according to your understanding of the standard.

Thanks,
  Ingo
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-12-03 22:14               ` Ingo Schwarze
@ 2018-12-03 22:20                 ` Pali Rohár
  2018-12-03 22:37                   ` Ingo Schwarze
  0 siblings, 1 reply; 25+ messages in thread
From: Pali Rohár @ 2018-12-03 22:20 UTC (permalink / raw)
  To: Ingo Schwarze; +Cc: discuss

[-- Attachment #1: Type: text/plain, Size: 2132 bytes --]

On Monday 03 December 2018 23:14:54 Ingo Schwarze wrote:
> Hi Pali,
> 
> Pali Rohar wrote on Mon, Dec 03, 2018 at 11:01:42PM +0100:
> 
> > Seems that it is needed to put "border-bottom-style: solid"
> > for rowspanned td element.  At least this is working in chrome.
> 
> That would further degrade the quality of the HTML code written by
> mandoc.  As a rule, "style=" attributes should be avoided and CSS
> should instead by used.  Unfortunately, that's not possible here
> because the hard-coded presentational decisions like "draw a border
> right here" are already contained in the tbl(7) input, and there
> is no way to convert those purely presentational decisions of the
> author into semantic or structural markup that could be handled
> with CSS.
> 
> But at least the amount of "style=" attributes written should be
> minimized.  Only those "style=" attributes should be written that
> are required to correctly express the author's intent.

This suggestion is to move border style definition from tr do td.

> > And after playing a bit I was not able to achieve visible border
> > when was specified for tr element.
> > 
> > It is possible such change in mandoc generator? I understand that
> > current HTML output is (or you think) correct, but is unusable in
> > chrome browser.  And chrome is one of the major browsers, so it
> > should not be ignored.
> 
> If you think chrome is important, please report the bug with chrome,
> because right now, it looks like mandoc output is correct and
> chrome rendering is buggy.
> 
> Alternatively, please explain why you think that chrome rendering
> is correct, and please explain in which way mandoc is violating
> the HTML standard, according to your understanding of the standard.

I'm not saying that mandoc output is incorrect. Just I'm trying to find
some modification or workaround which results in non-broken tables in
chrome which are generated by mandoc. What I like to have is ability for
users to see tables in manpages rendered correctly in current versions
of web browsers.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-12-03 22:20                 ` Pali Rohár
@ 2018-12-03 22:37                   ` Ingo Schwarze
  2018-12-04 16:44                     ` Pali Rohár
  0 siblings, 1 reply; 25+ messages in thread
From: Ingo Schwarze @ 2018-12-03 22:37 UTC (permalink / raw)
  To: Pali Rohár; +Cc: discuss

Hi Pali,

Pali Rohar wrote on Mon, Dec 03, 2018 at 11:20:45PM +0100:
> On Monday 03 December 2018 23:14:54 Ingo Schwarze wrote:
>> Pali Rohar wrote on Mon, Dec 03, 2018 at 11:01:42PM +0100:

>>> Seems that it is needed to put "border-bottom-style: solid"
>>> for rowspanned td element.  At least this is working in chrome.

>> That would further degrade the quality of the HTML code written by
>> mandoc.  As a rule, "style=" attributes should be avoided and CSS
>> should instead by used.  Unfortunately, that's not possible here
>> because the hard-coded presentational decisions like "draw a border
>> right here" are already contained in the tbl(7) input, and there
>> is no way to convert those purely presentational decisions of the
>> author into semantic or structural markup that could be handled
>> with CSS.
>> 
>> But at least the amount of "style=" attributes written should be
>> minimized.  Only those "style=" attributes should be written that
>> are required to correctly express the author's intent.

> This suggestion is to move border style definition from tr do td.

That would mean writing more "style=" attributes.
If a row intersects N cells, N times more.
That is not good.

>>> And after playing a bit I was not able to achieve visible border
>>> when was specified for tr element.
>>> 
>>> It is possible such change in mandoc generator? I understand that
>>> current HTML output is (or you think) correct, but is unusable in
>>> chrome browser.  And chrome is one of the major browsers, so it
>>> should not be ignored.

>> If you think chrome is important, please report the bug with chrome,
>> because right now, it looks like mandoc output is correct and
>> chrome rendering is buggy.
>> 
>> Alternatively, please explain why you think that chrome rendering
>> is correct, and please explain in which way mandoc is violating
>> the HTML standard, according to your understanding of the standard.

> I'm not saying that mandoc output is incorrect. Just I'm trying to find
> some modification or workaround which results in non-broken tables in
> chrome which are generated by mandoc. What I like to have is ability for
> users to see tables in manpages rendered correctly in current versions
> of web browsers.

I disagree with that goal.

It is not the job of some software to work around bugs in other software.
It is the job of the maintainers of the broken software to fix it.

If every program tried to work around bugs in other programs,
every program would become more complicated (and hence more buggy).
Time is wasted for devising, implementing, testing, and maintaining
workarounds that would be better spent fixing actual bugs.
And for the authors of the other software which is buggy, the
incentive to fix their bugs is also lowered.

So everybody loses.  In particular the users, because they end up
with *both* programs more buggy than necessary.

And no, the size of the chrome project is not an excuse for letting
bugs unfixed.  Quite to the contrary, the size of a project is one
of the reasons that lead to many bugs in the first place.  So the
bigger a project, the more important it gets to diligently fix bugs.

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-12-03 20:46             ` Pali Rohár
@ 2018-12-04  5:33               ` Ingo Schwarze
  0 siblings, 0 replies; 25+ messages in thread
From: Ingo Schwarze @ 2018-12-04  5:33 UTC (permalink / raw)
  To: Pali Rohar; +Cc: discuss

Hi Pali,

Pali Rohar wrote on Mon, Dec 03, 2018 at 09:46:28PM +0100:

> Hi! I played with colors and seems that browsers do not inherit table
> border color to td border color.

Well, inheritance always works, but it can be overridden, and it
appears that some browsers override border-color on varying levels
of the table element hierarchy without overriding the default for
the levels above.

> And by default my chrome and firefox
> uses gray color for table (if not specified).
> 
> E.g. when you set "table { border-color: yellow; }" and border of
> "table" and "tr" elements are yellow, but "td" elements in black.

That doesn't match what my Firefox 62.0.2 does: it draws "table"
borders yellow but "tr" and "td" borders black.

[...]
> What do you think about this patch? In troff/tbl you does not specify
> color, but I think that HTML output should have consistent colors -- not
> different color for horizontal lines and different for vertical lines.
> Just because browsers have different defaults.

I think that is reasonable.  CSS is the place where styles are
supposed to be defined, so adding a few additional attributes is OK
when there are good reasons, as opposed to adding style= attributes
to the HTML code.

I think "browsers have inconsistent defaults and we want consistent
layout" is a good enough reasons to add a few CSS attributes, even
though "browsers have bugs" does not look like a good reason to
encumber the HTML code with spurious "style=" attributes.

So i committed the following patch.

Yours,
  Ingo


Log Message:
-----------
Make sure all borders in a table are drawn in the same color.
Required because browsers tend to have inconsistent defaults:
For example, Firefox 62.0.2 sets border-color for tbody, but not for table,
and Pali Rohar reports that Chrome set it for td, but not for tr or tbody.
The td part is from Pali Rohar, the tbody and tr parts from me.

Modified Files:
--------------
    mandoc:
        mandoc.css

Revision Data
-------------
Index: mandoc.css
===================================================================
RCS file: /home/cvs/mandoc/mandoc/mandoc.css,v
retrieving revision 1.40
retrieving revision 1.41
diff -Lmandoc.css -Lmandoc.css -u -p -r1.40 -r1.41
--- mandoc.css
+++ mandoc.css
@@ -15,9 +15,14 @@ body {		font-family: Helvetica,Arial,san
 table {		margin-top: 0em;
 		margin-bottom: 0em;
 		border-collapse: collapse; }
+/* Some browsers set border-color in a browser style for tbody,
+ * but not for table, resulting in inconsistent border styling. */
+tbody {		border-color: inherit; }
+tr {		border-color: inherit; }
 td {		vertical-align: middle;
 		padding-left: 0.2em;
-		padding-right: 0.2em; }
+		padding-right: 0.2em;
+		border-color: inherit; }
 ul, ol, dl {	margin-top: 0em;
 		margin-bottom: 0em; }
 li, dt {	margin-top: 1em; }
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-12-03 22:37                   ` Ingo Schwarze
@ 2018-12-04 16:44                     ` Pali Rohár
  2018-12-04 18:04                       ` Ingo Schwarze
  0 siblings, 1 reply; 25+ messages in thread
From: Pali Rohár @ 2018-12-04 16:44 UTC (permalink / raw)
  To: Ingo Schwarze; +Cc: discuss

[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]

On Monday 03 December 2018 23:37:43 Ingo Schwarze wrote:
> Hi Pali,
> 
> Pali Rohar wrote on Mon, Dec 03, 2018 at 11:20:45PM +0100:
> > On Monday 03 December 2018 23:14:54 Ingo Schwarze wrote:
> >> Pali Rohar wrote on Mon, Dec 03, 2018 at 11:01:42PM +0100:
> 
> >>> Seems that it is needed to put "border-bottom-style: solid"
> >>> for rowspanned td element.  At least this is working in chrome.
> 
> >> That would further degrade the quality of the HTML code written by
> >> mandoc.  As a rule, "style=" attributes should be avoided and CSS
> >> should instead by used.  Unfortunately, that's not possible here
> >> because the hard-coded presentational decisions like "draw a border
> >> right here" are already contained in the tbl(7) input, and there
> >> is no way to convert those purely presentational decisions of the
> >> author into semantic or structural markup that could be handled
> >> with CSS.
> >> 
> >> But at least the amount of "style=" attributes written should be
> >> minimized.  Only those "style=" attributes should be written that
> >> are required to correctly express the author's intent.
> 
> > This suggestion is to move border style definition from tr do td.
> 
> That would mean writing more "style=" attributes.
> If a row intersects N cells, N times more.
> That is not good.

You can avoid all style= attributes in tables, by declaring class=
attributes instead of them and then in CSS defines border styles for
defined classes.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-12-04 16:44                     ` Pali Rohár
@ 2018-12-04 18:04                       ` Ingo Schwarze
  2019-01-21  9:39                         ` Pali Rohár
  0 siblings, 1 reply; 25+ messages in thread
From: Ingo Schwarze @ 2018-12-04 18:04 UTC (permalink / raw)
  To: discuss

Hi Pali,

Pali Rohar wrote on Tue, Dec 04, 2018 at 05:44:14PM +0100:
> On Monday 03 December 2018 23:37:43 Ingo Schwarze wrote:
>> Pali Rohar wrote on Mon, Dec 03, 2018 at 11:20:45PM +0100:
>>> On Monday 03 December 2018 23:14:54 Ingo Schwarze wrote:
>>>> Pali Rohar wrote on Mon, Dec 03, 2018 at 11:01:42PM +0100:

>>>>> Seems that it is needed to put "border-bottom-style: solid"
>>>>> for rowspanned td element.  At least this is working in chrome.

>>>> That would further degrade the quality of the HTML code written by
>>>> mandoc.  As a rule, "style=" attributes should be avoided and CSS
>>>> should instead by used.  Unfortunately, that's not possible here
>>>> because the hard-coded presentational decisions like "draw a border
>>>> right here" are already contained in the tbl(7) input, and there
>>>> is no way to convert those purely presentational decisions of the
>>>> author into semantic or structural markup that could be handled
>>>> with CSS.
>>>> 
>>>> But at least the amount of "style=" attributes written should be
>>>> minimized.  Only those "style=" attributes should be written that
>>>> are required to correctly express the author's intent.

>>> This suggestion is to move border style definition from tr do td.

>> That would mean writing more "style=" attributes.
>> If a row intersects N cells, N times more.
>> That is not good.

> You can avoid all style= attributes in tables, by declaring class=
> attributes instead of them and then in CSS defines border styles for
> defined classes.

Sure, i could write

  <td class="border-left-double">
  <td class="border-bottom">
  <td class="border-bottom border-right">

and then in mandoc.css

  .border-left-double { border-left-style: "double"; }
  .border-bottom { border-bottom-style: "solid"; }
  .border-right { border-right-style: "solid"; }

But is that better than

  <td style="border-left-style: double;">
  <td style="border-bottom-style: solid;">
  <td style="border-bottom-style: solid; border-right-style: solid;">

and if it is better, why?

It is almost the same amount of attribute text, with only a minor
difference in syntax, and it doesn't add any information about
meaning or structure.  Also, there is no point for the user to
modify ".border-left-double { }" in the stylesheet - what should
it be mapped to as a personal style?  Mapping it to, say,

  .border-left-double { border-top-style: solid; }

just wouldn't make sense.  Classes only make sense to me if they
tell something about meaning or structure.  If they are merely
other names for physical style attributes, they seem pointless
to me.  Or am i wrong - and if so, why?

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2018-12-04 18:04                       ` Ingo Schwarze
@ 2019-01-21  9:39                         ` Pali Rohár
  2019-01-21 13:16                           ` Ingo Schwarze
  0 siblings, 1 reply; 25+ messages in thread
From: Pali Rohár @ 2019-01-21  9:39 UTC (permalink / raw)
  To: discuss

On Tuesday 04 December 2018 19:04:57 Ingo Schwarze wrote:
> Hi Pali,
> 
> Pali Rohar wrote on Tue, Dec 04, 2018 at 05:44:14PM +0100:
> > On Monday 03 December 2018 23:37:43 Ingo Schwarze wrote:
> >> Pali Rohar wrote on Mon, Dec 03, 2018 at 11:20:45PM +0100:
> >>> On Monday 03 December 2018 23:14:54 Ingo Schwarze wrote:
> >>>> Pali Rohar wrote on Mon, Dec 03, 2018 at 11:01:42PM +0100:
> 
> >>>>> Seems that it is needed to put "border-bottom-style: solid"
> >>>>> for rowspanned td element.  At least this is working in chrome.
> 
> >>>> That would further degrade the quality of the HTML code written by
> >>>> mandoc.  As a rule, "style=" attributes should be avoided and CSS
> >>>> should instead by used.  Unfortunately, that's not possible here
> >>>> because the hard-coded presentational decisions like "draw a border
> >>>> right here" are already contained in the tbl(7) input, and there
> >>>> is no way to convert those purely presentational decisions of the
> >>>> author into semantic or structural markup that could be handled
> >>>> with CSS.
> >>>> 
> >>>> But at least the amount of "style=" attributes written should be
> >>>> minimized.  Only those "style=" attributes should be written that
> >>>> are required to correctly express the author's intent.
> 
> >>> This suggestion is to move border style definition from tr do td.
> 
> >> That would mean writing more "style=" attributes.
> >> If a row intersects N cells, N times more.
> >> That is not good.
> 
> > You can avoid all style= attributes in tables, by declaring class=
> > attributes instead of them and then in CSS defines border styles for
> > defined classes.
> 
> Sure, i could write
> 
>   <td class="border-left-double">
>   <td class="border-bottom">
>   <td class="border-bottom border-right">
> 
> and then in mandoc.css
> 
>   .border-left-double { border-left-style: "double"; }
>   .border-bottom { border-bottom-style: "solid"; }
>   .border-right { border-right-style: "solid"; }
> 
> But is that better than
> 
>   <td style="border-left-style: double;">
>   <td style="border-bottom-style: solid;">
>   <td style="border-bottom-style: solid; border-right-style: solid;">
> 
> and if it is better, why?
> 
> It is almost the same amount of attribute text, with only a minor
> difference in syntax, and it doesn't add any information about
> meaning or structure.  Also, there is no point for the user to
> modify ".border-left-double { }" in the stylesheet - what should
> it be mapped to as a personal style?  Mapping it to, say,
> 
>   .border-left-double { border-top-style: solid; }
> 
> just wouldn't make sense.  Classes only make sense to me if they
> tell something about meaning or structure.  If they are merely
> other names for physical style attributes, they seem pointless
> to me.  Or am i wrong - and if so, why?

I was thinking about it... I can say there are two arguments why to use
classes instead of inline style=.

1) Separate style logic (semantics) outside of html text (syntax).

2) Ability to correctly set style via custom css file. If somebody wants
   to use custom css file, then inlined style= attributes can cause
   problems.

With <td style="..."> you are saying use this specific style. But with
<td class="..."> you are saying that it belongs to specific class and
make abstraction how styles are used. For me it looks like a "proper"
way how to implement different things, by usage of layering abstraction.

> Yours,
>   Ingo

-- 
Pali Rohár
pali.rohar@gmail.com
--
 To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: Broken tables in HTML output
  2019-01-21  9:39                         ` Pali Rohár
@ 2019-01-21 13:16                           ` Ingo Schwarze
  0 siblings, 0 replies; 25+ messages in thread
From: Ingo Schwarze @ 2019-01-21 13:16 UTC (permalink / raw)
  To: Pali Rohar; +Cc: discuss

Hi Pali,

i'm leaving the complete quotations intact because the context is
important here - even though it is long.

Pali Rohar wrote on Mon, Jan 21, 2019 at 10:39:09AM +0100:
> On Tuesday 04 December 2018 19:04:57 Ingo Schwarze wrote:
>> Pali Rohar wrote on Tue, Dec 04, 2018 at 05:44:14PM +0100:
>>> On Monday 03 December 2018 23:37:43 Ingo Schwarze wrote:
>>>> Pali Rohar wrote on Mon, Dec 03, 2018 at 11:20:45PM +0100:
>>>>> On Monday 03 December 2018 23:14:54 Ingo Schwarze wrote:
>>>>>> Pali Rohar wrote on Mon, Dec 03, 2018 at 11:01:42PM +0100:

>>>>>>> Seems that it is needed to put "border-bottom-style: solid"
>>>>>>> for rowspanned td element.  At least this is working in chrome.

>>>>>> That would further degrade the quality of the HTML code written by
>>>>>> mandoc.  As a rule, "style=" attributes should be avoided and CSS
>>>>>> should instead by used.  Unfortunately, that's not possible here
>>>>>> because the hard-coded presentational decisions like "draw a border
>>>>>> right here" are already contained in the tbl(7) input, and there
>>>>>> is no way to convert those purely presentational decisions of the
>>>>>> author into semantic or structural markup that could be handled
>>>>>> with CSS.
>>>>>> 
>>>>>> But at least the amount of "style=" attributes written should be
>>>>>> minimized.  Only those "style=" attributes should be written that
>>>>>> are required to correctly express the author's intent.

>>>>> This suggestion is to move border style definition from tr do td.

>>>> That would mean writing more "style=" attributes.
>>>> If a row intersects N cells, N times more.
>>>> That is not good.

>>> You can avoid all style= attributes in tables, by declaring class=
>>> attributes instead of them and then in CSS defines border styles for
>>> defined classes.

>> Sure, i could write
>> 
>>   <td class="border-left-double">
>>   <td class="border-bottom">
>>   <td class="border-bottom border-right">
>> 
>> and then in mandoc.css
>> 
>>   .border-left-double { border-left-style: "double"; }
>>   .border-bottom { border-bottom-style: "solid"; }
>>   .border-right { border-right-style: "solid"; }
>> 
>> But is that better than
>> 
>>   <td style="border-left-style: double;">
>>   <td style="border-bottom-style: solid;">
>>   <td style="border-bottom-style: solid; border-right-style: solid;">
>> 
>> and if it is better, why?
>> 
>> It is almost the same amount of attribute text, with only a minor
>> difference in syntax, and it doesn't add any information about
>> meaning or structure.  Also, there is no point for the user to
>> modify ".border-left-double { }" in the stylesheet - what should
>> it be mapped to as a personal style?  Mapping it to, say,
>> 
>>   .border-left-double { border-top-style: solid; }
>> 
>> just wouldn't make sense.  Classes only make sense to me if they
>> tell something about meaning or structure.  If they are merely
>> other names for physical style attributes, they seem pointless
>> to me.  Or am i wrong - and if so, why?

> I was thinking about it... I can say there are two arguments why
> to use classes instead of inline style=.
> 
> 1) Separate style logic (semantics) outside of html text (syntax).

In general and in theory, yes.

But that argument does not apply to the specific class attribute
we are discussing: class="border-left-double" would still be
specifying styling and not semantics.  It would abuse the class=
attribute for physical styling.  Using class= (which is *supposed*
to be semantic, but wouldn't be semantic in this case) does not
make "border-left-double" a statement about logic; "border-left-double"
remains a styling instruction no matter what.

It can't be helped because the document author specified the physical
styling, without stating for which logical reasons it was chosen.

> 2) Ability to correctly set style via custom css file.
>    If somebody wants to use custom css file, then inlined style=
>    attributes can cause problems.

In general and in theory, yes.

But that argument does not apply to the case at hand.  Suppose i would
put a class="border-left-double" attribute in there, and the user
wanted to do CSS customization.  Then all they can do is, say,
replace all left double borders with top dotted borders, or something
like that.  Customization just doesn't make sense to me in this case.

> With <td style="..."> you are saying use this specific style. But with
> <td class="..."> you are saying that it belongs to specific class and
> make abstraction how styles are used. For me it looks like a "proper"
> way how to implement different things, by usage of layering abstraction.

In general and in theory, yes.

But in the specific case, i see no practical advantage whatsoever,
and abusing class= for physical styling seems even worse to me than
at least being honest and admitting that we have to do hard-coded
styling because that's what the document author requested, and because
we don't have the slightest idea what the intended *menaing* of these
borders might be.

Or what am i missing?

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2019-01-21 13:16 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-16 11:03 Broken tables in HTML output Pali Rohár
2018-07-16 15:29 ` Ingo Schwarze
2018-07-16 16:36   ` Pali Rohár
2018-07-16 17:44     ` Ingo Schwarze
2018-11-24 23:15   ` Ingo Schwarze
2018-11-25 19:34   ` Ingo Schwarze
2018-11-25 21:25     ` Ingo Schwarze
2018-11-26  8:53       ` Pali Rohár
2018-11-26 21:27   ` Ingo Schwarze
2018-11-26 21:58     ` Pali Rohár
2018-11-26 22:01       ` Pali Rohár
2018-11-26 22:05         ` Pali Rohár
2018-12-01 17:20           ` Ingo Schwarze
2018-12-01 19:35             ` Pali Rohár
2018-12-03 20:46             ` Pali Rohár
2018-12-04  5:33               ` Ingo Schwarze
2018-12-03 22:01             ` Pali Rohár
2018-12-03 22:14               ` Ingo Schwarze
2018-12-03 22:20                 ` Pali Rohár
2018-12-03 22:37                   ` Ingo Schwarze
2018-12-04 16:44                     ` Pali Rohár
2018-12-04 18:04                       ` Ingo Schwarze
2019-01-21  9:39                         ` Pali Rohár
2019-01-21 13:16                           ` Ingo Schwarze
2018-11-29  2:15     ` Ingo Schwarze

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).