Joe Hogan wrote:
Hello,
THis discussion should really be moved to discuss or social. However, I
see that some of you really like WP so I thought that the following
might encourage you to accept OOo as it is and go on to other more
important things.
While you might bringup a point that this 'seems' to be dragging along, I
disagree that we should have to move on. A list like this is to discuss the
usage of the software, and discuss improvements.
Will these ideas be brought forth to the developmental stage, I hopeso, but
unless it is deemed important enough, it might not make it.
Your argument of accepting it because of prices of WP, well, we could just
accept Microsoft Office and accept the prices. Bad argument.
I personally has used styles, but styles do not always apply in all cases.
So, we must use the bold, italics, etc... So, this is where reveal codes
would come in handy.
First, you can use styles in all cases if you want. (I will admit in
some cases it is quite reasonable not to want to.)
Second, since OOo Office does not use codes internally, there are no
codes to reveal. Internally bolding is set directly as a formatting
attribute on a range of text, not through code tokens. If you select a
range of text in your document, and apply bolding, then a text range
object is created which points to that portion of text and contains,
among other attributes, the attribute bold.
No codes, whatsoever to reveal. So how does reveal codes come in handy?
And you can see the bolding right on the screen in any case.
As for being stuck with the features as is, lets bring this up to the people
that do the development. Reveal codes is a valuable tool, and many people
have grown to like it.
Why is reveal codes valuable? Because in a text processing system that
uses internal formatting codes embedded in a text stream it helps in the
understanding what is going on. And it helps to be able to fix things at
a more basic level than the normal display mode shows.
But how are reveal codes valuable on a system that doesn't use internal
formatting codes embedded in a text stream, when they are no formatting
codes to reveal other than those that may appear when you use View ->
Nonprinting characters?
In OOo Writer, if you do want to see the low-level formatting attributes
applied to a paragraph, use Format -> Paragraph. What you see are the
current settings in memory for that paragraph object which you can
change directly, just as you would change codes if there were any. In
OOo Writer, display routines use those values in displaying that
paragraph, just as they would use codes, if there were any formatting
code tokens, which there aren't.
Select a range of text, and use Format -> Character to see directly the
formatting attributes of that text. Then change anything you like. The
text you selected will now be a new object in memory with the attributes
you have chosen. But there are no codes, only settings (attributes)
attached to that particular text range object.
In WordPerfect a particular formatting code can turn on bolding and
another turns it off. But the text between then gains the bold
attribute. What OOo Writer and most other word processors do is apply
the bold attribute directly without inserting unnecessary code tokens in
the text stream to turn it off and on. The system knows whether a
particular stretch of text is bolded or not in other ways, by keeping
track of the points where any formatting changes.
Note ... I have not brought styles into this at all. This is all direct
formatting.
A style is simply a way creating a bundle of attributes that you can
more easily apply all at once, and then change all text or paragraphs or
pages to which the style is applied. But a style just sets the same
values you can set yourself with direct formatting, and does it in OOo
Writer and MS Word without using or needing any formatting codes.
I believe that instead of saying that it is not possible because of the way
OO is structured, that we talk to the programmers to work out a solution.
A solution to what? The unshakable but totally incorrect belief of some
WordPerfect users that that there must be formatting code tokens used
internally in every other word processor?
What do you really want to do with codes, that you can't do now with
direct formatting (or styles)? Many of the problems that a formatting
code systems have such as orphaned closing tokens, accidental deletion
of a token character, and so forth cannot exist in a system that doesn't
use formatting character tokens. You can't delete what isn't there. A
simplified system that does without these codes also avoids the kinds of
problems which they cause.
What we could use, as myself and others have discussed, is better tools
for debugging, including perhaps a tool that would portray the
underlying structure of a Writer paragraph in memory, including a map of
the text ranges with quick ways to reveal the actual formatting
differences between such ranges and providing information as to which
attributes depend on the style applied to the paragraph, which
attributes derive from a named character style, and which attributes
derive from direct formatting.
There would be value in a mode that portrays underlying aspects of text
display not visible in the normal mode, but they must be the underlying
aspects that matter in OOo Writer.
Should this discussion continue. Perhaps not.
Yet, this forum is supposedly to aid users with problems, not discuss
operating systems. But problems that arise with OpenOffice.org (and
other software) often partly derive because users misunderstand what is
going on ... for example the common misunderstanding that because OOo
icons appear on .doc files that the files themselves have been sometimes
converted, the confusion that often arises about language attributes,
the common expectation the a change in Page format should be global.
A difficulty many WordPerfect users have with other word processors is
they approach them with the wrong model in mind. Their very experience
is in some ways more likely to hinder than help compared to a new user
of OOo Writer of MS Word, because so much of what they think they know
is absolutely wrong. Of course, they then blame the stupid word
processor. Whereas using dialog boxes to set formatting is in
WordPerfect a high-level function, in that it sets underlying codes, OOo
Writer this is most a low-level function the sets values directly in
memory. WordPerfect users think they are being kept at a high level and
away from the the low level because they do not have a reveal codes
mode, when in fact OOo Writer lets users access the system at a lower
level than WordPerfect.
Perhaps there should be some help documentation specifically pointed
towards WordPerfect users, pointing out how exactly how different Writer
is underneath, that it doesn't have a reveal codes mode because it
doesn't use codes, but that viewing and changing values through
attribute dialog boxes is a low-level function, at the same level that
manipulating code tokens is in WordPerfect, indeed below that level.
Such a document would have to be written by someone versed in both
WordPerfect and OOo Writer. It would be helpful to be able direct
WordPerfect users to such a document which would have examples of how
debugging at a low level is done on a system where you aren't kept away
from direct formatting by a formatting codes level.
Jallan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
