Description: Typing before a formatted word does not formatting but it does when word is at beginning of the line Steps to Reproduce: 1. Open the attached file 2. Type something before NOP -> will be formatted 3. Place cursor before DEF and type something.. no formatting Actual Results: No formatting when typing before DEF formatting when typing before NOP Expected Results: Personally typing directly next to a formatted word should add formatting Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.alpha0+ (x64) Build ID: 97a2c1fc5e376c0c00968f17a0392c6d3a5ed565 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: threaded
Created attachment 160569 [details] Example file
Same occurs in a table.. typing before the first (formatted word) will apply formatting
Reproducible on both stable and pre-released version. Version: 6.4.3.2 (x64) Build ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: GL; VCL: win; Locale: en-GB (en_GB); UI-Language: en-GB Calc: CL Version: 7.0.0.0.alpha1 (x64) Build ID: 6a03b2a54143a9bc0c6d4c7f1... CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: en-GB (en_GB); UI: en-US Calc: threaded
Could imagine users expect the formatting to stay when typing at the beginning likewise at the end. So unless there is a good reason not to do so, let's change this.
(In reply to Heiko Tietze from comment #4) > Could imagine users expect the formatting to stay when typing at the > beginning likewise at the end. So unless there is a good reason not to do > so, let's change this. Just a second! Anything "before formatting" - which is not at the beginning of a paragraph - is also "after formatting". The text looks like this: [<empty property set>text of 1st span ][<bold>bold text of 2nd span][<italic>text of 3rd span]... And so, if you consider a place *after* a formatting as to continue previous formatting, then you need to realize that place just before 2nd span is *after* 1st span, and necessarily continues its (empty - in this specific case - but anyway) formatting. When you have a span starting at the very beginning of the paragraph, there's no previous span to continue. So - "let's change this" is a bit too quick.
(In reply to Mike Kaganski from comment #5) > Anything "before formatting" ... is also "after formatting". That's true. So if the DF or CS has no DF/CS before we continue to before/left, otherwise we keep the formatting after/right.
(In reply to Heiko Tietze from comment #6) > So if the DF or CS has no DF/CS before we continue to > before/left, otherwise we keep the formatting after/right. That won't work. Besides the awful idea to multiply special cases, the idea of "no DF/CS before" is wrong. E.g., on platforms where system input language is taken into account (Windows = >90% users), every keyboard layout switch changes the language - that is DF. Just DON'T do that. Typing should always continue what's to the left, unless there's nothing to the left. That's consistent, and doesn't need any special-casing.
(In reply to Mike Kaganski from comment #7) > Typing should always continue what's to the left, unless > there's nothing to the left. That's consistent, and doesn't need any > special-casing. Reasonable statement, let's close the ticket as WFM.
(In reply to Heiko Tietze from comment #8) > (In reply to Mike Kaganski from comment #7) > > Typing should always continue what's to the left, unless > > there's nothing to the left. That's consistent, and doesn't need any > > special-casing. > > Reasonable statement, let's close the ticket as WFM. Is there a special translation available for this Benjamin.. Typing before formatted text at the beginning of a paragraph inherents formatting from the formatted text. And typing before formatted text somewhere else doesn't and both cases are the correct behavior?
(In reply to Telesto from comment #9) > (In reply to Heiko Tietze from comment #8) > > (In reply to Mike Kaganski from comment #7) > > > Typing should always continue what's to the left, unless > > > there's nothing to the left. That's consistent, and doesn't need any > > > special-casing. > > > > Reasonable statement, let's close the ticket as WFM. > > Is there a special translation available for this Benjamin.. > > Typing before formatted text at the beginning of a paragraph inherents > formatting from the formatted text. And typing before formatted text > somewhere else doesn't and both cases are the correct behavior? Are you simply ignoring the text above that you quote? There's no "typing before", there's "typing after". Typing after any text continues its formatting. No exceptions. If you try to extend it to "typing before and after", you suddenly loose that "after", because it becomes before something else. And you would need to create different - and more complex - rules for Benjamin.
(In reply to Mike Kaganski from comment #10) > (In reply to Telesto from comment #9) > > (In reply to Heiko Tietze from comment #8) > > > (In reply to Mike Kaganski from comment #7) > > > > Typing should always continue what's to the left, unless > > > > there's nothing to the left. That's consistent, and doesn't need any > > > > special-casing. > > > > > > Reasonable statement, let's close the ticket as WFM. > > > > Is there a special translation available for this Benjamin.. > > > > Typing before formatted text at the beginning of a paragraph inherents > > formatting from the formatted text. And typing before formatted text > > somewhere else doesn't and both cases are the correct behavior? > > Are you simply ignoring the text above that you quote? There's no "typing > before", there's "typing after". That *not* true. There are cases of typing before where formatted is applied .. Starting of paragraph/text in table cell. Follow the steps in comment 0. That's the point of the whole bug. The bug wasn't intended as an enhancement request :-). My major concern: current behavior isn't consistent.. because there are cases where it happens. If this shouldn't happen, it's bug too.. That's why I added Heiko.. as I can't tell what it should be.. And if you ask me, what 'should it be' yes, typing before should get formatting.. But if the LibreOffice 'way' is not doing so (what the reason might be), also OK, but be at least consistent.. So there is a bug in one way or another..
(In reply to Telesto from comment #11) > .. Starting of paragraph/text in table cell. That is consistent, too. Putting cursor anywhere puts it into some existing text span. The decision is that we always put it into the same span as the character to the left. The result is that previous formatting is continued. Starting of a paragraph is tbe place where no characters to the left exist. So this is *not* inconsistent: it doesn't break the rule. Simply when characters to the left don't exist, we still end up in existing span - the very first one of the paragraph. If you revert the rule, and always get to the same span as character to the right, you also get consistent behavior - just the opposite - you would prepend text to yhe formatting to the right of cursor. It's less intuitive - people tend to think more about continuing than about prepending; but still it would be consistent. And it would have the same additional point - at the end of paragraph, where no span to the right exist. Then you have the same thing to "fix": "I can prepend red text to red part, and not append - but in the end, I append. Lets expand it from both ends!" But if you try to do that, you suddenly can't create anything consistent. You need to decide in which span your cursor is situated, to inherit the properties. And now it's not something you can easily explain: "if your text has no character-level formatting on one side of cursor, but some formatting on the other, the cursor will stick to the formatted side. Oh, but what to choose when both sides are formatted, but differently? Choose left side or right side? Let's choose left side. Oh, but now it looks inconsistent for Benjamin, when left side is formatted English, and right side is formatted Russian+red! User doesn't see rhe formatting to the left, and expects cursor to stick to the right part. Now user needs to consider more variables when expecting which effect their typing will have. And you special-cased not a logical thing (when just one side exists), but something illogical - tge case where number of character-level properties in the property bag is 0, not 1, or 2, or... . It's not consistent; it's not visible to user (consider formatting coming from paragraph, or invisible formatting). It can't be explained easily. It's just bad.