Support ctable-like tables

[PanderMusubi]

Please support tables with the (as much as possible) syntax of cable, see also http://www.ctan.org/tex-archive/macros/latex/contrib/ctable

[jamadagni]

Hello! SILE doesn't have any existing packages that creates tables?!

[ctrlcctrlv]

Hi. It does but it is nowhere near as powerful as ctables. I was planning to write a ctables extension for SILE, but it's been bumped down on my priority list. If this is something you'd be willing to pay for you can email me. Until then you can check out some of the examples I've made, like my repository PamudpodUnicodePaper, which contains code for enabling the simpler table that comes with SILE.

[jamadagni]

Hello and thanks for your reply. Saw your document. Very interesting especially to one who has worked on Indic Unicode, but really there don't seem to be any tables with column in your final document.

[ctrlcctrlv]

@jamadagni There is, there's a table on the first page with my name and email.

[jamadagni]

Hello yes. I did see your `.sil` file and it had the `\table` element but scarcely what would normally be perceived as a table, with multiple columns and rows.

…

On Tue, 8 Sep, 2020, 13:19 Fredrick Brennan, ***@***.***> wrote: @jamadagni <https://github.com/jamadagni> There is, there's a table on the first page with my name and email. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#45 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHHPSRDZBIKON6E7337ZITSEXOXHANCNFSM4A3PJH3Q> .

[ctrlcctrlv]

...There are multiple columns and rows.

Perhaps you will prefer the example used to build the documentation, although at a base level it is identical, since it looks more ordinary. 😄

Please see:

sile/documentation/developers.sil

Lines 31 to 48 in 4a92f58

	\noindent\begin{table}%
	\tr{\td{\code{core/sile.lua}}\td{\relax\qquad SILE startup and file handling}}
	\tr{\td{\code{core/baseclass.lua}}\td{\relax\qquad Base of document classes}}
	\tr{\td{\code{core/frame.lua}}\td{\relax\qquad Base class for frame objects}}
	\tr{\td{\code{core/frameparser.lua}}\td{\relax\qquad Parser for frame definitions}}
	\tr{\td{\code{core/languages.lua}}\td{\relax\qquad Code which loads language support}}
	\tr{\td{\code{core/length.lua}}\td{\relax\qquad Base class for SILE length objects}}
	\tr{\medskip} \tr{\td{\em{Main typesetting algorithms}}} \tr{\medskip}
	\tr{\td{\code{core/nodefactory.lua}}\td{\relax\qquad Prototypes for boxes and glue}}
	\tr{\td{\code{core/typesetter.lua}}\td{\relax\qquad Main typesetting algorithms}}
	\tr{\td{\code{core/break.lua}}\td{\relax\qquad Knuth-Plass line breaking algorithm}}
	\tr{\td{\code{core/hyphenator-liang.lua}}\td{\relax\qquad Liang’s hyphenation algorithm}}
	\tr{\td{\code{core/pagebuilder.lua}}\td{\relax\qquad Page building algorithm}}
	\tr{\medskip} \tr{\td{\em{Font and glyph shaping}}} \tr{\medskip}
	\tr{\td{\code{core/font.lua}}\td{\relax\qquad The \command{\\font} command and font settings}}
	\tr{\td{\code{core/base-shaper.lua}}\td{\relax\qquad Base class for glyph shaping}}
	\tr{\td{\code{core/harfbuzz-shaper.lua}}\td{\relax\qquad Glyph shaping using Harfbuzz}}
	\tr{\td{\code{core/pango-shaper.lua}}\td{\relax\qquad Glyph shaping using Pango}}

[alerque]

SILE's simpletable is a starting point, but yes a more advanced table module is definitely something we'd like to have at some point.

For now depending on your use case parallel frames (where each frame is essentially a column and the sync functions align content in rows) might be more useful than the current table implementation.

[simoncozens]

I remember when I tried looking at this many years ago, I was planning to use the CSS table model which contains some algorithms that might be useful for implementors.

[Omikhleia]

[simoncozens]

Whoa.

[OlivierNicole]

You're on fire these days!

[Omikhleia]

Well, I admit this is not really related to "ctable" (and "as much as possible" of its syntax), as per the original ticket...

But I couldn't find another ticket on complex tables. The true question should be "how complex" and what is the minimal subset of features that should be provided to cover 90% of the normal (non-nerdy) needs.

I read the "ctable" documentation, and honestly, to me, its syntax his awful and near to non-human. Some 30+ options, obscure column specifiers (so weird to me that I would never remember them), mixing of concerns (e.g. dedicated footnotes, specific captioning, weird content alignment logic etc.). I would hate having to use it, honestly... I understand the requester concern, though, it's also a powerful solution - and it may be interesting probably with LaTeX compatibility in mind - but heh.. Do we want or need to be LaTeX followers? The Web/CSS model is more akin to my line of thinking, though the way it addresses column/row merging (= spanning) could be debated.

My example above includes a few "cheats" - I actually just wanted to see if my current "parbox" implementation could be put to benefit beyond the most basic use case I had for it. A parbox being a "paragraph box" - that is, more or less, an hbox containing paragraphs. I pushed the initial code for it in my repo, with documentation. The above table is not there yet, I'll want to fine-tune it first 😉 but the naive logic is on that line of reasoning:

• a table is a parbox with borders an all sides and containing only row elements
• a row is
  • a parbox with horizontal borders and containing only basic cell or (sub)table elements
  • followed by a fined-tuned linebreak
• a cell is a parbox with internal padding, vertical borders, aligned vertically with respect to the other cells in the same row (defaults to middle)

