1-Visitor

Question

S1000D PDF Table Output Column Widths

Forum|Forum|12 years ago
January 29, 2014
30 replies
8902 views

Ok, I'm using v5.3 of the editor with CSDB and I've created some S1000D
PDF output using the "Publisher" and I've noticed that the tables as
output completely ignore the column settings. Instead of getting columns
of variable width I get columns of equal width. In the output the
columns are equally divided between 38 pi, which is total chaos. I have
content running across cell borders etc.

I have clearly set the columns as follows:

<table colsep="1" frame="all" rowsep="1">

<title>Something</title>

<tgroup cols="7" tgstyle="1"><colspec<br/>
colwidth="2.00pi"/><colspec colwidth="7.50pi"/">

<colspec colwidth="3.00pi"/"><colspec<br/>
colwidth="2.00pi"/><colspec colwidth="10.00pi"/">

<colspec colwidth="7.00pi"/"><colspec<br/>
colwidth="3.00pi"/>

I suspect this is a problem with the Publisher; it doesn't create Issue
4 compliant covers either. Does anyone know if there is an attribute
which can be set in the XML to force the output to use the column widths
as entered?

Show previous replies

J

jsillari

1-Visitor

Greg:

Thanks for the shout out...you have multiple trouble ticket items for PTC. Check out the release notes and SPR fixes for AAD 4.4 (don't forget to include the maintenance releases as well) to see if any of your issues have been addressed in later releases. Just for fun, I created a table in an Issue 4.0 DM (we're using AAD 4.4 M050) and tried all permitted units for column width. All of them saved as I had entered them **except** pc; it always reverted to pica. Go figure.

John Sillari
Chief Technologist
Dayton T. Brown, Inc.
Technical Services Division

C

ClayHelberg

18-Opal

Hi Greg--

You should still be able to address this by modifying the XSL stylesheets used for PDF output, I think. Unless publishing has changed in the latest release, it uses XSL-FO, which means the XML gets exported and transformed to FO markup using XSL stylesheets. You should be able to modify those so they convert the "pi" units inserted by the CSDB back to the "pc" units the FO formatter is expecting.

--Clay

G

GregoryMackenzi

Author

1-Visitor

Hi John,

I'll check out the release notes! To be fair I think there is potential
that many of my issues have likely been resolved, we're currently at 4.3
M060 (7), but it would be comforting to know which bugs are already
resolved. It would then make a convincing argument for staying current
if they address the issues I've been experiencing.

Greg
🙂

G

GregoryMackenzi

Author

1-Visitor

Hi Clay,

In the interim, pending an upgrade, that sounds like a practical course
of action. In any event I will need to look at the Arbortext
documentation; are you aware if those stylesheets are stored locally in
the PTC folder?

Greg

C

ClayHelberg

18-Opal

Hi Greg--

I think they are probably on the server. (I can't say for sure, because my configuration uses the same computer for both server and workstation.) In my older installation, I found them in C:\Program Files\PTC\Arbortext AAD\Publisher for S1000D (Print Services).

It looks like the key piece would be in foTable.xsl. In that file, there is a template named "T_Convert_toMilliMetres". It knows how to find "pc" units but not "pi" units. You could modify the xsl:when branch for Picas like this to make it handle the "pi" units:

<xsl:when test="contains($pValue," 'pc')=" or=" contains($pvalue,=" 'pc')=" or=" contains($pvalue,=" 'pi')=" or=" contains($pvalue,=" 'pi')"=">
<xsl:value-of select="round(number(translate($pValue,'pcPCiI','')" *=" 4.23333333))"="/>
</xsl:when>

Note the additional "or" conditions in the when test, and also the addition of upper- and lower-case "I" in the translate call inside the value-of.

--Clay

G

GregoryMackenzi

Author

1-Visitor

Hi Clay,

Thank you very much for the directions! 🙂 Just looking at the file now, and I noticed one test for colwidth, and it does not contain "pi".

<xsl:when test="contains(@colwidth,'*')" or=" not(contains(@colwidth,'cm')=" or=" contains(@colwidth,'cm')=" or=" contains(@colwidth,'mm')=" or=" contains(@colwidth,'mm')=" or=" contains(@colwidth,'pt')=" or=" contains(@colwidth,'pt')=" or=" contains(@colwidth,'pc')=" or=" contains(@colwidth,'pc')=" or=" contains(@colwidth,'in')=" or=" contains(@colwidth,'in'))=" or=" not(@colwidth)"=">

Interesting...

Gregory B. MacKenzie, B.F.A.
Programmer II
L-3 Electronic System Services (L-3 ESS)
249 Aerotech Park Drive
Box 960 Enfield Postal Station
Enfield Nova Scotia, Canada, B2T 1K9

C

ClayHelberg

18-Opal

Hi Greg--

Good catch. Probably not a bad idea to grep through the XSL files to check for any other instances that check for colwidth. I would expect them all to be in foTable.xsl, but you never know.

--Clay

G

GregoryMackenzi

Author

1-Visitor

Hi Clay,

Thank you very much for your help, I went through foTable.xsl and I made changes in three places under the following general entries:

<xsl:template name="T_setTableWidth">
<xsl:when test="@colwidth" and=" not(@colwidth=" )"=">
<xsl:template name="T_ConvertToMilliMetres">

Basically in each case the statement to include picas was not defined:

or contains(@colwidth,'pi') or contains(@colwidth,'PI')

So the result is now the tables do print with the variable columns. I do have to revisit all my tables and make sure they add up to 38 picas wide.

In all fairness to PTC this variable column print issue may have been addressed in a later update but I won't know until we upgrade, which I have now learned is on the near horizon.

I didn't find any other references in the other files.

While I was at it I set the hyphenation in the other xsl files to false, the hyphenation was most annoying and awkward in the output. Interesting, there doesn't seem to be a manual </brk> in the S1000D issue 4 markup... There are a few spots where I might want to force a break onto the next line.

Thanks again!

Greg
🙂

C

ClayHelberg

18-Opal

Hi Greg--

Glad to hear you got it sorted out.

Regarding line breaks, you could possibly leverage Arbortext's touchup processing instructions for this. I'm not sure if the S1000D application customizes this or not (don't have time to fire up the VM and check right now), but normally Editor will let you insert a processing instruction where you want a line break, , from the Format->Touchup menu.

If you want to use this, you would probably need to add a template to the XSL to recognize it, something like this:

<xsl:template match="processing-instruction('Pub')[.='_newline']">
<fo:block/>
</xsl:template>

--Clay

G

GregoryMackenzi

Author

1-Visitor

Hi Clay,

Thanks very much for the tip on how to use the processing instruction to
insert a break. I'll have to give that a try.

Greg
🙂

Sign up

Please use your PTC eSupport account.

Welcome to the PTC Community

Please use your PTC eSupport account.

Scanning file for viruses.

This file cannot be downloaded