1999102508 mozilla.exe on WinNT 4.0 SP3. To repro: 1) open http://www.abcnews.go.com/sections/us/DailyNews/modelseggs991023.htm 2) view the paragraph "Nancy Etcoff, the Cambridge-based author of it’s natural to consider how your mate’s attractiveness will be reflected in your children. But she said such direct marketing of beauty is a false promise." Expected: it's will never be line-broken after the ' Actual it's is broken after the ' and the s appears on the next line

Corrected URL to have trailing "l" in ".html". The correct URL is http://www.abcnews.go.com/sections/us/DailyNews/modelseggs991023.htm The omission was caused by Location bar URL copy-and-paste bug I'm filing separately.

Change the status whiteboard to indicate that I need a testcase before proceeding.

Not to be difficult, but is a simplified test case truly necessary here? Reason: in text layout algorithms, characters can be grouped as follows, loosely speaking: 1) characters that define a word break (e.g. space) at which a line break is OK 2) characters within a word after which a hyphenation for line break is OK 3) characters within a word after which neither a hyphen nor a line break are allowed The apostrophe clearly falls into group #3. There should never be a line break or a hyphen after an apostrophe (unless the apostrophe is followed by a space, in which case breaking the line is OK, but that's a different case). If it's possible for a line break to be inserted between the apostrophe and the next non-space character (and the URL demonstrates that it is) the line layout algorithm is clearly broken and the handling of the apostrophe needs to be changed. Removing the "NEEDTESTCASE" statement from Status Whiteboard as making the Status Whiteboard field non-empty *removes* the bug from the BugAThon list of bugs that need test cases. If you're trying to get external creation of a test case, Status Whiteboard field should be empty and the bug will be on the list. If a bug needs no test case, it's explicitly removed from the list by setting the field to [NOTESTCASENEEDED]. Changing from M19 to M14 as this is a fairly basic text line layout correctness issue.

Don't mess with my priorities. If you want to talk about, talk about it.

I think this bug is invalid, but the i18n folks would know for sure. The apostrophe used in the document is an ’ (sic) character entity, which is, I believe, the fake-windows-equivalent for an ’ (left single quote). I would think that quotation marks are defined in Unicode as separating punctuation marks, but I'm not sure. (Either way, the author should have used an apostrophe for an apostrophe. However, there is a bug with that too: bug 15909.)

Frank - you should investigate this and either close it or fix it - the implication is that the i18n line breaker is not doing the correct thing for english characters.

move to M12. It won't be too diffuclt to fix it if that that is the right thing to do. Need to think hard about this first. Also, need to check with JIS x4501... If JISx4501 didin't mention these characters, it probably safe to fix it.

post beta per ftang/bobj chat. Should be easy to fix.

easy to fix. Add 0x2019 into contextual analaysis when try to line break. Fix in local tree.

fix check in

Fixed in the Dec 22 build.