The horizontal ruler area at the top of a text window contains the expected formatting tools: you can set the paragraph containing the insertion point to be ragged-right, ragged-left, centered, or right-and-left justified; you can insert four kinds of tabs; increment or decrement line leading and paragraph leading; and, of course, slide the wrapping margins. There is also a ruler icon which, if checked, causes small ruler symbols – the Governing Rulers – to become visible to the left of some paragraphs in the text.

It appears that Paragon began by hoping to do without Word-type named paragraph styles altogether; and the curious hierarchy of ways to manipulate paragraph formatting reflects the remnants of this hope. At the bottom of the hierarchy is a mechanism for physically and namelessly manipulating paragraph styles, the Governing ruler, rather like the ruler in the original MacWrite. Under this metaphor a ruler appearing in the left margin continues to govern every subsequent paragraph until a paragraph is encountered whose format information (margins, justification, tab placement, line leading, paragraph leading, etc.) differs in some way, and then a new ruler appears in the left margin next to that differing paragraph.

You can do many things with these rulers:

• (i) You can alter the format of one paragraph. <more>
• (ii) You can select any number of paragraphs (contiguous or otherwise, remember) and alter their formatting. <more>
• (iii) You can alter the format of one paragraph and all contiguous paragraphs governed by the same individual ruler. <more>
• (iv) You can alter the format of one paragraph and all identical paragraphs – that is, all paragraphs anywhere in the document whose formatting is just like the current paragraph. This is a cool feature because you can essentially redefine a paragraph style for the whole document without ever worrying about style names. <more>
• (v) You can treat the Governing rulers that appear in the margin as characters, and cut and paste them as a way of altering paragraph formats. <more>

Adam thinks that when it comes right down to using Nisus, over 90% of users will never even notice or care that they can do anything but format either the paragraph holding the insertion point or the selected paragraphs, although he admits to being fond of the ability to cut, copy, and paste ruler icons to format text. This may be true, though I happen to think that even such users will probably accidentally run across the more advanced properties of Governing rulers. But in any case we both agree that the combinations of these various actions on Governing rulers are extremely powerful, a fantastic implementation of the concept.

The Paragon people at some point decided that this way of working with formats was incomplete, and so a second level of hierarchy is included, Named Rulers. A ruler can be assigned a name; if this is done, a slightly different ruler icon appears, and the name can now be selected from a pop-up menu in the ruler at the top of the window as a way of assigning the given format to a paragraph, just as in Word. <more> Any changes made to the formatting of any paragraph governed by a Named ruler will instantly be applied to all paragraphs governed by a ruler with that name; this is what makes Named rulers so powerful and useful.

(If you’ve been working entirely with unnamed rulers and decide things would be easier if you used Named rulers instead, it is easy to make the transition: if you hold down Command as you name a ruler, all identical rulers throughout the document will be given that name. Try THAT with Microsoft Word! I’m deadly serious here: the only way in Word to give a single Style name to all identical paragraphs in Word is to find them all, one by one, and apply that style. Score a big one for Nisus here.)

Things can get a bit tricky in the interplay between named and unnamed rulers; you’ll have to download the longer version of this review if you want details. <more>

The top level in the formatting hierarchy is User-Defined Styles. In Nisus, the term Style in this context does not refer to paragraph formatting per se. It may involve character font, character size, character styling, or paragraph formatting by way of a ruler name – or any combination of these. (You will notice that paragraph formatting, as we have been discussing it so far, has not involved character features in any way. Pasting a named ruler, for example, will do nothing to the font, size, or style of any characters in the document.) This is the level on which you really want to operate, because it is the most global and convenient. Any change made to any part of the definition of a User-Defined Style is instantly reflected in all text to which that Style is attached; and you make your changes quickly and easily in a dialog box. Nisus is incredibly intelligent about remembering why text looks the way it does; you can cancel the effect of a User-Defined Style upon text, just by selecting the text and choosing the Style from the Style menu (whereupon it unchecks in the menu); and when you do, characteristics of the text that are imposed by that Style are removed – but characteristics of the text that are imposed by other Styles applying to it, or that were imposed manually (by choosing Italic from the menu, for example), are not removed.

