S1000D PDF Table Output Column Widths

[GregoryMackenzi]

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?

[tbihlmeyer]

Not  sure if it will really make a difference, but try adding a colname attribute to your colspec tag.

<colspec colname="col1" colwidth="2.00pi"/">


Trudy



On Wednesday, January 29, 2014 9:34 AM, Greg MacKenzie <-> wrote:

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?

----------

[GregoryMackenzi]

Hi Trudy,

Good catch! No joy though, I gave colnum a try as well, neither seem to make a difference. When I create a PDF via the toolbar, I still get evenly divided columns.

Thanks anyway!

Greg
🙂

[ClayHelberg]

Hi Greg--

You may need to change the way your sizes are specified. XSL-FO doesn't support "pi" as a recognized unit abbreviation. If you are looking for Picas, use "pc" instead. Or you can convert to any of the other supported units (described here:

[GregoryMackenzi]

Hi Clay,

Thanks for the link. 🙂 I must admit I got into the habit of using picas a long time ago and still do in our SGML, that's why I never gave it a second thought.

I changed the attribute from pi to pc, but as soon as I use "CSDB Save" they revert to pi, except for the first two columns... very strange...

When I create a PDF though from the toolbar the format of the first two columns is correct, so this must be the right track.

I'll be back...

Greg
🙂

[GregoryMackenzi]

This is almost working. I edited the xml as source and this is what I changed them to:

<tgroup cols="7" tgstyle="1">
<colspec colname="1" colnum="1" colwidth="2.00pc"/">
<colspec colname="2" colnum="2" colwidth="7.50pc"/">
<colspec colname="3" colnum="3" colwidth="3.00pc"/">
<colspec colname="4" colnum="4" colwidth="2.00pc"/">
<colspec colname="5" colnum="5" colwidth="10.00pc"/">
<colspec colname="6" colnum="6" colwidth="7.00pc"/">
<colspec colname="7" colnum="7" colwidth="3.00pc"/">

However, some revert to their original values with CSDB Save. This is what they look like now after CSDB save:

<tgroup cols="7" tgstyle="1">
<colspec colname="1" colnum="1" colwidth="2.00pc"/">
<colspec colname="2" colnum="2" colwidth="7.50pi"/">
<colspec colname="3" colnum="3" colwidth="3.00pc"/">
<colspec colname="4" colnum="4" colwidth="2.00pi"/">
<colspec colname="5" colnum="5" colwidth="10.00pi"/">
<colspec colname="6" colnum="6" colwidth="7.00pi"/">
<colspec colname="7" colnum="7" colwidth="3.00pi"/">

Columns 1 and 3 are ok, but the rest reverted to pi for some reason. I think I'm going to delete the attributes, save to CSDB, and redefine them.

[GregoryMackenzi]

Interestingly, if you delete all the colspec markup and "CSDB Save" the colspec is redefined in pi by default. The following is the default output, not unreasonable except for "pi":

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

I changed the values the way I wanted them and substituted "pc" for "pi", and created a pdf, the columns that take do output as desired but some of others don't, the markup colwidth values revert to pi without CSDB Save!

[ClayHelberg]

That sounds like a bug to me. You might want to let PTC know about it, they may be able to recommend a fix in the XSL stylesheet or somewhere else.

--Clay

[GregoryMackenzi]

Hi Clay,

It's an idea at that. 😉 Mind you I am stuck in the world of 5.3 at the moment... Usually responses invoke comments such as "your CSDB version is unsupported" and "you should upgrade..." However such things are not up to me and lie in the hands of powers beyond my ken...

I'll try another measurement, metric, and see if that stays put.

Greg
🙂

[ClayHelberg]

In that case, if you know some XSLT, you can probably modify the XSL stylesheets that are used for publishing. You would just need to modify it so that it checks the colwidth attribute on colspec, and if it contains "pi" change it to "pc" before passing it through to the FO engine.

--Clay

[ptc-1787870]

Picturing Elrond's Council or a Balrog after that comment. 🙂

I love that people are still gaining value from the older Arbortext versions.

[GregoryMackenzi]

