To get started using Hobo, perform these steps:

Now try opening one of the Hobo examples, such as /PCedar/Hobo/HoboLimits.tioga. Use the NEXT key (R12) to select an entire Hobo expression. Use CTRL-H to view the resulting Hobo artwork. Select the Hobo character, called a BoxChar, and click on CTRL-SHIFT-H to view (in a separate window) the Hobo expression corresponding to a given Hobo character.

Tioga is an able text editor, with provisions for user extensibility. Hobo takes advantage of one of these, Tioga's Artwork character capability, to provide facilities for material requiring two-dimensional layout, especially mathematics and tables. Because of this retrofit to Tioga, Hobo is not (yet) direct manipulation WYSIWYG, nor does it always do everything you would like automatically.

Hobo involves four components: the rendering interface to Tioga using TiogaImager boxes within Tioga Artwork characters, which I call BoxChars; a language for specifying what should appear in the BoxChars, which I also call Hobo; a nameless mechanism for extensible glyphs such as large parentheses; and a newly developed layout formalism I call Crossties, which is extremely powerful.

Crossties computes layout positions by solving a large quadratic programming problem, which it does in a way specially tailored for efficiency. From a consumer point of view, Crossties provides a variant of TEX's boxes-and-glue metaphor, and acts like an assembly of blocks and springs spread out in two dimensions. However, you are also allowed to specify, for example, that some columns of a table should have the same width.