The price of this power, though, is that User-Defined Styles work in a tricky way. The options available to the user when defining a Style include Named Ruler, font, size, color, and character styling. Now, if a User-Defined Style does not include a ruler name, then when you choose it from the Style menu it applies to the character formatting just of any selected material, or to the insertion point and any subsequent typing. But if it does include a ruler name, then, when you choose it from the Style menu, no matter how much text is selected, the ENTIRE paragraph containing the insertion point will take on the character formatting defined in the Style, – and the Named ruler in question will appear to the left of the paragraph. <more>

Well, you may disagree, but I find this more than a tad confusing. <more> However, let me get one thing perfectly clear: despite these confusing behaviours, I LOVE the way Nisus handles Rulers and Styles, and I think they put Word completely in the shade; Nisus gives you a power and convenience that Word just cannot match. <more>

A noteworthy aspect of Rulers and Styles is the way in which these are made transferable from one document to another. If several documents are open at once, the User-Defined Styles of all of them are available in the Style menu (those that are not in the frontmost document are marked with the name of the document they are in). If you select a User-Defined Style that is not in the frontmost document, it will be applied in the frontmost document, and it will also be transferred into that document. Thus a single action can change the character and paragraph formatting of a paragraph, and create a new Named ruler in your document, and define a new User-Defined Style in your document. Since you do this with only those Styles that you desire in your document, you have a method of making paragraph formatting and character styling match that of another document which is, I think, far better than that of Microsoft Word.

You can also create style and formatting libraries. A document called "Nisus New File" in the same folder as Nisus will contain all the formatting information for new files, so you can create styles in that document and then delete all the text, leaving just the styles to use later on in each new document you create. Or you can have the styles live in an ordinary file, since, remember, any window (including a macro file) that you open on the screen will have its styles available for use in any other document. <more>

Named rulers also provide a handy way of navigating your document. If you hold down the Shift key while selecting the name of a Named ruler from the pop-up menu at the top of the window, Nisus will find the next instance of that Named ruler for you. As you will doubtless assign a Named ruler (most likely by way of a Style) to every heading your document, for example, you can now quickly page through the sections of your work. (You can also find character styling or User-Defined Styles in Nisus; see below.)

Missing is any way to arrange Named rulers or Styles into a hierarchy, by defining one in terms of another, as Word does. If I change the principal font of my main paragraphs, I probably want that of my subordinate paragraph types to change to match it. In Word you can arrange to have this happen automatically; in Nisus the onus is on the user to select beforehand all paragraph types to which a change is to be made. (However, once you do this, changes made to a Named ruler or Style are of course reflected instantly throughout the document.)

A very important thing you cannot do from within a Style definition is to require that your paragraph be kept on the same page with the start of the following paragraph. There is thus no way, from within the Styles dialog, to ensure that a heading will not become isolated from the succeeding paragraph, appearing instead alone at the bottom of the page. (Indeed, this error occurs several times in the Nisus manual.) This is not to say that there is no way whatever to ensure that a paragraph will be kept with following material; but again, this is a place where Nisus’s philosophy of what level a feature should dwell on might strike one as perverse. Under the Format Menu is an item, Keep On Same Page. I don’t know why this is under the Format Menu; it does not in fact alter formatting; Keep On Same Page is in reality a style (I think of it as a pseudo-style), and what choosing it from the menu really does is to impose this style on your selected text. If you want to prevent material from being interrupted by a soft page break, you have to impose the Keep On Same Page pseudo-style upon the entire run of material yourself. What you would need to do in order to keep headings from being separated from their following paragraph, for example, is to write a macro which selects every heading and a couple of lines of whatever follows, and imposes the Keep On Same Page style onto them. In the same way, Nisus does not come with any automatic prevention of widows and orphans: it is possible that as you type, a single line from the start or end of a paragraph will wind up isolated on a page. To prevent widows and orphans in your printed document, you run a macro (included with Nisus): it selects the first two lines and the last two lines of every paragraph, and imposes the Keep On Same Page style.

