To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=20878
------- Additional comments from [EMAIL PROTECTED] Thu Nov 29 09:07:44 +0000 2007 ------- This is mostly a report of the results of my experiments with MS Word XP and WordPerfect 10. These are probably not the very latest versions, but they’re pretty new. First, WordPerfect has some seriously convoluted and complex behavior. I think part of the problem is they don't have a soft-return (shift-return). At least not one I could easily find. Therefore, besides the really complex stuff they do to you when you stick more than two spaces between words, they also need two kinds of full justification. Also, when you have "show nonprinting characters" turned on, the last space on the line is only half a floating dot rather than a whole floating dot. I have no idea why they did this. The full dot and the half dot mean exactly the same thing (a space character) and I feel it's a mistake to complicate the UI in this way. Since I do not advocate the WordPerfect method, I decline to provide any screen shots. In contrast, MS Word XP is dead simple and very easy to understand. I made four identical paragraphs and diddled the line wraps within the paragraph so everyone could see how it behaves. Paragraphs are 4 lines each, 1st paragraph has extra spaces at the word-wrap site, 2nd paragraph has only single spaces, 3rd paragraph has single spaces but with soft-returns to break the paragraph up, and 4th paragraph is broken into four paragraphs using hard-returns (this affects justification). I used 12 pt "Courier New" font with a 6.52 inch wide text area. http://www.skunkwks.com/web/hidden/OOo/MSWordXP_word-wrap1.png This is the right-hand side of the four paragraphs. 2nd line of 1st paragraph has a whole bunch of spaces, but they are not all visible because some have "fallen off" the edge of the "paper"; if you happen to put your cursor out there (using the arrow keys) the cursor is not visible either; however, the cursor and the spaces exist and are out there, somewhere. The 1st line of the 4th paragraph has extra spaces before the hard-return; both hard and soft-returns can live in the margin, and even in the gray zone off the edge of the "paper". http://www.skunkwks.com/web/hidden/OOo/MSWordXP_word-wrap2.png Here I've selected all the text so you can see what Word's select box encompasses. This is very different than OO's current behavior. OO now simply makes a reverse-video box that fills up the text zone from left to right. Note that the extra-long line in the 1st paragraph is only reversed out to the edge of the "paper". I suppose it would be extra work to do a select box this way, but I feel the MS method is superior from UI point of view because it shows the actual selected text. However, the select box is not the real issue, and it's probably different code. http://www.skunkwks.com/web/hidden/OOo/MSWordXP_word-wrap3.png I've justified the text so that both margins are lined up. As you can see justification ignores the "dangling spaces" and goes off the last non-space character in each line. The last paragraph with hard-returns is not justified because each line is really a paragraph; the lesson is that if you feel you must insert returns, make them soft-returns so the system recognizes the lines belong in a single paragraph. You'll be happy to know that OO Write behaves like MS Word... almost; the exception is that when using soft-returns, if there is a space before the soft return, OO puts the space *inside* the text area. I feel MS Word's method is the correct one. For the 1st paragraph: OO Write justifies strings of spaces the same way MS Word does, which I feel is correct. http://www.skunkwks.com/web/hidden/OOo/MSWordXP_word-wrap4.png Here I've centered all the paragraphs. I've also turned off "show nonprinting characters" so you can see how MS Word ignores the dangling spaces and those hard and soft-returns when it figures out how to center the lines. It looks beautiful, doesn't it? OO Write does pretty good here, except when there is a return (of either type) and there is a space at the end of the line before the return, then it shoves the line over to the left... sometimes. I feel that nudging text with extra spaces is the wrong method to use in a word processor. A text editor, sure, but not a word processor. Personally, I'd rather see the MS Word method of *always* ignoring the width of dangling spaces and any returns when justifying text. It's simple and easy to understand. http://www.skunkwks.com/web/hidden/OOo/MSWordXP_word-wrap5.png Same view, but with all text selected. Both MS Word and OO Write treat the first two paragraphs the same and give perfectly centered lines. However, the paragraphs with inserted returns (hard or soft) behave very differently. MS Word *always* ignores the width of trailing spaces and returns, OO Write sometimes ignores them but usually not. For the 1st line of the paragraph, where the text exactly fills the text zone, if there is no space but only a hard or soft-return, the line is centered correctly and the return is in the margin. If you add any spaces between the last word and the soft-return, the line is centered properly, but the soft return is shoved down to a new line (and centered), thus you get a blank line. If you add any spaces between the last word and a hard-return, the line is centered properly and the hard-return remains glued to the end of the line (and the spaces don't show, although they are there). Consider the 2nd line of the paragraph, where the line does not fill up the text zone. As you add spaces between the last word and the return the line is shoved a bit to the left until it fills with spaces, then they suddenly vanish and the line pops back to being centered again. Now with a soft-return the soft-return character is shoved down to its own line, but with a hard-return it stays on the original line and snuggles up against the last character of the last word. Of course the spaces are there in both cases, but we can't see them. To answer some of the more recent comments: Should we have a "magic mode" where spaces in the margin are always shown, irregardless of the state of the "show nonprinting characters" button? Absolutely not! Why? Because when I want to see the spaces (or other nonprinting characters) I'll turn on that mode. And when I turn that mode off I don't want to see nonprinting characters. No exceptions, ever. It breaks the WYSIWYG paradigm to do otherwise. Should we have more than one type of character to show spaces (when the "show nonprinting characters" is on)? If we're talking one space = one character, no! The WordPerfect paradigm is just plain weird and seems senseless, plus someone has to write and maintain extra code. If you mean a "fat space" to show a gob of spaces, maybe. However, consider the MS Word paradigm where you just let single spaces dribble off the edge of the "paper". Sure, it might be inconvenient if you've got 7,000 spaces in the middle of your paragraph, but how often will that happen? Should we wrap after typing two spaces, then allow new spaces to go on the next line? Absolutely not! WordPerfect does that, sort of, but then it provides several tricks to get around it (e.g. type three spaces, then backspace, type three more spaces, then backspace, etc.). First, throwing a string of spaces into a paragraph is going to almost never be a requirement as long as the user is using OO Write like it's a word processor and not a text editor. I think MS Word has the right approach: If for some bizarre reason there happens to be a bunch of spaces in a paragraph, and they run into the word-wrap area, stick them at the end of the line. *If* the user really does intend to manually monkey with formatting (maybe they are trying to stick spaces at the beginning of lines in a paragraph) then they should insert soft-returns at the end of each line. It'll be far less trouble for them to maintain the document that way. Besides, OO Write now sticks the extra spaces at the end of the line--the issue is that it doesn't show them. About barryii's down arrow widget. I'm not sure that's needed. First, as fme has rightly pointed out, my idea to snap the cursor and pilcrow down to the next line before the user types a non-space character, sucks. So I've abandoned the idea. It isn't that your down arrow widget is a bad idea, but I don't think it's needed to fix this particular problem. About MS Word and cursor position while entering fresh text/editing existing text: When entering new text, that is there is a pilcrow just to the right of the cursor, you can push the cursor and the pilcrow into the margin by inserting a bunch of spaces. In fact, you can push the pilcrow and cursor right off the edge of the "paper" and into the gray "never never land" that exists somewhere to the right of your monitor. As soon as you type your first non-space character the new character, cursor, and pilcrow all pop down to the next line. Clean, simple, intuitive. And best of all, you don't start sticking blank lines below paragraphs. When editing an existing paragraph, you can set your cursor at the beginning of a line, just in front of the first character. However, you cannot set your cursor at the end of a line after the final space on that line. It really is the same place in the string of text, so pick a spot. Normally this is fine if you decided you needed to insert a word. You'd start by typing a non-space character and all behaves as expected. BUT if for some weird reason you try to type a space at the beginning of a line, it flies up and sticks to the end of the previous line (and the space already there). Some may find that a bit weird, but it does fit the simplified rules of word-wrap that MS Word seems to use. MS Word and tabs: You cannot stick tabs in the right margin in MS Word. I know, I suggested it a couple of days ago, calling a tab nothing more than a variable width space. However, it probably wouldn't hurt to mimic MS Word behavior. So, when you push the cursor into the margin by typing a few spaces, you can hit tab and the tab will fly down to the new line. For those who feel they must manually diddle format with characters (perhaps they miss edlin (which is vi for DOS, but far more primitive)). This could be an alternative to inserting soft-returns. Thoughts on justification and text centering, mentioned above: Everything is deeply intertwingled. Based on my brief experiments with OO Write and centering text, I'm going to make wild guess that text justification and centering *relies* on visually hiding the spaces at the end of lines. So when someone unhides those spaces, all kinds of ugly is gonna happen to people's documents. Therefore, the justification and centering routines will probably need to be tweaked too. For consistent and robust behavior, the MS Word model is hard to beat: Always ignore the width of dangling spaces and returns when doing justification and centering calculations. Mostly this will work, even with old documents. Where it fails is where some people have jammed a few spaces at the end of a short paragraph they wanted centered. Example: Let's say I'm writing a novel. I have a custom paragraph style called "manuscript" and this style includes a first-line indent. When I get to a scene break, I type "# # #" in a new paragraph by itself, and I want it centered on the line. If I was a newbie I might select the paragraph then click the "center text" button. Except it wouldn't be quite centered because of the first-line indent. One newbie way to fix this is to put a few spaces after the last "#", to shove the whole mess over to the left a bit. Of course the best way to fix it is to create a new style and maybe call it "manuscript centered". Now using that newbie method to tweak centering, we could break those tweaks if OO Write v3.0 starts ignoring dangling spaces. How bad does this hurt the user? Well, the information is all there and all visible. It's just not quite as pretty as it was before. And the reason it's not quite as pretty is the user used a poor technique in the original document. If it were up to me, I'd say, "Go for it. Don't look back, and don't create exception code." The cost of failure is low. That's about it, I think. Legal stuff: I'm not even gonna mess with a CC license on those screen shots. They are public domain, but please don't hot link. The text is a mashup of Kennedy quotes and an old nursery rhyme. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
