Sunday, October 30, 2005 Nicolas Mailhot wrote: > Le dimanche 30 octobre 2005 à 09:13 +0100, Giuseppe Bilotta a écrit :
>> As I mentioned in one of the parts of my mail that you >> snipped, I have nothing against language selection in style. >> Why? Because language is a property of the text. True, it's >> not a property with an immediate visual feedback, but it can >> influence typesetting (by e.g. changing the hyphenation >> points and thus the overall formatting of the paragraph). > If language can influence typesetting then let's have it influence > typesetting, not the other way round like now. ie permit conditional > styling which I think it's clear by now is the only expressed need for > style <-> language interactions. > ie make the language field in styles mean "if the text is in this > language" not "set the text to this language" and have OO.o switch > between alternatives automatically (when this filed is set, allow > creation of sibling styles for other languages and define one default > style if the language condition is not met) If you allow me: that's a call for something absolutely clusmy to manage, even worse than what we have now. But please read further on for a more detailed explanation. >> I am not sure what you mean by language conditionals, OTOH. >> Something like: "if the language is Italian, format this >> way, if the language is not format this other way"? If this >> is it, the idea doesn't appeal to me very much, honestly. >> >> > With free cascading styles you'd have a better workaround for languages >> > than now, since you'd be able to short-circuit the macro step but it >> > would still be a workaround. Just consider what happens if someone >> > changes the language in your style instead of just changing the >> > formatting attributes -> instant content loss >> >> Why would someone change the language in any of my styles? > Because you can (usual stupid reason : if you expose a control to users > don't be surprised they'll use it). That's a rather silly argument, if you allow me. Of course people will use it. It's not clear why 'somebody else' would want to make such a change to *your* styles. Moreover, whatever other mechanism you put in place to assign languages to text sections will suffere from the exact same problem. Even your 'conditional formatting'. > And you can't do it sanely because you don't have the > affected text on-screen and can not check you're doing the > right thing. Excuse me? I'm afraid I'm not following you at all. Could you write down a step-by-step scenario? Who would change what when? To what purpose? Why shouldn't such a change occur and/or why should it be detectable and why? OTOH, if you agree with what I wrote at the of the email, there is no need for such an explanation :) > Honestly instead of continuing to avoid the issue and devise better > workarounds than the current workaround please all of you forget the > current implementation and focus on the two needs that have emerged : > 1. set the language of the text while typing, with possibility to change > later the langage of a selected part of the document if it has wrongly > been entered (later enhancements : sync with input methods, > autodetection routines, etc) > 2. have language influence typesetting (your words, not mine, but all > too true). This need is not limited to character styling, you can > imagine adding a small flag before §s for example. I have absolutely no problem acceoting these as being the issues at hand. I also think you are right that we should do so without getting hooked up with the current implementation. If you will allow me, I will rephrase them further down, hoping not to change their meaning. Just a little nitpick. > For me: > 1. clearly requires what you have been called hard-formatting in this > thread (it's not formatting, but it's certainly hard ie not mutable) > 2. calls for conditional formatting in my mind. > If you disagree here, please argue starting from the user need not the > current implementation. You can arrive to the "styles need to set > language" conclusion if you want to but please show how it will actually > help users to have it this way. I posit anything else than what I > propose will be suboptimal, as my proposal is a direct mapping of what > users been asking for. Believe it or not, this exactly what I've been trying to do all along :) Let me try to give you a detailed explanation of why I think that the current implementation, with the added ability of cascading (details to follow) solves all the language problems and more. Please make sure you read the email to the end before actually replying. It's a rather long email, but that's because I'm trying to explain in a very detailed way the rationale behind my suggestion. First of all, I think we can agree on one point: 'language' is a property of each section of text. When you write a document (even with pen and paper) you write it in one or more languages, but ultimately you can split this document in blocks and say 'these blocks are in language A', 'these other blocks are in language B'. These blocks may be as big as the whole document, or a single chapter, or a single paragraph, or a single sentence, or even a single word, but they will still be text blocks, text sections. Now, when writing on the computer, this property is important because it determines how to do the spellchecking, the hyphenation, the grammar checking and all these other things you use the language property for (I think autocompletion is also language-based? anyway ...) a. So when you write a document you want to be able to tell the computer (in some way we will discuss briefly) "I'm currently typing in this language" (your point 1 above); the computer should therefore mark the text you're writing as being in that particular language. And if you change language while typing, you want to be able to tell the computer (manually or preferrably automatically) that what's coming will be in another language. b. You also want to be able to select part of a document and say "this text is in this other language"; the computer is therefore supposed to mark the text you selected as being in that other language. c. You also want to be able to tell the computer: "Text in this particular language should appear this way" (for example: in italic; or: surrounded by small icons with the flag of the country; or whatever else); and you want the computer to do that for every occurrence of the text in that language. Does this describe precisely the needs you pointed out above? I think it does, and I hope you (and everybody else) agrees. The key point in all this is that: [A] Language is a property of the text So what we want is a way to assign this property to sections of text *without influencing all other aspects of it*: a paragraph should remain a pragraph, a title should remain a title, a footnote should remain a footnote, quotations should remain quotations and so on and so forth. I assume this is also something we can agree on. On the other hand you may also want (point c. above or your point 2.) to be able to attach 'visual feedback' properties that go together with this property that is 'language'. Second part of the explanation (I'm making it long so that you can pop up at any time and say "this is where I don't agree with you" and explain why). Let me take a tangent and describe this scenario. I am reading a nice book. It contains the standard text, divided into sections, chapters and parts. Some paragraph are quoted from other sources and they are typeset smaller, with tighter margins. There are also code listings (this is a book about programming). While I read it, I find some interesting words, passages, pieces of source code, so I grab my big yellow marker and hilight the relevant pieces of text. Great uh? The document is just the same but where I highlighted I have a bright yellow background. Now say that I am *writing* such a document. I have a few parts, each part with a few chapters and sections and subsections. I also have some quotations from other books, and source code listings. Each of these separate part of the document is appropriately marked up, and has its own visual representation: for example, chapte titles are centered, with a bigger point size; quotations have reduced margins and are written in smaller text; source code is in a monospace font. Now I want to highlight some stuff in this document, in the electronic version. So I want to be able to select some text and tell my word processing application: "this text block should be hilighted". What I *expect* is that the word processing application will put, say, a yellow background behind the highlighted text *regardless of whether it's a heading, a quotation or some source code*. Is that right? I want to change a *single* property (text background color) *without* touching everything else. And I want to do this consistently across the document (all highlights have this same yellow background) and I want to be able to change it consistently across the document if I change my mind (say I now want a blue background, because I found that some of the text was already written in yellow, or say I want to add a frame around highlighted text, too). Do you start to see the parallel between the 'language' property and the 'highlight' property? You want to be able to assign this property to sections of text, consistently, *independently* from the other properties, and yet be able (if we want) to give visual feedback of it in a way that is (1) consistent across property assignments and, again (2) independent of other properties. Let's *now* talk about implementations. Let's start from the 'highlight' property. *Currently* in OOo, if you want to create a style for highlighting you have to create ONE FOR EACH OTHER TEXT STYLE YOU HAVE, or you have to apply it manually. Oh wow, this is exactly the same problem we are having with language! But what if you could have a style that changes *one* (or two or three) text properties *without touching all the others*? BINGO! You suddently have *one* Highlight style that can be applied over text in any other style and it won't alter any property *but* the one which are characterstic of highlighted text. Substitute 'language' (which *is* a text property, and this is the reason why it's there together with all the other text properties in the Stylist!) for 'hilight' and you have *the exacty same problems* and *the exact same solution*. And the solution is called 'cascading'. I think that some people have a *semantic* problem with the name "Style": they automatically link the concept of "Style" with the concept of "formatting" and/or other *visual* properties. However, "Style" is just a generic term for "collection of properties" (collection which can be reduced, in theory, to a single property). (This is easier to understand for people like me that come from WordPerfect, where Styles are "collection of tokens", and you can have *everything* in styles, including text, images, and whatever else you want.) Now, let us assume the OOo programmers finally implement (in one way or the other) this "cascading style" concept. How does that help you or the other multi-language-writers? Let us say that you are writing a document in English (primary document language) and that there will be parts in another language (French, or Greek, or Russian or whatever you want). You set the Default style to have language English (this for both the Default paragraph *and* character style) and then you create a character style called "French_language", for example. This style will be a cascading style and the only property it will touch will be the language (set it to French). You assign this style to a certain hotkey (say, Ctrl+Alt+F), and you're ready to go. Whenever you want to switch to French, you press Ctrl+Alt+F and keep typing. Press it again and you get out of the style. Select some text, and Ctrl+Alt+F it gets marked as French. You want all French text to be in italic? Edit the style and add the italic property: all text in that style will be marked as French and be put in italic. This is exactly what we want. Of course, these things may need further improvements, but still regardless of the specific 'language' problem: for example, you can't currently assign Alt+character combination. I don't know how style hotkey works, but I'm not sure it acts as a proper toggle. And of course you want to be able to assign the style to the 'keyboard layout changed' event, so that whenever you set your keyboard to French the French_language style will be activated too, and switched off as appropriate. And these are further enhancement that need to be worked on. So I hope we can finally agree on these two things: 1. language in styles (i.e. as text properties) make sense 2. styles in OOo need to be improved by allowing cascading, hotkey toggling and other-event assignments Would you say that this solves all the linguist problems, and more? :) -- Giuseppe "Oblomov" Bilotta --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