You have to adjust your working method to accommodate this way of doing things, and you may find it just too inconvenient to do so. It is up to you to remember to run these macros relating to widows and orphans just before print time; and you dare not run them any sooner, either, for if you impose the Keep On Same Page style onto a run of text, and then find you need to make alterations to that text, your Keep On Same Page style will be incorrectly attached in the document – being a style, it is attached to specific text, and is moved or expanded or deleted with that text. Moreover, there is no way to render the presence of Keep On Same Page style visible on the screen, so it is easy to make an error in this regard (though admittedly you could make such text temporarily visible by writing a macro to select it – but this is only a workaround, not a real solution). A macro is included for simply removing all Keep On Same Page styling, and you certainly would need to run this, if you have previously run the Widows and Orphans macro, before making any changes to your document that might alter the first or last lines of any paragraphs, or else your widows and orphans will come out wrong; but this can hardly be termed a solution. What if some of your paragraphs or paragraph styles intentionally include Keep On Same Page formatting that you would rather not lose (such as a small columnar table that needs to be kept together)? The macro will undo that styling as well! <more>

We turn now to the bottom level of Nisus, the area where the nitty-gritty is, the stuff that Nisus seems truly made for: the find-and-replace and macro/programming facilities.

You set up a find or find-and-replace in a dialog window, and the flexibility of what you can do is astonishing. You can include any sort of styling in your Find text or your Replace text – font, size, character styling, User-Defined Styles – as part of what Nisus is to look for, or the change it is to make. A built-in global regular expression parser ("grep"), or as Paragon was asked by Apple to call it, PowerSearch Plus, lets you build complex textual patterns to find and complex ways of dealing with them when they are found, and, in the Find dialog window, those not wishing to learn and type the cryptic, but oh-so-powerful codes to match patterns can select expression components from a menu instead. (It’s interesting to note that Nisus is one of a few programs that put menus in a window rather than further burdening the menu bar, something which is especially handy on large and multiple monitor setups. It would be nice to see more of this in the future.) You can find forward or backwards through a document, find one or all instances, limit your find to previously selected text. You can have your find performed on just the frontmost document, all open documents, or even on closed files for which you provide a list via the Catalog.

There is no point trying to enumerate all the features of PowerSearch Plus, but some examples will illustrate the power of the results. To change all instances of underlined text to italicised text is trivial. To change all instances of an imported marked-up expression such as "<it>some text<ro>", where the <it> and the <ro> may or may not be capitalised, so as to have the <it> and <ro> removed and whatever is in between become italicised, is only mildly less trivial. (That’s a real example in my life.) To find all instances of text that might be a phone number is an interesting challenge, but it is in fact possible to set up a single find that would be able to find such variations as "KI4-3459", "(607)-4215151", and "301 421-5353"; a single find-and-replace procedure might find all phone numbers regardless of their format and alter them so that they conform to some set format – say, parentheses round the area code if there is one, space after the area code, hyphen between the first three and last four digits of the number.

No doubt numerous possibilities for using all this power are occurring to you as you read, from free text databasing to file format translation – and rightly so. PowerSearch Plus (together with the macro capacity) is what I bought Nisus for, and it has done me yeoman service in this regard.

There isn’t much not to like about this wonderful aspect of Nisus. I have one suggestion, though. I often use foreign alphabets. Nisus’s PowerSearch Plus distinguishes numeric, alphabetic, uppercase, lowercase, alphabetic-with-diacritical, and punctuation characters, but these definitions are pre-defined for the Mac’s standard character set; the possibility that someone might be using a font where it is not true that a character is uppercase alphabetic if and only if it is ASCII 65-90, seems not to have occurred to Nisus’s designers. What I’d like to see is some sort of dialog that would let the user define these categories for any given font. Perhaps the new Script-Sensitive finding option present in Nisus 3.06 indicates some coming step in this direction; I’ve no documentation on it, so I can’t tell.

Finding text also responds inconsistently to the Keep On Same Page pseudo-style (see above). If text gets into the Find dialog that is marked Keep On Same Page (which can happen quite easily without the user’s knowing it if Copy is used to obtain the text to be sought), a style-sensitive find will not find text in the document unless it is marked Keep On Same Page (quite disconcerting, since the find will seem to be failing for no reason that the user can detect); but if the text in the Find dialog is not marked Keep On Same Page, then, even if the find is style-sensitive, text in the document that is marked Keep On Same Page WILL be included as a match. This is weird behaviour, but the root of the problem is really the fact that Keep On Same Page is a pseudo-style.

