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