27074 2009-07-08 02:20:08 -0700 Text should wrap after hyphens, not before 2010-11-08 10:53:47 -0800 1 1 1 Unclassified WebKit Layout and Rendering 528+ (Nightly build) PC Linux RESOLVED WORKSFORME P2 Minor --- 41103 0 iain.dalton webkit-unassigned phnixwxz oldest_to_newest 130396 0 iain.dalton 2009-07-08 02:20:08 -0700 Calibre (http://calibre.kovidgoyal.net/) uses Webkit, I'm not sure what version, and it wraps hyphens to the next line, which looks weird, and not book-like. The dev says it's a WebKit issue, so I'm reporting it here. 130459 1 mrowe 2009-07-08 10:48:15 -0700 Perhaps you'd like to include a list of steps necessary to reproduce the problem? 130614 2 iain.dalton 2009-07-08 21:57:24 -0700 1. Download and install Calibre (http://calibre.kovidgoyal.net/download). 2. Open an ebook (http://www.epubbooks.com/book/60/count-of-monte-cristo) with Calibre's viewer. 3. Resize the window until it has to break a hyphenated word (of which this book has several right at the top). Of the few ebooks I've looked at, only this one puts the hyphen on the new line. I see nothing suspicious in the HTML, so I don't know why. 131061 3 ap 2009-07-10 21:46:12 -0700 > I see nothing suspicious in the HTML, so I don't know why. Is this reproducible with WebKit-based Web browsers? Could you make a reduction, or upload the HTML source here? 131206 4 iain.dalton 2009-07-12 14:48:53 -0700 In looking at the source, I see that the hyphens are actually en-dashes misused. I'm no typographer, but the only place I've know an en-dash to occur without spaces around it (other than this misuse as a hyphen) is in a range, such as 2–5. Should breaking occur at all at an en dash? 297211 5 71384 phnixwxz 2010-10-20 20:15:37 -0700 Created attachment 71384 test case I couldn't reproduce the bug in Chrome 7 and 8 and Safari 5, but I could reproduce it in Qt version of WebKit. Qt version of WebKit uses QTextBoundaryFinder to find line breaking opportunities, so this bug should be of QT, not of WebKit itself. 306217 6 vincent.bradley 2010-11-08 10:53:47 -0800 Using QtWebKit trunk (wk45), this is not reproducible. The test content is using entities ߝ for the endash and the breaks occur *after* the dash. Tried the test content saved as UTF-8 with and without BOM, also UTF-16 and the content displayed and broke after the endash. Used QtTestBrowser to verify on Symbian and Linux. Both work as expected. Test content, as provided, used: <!DOCTYPEhtml> abcdefg–abcdefg–abcdefg–abcdefg–abcdefg–abcdefg– .... Note, that test content has no meta tag: <meta http-equiv="content-type" content="text/html; charset=UTF-16"> Tested with meta tag added and works as expected. The behavior is the same for Firefox, Safari, and QtTestBrowser. 71384 2010-10-20 20:15:37 -0700 2010-10-20 20:15:37 -0700 test case testendash.html text/html 736 phnixwxz PCFET0NUWVBFaHRtbD4KYWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIw MTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYj eDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVm ZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJj ZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7 YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIw MTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYj eDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVm ZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJj ZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7 YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIw MTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYj eDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7YWJjZGVmZyYjeDIwMTM7Cg==