User's Guide > About the User's Guide > Codebeamer DOORS Bridge > DOORS Known Limitations
DOORS Known Limitations
There is a known problem in IBM Rational DOORS with Word/RTF tables.
You cannot create or edit Rich Text Tables in DOORS directly, but if you pasted Rich Text Tables (e.g. from Microsoft Word) into DOORS Rich Text Attributes, such tables will be displayed, because DOORS delegates this task to the Microsoft Rich Text Control.
But DOORS itself does not provide tools, to operate on RTF tables.
Especially the DOORS extension Language, that DOORS Bridge is build upon, ignores or skip unsupported RTF markup (e.g. RTF table tags), so upon export (even with the build in DOORS tools), RTF tables will loose all decorations.
DOORS Bridge 1.3 and newer, therefore use a different approach.
Instead of parsing DOORS rich text with the build in DOORS/DXL parser, the raw rich text is exported as RTF fragments and post-processed with an own RTF parser, that is able to handle also RTF elements, not supported by DOORS natively.
• RTF Pictures
• RTF Objects
• RTF Lists
• RTF Tables, including nested tables
• RTF Bullets and Numbering
Another known problem are Symbols using the special Symbol and/or WingDings fonts.
Codebeamer (Wiki) Text uses the UTF-8 character set and a standard Web font (e.g. Arial):
• Only a subset (~70%) of the Symbol and/or WingDings characters have an equivalent UTF-8 character.
• Even if there is an equivalent UTF-8 character, not all fonts support all UTF-8 characters.
• So some exotic symbols may not be imported properly and show as
Yet another known problem is whitespace, especially tabs within text.
RTF renders each whitespace character as is, but Codebeamer Wiki Markup is translated into HTML, and HTML typically renders consecutive chunks of whitespace into a single space.
Text that uses tabs and spaces
• To show multiple lines in a tabular form, or
• To simulate numbered and bulleted lists with different indentation,
can therefore appear to be misaligned in Codebeamer.
Transformation of DOORS Test Specifications to Codebeamer Test Cases
There is no standard schema for Test Specifications in DOORS, so customers have invented their own methods of defining Test Cases, including
• Prerequisites
• Test Steps
• Test Parameters, etc.
in Formal DOORS modules.
But this means, that there is also no standard way of mapping these custom schemas to the Codebeamer schema upon import.
But in CB-10.0 and newer, you can implement and deploy own Java code, that plugs into the import process, to perform special data transformations, not supported by default.
OLE objects are displayed as attachments
If new office is installed on DOORS bridge server it could happen that OLE objects within import files which were created by older Office versions are shown as .png attachments after import.
To resolve this error you should install also an older Office version on DOORS bridge server (e.g. Office 2003) so these OLE objects can be imported properly.
Was this helpful?