Andy Pepperdine wrote:
For the record, now I see what RC's are, I think I would not like them. Styles
encourage me to think before acting, to plan the layout of a document before
writing it. I can define header styles, normal body text styles, indented
text for quoted English text, and indented paragraphs for a foreign language
which would show also be italic. Emphasis in the English is shown by making
the text italic, but emphasis in the foreign language is normal. What would
RCs show in the latter case? I would think in terms of emphasis; I would
expect them to say "turn on normal". Or would they actually say "turn off
italic"? How do you keep track of the actual state of things from the
beginning of the document? All those ons and offs. Whereas with a style which
I have defined, I know what the state is at any place at all, and if I want
to change it, just select the text, and apply the style. Easy. And if I
decide to change the way emphasis is shown (eg. by underlining), then I have
only to change the styles and not find all the places in the text which are
emphasised.
But WordPerfect reputedly does support styles. I have not used it myself
for years, which is why I say "reputedly". The version I last used many
years ago did not support styles.
But numerous text processing formats such as LaTeX and XML (including
the new Oasis Open Document Format that OpenOffice.org now uses,
certainly do reveal code tags all over the place.
And although there are no code tags worth mentioning used internally by
either MS Word or OOo Writer, that doesn't prevent many users from
avoiding styles altogether. Indeed, there are LaTeX users who avoid
styles as much as possible.
The issue is not, and never has been, one between use of code tags and
use of styles. Use of one has nothing to do with use of the other
The difference has to do mostly with maintaining state, with the fact
that coding has difficulty in being layered.
Generate a Postscript or PCL printer file to produce 10,000 pages,
perhaps personalized subscription renewals. Print the file. At around
record 10,500 the printer operator notices that smudges are appearing on
the pages. The operator stops the printer, cleans it, and then starts it
again, and as it continues to print, the operator puts aside the section
of pages that need to be reprinted, perhaps pages 10,400 to 10,500.
To reprint, the operator tells the system to jump to page 10,400 in the
file and print 100 records from that point. However what the printer
system actually does is start at the beginning of the file because it
has no way of knowing what internal values to set at the beginning of
page 10,400 without first doing an internal dummy print of every page up
to that point. For example, assuming this is a PCL file, perhaps page
10,405 contains a vertical tab command. Perhaps the vertical tab
channels are being set and reset several times in the file. The only way
to be assured that what is output is correct is to always start each
time at the beginning. And indeed the system can't even find page 10,400
for certain without starting at the beginning and counting.
So the operator watches the screen as the system chugs away for a while
until reaching record 10,500, at which point it actually begins to print.
The same is true of a text processing system "printing" to a display
screen.
One way linear processing not much of a problem if we are sequentially
previewing a document, especially a short document. But if we want to
jump around in it randomly, go to page 56, then to page 200, then to
page 5, and want to edit it while doing so, it would become annoying if
every time we attempt to jump backward or scroll backward, the system
hangs while reformatting the entire text from the beginning.
(With short texts the system may be able to keep the entire document in
memory, but not with long texts, especially not 10 or 15 years ago.)
And even when jumping forward, it would be nice not to have to wait for
the formatting to catch up.
The general answer for this is to maintain state throughout the entire
document for all attributes applied to the text, so that at any point in
the text the display system can immediately obtain the current margins,
line spacing, character spacing, indents, font name, font size,
character formatting effects and so forth without having to recalculate
the state of these attributes at that point in the text by going back to
the beginning of the file.
How the maintaining of state is done is irrelevant.
In this kind of system, when a change is made, such as bolding some
text, the system updates the state of bolding in following text as
necessary. If the bolding is done by inserting a bold-on character,
state of the text is set to bolding on from that point on until a
bolding-off token is encountered.
So when jumping from one point in the text to another, the display
system does not look at the codes at all, but instead at the various
properties of the text which have been internally generated by those
code. This is presumably what WordPerfect is doing.
But then ... if the display system doesn't need the codes, why not get
rid of them altogether? Instead of inserting code tokens that change
properties in a range of text, why not directly change properties in a
range of text without worrying about codes?
Let the user change the properties directly and throw out the codes
altogether internally.
This is much simpler.
Instead of two levels of formatting representation, a code tag level and
an attribute level, there is now only one level to worry about, both for
the system and for the user, no orphaned italic-off codes muddling up
the text, no wading through masses of codes to find out what the exact
line spacing is. Just go the paragraph properties at any point and see
what the line spacing is. And if you want to change this line spacing,
select a range of text and change directly those paragraphs without
unnecessary codes being generated at the beginning and end of the range
of paragraphs, codes which the system really doesn't need in any case.
But none of this has anything to do with whether a particular user is
setting text attributes through styles or direct formatting. It has to
do with how text can be most efficiently processed within word processor
memory.
Of course, when you save the text to a file, then formatting codes are
necessary, at least if you want to create a source file that is
reasonably easy to understand by humans.
Jallan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