(N.B. And I overused the parbox here, only cells would need it, and the other some simpler framed hbox)

So the above table actually is 4x3, with only 4 rows, hehe. Instead of row merging (on row no. 3), it uses cell spitting, in the form of a 3x2 sub-table. I don't pretend it has to be done this way - the whole question still is "how complex" and "which minimal features" !

[simoncozens]

I don't think we want to follow LaTeX ctable directly, and certainly not the horrendous syntax. But I think we probably want to make sure we can do as much of the functionality as possible.

That said, something is very definitely better than nothing...

[ctrlcctrlv]

Impressive output :)

Definitely agree with «something is very definitely better than nothing»!

[Omikhleia]

Definitely agree with «something is very definitely better than nothing»!

Ok, ok 😄 ... I cleaned up and pushed a decently working version of my "ptable" package to my own package repo - It can probably live there for a while, I'm still testing and considering improvements, but it's there if anyone wants to check and try it. It's fully documented (§1.1.8 in the generated documentation) and I hope the code to be commented enough where I erred initially.

And would it seem fit by @simoncozens and @alerque at any convenient step, AFAIC, it could go to the core distribution along with the lower-level "parbox" package on which it relies.

Just for the fun of it - this one example gave me a headache due to a bad bug - one day, the following could happen, count me in:

(And on a more personal angle, this "ptable" package is my 15th package. Yeah! Ok some of them are dumb simple, but heh, anyhow I sort of feel closer to being able to start typesetting a book with all the building blocks I need... And it's real fun hacking SILE, lol)

[Omikhleia]

Added background color for rows and cells, and a "hook" for cell styling.

[Omikhleia]

Added more flexibility with the cell border options, so that this kind of table (from the ctable documentation) is doable - I am told this presentation is frequent is scientific layouts.

AFAIC, the only "missing" features so far could be:

• An easier way to set the borders at the row level. This would just be a convenience to achieve the same result as above, so I won't add it to avoid feature creep, unless it's really demanded.
• Repeating a header row on page breaks. Is the extra complexity worth it? (I seldom have long tables of that type in my own writings)

[ctrlcctrlv]

AFAIC, the only "missing" features so far could be:
[…]
Repeating a header row on page breaks. Is the extra complexity worth it? (I seldom have long tables of that type in my own writings)

I'd say it's worth it, as I plan to use this for Unicode tables (so will often have long tables).

[Omikhleia]

Added more flexibility with the cell padding options, so that this other table (from the LaTeX booktabs package) could be reproduced:

Again, settings at cell levels are sufficient, but a bit pedestrian, one could want an easier way to set them at row levels to simplify their typesetting. Still, it would be a convenience rather than an actual feature, so I don't add it for now, as for the borders.

The repeated header is less obvious, due to the way the pagebuilder works (so you might not be any longer in the table enviromnement when boxes are moved until a good break point is found... I'll try to think to it... or maybe you can have a look at it @ctrlcctrlv ?

[simoncozens]

Do you need a hook from the typesetter from when a new page is started but before all the boxes are put back into it?

[Omikhleia]

@simoncozens I've a semi-working version just overriding the initNextFrame() method and doing some look up. It sort of works, though I have to take into account potential glues that could be there too and skip them. I wonder whether this is very robust ;)

[Omikhleia]

Ok, pushed a version with header rows repeated on page breaks. As stated, this could be fragile... The basic test case worked (in the "examples" folder), though. As far as features are concerned, this should be enough?

As an aside note, this beast is not very efficient, performance-wise, on long tables...

[Omikhleia]

As an aside note, this beast is not very efficient, performance-wise, on long tables...

Er. No longer true. Bug fixed ^^

[Omikhleia]

For reference, I've updated the Wiki equivalent packages:

• Adding LaTeX booktabs (I found it's documentation and examples more interesting than those from tabu, so it's good to mention for inspiration)
• Mentioning my 3rd-party package ptable.sile as a possible way for addressing
  tables, with SILE 0.14.0 or upper.

The question now, is what to do with this very issue. Reading the latest manual:

• Perhaps should we mention in the manual https://luarocks.org/m/sile since you created that manifest
• Or perhaps show it too on the main SILE website

This is kind of our CTAN for SILE...

And then we could close that issue (perhaps other too).

(Erm, OT but maybe it's a remembrance from having read A. E. van Vogt in my youth, but SLAN just came to my mind when I wrote this. I don't even remember if that Slan novel was worth reading, just the name stuck, lol).

[Omikhleia]

I'm closing this issue:

• Tables are complex, and there are various ways to address them. Let's compare with the TeX ecosystem, FWIW. In these days, I'd bet few people use plain-TeX tables. Many are probably using the LaTeX version of them... But there's a reason too for many competing solutions to exist (ctable, booktabs, tabu... and plenty of others) - It's hard to cover everything and satisfy everybody. That is to say, whatever "core" solution SILE might eventually want, it wouldn't be a definitive answer ;)
• Anyhow, as of a SILE solution, we have my 3rd-party "ptable" as explained above. It doesn't have to be the definitive answer either (and since I once mentioned it... I failed at achieving a "ptable2" re-implementation with extra goodies - perhaps because the initial "ptable" suffice for most of my own needs, or it's just real hard for me to reinvent it on new grounds, having already walked upon a given path!)
• Since 0.13, SILE has a package ecosystem using luarocks. So anyone is now able to propose new packages as part of the ecosystem, and that is really cool. Anyone is free to come with a competing solution, perhaps based on a wholly different approach ;) -- So closing this issue doesn't imply it's necessary fully solved, but I really don't think there's any good reason for keeping it open.