Problem description: Position of the cursor calculated incorrectly and cursor moves far and far ahead of text as you are typing. Steps to reproduce: 1. Using fonts with GPOS-GSUB tables (I haven't tested if the problem is GPOS kerning-related or based on wrong numbers of glyphs -- as liga function is enabled by default), like Adobe Source Sans Pro 1.050 or Microsoft Calibri 5.72. 2. Using Print layout (it isn't a duplicate of bug 66577) Expected behavior: correct cursor placement when using writer Operating System: Mac OS X Version: 4.1.0.4 release
Seems to be the Mac version of an old Windows bug: https://issues.apache.org/ooo/show_bug.cgi?id=27336 (comment 34)
Hi Thomas, imo this is already fixed in the latest LO release. Please try this pre-release and update the bug accordingly: http://www.libreoffice.org/download/pre-releases/
Nop, still not fixed in 4.1.2. Seems random, I fail to see the exact pattern... Seems editing an ODT document embedded within a PDF file is more likely to trigger the bug. Some fonts are displaying the bug more than others: Brill fonts are good candidates for testing. http://www.brill.com/about/brill-fonts
Played some more as well. I've not noticed this problem when in page view. But when I switch to web view the cursor behavior is off here and there. It's hard to say when exactly that starts. But it's easy to reproduce. Font I had selected when this happened was Calibri on OS X 10.8.5 LO 4.1.2.2.
Thomas, could you attach a font that is causing this problem? May I ask why you are sure that this here is not a duplicate of bug 66577?
Hi, Could you download the Brill fonts at http://www.brill.com/about/brill-fonts ? (so you could agree to the License Agreement) I'm not sure this bug here is not a duplicate of bug 66577, or bug 63993, or bug 65971. But Khaled Hosny wrote in Comment 8 in bug 66577 : "the issue is limited to the Web Layout". And my issue is using print layout. I thought about OpenType layout issues because it was a old OpenOffice bug https://issues.apache.org/ooo/show_bug.cgi?id=27336 : Herbert Duerr fixed it with very strict glyphs counting (1 glyph = 1 character, which is wrong with OpenType features enabled). I predict at the time when it would be a problem later, but I don't know the current state of LibreOffice related to this, specially with CoreText. I'm sorry to not be able to write better bug reports. I should have better tested this, but I don't have time.
I also have this problem, but in web layout rather than print layout. Have had this for a while - I think since version 4 was introduced. Currently using version 4.1.4.2 (Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72), Mac OS 10.7.5. In my case, it doesn't seem restricted to OpenType fonts. Using Apple's Times system font, when editing or inserting text towards the end of a line of text, the insertion point is to the right of the cursor (increasingly to the right the further it is towards the end of the line), which makes editing very difficult. Switching to Monotype Times New Roman (OpenType), the insertion point (at the moment) is in the same place as the cursor, but the cursor appears some way to the right of the place I click on. This is only a problem in web layout; in print layout it is fine. Hope it's OK to append this report to this bug, even though in my case it's in the other layout. It's the closest one I could find to my bug.
Created attachment 93569 [details] Screenshot illustrating cursor alignment problem In Web Layout, this cursor is actually considered to be at the end of the line, not straddling the "0" and the "s" as it appears to the eye.
Created attachment 93570 [details] Sample document illustrating cursor alignment problem Really, any document will do: I have seen this bug consistently with every single document, loaded or created from scratch, since release version 4.1.
Works for me in 4.2.2rc1, Apache Bug #124233 patch has been applied. Please test. https://issues.apache.org/ooo/show_bug.cgi?id=124233
Per comment 10, marking this ticket as a duplicate of 55142, which even when refers to justified text, it seems to fix this one as well. If it turns out not to fix this, please reopen. *** This bug has been marked as a duplicate of bug 55142 ***
The problem seems to appear only when using "non printing characters", if I disable those it is all fine. Version: 4.1.5.3
I was VERY annoyed by this bug and now I'm more than happy to confirm that 4.3.0.0.beta1 Build ID: 2e39c7e59c8fc8b16a54c3d981dceef27fb0c07f on MacOSX Mavericks works just fine :-) This is a damn good selling point for the beta version. Thank you!
… actually positioning is still not perfect, especially in underfull lines where letters unnaturally stretched – but those are dire circumstances and you should keep clear of those distortions anyway :-/