Jonathon Blake wrote:
Wolgang skriften:
The reason for the reveal codes is not to have a nice feature or a
"crutch" as one person indicated.
They are a crutch.
If WP had correctly implemented styles in the first place, there would
never have been a reason for reveal codes.
Within the context of WP's stream/token model, RC is sensible, useful,
and necessary.
This is fascinating; your argument shows every bit as much lack of
understanding as the OP's. And perhaps a bit more belligerence to boot.
For me time is money
Then take the time to learn to use your tools
You are acting like the drunk who is searching for the change he
dropped under the street lamp, when he actually dropped it in a dark
alley several blocks away.
And you're acting like a religious zealot. There's no reason to insult
people here.
and I am not interested to use it until I have the flexibility I have with the
reveal codes of WP.
That happened with the release of OOo 0.93, or earlier.
Remember WP is still in the market and those serious regarding the flexibility
of the reveal codes
OOo styles are at least 100 times easier to use, and more flexible
than WP with its reveal codes is..
In terms of functionality, OOo Styles are far more functional than WP
reveal codes/styles are. [The fact that one does not need to use
Reveal Codes, to see what is going on with one's text, is a testament
to the functionality of OOo, and the total dysfunctional of WP.]
I have to disagree. While on balance I believe the object/style model is
better and probably makes for more efficient program code, the
stream/token model is arguably more flexible.
With the stream/token model you can create a style that is a combination
of any keystrokes and direct formatting commands. With the object/style
model you're limited to whatever the program architects could think of
during the design stage. So, for example, in Writer it is impossible to
create a run-in heading style. It was decided in the design stage that
headings would be paragraph styles and that paragraphs would always end
with a carriage return. This could be corrected by either making
headings a kind of character style or giving paragraphs the option of
not ending with a carriage return, but either change would be terribly
difficult to implement at this stage and would probably break a lot of
other stuff.
As to your second point, Reveal Codes in Wordperfect does a lot better
job of showing you what's going on than Writer's Stylist. If I have a
block of text in Bold type, for instance, there is no way of telling at
a glance *why* the text is Bold. It could be a paragraph style, a
character style, or direct formatting. The only way to know is to place
your cursor in the text and see what happens in the Stylist and even
then you may have to highlight it all and Cntl+Shft+[Space] to get rid
of any direct formatting that may be there. In other words, what you can
see at a glance with WP and RC you can't determine in Writer without a
fair amount of screwing around in many cases.
What's really needed in Writer is function *similar to* RC, something
along the lines of "View Non-Printing Characters," that give you some
indication of what styles and direct formatting are applied throughout a
document. I'm not filing an RFE because I don't have a good notion of
what visually that should be. Color coding would be one option except
text color can be a style attribute in itself. That and I'm color blind
and _hate_ color coding on principle.
Maybe something in the margin for paragraph styles and DF along the
lines of:
_____
|
|
S: Text Body
D: Indent +5
|
|_____
and something similar in between the lines of text for character styles
and formatting.
_____S: Emphasis______ __________D: Bold___________
| | | |
some text that is in a style and other text directly formatted
Anyway, that's my idea, and it would likely satisfy the "Give Me Reveal
Codes or Give Me Wordperfect" crowd.
--
Rod
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]