The macro facility is divided into two levels, referred to as Macros and Programming. The difference is formal: the two levels involve different commands, which cannot be combined on a single line of a macro (though they can be combined within a single macro), and the Programming Dialect requires the presence of a special interpreter file. In addition, you can record a macro by asking Nisus to watch what you are doing, and then go in afterwards and customize the macro that Nisus has created for you.

The Macro level, in a nutshell, allows you to do anything you could have done with menus and typing. You can enter find-and-replace commands in a single line rather than having to make Nisus fill in the Find dialog piece by piece, and a few other menu commands can similarly be encoded in condensed form within a macro; but the net effect is precisely to automate actions you could have taken through menus and keyboard. A macro can call itself or another macro; the find-and-replace syntax provides a means of terminating a macro, which may be in a loop or calling itself, if the find fails. The macro file appears in a window which is a version of the regular text window, with the normal tools at the top of the window and all menus available; this means you can include rulers and styles in a macro and cause them to appear in the document on which it operates. Writing macros is not at all difficult (although I find I have to have the manual in front of me if I’m to remember the find/replace syntax), and there is an excellent facility for testing them: you can tell Nisus to regard any selected text as a macro and to attempt to execute it (and you can Undo the results in one stroke, so you’re not afraid to experiment).

What the Programming dialect adds is: mathematical and string operations and functions; a rudimentary control structure (if, goto, exit); functions for obtaining information about the document – what is the name of the ruler governing the current insertion point? what is the character offset (from the start of the document) of the insertion point? of the current ruler? of the next ruler?; a storage class which is sort of a cross between an array and a stack; and commands for obtaining or setting the selection point in the document. A thing you are likely to do is combine the selection-point commands with the storage class. For example, you might do a find which results in a number of non-contiguous selections; you could then store the selection-points in the storage class; this would allow you to run through the selections one by one, doing some complicated (possibly conditional) operation on each of them.

