Find a good workflow for tables

[bertfrees]

Currently the default CSS handles all tables the same. Whenever you want to give a table a different formatting, you need to apply some custom CSS to it, for example by giving it a certain class. Because the default CSS is applied to all tables, it needs to be reset first, otherwise it may give undesired results in combination with your custom CSS. I've added a convenience "extend-only" rule to do this (see default.scss#L808):

%table-reset {
   display: initial;
   ...
}

It is used like this:

table.some-class {
   @extend %table-reset;
   display: table;
}

This method could work, however it does complicate things a little. A somewhat simpler alternative could be to apply the default CSS only on tables without a class attribute:

table:not([class]) {
   ...
}

This means that whenever you add a class to a table, the default style is cancelled automatically, so the @extend %table-reset; line isn't needed anymore. Of course the downside is that when the table has a class for a different reason (e.g. because you got it that way from the publisher), it won't have a default style either.

So now we have a way to style individual tables, but it might not give us the most efficient workflow. We could for example consider doing something similar as we are doing now with dtbook2sbsform, namely create 3 different versions of a table, so that you can determine the best layout immediately without having to try them all manually. It could work like this: every table without a class is copied a number of times and every table gets a different class (the copies as well as the original). Every class corresponds to a different style in the default CSS.

After the first pass, all versions of the tables end up in the resulting PEF. Then you go through the input document and add to each table the class that corresponds to the preferred layout. All tables need a class otherwise they will be duplicated again in the second pass. (Or possibly we can add an option to disable the duplication, and instead give tables without a class attribute a default style.) This workflow could of course be combined with custom table classes as well.

@mixa72 and @egli: what do you guys think?

[bertfrees]

Oh, I should also mention that OBFL/Dotify supports defining custom fallback mechanisms for tables. If there are certain situations where table layouts could be selected without human interaction, we can exploit that.

[egli]

@bertfrees , I had a discussion with @mixa72 yesterday. The following are my notes:

• Rarely used Tables are used quite rarely
• 3 predefined styles It would make sense to predefine three classes for tables namely
  • linearized
  • matrix
  • matrix transposed
• Default style If a table has no class attribute it defaults to linearized
• only one rendering We would rather not explode every table into all three possible representations but instead just render the table according to its class (or the default style). The inspection afterwards will uncover problematic tables and then these are dealt with by changing their class.
• Custom classes As a fallback it should be possible to define custom classes. These do not have to be derived from an existing class.

[bertfrees]

Thanks. Makes sense.

[bertfrees]

See also #56.

[bertfrees]

Hi @mixa72. Have you looked at this?

[mixa72]

When I try to produce a table with class="table-matrix-transposed", the pipeline hangs. What are the class names to be used: table-linearized, table-matrix and table-matrix-transposed?

[bertfrees]

Yes, those are the classes.

Could you send me the input file that is causing the Pipeline to hang?

[bertfrees]

@mixa72 Thanks for the input files. It appears the table has too many rows to fit on the page. The same would happen if you had a table without the class "table-matrix-transposed" but with too many columns.

[mixa72]

All of our table classes seem to render correctly:

 MULTIPLIKATIONSTABELLE

 MAL :: #A :: #B :: #C :: #D
   :: #E
 ::::::::::::::::::::::::::::
 #A :: #A :: #B :: #C :: #D
   :: #E
 #B :: #B :: #D :: #F :: #H
   :: #AJ
 #C :: #C :: #F :: #I :: #AB
   :: #AE

 MULTIPLIKATIONSTABELLE



 MAL  #A   #B   #C   #D   #E
 :::  :::  :::  :::  :::  :::
 #A   #A   #B   #C   #D   #E
 #B   #B   #D   #F   #H   #AJ
 #C   #C   #F   #I   #AB  #AE



 MULTIPLIKATIONSTABELLE



 MAL   #A    #B    #C
 ::::  ::::  ::::  ::::
 #A    #A    #B    #C
 #B    #B    #D    #F
 #C    #C    #F    #I
 #D    #D    #H    #AB
 #E    #E    #AJ   #AE



 TABELLE MIT LEADER



 MAL    #A EINS  #B ZWEI
 :::::  :::::::  :::::::
 #A ..  #A ....  #B
 #B ..  #B ....  #D
 #C ..  #C ....  #F


                           #A  

The first table has the class "table-linearized", the second "table-matrix", the third "table-matrix-transposed" and the last one has an individual style with leaders.
The only issues I found are the following:

1. inconsistent behavior of "table{ margin-bottom:3; }" in the css: in table 2, 3 and 4 the margin is inserted after the caption but before the table body (that's an error).
2. the underlinings in table 3 are too long by one character (I'm not sure if this "bug" has already been reported; perhaps it's not a bug)
   test_4.4.58_all_types.zip

[bertfrees]

The margin thing was a bug. I've fixed it.

The underlining thing is not a bug. It's just how tables are formatted. If the minimal total width of the table is lower than the available page width, the columns are made slightly wider. The underlinings are as wide as the columns.

How much space the columns take can be controlled with the -obfl-preferred-empty-space property. Setting it to 0 results in the behavior you want. Setting it to a high value results in the table filling up the whole page width. The default is 2 (which is something in between).

[mixa72]

OK. That also explains why table 2 has shorter underlinings than table 3: it takes nearly the whole page width. I suggest that we set -obfl-preferred-empty-space to 0 for the benefit of a uniform table layout.

[bertfrees]

Done.