Bug Hunting Session
Bug 69879 - EDITING: Wrong cursor position with OpenType fonts
Summary: EDITING: Wrong cursor position with OpenType fonts
Status: RESOLVED DUPLICATE of bug 55142
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.0.4 release
Hardware: Other Mac OS X (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2013-09-27 11:11 UTC by Thomas Linard
Modified: 2014-05-27 21:27 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot illustrating cursor alignment problem (38.16 KB, image/png)
2014-02-06 21:59 UTC, jcompton
Details
Sample document illustrating cursor alignment problem (42.00 KB, application/msword)
2014-02-06 22:00 UTC, jcompton
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Linard 2013-09-27 11:11:57 UTC
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
Comment 1 Thomas Linard 2013-09-27 12:31:31 UTC
Seems to be the Mac version of an old Windows bug: https://issues.apache.org/ooo/show_bug.cgi?id=27336 (comment 34)
Comment 2 retired 2013-09-27 13:40:09 UTC
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/
Comment 3 Thomas Linard 2013-09-27 22:07:44 UTC
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
Comment 4 retired 2013-09-30 22:21:54 UTC
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.
Comment 5 retired 2013-11-21 08:43:11 UTC
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?
Comment 6 Thomas Linard 2013-11-21 09:36:51 UTC
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.
Comment 7 a_fulva 2014-01-24 20:26:52 UTC
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.
Comment 8 jcompton 2014-02-06 21:59:37 UTC
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.
Comment 9 jcompton 2014-02-06 22:00:53 UTC
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.
Comment 10 Vossman 2014-03-03 17:08:54 UTC
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
Comment 11 Adolfo Jayme 2014-03-25 21:28:03 UTC
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 ***
Comment 12 anonym-user 2014-04-14 13:14:32 UTC
The problem seems to appear only when using "non printing characters", if I disable those it is all fine.
Version:  4.1.5.3
Comment 13 Georg Verweyen 2014-05-27 20:57:00 UTC
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!
Comment 14 Georg Verweyen 2014-05-27 21:27:20 UTC
… 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 :-/