Skip to main content
G
GregoryMackenzi1-Visitor
1-Visitor
January 29, 2014
Question

S1000D PDF Table Output Column Widths

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

    30 replies

    Show previous replies
    G
    GregoryMackenzi1-VisitorAuthor
    1-Visitor
    January 29, 2014
    @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... 😉
    J
    jsillari1-Visitor
    1-Visitor
    January 29, 2014
    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
    E
    ebenton1-Visitor
    1-Visitor
    January 29, 2014
    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?
    G
    GregoryMackenzi1-VisitorAuthor
    1-Visitor
    January 30, 2014
    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
    🙂
    G
    GregoryMackenzi1-VisitorAuthor
    1-Visitor
    January 30, 2014
    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.
    G
    GregoryMackenzi1-VisitorAuthor
    1-Visitor
    January 30, 2014
    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

    G
    GarethOakes16-Pearl
    16-Pearl
    January 30, 2014
    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
    >
    >
    G
    GregoryMackenzi1-VisitorAuthor
    1-Visitor
    January 30, 2014
    I put in a case...
    B
    BobSpangenburg1-Visitor
    1-Visitor
    January 30, 2014

    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

    G
    GregoryMackenzi1-VisitorAuthor
    1-Visitor
    January 30, 2014
    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
    Show more replies
    Terms & ConditionsAccessibility statement