[oXygen-user] Table rules for empty cells

[Sorin Ristache]

Hello,

I tried the default scenarios Docbook HTML and Docbook PDF on a table 
with the rules="all" attribute and the rule lines were created correctly 
between all the rows and columns. The table looks the same in the HTML 
and PDF outputs. For the border lines of the table, that is the lines 
that surround the first and/or last rows and/or columns you need to add 
the frame attribute on the table element. For example if you want to 
surround the table on all four sides you have to add frame="border". If 
this does not work for you please send a small Docbook sample document 
for reproducing the problem. What Oxygen version do you use?

If you want equal heights on the table rows of a sparse table you have 
to place non-empty content in at least one cell of each row. An XML 
comment or white spaces do not qualify as non-empty content. Also the 
column width can be adjusted with col elements added in the table, for 
example:

<table rules="all" frame="border">
<caption>HTML table</caption>
<col width="25%"/>
<col width="50%"/>
<col width="25%"/>
<tbody>
. . .


Otherwise in case of a sparse table the default width and height of a 
cell located on an empty row an empty column are very small in the 
output result of the transformation making that empty row and empty 
column almost invisible.


Regards,
Sorin


Kiparsky, Jon wrote:
>
> Is there a simple way to force a table to actually generate rules 
> around all cells when generating html from docbook? <table 
> rules="all"> is not doing it. Right now, I’m having to insert 
> non-breaking spaces to force empty cells to get rules, which means I 
> have a lot of lines like this:
>
> <td> <!-- nonbreaking space --></td>
>
> in a sparse table. This is okay – easily generated with global replace 
> – but a but of a nuisance. PDFs generated from the same source are 
> ruled correctly, but the HTML is not, unless the &nbsp is inserted.
>
> Or, for a workaround, is it possible to add a non-breaking space to 
> the “insert from character map” options in a future version?
>
> (speaking of the character map, it would be really nice if the 
> non-printing characters were labelled – I can usually remember that 
> U+000D is a CR, but the others I have to look up)
>
> Cheers,
>
> -Jon Kiparsky
>