Reply To: Controlling Table Borders

[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