Giuseppe Bilotta <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> This is a long reply, so please read it through before
> replying to it :)
>
> Let me reply to these two paragraphs at the same time. The
> main difference between manually (or macro) applied
> 'formatting' (and I'm including language in this because
> it's a property which is handled at the same level as actual
> visual formatting in OOo) and formatting applied via styles
> is that the former, once applied sticks there, while the
> second can mutate by changing the style. Hence the
> difference between 'hard' and 'soft'. In some way, the first
> is 'carved in stone' whereas the second is only 'indicated'.
>
Yes. I entirely agree with this. We do, I think agree what we
are talking about and that the difference between a style and a
hard format is that the style is editable (even though the
individual attributes making it up are not) and that these
changes apply retroactively, to so say, across the whole
document.
> An obvious remark is that text in a foreign language is in
> that foreign language, full stop. It's highly dubious that
> you could have second thoughts ("hm, maybe this isn't
> Russian, maybe this is Japanese") and have such second
> thoughts consistently across all occurrences of that
> language.
Agreed
> *However*, taking your example ("different font
> for Swedish text") is exactly the reason why it should
> nevertheless be part of an appropriate style, and not be
> applied manually (or macroly): if halfway through a document
> to decide, or otherwise need, to set all the foreign text
> in a different font (or with a different font property,
> typically in italic), you can of course change the macro,
> which will work for all the *future* text, but it won't
> change all the text you already typed in. This is *exactly*
> what styles were made for.
Agreed - 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.
Obviously, nobody wants to have to write a macro to do this when
styles are a much easier way. But what I am thinking -- and I
hope this is a clarification rather than a disagreement -- is
that someone could put a pretty front end on the process, just
as with normal styles. It wouldn't look or feel like writing a
macro.
> Let me clarify one thing: I have no objection to your macro.
> Actually, I would go as far as saying that your macro (or
> more probably a more exhaustive and customizable successor
> of it) is *the* correct /*WORKAROUND*/ for a limitation in
> OOo: the inability to cascade character styles.
>
> Just to make my point even clearer: I have *no* objection to
> 'language' being treated at the same level as fonts or
> whatever; it is, after all, a textual property, albeit not
> an immediatly visual one (since in really it influences
> hyphenation and hence ultimately typesetting). My gripe is
> with OOo's inability to cascade styles. Your usage of macros
> is a barely functional (although /the/ optimal one, given
> what we have) workaround. The limitation in OOo remains, and
> IMHO *should* *be* *addressed*.
>
Agreed.
> 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 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.
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.
--
Andrew Brown
The email in the header does not work.
Contact details and possibly useful macros from
http://www.darwinwars.com/lunatic/bugs/oo_macros.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
