Improved Access to RPL Documentation -- Scope Notes -- March 2014
Phil Weinstein, CADSWES, edit: 3-13-2014 (d)
Project: BOR IDIQ - 19 Alb Enhancements to RPL
Design and estimate improved access to RPL documentation
CADSWES staff will design and estimate mechanisms for more convenient access to RPL documentation. For example, the Predefined Functions tab of the RPL palette should provide access to function documentation that is comparable to that contained in on-line help. This includes a description of the purpose of the function as well as meaningful names and descriptions for the function parameters. Similarly, the Predefined Function editor should provide convenient access to the same information. RPL editor dialogs should provide context-sensitive access to on-line help based on the current selection.
We are limiting the scope of this particular development to providing access to the most needed parts of the RPL documentation (e.g. Predefined Functions) using our current document authoring procedures and tools (using Adobe FrameMaker), possibly accommodated with some changes to the documentation source.
In the future, we may want to consider an entirely different structure and process for all RiverWare documentation which would support ideal presentations in these media:
Some of the qualities we will eventually want in a modernized RiverWare documentation system are:
It's virtually a forgone conclusion that RiverWare documentation will need to support HTML as a display format. This is not to say that HTML should be the source format. We will want to manage our content with high level tools which will support, for example, specification of mathematical formulas for display (as does FrameMaker). This will require a much broader analysis of available technologies and products.
But with respect to enhancing RiverWare to display more RiverWare documentation within the GUI, an intermediate step is doing so with the HTML format -- regardless of how that HTML content is generated. RiverWare's recently developed model report capabilities demonstrate displaying HTML content with CSS and JavaScript. This makes use of Qt WebKit in Qt 4.8 which continues to be in active development in Qt 5.
RiverWare documentation is currently authored with Adobe FrameMaker 10. We now generate only PDF. An external tool is used to define hyperlinks between PDF documents. FrameMaker has the capability to generate HTML, but has some limitations which would have to be addressed.
Note: I did take a look at some possible technologies to display PDF within Qt. It would require integration of new special 3rd-party libraries (e.g. Poppler, or the Adobe PDF Library SDK). But the fact that PDF content is presented with a fixed-width limits the value of this approach, given that, in some contexts, we would want to display documentation content in narrower panels.
The Appendix, "RPL Documentation Content" summarizes the types of information in RPL documentation. This current effort will focus on the "Enumerated Item" topics:
Controls to show relevant content for selected "items" could be added to these RiverWare GUI components:
Content will be provided as HTML, and may contain references to image files of a format typically supported in webpages (PNG, GIF, JPG). To the extent possible, text should wrap to the available visible horizontal space, though the presence of an image may define the content width. In that case, a horizontal scrollbar may be displayed when the panel is narrow.
FrameMaker 10 supports HTML output (and also an alternative HTML-like XML output, which is very similar). It's got some problems which hopefully can be worked out -- possibly with the newest version of FrameMaker (version 12). The problems are characterized below.
Here is a comparison of the PDF and HTML output for a particular function. (See also a link to the actual generated HTML file, below):
http://cadswes2.colorado.edu/~philw/2014/RplDocDesign/Example1/Test1/RPLPredFuncs-30.htm
I have these observations about generating the RPL Predefined Functions document:
PDF: | ![]() |
|
HTML: | ![]() |
<A HREF="../Objects/storageReservoir.htm#10002" CLASS="XRef"></A>
As mentioned above, some of these problems may be addressed by a newer version of Adobe FrameMaker (i.e. upgrading from version 10 to version 12). But quite likely, we will need to post-process the HTML (or XML) generated from FrameMaker to fix things up. This would probably be a custom script, maybe written Python. We might also need the post-processor to generate a translation dictionary for filenames and/or anchors, for use by RiverWare.
The HTML files (and associated CSS and image files) would need to be distributed with the RiverWare executable (ideally in a distinct subdirectory). Alternatively, we could embed these files within the RiverWare executable using Qt Resources (i.e. as we do with RiverWare icon images).
(A) Enumerated Item Topics
(B) Discussion Topics
(C) User Interface Description
(A) Enumerated Item Topics:
(B) Discussion Topics
(C) User Interface Description
--- (end) ---