By now it should be clear that Hobo is neither trivial nor complete (otherwise I wouldn't bore you with implementation details). What it is, is useful.

My research papers require mathematical notation such as integrals, summations, fractions, and matrices; Hobo can manage all of these, both as run-in text and displayed equations. It provides less direct manipulation and WYSIWYG ability than most of Tioga, but much more so than TEX.

Hobo can handle a very flexible form of table, essentially the generalized grids Rick Beach described in his thesis. Tables can use horizontal and vertical rules of definable thickness, and colored background fills. The Crossties block-and-spring layout formalism allows tables to adapt themselves to the dimensions of their contents, requiring less user involvement than ViewPoint tables.

Anything you can put inside a Tioga document, you can put inside Hobo; this includes graphics, paragraphs, and more Hobo, recursing as much as you like. Specifically, tables can include mathematical formulae and nested tables.

Documents using Hobo will look pretty boring unless you have Hobo in your load state, and have turned Artwork on; otherwise, an entire table will look like a single character! To activate Hobo, you simply type

to the PCedar Commander. In addition to providing Tioga the display machinery for Hobo Artwork characters, running Hobo defines three new Tioga operations: MakeBox, StuffBox, and ViewBox. These are used for creating and editing Hobo material.

If you have the Hobo TIP table layered in (using the "Tioga.TiogaTIP" profile facility), editing can be keystroke economical.

Some folks who use a variety of keyboards and systems prefer to use [CNTL]-H for backspace. They will have to create their own TIP table by modifying Hobo's definitions. One possibility is to define the EditTool's Command-1 and -2 as "MakeBox StuffBox" and "ViewBox", respectively. These can then be invoked by typing [CNTL]-1 and [CNTL]-2.

Because of a lingering implementation weakness, Hobo sets the dirty bit of a file when it is first displayed. This is not hard to fix in the code; meanwhile, get used to seeing the "[Edited]" flag come on for files you've just opened.

Hobo has a primitive input syntax, which human beings should be spared the sight of; unfortunately, that's left to the Grand and Glorious Future. Meanwhile, there are some handy abbreviations and some examples to help you along. Thus, for example, to put a fraction in your document, you merely type "hobo.fraction", type [CNTL]-E to expand the abbreviation (assuming Tioga finds the "hobo.abbreviations" file), fill in the blanks for numerator and denominator, and type [CNTL]-dblclk-H. Notice that you are responsible for any special typographical attributes, such as italics, Greek, or small characters.

You are also responsible for adjusting Tioga's line spacing, since there is currently no working mechanism for Tioga to adjust line spacing based on the size of the characters in a line. (But stay tuned for possible future developments.) This is, if I do say so myself, a terrifically irritating nuisance, especially since Screen style and Print style can require somewhat different adjustments. I apologize for the inconvenience; I would love to have a fix yesterday.

One of the peculiarities of Hobo's language is that the text that goes in boxes, like the numerator and denominator of a fraction, is given as a complete nested node (or list of nodes) immediately after the equals sign. If a Hobo character follows immediately on the same line instead, it is taken as the box for the argument, predigested as it were. In contrast, numeric arguments such as spacing values (always in points), are always given on the same line. Just follow the example of the abbreviations and you should have little trouble.

Hobo will set multi-line text as a paragraph, using a width that may not suit you. This is rarely an issue in mathematical formulae, but can be a problem in tables. You can chose a paragraph width yourself using a Postfix property of, say, "3 in lineLength" on the node.

Tables have an arcane syntax all their own. I was in the process of replacing it when my term expired; sorry. Remember that tables are not really tables, but free-wheeling grids, and you'll appreciate the notation more.

Three kinds of items make up a grid: entry boxes, horizontal and vertical rules, and background fills. The placement of each item is specified by two reference points, the upper left corner and the lower right corner. Each point is at the intersection of two alignment lines: a horizontal "level line" and a vertical "plumb line". These lines are numbered starting with 0 at the top left corner of the grid, and increasing to the right and downward. Thus the first cell in the grid has position "0@0,1@1", meaning it lies between level lines 0 and 1 and between plumb lines 0 and 1.

When typing these beasts in by hand, you can allow most of this to default. The bottom corner will offset automatically for a single entry, and the top corner will increment automatically across entries. In common cases, this means you need only explicitly give a single number for the start of each row, since by default the top corner increments by 1 horizontally with each new entry. You can change this behavior by setting rowStep and colStep; for example, you can set both to 1 for a diagonal matrix. Explicit positions will override the defaults, so a free use of the grid just requires more typing.

Rules will normally have either both horizontal or both vertical lines the same, but this is not enforced. The argument value for a rule gives its thickness in points. For a fill, the value is a gray level. (I haven't figured out how to get Tioga to parse color specs for me; Both rules and fills should eventually be colorful.) I have found a gray value of 0.1565 to work well both on the screen and the page. To specify a fill, you follow the position with "/f"; to specify a rule (a grid separator), you use "/s".

Hobo can align grid entries in a number of different ways, both vertically and horizontally. The desired alignment is given by following the position with a slash and one or two letters. Since horizontal alignment between plumb lines is needed more often than vertical alignment, a single letter defaults vertical alignment to use the text baseline. Horizontal alignment can be natural (n), left (l), right (r), center (c), decimal (d), or character ('+ for example). Natural alignment differs from left alignment if the box extends to the left of the origin of its box; left uses the bounding box edge while natural uses the box origin. Character alignment can use characters including backslash syntax, such as '\020. Vertical alignment can be natural baseline (n), top (t), bottom (b), or center (c). Since most text has decenders, natural alignment is the default, and uses the origin of the box. If two letters are given the first is for vertical alignment; for example, "0@0,2@1/tc=" means an entry lying between plumb lines 0 and 2 and between level lines 0 and 1, aligned at the top of the entry bounding box vertically and at the center horizontally.

Grid alignments can get pretty wild. Remember that there are really no rows or columns internally, only level and plumb lines. It is perfectly acceptable to have a column with some entries right aligned, some centered, and so on. You will probably be satisfied with the results. You can also have entries that span multiple columns and/or rows, also with centering and the like. This is the sort of thing that makes the Crossties machinery happy, though it does take longer if there are lots of overlapping spans. (For most tables the majority of the overhead is in parsing, not layout.)

Actually, there are implicit alignment lines bracketing the separator lines, both to provide space between entries and to allow for the width of any rules. Thus left and right aligned entries do not usually touch the true edges of a column, though they can be made to do so. Fills, on the other hand, do go all the way from edge to edge.

Ultimate ugliness in interface design is found in the variable glyph mechanism. This was one of the first parts implemented, and it shows it; it was never intended as a final solution. Basically, you must manually set the Artwork property of the character to "Hobo", and also set the "reach" property to some satisfactory number for the height of the character in points. If hard copy will be important, remember to make sure that everything looks okay in Print style, which can differ considerably from Screen style in size and appearance.

Hobo is extended by registering new box makers. The box makers currently built in are:

Each of these takes arguments, some of which you will probably never use. Consult the abbreviations file for guidelines. If you must know more, you can always consult the code in HoboImpl!

In my opinion, it should be possible to mate Hobo with Eric Bier's buttons and produce a more civilized WYSIWYG interface. There is really no good reason for Tioga to limp along without mathematics and table abilities. If you'd like to see Hobo fulfill its destiny, try using it as is, and let your lab manager know you want more. Of course, you could always use a Macintosh.