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