The library contains a lot of procedures, currently only the most important public procedures are documented. If all you want to do is let your users save the contents of a richtext widget in various formats, the only procedure you'll need is j:tc:saveas.
Currently, the following output formats are supported:
However, when converting to HTML, jdoc hypertext links to other documents (i.e., not within the same document) are preserved after a fashion. (These can be links to other jdoc documents, which will be converted to references to HTML documents, or standard Web URLs, which will be preserved without change.) The HTML links generated for links to other jdoc documents (as opposed to standard URLs) may need handediting, however, since relative links in HTML documents and jdoc don't follow the same rules.
Also, when converting to HTML, one level of unordered list is supported. (The lists generated may be very strange if you haven't been careful when typing the list; all text within the list must be tagged as an unordered list, and list item markers must appear within the list in appropriate places.)
j:tc:tclrt:convert_text
t - convert to Tclformat richtext; see
jrichtext.tcl
j:tc:tex:convert_text
t - convert to TeX source
j:tc:html:convert_text
t - convert to HTML (without links, currently)
j:tc:ps:convert_text
t - convert to PostScript
The distinction between j:rt:par and two successive j:rt:cr's is lost when converting text that was generated with the jrichtext.tcl library, but it's not actually reflected in the text widget in the first place.
Tabs are converted to a fixed amount of whitespace, and spaces at the beginning of a line are lost. Multiple blank lines are also lost.
The distinction between paragraphs and line breaks is lost; all sequences of line breaks are translated as a single <P> code.
Tabs are rendered as a fixed amount of space. Spaces occasionally appear at the beginnings of lines when they shouldn't (similarly to the way they do in the Tk text widget).
What is generated is actually a PostScript program that generates the formatting, rather than a set of simple page descriptions, so it makes a lot of demands on your PostScript interpreter, and may print more slowly than you expect. Also, it doesn't conform to the PostScript comment conventions (it can't), so tools that need to work with PostScript files pagebypage will fail.
The ISO 8859-1 character set is supported only if you have a Level 2 PostScript interpreter (or at least an interpreter than knows ISOLatin1Encoding).
* Whitespace is often lost or garbled in many of the formats.
* Much of the code is pretty inefficient.
* Tags other than font tags should be handled, for instance, colour and underlining should be supported (where possible).
* It would be nice to support WYSIWYG writing of manual pages, or generation of them from jdoc documents. This would probably require a little additional information beyond what's in the text widget (e.g. name and description, section of the manual, etc.)
* When jdoc documents are converted to HTML, I'd like to translate hypertext links and anchors as well as fonts. (The capabilites of jdoc are closely modelled after those expressible in HTML.)
* The exact fonts used when generating PostScript and TeX should be user preferences.
* The TeX conversion does a lot of work to support ISO 8859-1.
This should only be done if there are actually nonASCII characters
in the text (or perhaps it should be a user preference). The
PostScript conversion should support ISO 8859-1 even on Level
1 interpreters (it's easy enough).