@Clay: It looks like I may be forced to look at that, when I change to metric, upon CSDB save it actually recalculates those values in picas. So there is definitely something going on there. Thanks very much for your help! I have a smattering of XML/XSLT training, enough to make me dangerous! 😉

@Jason: We also run Epic 4.3 for some SGML and it's FOSI. Now rolling d20 for my saving throw... 😉

[jsillari]

Greg:

I suspect the CSDB itself is modifying the table data for reasons beyond speculation. Much of the DM content is parsed by Oracle and deconstructed into a set of tables within the database. What happens to the colspec attributes, for example, may be more a function of a stored procedure in Oracle than XSLT.

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

[ebenton]

We use Print Composer to make paper/PDF and our Navy customer is so sensitive to page fidelity that we tend to stick with Arbortext versions for a long time. We went from 4.3.1 to 5.2 and then from 5.2 to 6.0. Who knows how long we will be on 6.0?

[GregoryMackenzi]

Hi John,

If that is the case, I probably don't have too many options. We really should be using the current CSDB version etc.

I wouldn't really have a problem with the change to picas if the Arbortext S1000D Publisher (at my current version) output the variable column widths in picas. This it doesn't seem to do with the content I have. I'm not sure why that is.

I have a bunch of tables that came out of various MS Word documents via MS Excel, and I've been doing some tinkering as well with Arbortext Import to bring in those tables without using Excel as the go between.

The Arbortext Import tool gave very clean xml overall but was considerably more effort to get a similar result. In any event, the result is exactly the same no matter where the table came from, the column widths are modified to picas by the CSDB Save and the PDF column output is divided evenly within 38 picas in the output by the publisher.

I think what I'm going to do today is construct some tables directly in the editor and see what happens to those variable columns.

By the way, I still have reams of notes from when you were here and gave us S1000D training. 🙂 Thanks very much for that great experience as it has proved an excellent foundation.

Greg
🙂

[GregoryMackenzi]

The ability to retain print fidelity is not something anyone wants to give up. We have a similar situation with an SGML DTD and Print FOSI which, since they will not be modified, are only really compatible with Epic 4.3. Hence Epic, and its print composer will be with us for a long time.

[GregoryMackenzi]

I constructed some very simple tables this morning and here are some
screenshots which show the problem I'm having. So the issue has nothing
at all to do with any tables imported from other sources.

Greg

[GarethOakes]

Sounds like one for the PTC support team.


Gareth Oakes
Chief Architect, GPSL
www.gpslsolutions.com


On 30/01/2014 21:48 , "Greg MacKenzie" <-> wrote:

>I constructed some very simple tables this morning and here are some
>screenshots which show the problem I'm having. So the issue has nothing
>at all to do with any tables imported from other sources.
>
>Greg
>
>

[GregoryMackenzi]

I put in a case...

[BobSpangenburg]

Greg,

I've work with the Arbortext software for some time and my output is pretty much paper (PDF). However, I'm thinking that S1000D is geared more to the IETM arena. That said, what if you tried using "*" instead of "pi"? My thought is that you'll get the proportion of the table widths, just not the exact pica widths.

Just a thought...

Bob

[GregoryMackenzi]

Hi Bob,

Thanks for the idea, I just gave it a try, the CSDB Save function returns the values to "pi". I sense a theme... 😉 Basically whatever I enter for a measurement be it mm or in. gets converted to picas.

The Arbortext Publisher for S1000D gives the user the option of PDF, PDA, and IETM as output.

I've got a few other axes to grind with the Publisher output as well, such as; each DM toc not actually reflecting all of the titled levelledParas, tables which have no toc entry being counted such that the following table number gets incremented, the cover doesn't actually match an issue 4 spec, etc.

One windmill at a time... 😉

Greg

[jsillari]

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

[ClayHelberg]

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

[GregoryMackenzi]

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
🙂

[GregoryMackenzi]

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

[ClayHelberg]

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')&quot;=">
<xsl:value-of select="round(number(translate($pValue,'pcPCiI','')" *=" 4.23333333))&quot;="/>
</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

[GregoryMackenzi]

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)&quot;=">

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

[ClayHelberg]

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

[GregoryMackenzi]

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=" )&quot;=">
<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
🙂

[ClayHelberg]

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