HT has even more ambiguous semantics than you indicate. We did a survey a
few years ago of word processors and desktop publishing programs, and
found a wide range of different behaviors. Suppose you have a set of tab
stops, e.g. at 12pt, 36pt, 72pt, etc. You also have a string of text
containing tabs. The tabs in the text divide up the text into a list of
tab fields (the text between tabs). There are four problematic
situations.
1. A tab field would touch or overlap a previous tab field if placed at
the tab stop.* Possible behaviors we observed here were:
- go to the next tab stop
- go to the next line, at that tab stop.
- go to the next line, at the start
- ignore the tab, treat it as a space, and merge with the next tab field.
2. There are more tab fields than tab stops. Possible behaviors we
observed here were:
- go to the next line, at that tab stop.
- go to the next line, at the start
- ignore the tab, treat it as a space, and merge with the next tab field.
- manufacture implicit tab stops past the end, e.g. at every 36 points,
or at every 8 em.
3. A tab field would exceed the paragraph margin. Possible behaviors we
observed here were:
- go to the next line, at the start
- go to the next line, at the first tab stop.
4. Tabs are used in non-left flush lines (e.g. with centered or
right-flush lines). Possible behaviors we observed here were:
- ignore the flush setting on the line.
- apply the flush to just the first tab field.
- apply the flush to just the last tab field.
- lay out the tab fields as if the text were left-flush, then shift the
entire line to center or right-flush it. (This comes up with pretty
random looking tabulation.)
Some DTP programs, despite our best efforts to figure out the rules they
were using, appeared to be pretty random in their behavior. This is
especially the case with #4.
* Overlap (#1) does not only mean that the tab field is too big for the
tab stop; it also happens with mixtures of left, right and center tabs.
Look at the following example, where '[' means left tab stop, and '|'
means centered tab stop, and '~' means tab (and use monospaced font to
see properly):
[ |
aaaaaaaaaaaa~bbbbbbb
The bbbbbbb text can't be placed at the centered tab stop properly
without overlapping the aaaaaaaaaaaa. Overlap can also happen when the
second tab field is centered or right flush and is so large that it
overlaps with the left margin.
Mark
Tony Harminc wrote:
> On 6 Jul 99, at 10:25, John Cowan wrote:
>
> > As for HT and FF, nobody uses them incompatibly, and
> > introducing new characters for them is supererogation at best.
>
> Actually the question of HT and FF is the most bothersome one, for
> me. There are (at least) two problems:
>
> HT and FF both depend in some sense on the user's environment, e.g.
> page length (paper size if the "rendering engine" is a printer or
> hardcopy terminal), and tab stop settings.
>
> HT has ambiguous semantics when the HT occurs when the cursor is
> already at a tab stop. If the cursor got to a tab stop because of an
> HT, then there is no argument - another HT moves to the next tab
> stop. But if the cursor got there because of ordinary, implicit
> movement, then some systems ignore an HT (i.e. stay in the same
> place), while others move on to the next stop. Granted, this is
> mainly a problem of input methods rather than data storage or
> interchange, but I don't think it's quite fair to say that no one
> uses HT incompatibly.
>
> Tony H.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:48 EDT