Saturday, October 29, 2005 Andrew Brown wrote:
Yes. I entirely agree with this.
[snip]
Agreed
[snip]
Agreed
I love it that we are not talking at cross purposes :)
but this retroactive change is _also_ something that
can be simulated by a macro; I suspect that this hypothetical
macro is merely reproducing the internal logic of OOo: when a
style is changed now, the program must search through the whole
document for text to which that style has been applied, and
apply the new definition. IIRC, one of the first examples in the
developers' guide is how to change character formatting
throughout a document. All my hypothetical macro does is to
replicate this process.
The problem of manually (or macroly) changing chracter
formatting is that there is always the possibility of false
positives (at best): things which are formatted the same way
but shouldn't be changed because they are of a different
'hard styling'. Anyway, editing styles does not involve any
form of search/replace through the document, since styles,
in a way, a re just pointers; so when a style is changed,
the only thing that gets changed is the area that contains
the style definition: all the pointers to that area remain
unchanged.
The next question is: is there already an issue on this?
Should we create it? Note the the issue should be on the
cascability (ehehehe) of (at least character, but I would
also say paragraph) styles, not so much specifically on the
management of language; indeed, allowing cascading styles
will solve the language issue *and* a bunch of other
problems.
I don't know if there is anything in IZ. It's something that
might get into 3.0. I quite agree that the central problem is
cascading styles. The mechanisms are certainly there in the API
to implement them.
I surely hope so, but I would like to have the dev's word on
this :) I'm especially interested in knowing if the ODF has
support for such a thing. I'll see if I can find the time
for a simple test.
I don't think, though, that they should entirely replace the
present sort. Both have advantages and disadvantages.And if we
do have both, there is potential for even more user confusion
than styles presently cause.
Well, we could think of two ways to do it: have both
cascading and non-cascading styles, or have styles of one
kind and choosing at application time if it should be
applied cascadingly or not.
However, I honestly don't see the need for non-cascading
style: a style which is not supposed to inherit from the
surroundings should just set the non-inherited property
itself.
Cascading could even be taken as far as the inheritance in
the current style hierarchy mechanism, by allowing more than
one Linked to, the order of linking giving the priority of
the formatting.
This opens a door to some amazing styling enhancement.
It does seem to me a prime example of the sort of thing which
could be written as an extension, and tested like that, by
interested parties.
I have absolutely no knowledge of how this things work so
I'll just take your word for it :)
--
Giuseppe Oblomov Bilotta
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
