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]