The power of all this is so obvious as to need no further elaboration. Yet, to the reader’s possible astonishment, I should like to say that I think nowhere near enough power is provided. Nisus has a lot to live up to in this regard. On my little Apple ][c, with just 128K, I ran a program called Gutenberg. This fantastic program, by John Wagner of Scarborough, Ontario, is my measuring stick for all other word processing programs. It had no WYSIWYG bells and whistles, of course; but it revolved around a programmable page-layout language with which you could dictate, through a nesting series of macros, down to the last pixel what your dot-matrix printer would ultimately generate (in other words it was like TeX). What attracts me to Nisus is that it dwells in Gutenberg’s philosophical world; what disappoints me is that it never quite lives up to its promise. That’s right: I’m saying that Gutenberg was more powerful.

The reason for this is that Gutenberg’s programming language gave the user access to something Nisus’s does not: the global variables of the document. There is no way to find out from within a Nisus macro such things as: what is the font of the text at the insertion point? what, numerically, is the placement of the left margin? what, numerically, is the position of the insertion point on the line? (You can figure out how many characters there are from the start of the line to the insertion point, but not how many centimetres.) Similarly, you cannot set these global variables, unless through a menu command – and menu commands do not do everything. There is absolutely no way, from within a Nisus macro, to set a tab or move a margin. (Of course you can impose a ruler which includes preset tabs and margins; but I’m talking about being able to respond flexibly and numerically to the actual situation: e.g., set the left margin to 1 inch more than its present value.) I cannot believe that it would be much trouble to add this sort of facility and give Nisus’s programming language some truly incredible power. Remember, this is all stuff I used to be able to do on an Apple ][. Paragon does realize this, but has had other priorities, such as getting Nisus Compact and Nisus XS out the door. I’d like to see them focus on their programming language next, since it would help Nisus to further break from the word-processor pack.

One silly feature of macros, by the way, is that for many commands you need to be able to enter special symbols for Option, Shift, Command, arrow-keys, and the like; a special font is provided to allow this, but there is no way to type some of the symbols (no way to type any of them if you’ve no Control-key) – you have to pull down a special window called ASCII which shows the symbols, and double-click each one as needed to get it into the macro. (However, things are better than they used to be. In Nisus 3.01, you couldn’t even see the symbols in the ASCII window; you had to memorize their ASCII codes, and double-click the correct code number to cause the required symbol to appear in your macro!) The only other workaround is to turn on macro recording, type some keys with the modifiers down, and then copy the modifier symbols from the recorded macro. It’s clumsy, but it works. I just leave the symbols in a comment at the top of my macro file so they’re easy to get to.

We now come to the top layer of Nisus, a number of miscellaneous page-layout features cobbled together (a recent MacUser refers to it as a "Swiss-Army knife," an apt comparison). In my opinion these are of uneven quality and value, especially in comparison to the fantastic find/replace and macro facilities; but I’ll describe them and let you be the judge.

The Footnote facilities are the most disappointing. On the one hand, it is true, Nisus has commendably gone out of its way to provide much more flexibility here than many other word processors do. You can let any given footnote be numbered automatically or give it a special symbol, or no symbol at all; if it is numbered, you can include any sort of constant punctuation with the number, superscripting it or not, and the number format can differ in text and notes. (Thus the footnote could be marked as "(2)" in the text but "2." in the footnote.) You can restart automatic footnote numbering at any point in the document. You can have footnotes or endnotes; if footnotes, you can choose whether footnotes may be split, whether they may be separated from their main text, whether they appear at the bottom of the page or tight up against the main text, even how much of a page can maximally consist of footnote material.

But you still wouldn’t want to have to produce a proper book with Nisus’s footnote facilities. They are awkward to use because, as pointed out already, you can’t write or edit a footnote with the main text in view without messing around with manually copying the text and using the Show Clipboard feature. This may be a personal thing, but I hate not being able to see my text while writing the footnote. A Nisus document has no sections, so you cannot cause notes to appear as endnotes after each section or chapter. An unbelievably rudimentary omission is that Nisus does not allow you to define the separator line between main text and footnotes differently depending on whether the first note on that page starts a footnote or is a continuation of a note from the previous page (called a continuation separator); this is something that even Microsoft Word lets you do, and it is required by standard typographical convention. You cannot preset the font, size, and character styling of footnote numbers; you have to use the find/replace facilities to change them after they are created, and if you then make a new footnote you’ll have to do it again. On the other hand, you must preset the numbering style of footnotes; if you create several footnotes and decide you don’t like their numbering style, you have to change all the numbers one by one! As you make each footnote, Nisus attaches an unnamed ruler to each note; if you want to be the master of footnote formatting (or Style), you have to change this, and again you must do this yourself once more if you add a new a footnote. Unaccountably, Nisus insists on inserting a Tab character before each new footnote! When Nisus does a find, it cannot see footnotes; you have to find just the footnotes explicitly. When Nisus does a find of closed files, it cannot find text in footnotes at all! (Nor can other applications see text in Nisus footnotes, since they are a resource – whereas main text is of type TEXT.) And you cannot index text from your footnotes, which makes indexing largely useless to me, since in my academic writing the technical part of the argument, and all the references, are in the footnotes.

The upshot is that the problems with footnoting alone are enough to keep me from being able to use Nisus for routine production of scholarly work, even though I’d like very much to do so. What possessed Paragon to construct their system this way is beyond me to imagine.

There are no table-making facilities whatever. Zero. Zilch. This is an unbelievable state of affairs. Tables are not a luxury. I use them very often, not merely to display data but for such mundane things as making a syllabus, writing a resume, and making a question and answer appear side by side. Nisus has nothing, not even side-by-side paragraphs; all sorts of effects involving paragraph placement that in Word are almost trivial to attain are more or less impossible in Nisus. The manual mentions that you could, if you wanted, make a table in Microsoft Word and then import it to Nisus as a graphic. Hey, I think I’ll make a table in Microsoft Word and stay right in Microsoft Word. Get real, Paragon. And remember, I’m not asking for anything here that I couldn’t do with 128K using Gutenberg on an Apple ][c. Interestingly enough, Microsoft was shocked at the response they got to the addition of tables in Word 4.0. Apparently they had just though tables might be a nice way to format columns of numbers and since Word provided rudimentary calculation features, they threw in the tables, which were an immediate hit. Word’s tables still have some serious problems (such as not being able to split a row over a page break), and Paragon could win over many Word users with a killer table feature. Hint hint.

Since there is no such thing as a section in Nisus, you cannot vary the columnization of your document; either it must all be one column, or it must all be two, and so on – and your columns must all be of equal width.