On this Page

    RTF Support

    We believe RTF (Rich Text Format) support is important. But let's be clear that DocOrigin's support of RTF is limited. What is there is amazingly useful, covering most things a typical business form needs. For the most part, it is used for the Terms & Conditions text, which is usually fairly bland, requiring only bolding, possibly italicization, and font size and typeface changes. The selected typeface must be included in the current output configuration (.prt). DocOrigin supports all of that but not a lot more.

    RTF Editor Recommendation

    You should use a basic rich-text editor to create and modify your rich-text files. Avoid using Microsoft Word, as it contains unsupported content that may cause DocOrigin to fail.

    In April 2024, Microsoft announced that WordPad would be removed from Windows 11. If Microsoft WordPad is no longer available, Google Docs is a good alternative for editing rich-text files. Build your file according to the guidelines on this page, then export it as an RTF file.

    LibreOffice is also a recommended option for editing RTF files.

    We do support superscript, subscript, and basic underlining as well as color changes within the text paragraph.

    We do preserve tab characters and support a basic set of tab stops, which happen to default to 1/2", so an embedded tab will sort of work. If we encounter the start of a paragraph in the RTF, we interpret that as leaving a blank line and then starting at the left margin. If already at the start-of-line, the same is done except no blank line is added.

    That's all. DocOrigin is not a word processor and doesn't profess to be one. We recognize only that RTF fits nicely into our existing business form text capabilities. See the chapter below for a more detailed list of limitations.

    The limited tab support often tricks people into believing we have support for RTF-defined lists. We do not. Some system engineers have worked out ways to accomplish this feat, but it is not through direct usage of an RTF-defined list.

    As of 3.1.002.06, it's possible to enable the parsing of paragraph formatting commands. See -rtfParserVersion. Supported are per-paragraph indentation, tab positions, alignment, and before/after space.

    DocOrigin Merge strives to and seems to succeed in ignoring all of the RTF syntaxes that it doesn't understand. But you would be well advised to keep your RTF to a much more reasonable subset. For example, at worst, use a rich-text editor, not Microsoft Word, to edit your RTF. The bloat that is in MS Word is unbelievable. This generally makes it impossible to find your actual text or to do any debugging since the RTF string lengths will be huge and unmanageable. KEEP IT SIMPLE.

    DocOrigin supports rich text format directly in text objects through the use of the Common Properties Tab. In addition, rich text formatting is retained from your clipboard when copied from other files, such as PDFs, Word documents, and other DocOrigin files. Lastly, external rich text files (RTF) can be directly imported into a DocOrigin file (see chapter below).

    Note that it's a good idea to resave your rtf fragments in a basic rich text editor before using them in DocOrigin. This will significantly simplify the RTF structure and make it possible to parse with non-sophisticated RTF parsers.

    Like all textual data fields, RTF text fields support square-bracketed references to field names, in the style [fieldname]. However, such a string cannot have any RTF syntax within it. Don't bold the field name in your RTF editor, or make any such rich text changes. It must be literal. Your best action is to open your RTF in a plain text editor and verify that your [fieldName] reference is intact. Looking at your RTF in a plain text editor will be instructive and will surely lead you away from RTF editors that inject so much extra syntax. 

    If you want to keep the rich text simple, you can use DocOrigin to build your rich text in a text label. Then, capture the RTF content by selecting the object, hitting Ctrl+Alt+N, and copying the content between the <text></text> leaf notes of the XML snippet. Then paste the content from your clipboard into a file and add a file name with an RTF extension. 

    Limitations

    Supported Rich Text Features:

    The following features of rich text formatting are supported:

    1. Color

    2. Font - The available fonts are defined by the Printer Configuration File selected for the document, as well as the fonts installed for all users on the DocOrigin Design and Server machines.

    3. Bold

    4. Italic

    5. Single Underline

    6. Point Size

    7. Strikethrough

    8. Subscript

    9. Superscript

    10. Hyperlinks

    11. Paragraph Formatting:

      1. Line Spacing

      2. Paragraph Space Before and After

      3. Hanging Indent

      4. First Line Indent

      5. Tabs

    Note: Paragraph formatting applies to the entire text object. Meaning, you cannot have a regular paragraph, followed by an indented paragraph with hanging indents. 

    Unsupported Rich Text Features:

    1. No Tables

    2. No Images

    3. No Bullets

    4. No Outlines

    5. No Numbering

    Importing Rich Text Files

    When importing external rich text files into a text or field object, paragraph formatting, such as line spacing and tab stops, is defined in the DocOrigin object. Therefore, if you want .25” tabs, define the Tab setting in the DocOrigin object that the RTF is being imported into, and simply insert a literal tab in the RTF file. The syntax for importing the external RTF file is [@path/filename.rtf]. 

    Bullets and Numbering Support:

    Bullets and numbering can be accomplished using the desired character and hanging indents. Be sure to define the same value for the Hanging Indent and Tab stop. The Character Map application is useful for capturing the desired character(s).

    Rich Text Syntax and Escape Characters

    Rich Text (RTF) formatting behaves differently depending on where the content originates. 

    • RTF Stored in a Profile (INI) File - When RTF content is stored in a profile (INI) file as a key/value pair, the backslash (\) characters must be escaped using a double backslash (\\) – this preserves the literal RTF control word (like \rtf1). For example:
    RTF_DoubleBackslash_ComesFromProfiles={\\rtf1{\\fonttbl{\\f0\\fcharset0 Arial;}{\\f1\\fcharset0 Times New Roman;}{\\f2\\fcharset0 Tahoma;}}\\f0\\fs24\\b1\\i0\\nosupersub\\strike0\\ulnone Let's capture some simple, clean RTF text without the use of a Rich\\u160 ?Text Editor such as WordPad (which has been sunset). I am 12 point Arial Bold{\\fs20\\b0 \\par }{\\fs20\\b0\\i1\\ul I am 10 point Arial italic and underlined.}{\\fs20\\b0 \\par }{\\b0 I am 12 point Arial.\\par }{\\f1\\fs16\\b0\\i1 And I am 8 point Times New Roman.\\par }{\\f2\\fs20 IMPORTANT: Don't forget that any fonts used in your RTF will need to be in all of your PRTs - the Design Workstation and Server. And the fonts need to be installed for all users... and so on.}}
    • RTF in an Initial Value - When rich text is defined as the Initial Value of a field: 
      • Only a single backslash (\) is required.

      • This is standard RTF syntax.

      • This format is typically captured directly from a rich text editor or from a formatted DocOrigin text object.

      Note: The Initial Value acts as the field’s default value.


    • RTF Coming Directly from Data - When RTF content comes directly from structured data (XML or database field), it uses normal RTF formatting with single backslashes.
    • RTF from an External File - When a fully qualified path and filename are provided in the data, the system reads the external .rtf file directly. The file itself uses standard RTF formatting with single backslashes. No escaping is required. The format is [@path/filename.rtf]. See Importing Rich Text Files above.

    RTF_InDataOrField_vs_Profile.zip

    See Also

    -rtfParserVersion
    Merge External PDFs