Created attachment 82012 [details] test-document (writer) Problem description: In Attached document the curser is not moving along with the written text correctly when typing. It get's moved to far and is thus displayed the longer a line gets. Also when marking text the placement of the marked area is not matching the text that is acutally selected. I guess this derives to the same cause. This happens when in View > Webview. This does not happen when in print-layout. Steps to reproduce: 1. Open attached document 2. type something, and observe the cursor placement 3. also try marking text here and there and play with copy paste Current behavior: see above Expected behavior: correct cursor placement when using writer Operating System: Mac OS X Version: 4.1.0.1 rc
I can confirm this behavior using Mac OSX 10.8.4 with LibreOffice Version: 4.2.0.0.alpha0+ Build ID: 9ab800829b8a0e44824dc11276b54b1870bc5b2b @Khaled, Tor: Ping :). Don't know 'cursor placement' is related to CoreText? Thanks for your time! Kind regards, Joren
Created attachment 82013 [details] displaced curser screenshot
Not reproducible using Mac OSX 10.8.4 with LibreOffice 4.0.4.2. So looks CoreText related to me.
Not sure if this is the same issue: https://bugs.freedesktop.org/show_bug.cgi?id=63993 If so it would be all platforms. Calibri seems a good testing font, since in 63993 on Linux it was used for testing as well.
I can not reproduce this, either I’m too lucky or you guys too unlucky, that is the third Mac bug I can not reproduce today.
Aha, I think I can reproduce this now. It is only reproducible if spell checking is enabled, something i going wrong in here.
It looks like witchcraft. Guys, what did you hide in code? :)
I debugged this a bit and the issue is limited to the Web Layout, so IMO it shouldn’t be a release blocker. The wrote cause is that SwFntObj::DrawText() uses the glyph widths array returned by OutputDevice::GetTextArray() (which in turn calls CTLayout::FillDXArray()) to calculate character positions/text width, and all are integer based while Core Text is floating point based and can return fractional glyph widths, so we end up with accumulated rounding errors that manifests in this issue (and probably bug 65971 as well). Right now I have no idea how to fix this.
I wonder if accumulating the error from the last character in some horrible global static float - and adding it to the next one would work ? ;-)
Created attachment 82393 [details] Ugly hack Here is an ugly hack to distribute the rounding errors at word boundaries and also make sure calculating text width is always correcting, I tested it only briefly and it probably breaks something else.
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9a6ba2dacbcad6a326613a691b005348e3d8cedd fdo#66577: Cursor displaced in Web Layout The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Khaled Hosny committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=48bcea3710f14091e2e4fd078a31f278bce0c196&h=libreoffice-4-1 fdo#66577: Cursor displaced in Web Layout It will be available in LibreOffice 4.1.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Still happening in LO 4.1.0.3. But from what I read, Khaled did fix this. Thanks a lot! :) So waiting for 4.1.1 and setting to Resolved, Fixed. @Khaled: Would that mean that https://bugs.freedesktop.org/show_bug.cgi?id=63993 should be fixed as well?
This isn’t fixed yet. The last commits lessen the rounding errors a bit, but the issue is still there.
Created attachment 83405 [details] Calc screen shot showing out of place cursor. Tried the 31st July nightly build and the particular Writer doc I had issues with now works, but Calc still has the issue. Screen shot shows creating a spreadsheet and then starting to type... the text starts to resize in and out as you type and the cursor starts to get in the wrong position. This is same behaviour as the released 4.1 version. OS X 10.7.5. Regards
I am not suggesting it would be the proper "fix" for this bug, but still, just out of interest: How important is the "web layout" view actually? Personally I think we LibreOffice developers should be more brave in also *removing* seldom-used features that either 1) are buggy, or 2) introduce lots of complexity in the code (or both). Just my opinion.
LO Version: 4.1.0.4 Build ID: 89ea49ddacd9aa532507cbf8 OS X 10.8.4 (12E55) Problem occurs in Print Layout. Not evident in Open Office AOO400m3(Build:9702) - Rev. 1503704 2013-07-16 14:51:10 (Tue, 16 Jul 2013)
I am working in MAC OSX.7.5 and LibreOfice 4.1.1.2. In Print Layout I am experiencing the same cursor problem. It makes it almost impossible to type a document of any great length. Is there a fix?
*** Bug 70424 has been marked as a duplicate of this bug. ***
Tor: I disagree on this very much. Web Layout is my most used view. In times of digital documents, why at all would I want to work in page view? I don't plan on printing my documents so no need for page layout at all. Why would Web Layout be dropped if it is the format which might be most used in the future? Also attaching a video of two related problems. 1) the cursor is on and even before some letters when typing. 2) the cursor moves in front of what is being typed when using the Calibri font.
Created attachment 87555 [details] calibri font, cursor moves ahead of writing
On a Mac 10.5.7, I have experienced this error where the cursor is not aligned with each character using Times New Roman. When I switched to Times Roman, the problem disappeared. Perhaps there is a font width error with Times New Roman but not Times Roman.
*** Bug 70903 has been marked as a duplicate of this bug. ***
*** Bug 71337 has been marked as a duplicate of this bug. ***
Created attachment 88821 [details] Screen Copy of spellcheck-textwidth bug on macOS
Hi. This is a very tricky bug, and AFAIK, it's been present in other releases. It's present when in WEB VIEW and with SPELL CHECK on. It's actually very interesting to activate it and then toogle spellcheck on/off. You then realise that the cursor is not at falt. It's the text width that changes. spellchecked text is sometimes displayed wider, sometime denser. Will try to upload a screen grab. Seems to be the spell checking affecting the display layout, but not the cursor. Any clue ? Note on fonts: Adobe Caslon can be wider/narrower, when Times New Roman is only wider with spell check on.
Upping to "major" since this prevents any productive work from happening in Web Layout.
Created attachment 89961 [details] activating spell check changes the text size on MacOS Screen Copy of spellcheck-textwidth bug on macOS ==>CALC<==
Just added attachement 89961 Shows the same bug in CALC AFAIK, the bug is not present in IMPRESS and DRAW
I recognize this bug specially in IMPRESS. Regards Marcus
(In reply to comment #30) > I recognize this bug specially in IMPRESS. > Regards > Marcus Marcus, I did my best to replicate in IMPRESS and could not. Can you post your procedure and/or a sample file. I am using Version: 4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a On OsX 10.6.8 MacBookAir3,1
*** Bug 72860 has been marked as a duplicate of this bug. ***
Bug name just been changed from: VIEWING: Cursor displaced in Web Layout when misspelled text is highlighted to: Cursor is sometimes misplaced when editing text on Mac OS X and that's not the accurate description. Sugegsted FULL DESCRIPTION: The default is activated by enabling spellcheck in some viewing modes including WRITER Web View and CALC. It changes the displayed text length upon various unindentified parameters including text content and displayed font. Suggested COMMENT: The cursor stays at the same place as it would be with spellchech dis-activated, and is therefore not alligned with displayed text insert point when the bug is active. For this reason the bug is sometimes refered as "faulty cursor". Truth is, it is a text display bug. Enabling spellcheck should NOT change text layout. We suspect a letter spacing rounding error. Suggested TITLE: "Activating spellcheck changes the letter-spacing on Mac OS" ref: http://en.wikipedia.org/wiki/Letter-spacing "mal nommer les choses, c'est ajouter au malheur du monde" Albert Camus
Created attachment 91221 [details] Wrong cursor position in text (selection is highlighted) The problem disappears if I change the paragraph align to left instead of justified.
The title of this bug report looks accurate to me even if it might be not a single cause to the behaviour described by each and every user. Using LibreOffice 4.1.2.3 on Mac OS X 10.9 (but having the same issue previously on 10.6.8), I found the same extremely annoying behaviour of the cursor. It is sometimes displaced from the position where the actual editing happens. In the uploaded picture, the actual selected character is "r" but the selection is between r and the previous letter. The problem magically disappears if the I change the paragraph alignment from "justified" to "left". Could it be that the display position and cursor position are not linked ? When text changes slightly due to a different alignment requirement for the paragraph, it looks like the cursor does not know about it... Please, please, some text positioning guru, notice this problem and help us with a solution!
Dear Cosmin and Fellows Bug Commenters, If I may, I would like to insist on the fact that this is NOT a cursor bug. The cursors is, stays, remains at the right position. This is a *letter-spacing* bug that makes the text being improperly rendered when spell checking is activated. I agree, you suffer from "cursor misbehavior" but, please, keep reading: -1- Can we agree that "spell checking" should NOT change text rendering ? Yes ? Then take you favorite "wrong cursor" file and toogle spell checking on and off. Text rendering changes, OK ? More accurately, line lengths changes, sometimes expand, somtimes contract. This is the bug. Even if the cursor where behaving OK, we do not want the spell checking to wack our page desing. -2- Now that's a spellcheck text rendring issue, what about the cursor. Try this: - type aaaaaaaaaaaabbbbbbbbbbbb - disactivate spellcheck - place the cursor when you whant to inject text, between a and b - activate spellcheck, - the cursor did NOT move on screen, even if the text did. - insert text - you get aaaaaaaaaainsertbbbbbbb Conclusion: The bug does NOT move the cursor The bug DOES move the text The bug does NOT affect text insert logic please accept my appologies for CAPPING: *THIS IS NOT A CURSOR BUG* As soon as the bug -1- is solved, the bug -2- is no longer present. As we are helping programmers finding a bug, we should pay attention not to send them searching in the wrong piece of code. Thanks.
Comment on attachment 91221 [details] Wrong cursor position in text (selection is highlighted) I can confirm this bug! For me it's really a critical bug. It is hard to edit a document, when the cursor position is wrong. It's a core functionality of a text editting software.
Changed importance to reflect the new policy - Sophie
I'm a Window user so I cannot test, so please give me an update of the status of this issue with current LibO 4.2.3.3 release or 4.3master if bug is still there, move it to the mab4.2 list (Bug 65675) if bug is gone set status to RESOLVED
No longer am able to reproduce this issue under LO 4.2.3.3 and OS X 10.9.2. WORKSFORME Please test yourself and if you still are able to reproduce this most annoying behavior with 4.2.3.3 or newer, make sure to re-open this bug and provide exact repro steps.