 |
 |
> of terminating this, but instead <<mdnm>> meaning "revert to normal". > Consequently, <<mdit>><<mdbd>>bold italics<<mdnm>> and suchlike were > terminated by a *single* object, not two as we would expect in the XML > field. This meant that any translator to another format had to maintain > state so that the right switch could be applied in the output. True. I think when I did conversions that I resorted to inventing interim dtds with minimized closing tags and then normalizing, a crude and familiar tool (which is, you will have observed, the only kind found in my scantily equipped toolbox) but fairly effective. E.g. given a document like this (with NB 'format deltas' converted directly to opening tags): <!DOCTYPE nb SYSTEM "testnb.dtd"> <NB>This is a document <ITALIC>with some text in italic<NORMAL> and some not, with <ITALIC>some in plain italic <BOLD> some in bold italic<NORMAL> and some in normal type. Some was even <UNDERLINE>underlined or <BOLD>bold underlined or even <ITALIC>bold underlined italic<NORMAL> but most was not.</NB> I would normalize under this dtd: <!ELEMENT NB - - (#PCDATA | NORMAL | BOLD | ITALIC | UNDERLINE)*> <!ELEMENT NORMAL - o (#PCDATA)*> <!ELEMENT ITALIC - o (#PCDATA | BOLD | UNDERLINE)*> <!ELEMENT BOLD - o (#PCDATA | UNDERLINE | ITALIC)*> <!ELEMENT UNDERLINE - o (#PCDATA | BOLD | ITALIC)*> to get this: <NB>This is a document <ITALIC>with some text in italic</ITALIC> <NORMAL> and some not, with </NORMAL><ITALIC>some in plain italic <BOLD>some in bold italic</BOLD></ITALIC><NORMAL> and some in normal type. Some was even </NORMAL> <UNDERLINE>underlined or <BOLD>bold underlined or even <ITALIC>bold underlined italic</ITALIC></BOLD></UNDERLINE> <NORMAL> but most was not.</NORMAL></NB> This was years ago and I'm forgetting the details, but something like that seemed to work, albeit with complications posed by intervening formatting (I don't remember now how 'mode' tags interacted with other formatting tags). > rather than suck up my unit's time in supporting them. I think we have here the nub: when I was using word-processors, back in the 80s and early 90s, it never occurred to me to ask Cornell or UM to provide any support. NB, in my experience at least, was for us anarchists, not for institutions. I was always on my own and liked it that way. As I recall, my dissertation (written in WordPerfect 4.2 I think, not NB) was so unsupportable, institutionally speaking, as to employ an (almost) entirely proprietary character encoding, my own invention, that included codepoints for characters only recently added to unicode (e.g. runes) or still absent (e.g. Latin abbreviation symbols and oddities like Icelandic a-a digraph with double acute), and even abandoned legacy ASCII at many points in the 7bit range. One big PUA, in fact, which I adapted NB to use, print, and display as well. Now *that's* an idiolect. > Having said that, one user has used it for a whole journal Mediaeval Studies (Toronto) used to be edited in NB (which turned out to be lucky for me). More importantly, NB is basically XyWrite with added menus and templates. XyWrite was at one time a, or perhaps *the*, popular magazine- if not journal- editing software, designed as a front end to type-setting systems. PCMagazine, as I recall, was edited in XyWrite. Industry-standard, really, not niche. There may, indeed, be XyWrite filters out there that would make bulky batch conversion of NB files much easier. And there are some internal NB resources (e.g. macros written in the 'XyWrite Programming Language' xpl, and a still active email list) that might also be useful resources for someone faced with a mass of old NB files. pfs