Ok, I'm using 5.3 and I've created some S1000D PDF output and I've noticed that the tables ignore the column settings. Instead of getting columns of variable width I get columns of equal width.
I have clearly set the columns as follows
<table colsep="1" frame="all" rowsep="1">
<tgroup cols="7" tgstyle="1"><colspec
However in the output the columns are equally divided between 38 pi, which is chaos. I have content running across cell borders etc.
How can I force the output to use the column widths I've entered?
Further to this, if you change the colspec measurement to "pc" or "mm" it reverts back to "pi" with the first CSDB save, except for some random columns. If you use the toolbar to create a PDF the columns which use "pc" are rendered with the proper column width, the others with "pi" are evenly distributed.
Here are some screenshots of the error.
Source Code, showing the variable width colwidth attributes:
The table in the editor clearly shows variable column widths:
S1000D PDF Output: divides all columns equally between 38 picas
You should file a support case for this, providing the document and stylesheet as attachments. Someone can help you sort it out or file an SPR for it. Be sure to include your screen snapshots. They show things nicely.
Here is the link to file a case:
I did but have yet to receive a reply. In the meantime I have found some help at Adepters.
I am using CSDB 4.3 M060 and Editor 5.3 with CSDB plug-in.
if you look at foTable.xsl it does not contain the necessary markup for picas. If you look at the template "<xsl:template name="T_setTableWidth">" for example it is missing a statement for:
or contains(@colwidth,'pi') or contains(@colwidth,'PI')
also, "<xsl:when test="@colwidth and not(@colwidth='')">" and "<xsl:template name="T_ConvertToMilliMetres">" are missing the necessary statements for picas.
The CSDB enforces the use of picas converting all colwidth measurements to picas, but the stylesheet doesn't use them, that is the problem and why the variable columns do not render.
In all fairness this may have been addressed in a later update but I won't know until we upgrade.