Anecdotally, I haven't managed to convince macOS to put a space next to an eliding ellipsis. See attached.

It's possible that Apple's algo is smarter than just "trim whitespace" though. E.g. one case seems to move the ellipsis a little such that there is no need to trim.

For the related question/s - I don't know too much history about the specific implementations - what you describe does sound like a possible bug. Unless history or tests say otherwise, and you have cases that are broken, it sounds like it's worth fixing.

Deleted: Screen Shot 2018-10-23 at 17.43.15.png 47.2 KB

	Screen Shot 2018-10-23 at 17.43.15.png 47.2 KB View Download

Deleted: Screen Shot 2018-10-23 at 17.41.15.png 179 KB

	Screen Shot 2018-10-23 at 17.41.15.png 179 KB View Download

I don't see any obvious problems with removing whitespace. The latter two points sound like possible bugs, any fixes should include specific examples of broken behavior and regression unit tests. Thanks for digging in!

Here's what I'm specifically trying to solve. I assume Mac's material menus will need the corresponding problem fixed (so we need both ELIDE_TAIL and ELIDE_MIDDLE "working").

Do I understand correctly that what CharIsMark is checking is essentially for things like "COMBINING ACUTE ACCENT" and skipping past them (in either direction) so that the entire glyph is removed? If so I'll try to find cases that I believe might be broken.

Deleted: space_elide_tail.png 27.7 KB

	space_elide_tail.png 27.7 KB View Download

Right, that example screenshot is helpful.

I believe your understanding of CharIsMark is correct. Hopefully there are tests of that behavior somewhere.

** UI Mass triage **

Please see https://chromium-review.googlesource.com/c/chromium/src/+/1387737 for proposed CL.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/76d8382fb1d1ff05db2be8738276c4e6cafbaf1e

commit 76d8382fb1d1ff05db2be8738276c4e6cafbaf1e
Author: Dana Fried <dfried@chromium.org>
Date: Wed Jan 09 22:24:30 2019

Trim whitespace during head and tail string elision.

All string elision that removes the head or tail of a string will now
remove any whitespace adjacent to the elision point as well.

Furthermore, eliding the beginning of a string will never result in more
unicode codepoints or bytes than was initially requested. Previously,
it was possible to end up including a character with combining marks or
a character whose codepoint was split by the target number of
characters.

This does affect filename elision. For example, eliding "foo bar.gif" to
the width of 9 characters results in "foo….gif" rather than "foo ….gif",
because the filename elision logic elides the tail of the base filename
rather than eliding the middle of the full filename.

Bug:  897967 
Change-Id: I0e5e170b656c185a91de64ef042d01ec3920ceb8
Reviewed-on: https://chromium-review.googlesource.com/c/1387737
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Michael Wasserman <msw@chromium.org>
Commit-Queue: Dana Fried <dfried@chromium.org>
Cr-Commit-Position: refs/heads/master@{#621337}
[modify] https://crrev.com/76d8382fb1d1ff05db2be8738276c4e6cafbaf1e/ash/public/cpp/app_list/tokenized_string_char_iterator.cc
[modify] https://crrev.com/76d8382fb1d1ff05db2be8738276c4e6cafbaf1e/base/i18n/char_iterator.cc
[modify] https://crrev.com/76d8382fb1d1ff05db2be8738276c4e6cafbaf1e/base/i18n/char_iterator.h
[modify] https://crrev.com/76d8382fb1d1ff05db2be8738276c4e6cafbaf1e/base/i18n/char_iterator_unittest.cc
[modify] https://crrev.com/76d8382fb1d1ff05db2be8738276c4e6cafbaf1e/ui/gfx/text_elider.cc
[modify] https://crrev.com/76d8382fb1d1ff05db2be8738276c4e6cafbaf1e/ui/gfx/text_elider_unittest.cc
[modify] https://crrev.com/76d8382fb1d1ff05db2be8738276c4e6cafbaf1e/ui/gfx/text_utils.cc
[modify] https://crrev.com/76d8382fb1d1ff05db2be8738276c4e6cafbaf1e/ui/gfx/text_utils.h
[modify] https://crrev.com/76d8382fb1d1ff05db2be8738276c4e6cafbaf1e/ui/gfx/text_utils_unittest.cc