Formatting control and WordPerfect 5.1
A younger colleague was wrestling with a getting a multi-part numbered list to number sequentially across the multiple parts. The result was a wrestling match with Microsoft Word 2007. Even in Oracle OpenOffice.org or The Document Foundation LibreOffice.org one can get into battle with ordered lists.
Being older, I fondly remember the Reveal Codes setting in WordPerfect 5.1. I gather that Corel Office X5 not only continues to offer WordPerfect replete with Reveal Codes but also has the option of returning to the traditional white text on a blue screen. Although one can show hidden characters, this is a pale shadow of what Reveal Codes makes possible.
When I know I am going to want absolutely dictatorial control of complex formatting I switch to hand-crafted HTML + CSS. Once upon a time HTML was the unruly, unmanageable child of the formatting kingdom. Cascading Style Sheets has brought order to chaos.
With CSS providing management tools, HTML itself is the ultimate Reveal Codes language. Written as HTML5 but using the Polyglot markup guidelines as applied to HTML, there is absolute control over formatting. Done carefully, one not only gets exactly what one wants on screen, but also in print. I actually compose in a text editor, typing
for each new paragraph.
When I knew a table was going to get complex and would need to reflow for different print options users might select, HTML was the only logical choice. When ordered lists were going to be nested and span multiple tables and sections of an outline, HTML was again the only logical choice. I would later have to craft that outline in Word to provide an editable document for non-HTML code heads. Wrestling with the Word document was an all day affair. The HTML document was a single hour of work.
In another plus, one can tuck all sort of notes into hand-crafted HTML, comments that need not be printed nor displayed, but which provide information of use primarily to myself when I later want to know what I was thinking when I made a particular choice in the document.
My latest forays into the use of HTML for formatting complex documents has been my course syllabi. These are still XHTML documents which also deploy SVG to achieve effects simply beyond the imagination of most word processing users. Lines that cross table cell borders with circles on the end that are links to the appropriate rubric for a particular laboratory - a little impossible to reproduce with any word processing package. Sure, you could add drawings on top of tables, but the whole thing is likely to fall apart when the table is resized. And linking from geometric elements is not something I am aware one can do from most drawings in a word processing package.
There is a hefty learning curve for HTML + CSS and thence on to MathMl and SVG, but the pay off is insane control over every aspect of a document. Still, what with XML lurking under the hood of Microsoft's docx format and OpenDocument Format for Office Applications, revealing the underlying codes seems theoretically possible.
Being older, I fondly remember the Reveal Codes setting in WordPerfect 5.1. I gather that Corel Office X5 not only continues to offer WordPerfect replete with Reveal Codes but also has the option of returning to the traditional white text on a blue screen. Although one can show hidden characters, this is a pale shadow of what Reveal Codes makes possible.
When I know I am going to want absolutely dictatorial control of complex formatting I switch to hand-crafted HTML + CSS. Once upon a time HTML was the unruly, unmanageable child of the formatting kingdom. Cascading Style Sheets has brought order to chaos.
With CSS providing management tools, HTML itself is the ultimate Reveal Codes language. Written as HTML5 but using the Polyglot markup guidelines as applied to HTML, there is absolute control over formatting. Done carefully, one not only gets exactly what one wants on screen, but also in print. I actually compose in a text editor, typing
for each new paragraph.
When I knew a table was going to get complex and would need to reflow for different print options users might select, HTML was the only logical choice. When ordered lists were going to be nested and span multiple tables and sections of an outline, HTML was again the only logical choice. I would later have to craft that outline in Word to provide an editable document for non-HTML code heads. Wrestling with the Word document was an all day affair. The HTML document was a single hour of work.
In another plus, one can tuck all sort of notes into hand-crafted HTML, comments that need not be printed nor displayed, but which provide information of use primarily to myself when I later want to know what I was thinking when I made a particular choice in the document.
My latest forays into the use of HTML for formatting complex documents has been my course syllabi. These are still XHTML documents which also deploy SVG to achieve effects simply beyond the imagination of most word processing users. Lines that cross table cell borders with circles on the end that are links to the appropriate rubric for a particular laboratory - a little impossible to reproduce with any word processing package. Sure, you could add drawings on top of tables, but the whole thing is likely to fall apart when the table is resized. And linking from geometric elements is not something I am aware one can do from most drawings in a word processing package.
There is a hefty learning curve for HTML + CSS and thence on to MathMl and SVG, but the pay off is insane control over every aspect of a document. Still, what with XML lurking under the hood of Microsoft's docx format and OpenDocument Format for Office Applications, revealing the underlying codes seems theoretically possible.
Comments
Post a Comment