Controlling Table Borders

[Moshe Chertoff]

Hello to all,

We're trying to figure out why some of our tables appear with lines (internal and external borders) and some appear without.

We noticed that when we add a table header, the entire table gets lines. We also noticed that we can only give “1” or “0” values to line width, as opposed to HTML values. We could live with the extra row that a header inserts, if we could only control the line width.

Your help is appreciated.

Reply

[ghkrause]

Hi,
Could you be so kind and drop some lines of XML that highlight your problems? (I am accessing this forum via blackberry and it seems to me there is no file attached to your message.
Which DTD do you use?

Reply

[Moshe Chertoff]

Hi gh (?),

Thanks for you quick reply. Re the DTDs:

Avviso 90

Il catetere è progettato per
essere utilizzato da
personale di servizio
qualificato per verificare la
funzionalità del sistema ed
è limitato XXXXXXX di
YY punti.

Sostituire il XXXXXXX di prova con un XXXXXXX standard.

A XXXXXXX is detected. XXXXXXX!

Rilevato XXXXXXX di prova. Non utilizzare su XXXXXXX!

Avviso 91

Il catetere è progettato per essere utilizzato da personale di servizio qualificato per verificare la funzionalità del sistema ed è limitato all'acquisizione di
XXXXXXX punti.

Sostituire XXXXXXX standard per XXXXXXX di punti.

A Test Reference XXXXXXX is detected. It is not for XXXXXXX!

Rilevato XXXXXXX di prova. Non utilizzare su XXXXXXX!

Avviso 92

Il XXXXXXX per essere XXXXXXX di
XXXXXXX punti quando XXXXXXX mappante.

Per XXXXXXX, scollegare il XXXXXXX con un catetere XXXXXXX XXXXXXX.

A XXXXXXX is detected at the XXXXXXX connector. It is not XXXXXXX!

Rilevato catetere di XXXXXXX. Non utilizzare su XXXXXXX!

Avviso 93

Il XXXXXXX
utilizzato da personale di
servizio qualificato per la
verifica del funzionamento
del sistema. Sostituire il
XXXXXXX un”

Thanks in advance,

Moshe

Reply

[Su-Laine Yeo]

Hi Moshe,

Are you seeing the lines in XMetaL Author itself, or in output, or both? If it's in output, can you specify what formats (e.g. PDF?) Screenshots would help me understand what's going on. If you can  save a screenshot as a GIF file and attach it to a posting here, that would be great.

Reply

[ghkrause]

My observations, Moshe:
a) you are using SiberSave CMS
b) you do not use the DITA DTD files provided with XMetaL installation (no DOCTYPE PUBLIC, only SYSTEM)
c) you want to render a topic with standard table to HTML
My assumptions:
i) you do not use Open Toolkit that was installed with XMetaL installation ??
ii) you do not like the way the table looks like in the HTML rendition ??
Note: In DITA source you have CALS table, in HTML you get HTML table.
If you provide the equivalent code fragment of the HTML rendition this might help.
I am pretty sure you need someone to adopt the DITA2HTML XSLT to your requirements …

Reply

[Derek Read]

Doctype Declaration and Public vs System Ids:

With the Doctype declaration in this XML file (which points to ../../../../System/DITA/dtd/main.dtd) XMetaL Author will be looking for that file at that location (relative to the XML file).

An out of the box XMetaL Author Enterprise installation really expects to see a PUBLIC id here, as follows:

This way a catalog lookup is made possible, and XMetaL Author will then be able to direct itself to use the DTDs that we ship (which are standard unmodified DITA DTDs in case that is a concern). The reason the DTDs need to be in a specific location is because XMetaL needs many other files (also at this location) to provide a proper editing experience for DITA (CSS files for display, many scripts for functionality, forms to aid with attribute entry, and many other things).

If you simply direct XMetaL to use a DTD at a location of your choice that location will not contain all these other supporting files. When this happens the product automatically generates a minimal set of customization files (CSS and CTM). Because these are automatically generated they are not going to be optimal – a human really needs to be involved to provide a professionally functioning customization. This feature is there to help people with other (non-DITA) DTDs that do not yet have a customization, so they are able to at least view their documents. This is somewhat analagous to simply loading an XML document into IE, which provides a default tree-view, it might be usable but isn't really pretty. Compare that to loading an XML file together with an associated CSS or XSLT file (created by a person) into IE. You might see something similar to an HTML page. That is comparable to XMetaL loading an XML file that has an associated set of customization files (created by a person). We've spent a few years perfecting the customization files used for DITA editing.

In general when working with XML with multiple tools (in this case XMetaL Author, the DITA OT and a CMS) it is usually best to use PUBLIC id values because this enables catalog lookup by each tool. It is also very easy to break a SYSTEM id if you move a file with a non-XML aware application (such as Windows Explorer).

Sibersafe:

With regard to Sibersafe, I would strongly urge you to contact the vendor to obtain the proper configuration for XMetaL Author Enterprise from them, which ideally would have specific support for DITA. In this case (because a CMS is involved) there may be specific requirements about where you must store your files, as well as the content of the XML (SYSTEM vs PUBLIC id) that the CMS expects to see. In most cases a CMS vendor will provide a set of special files you either need to install on the CMS to support XMetaL and very likely a set of files you need to install with XMetaL (usually at a minimum this is a set of scripts) for it to communicate properly with the CMS. In addition, because XMetaL Author is customizable a particular vendor may modify the way it functions and so what I have stated in the previous section may not entirely apply. You really need to ask them how they expect the system to be configured.

CALS Table Support:

Finally, our Table Properties dialog only supports “0” or “1”. This is because of the wording in the [url=http://”http://www.oasis-open.org/specs/a502.htm”%5DCALS table specification[/url], which states that a value of “0” indicates a separator is off, while any value greater than zero indicates it is on. We chose to expose only the values “0” and “1” in this dialog so that users do not get confused and expect a value of “2” or higher to indicate something more than it does (such as the width of the border). CALS tables are different from HTML where the border attribute actually does mean “this many pixels wide”. Note that we also chose to render the value “0” as a dashed line and a value of “1” (or more) as a solid line. This allows people that have turned borders off to still see where cells start and end.

That having been said, it is perfectly valid to set another value and you may have good reason to do so. Personally, I would try to avoid putting any styling hints into XML wherever possible and move that into my transformations (whatever is generating my output), but if you find you do need to modify the colsep and rowsep to give it a value you cannot give in the Table Properties dialog you can do so in the Attribute Inspector. Keep in mind however, that if you set a value other than “0” or “1” it will not be reflected in the document in an obvious way (ie: any value greater than “0” simply indicates a border is “on”).

To change an attribute value for an element's ancestor (which for example would allow you to set values for

which is not really selectable) you can do the following:

1. Place your cursor inside an element (such as ).
2. Select the drop down list at the top of the Attribute Inspector and change it so that you are editing the attributes for the current selection's ancestor.
3. Set the attribute.

If you need to do really fancy table configurations that require setting attribute values on various table elements you may wish to set the INI variable tags_on_graphical_tables = false and make these changes in TagsOn view, which will then show all elements in the table (and not render the table as a table).

Keep in mind that we are talking entirely about the editing portion of working with DITA documents here, not the output. Depending on which output format you are generating and how the DITA OT supports that you may see different results. If you need your tables to look a certain way in your output it is generally best (in my opinion) to modify the XSLT or XSL-FO used to generate that output and keep the attributes in your CALS table to a minimum. This way you will generally get a more consistent output regardless of which person is editing your DITA documents because the table styling is then done in a more automated fashion.

Reply

[Author]

Posts