Bug 5461 - Text width measured incorrectly when text-align: justify
Summary: Text width measured incorrectly when text-align: justify
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Minor
Assignee: Nobody
URL:
Keywords: HasReduction
Depends on:
Blocks:
 
Reported: 2005-10-22 10:18 PDT by Duncan Wilcox
Modified: 2017-12-05 13:12 PST (History)
3 users (show)

See Also:


Attachments
test case (1.34 KB, text/html)
2005-10-22 10:18 PDT, Duncan Wilcox
no flags Details
Automated test case (935 bytes, text/html)
2005-10-22 13:35 PDT, Alexey Proskuryakov
no flags Details
Work in progress (13.08 KB, patch)
2005-12-29 07:14 PST, mitz
no flags Details | Formatted Diff | Diff
Use WebTextRenderer selection rects (23.95 KB, patch)
2005-12-30 02:25 PST, mitz
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Duncan Wilcox 2005-10-22 10:18:08 PDT
Load attached sample document, hold cmd-ctrl and hit "d" (keep holding cmd-ctrl), now hovering over 
words pops up the dictionary lookup. Hover towards ends of lines, the highlited text isn't exactly 
aligned with the word beneath it.

The only strange thing in the sample document is the "text-align: justify".

More specifically the highlighted text appears to be aligned on the non justified word position.

Tested with freshly checked out tree, this is printed to the console:

=================
ERROR: TEXTINPUT: characterIndexForPoint: not yet implemented
(/Users/duncan/builds/WebKit/WebView.subproj/WebHTMLView.m:4874 -[WebHTMLView
(WebNSTextInputSupport) characterIndexForPoint:])
=================
Comment 1 Duncan Wilcox 2005-10-22 10:18:46 PDT
Created attachment 4442 [details]
test case
Comment 2 Alexey Proskuryakov 2005-10-22 13:34:49 PDT
Justified text also has serious problems when being edited in Blot and Mail; I think the root cause is the 
same. To reproduce, open the test case in Blot and try moving the caret with arrow keys or mouse clicks - 
its positioning doesn't account for the justification. Renaming the bug and bumping priority to P2.

BTW, an implementation for characterIndexForPoint is currently in the commit queue (bug 5230), and it 
doesn't help in this case.
Comment 3 Alexey Proskuryakov 2005-10-22 13:35:52 PDT
Created attachment 4443 [details]
Automated test case
Comment 4 Eric Seidel (no email) 2005-12-27 15:36:32 PST
Particularly "note" and "are" in the second paragraph.
Comment 5 mitz 2005-12-29 07:14:42 PST
Created attachment 5353 [details]
Work in progress
Comment 6 mitz 2005-12-30 02:25:04 PST
Created attachment 5376 [details]
Use WebTextRenderer selection rects

There's more to this patch than just fixing the bug: past fixes to "highlight
leaves trails" were about narrowing WebTextRenderer's highlight rect to fit
into InlineTextBox's selectionRect, which due to the "rounding hack" was
narrower than AppKit's highlight rect for the same text. By moving all
selection/highlight rect computations to WebTextRenderer, this patch eliminates
unnecessary intermediate rounding and gives wider rects that match AppKit more
closely. I think it also improves caret positioning in RTL text.

It looks like AppKit uses different rounding modes for the right hand side of
the highlight (ceil) and for the caret (round). This patch sacrifices highlight
to get caret right. I guess this can be improved in the future.
Comment 7 Darin Adler 2005-12-30 11:29:42 PST
Comment on attachment 5376 [details]
Use WebTextRenderer selection rects

Nice. r=me
Comment 8 Daniel Bates 2017-12-05 13:12:07 PST
Committed in <https://trac.webkit.org/changeset/11846/>.