GNOME Bugzilla – Bug 595615
Use proper ellipses
Last modified: 2012-11-26 09:02:03 UTC
Created attachment 143465 [details] [review] Use proper ellipses Patch attached to convert GTK+ to use proper ellipsis characters ("…") instead of three dots ("..."), thereby making it look typographically prettier.
Not sure that assuming that the user's current font has this character in it is a good idea (and falling back to a different font is a really bad idea) So a prerequisite might be adding some sort of special fallback support in Pango. (pango internally has code for something like this when ellipsizing strings)
(In reply to comment #1) > Not sure that assuming that the user's current font has this character in it is > a good idea (and falling back to a different font is a really bad idea) > > So a prerequisite might be adding some sort of special fallback support in > Pango. (pango internally has code for something like this when ellipsizing > strings) The three-dot ellipsis is present in all the fonts I have installed (on a fresh Fedora 11 installation), with the exception of PakTypeTehreer. It has a different symbol, which might be the Pakistani version of an ellipsis (I don't know).
The glyph present in fixed width fonts (such as used on bugzilla) is at best an emergency fallback. Squeezing three dots into the space of one does not "mak[e] it look typographically prettier". I don't believe GTK+ has the infrastructure to do this right at the moment. The proper decision on whether to use ligatures (..., ffi, ffl, fi, fl) depends on the font that the string will be shown with. It's language dependent. It's font size dependent. It interacts with hyphenation. I think that's another way of saying that it belongs in Pango or below.
(In reply to comment #3) > The glyph present in fixed width fonts (such as used on bugzilla) is at > best an emergency fallback. Squeezing three dots into the space of one > does not "mak[e] it look typographically prettier". I don't think GTK+ is commonly used with fixed-width fonts. > I don't believe GTK+ has the infrastructure to do this right at the moment. > > The proper decision on whether to use ligatures (..., ffi, ffl, fi, fl) > depends on the font that the string will be shown with. It's language > dependent. It's font size dependent. It interacts with hyphenation. Are you sure the ellipsis is a ligature? From my understanding, a ligature is a special precomposed glyph to replace several others, so that one doesn't end up with ugly collisions between bits of the glyphs. An ellipsis is a punctuation mark in its own right, and we only use three full stop characters for it because ASCII didn't have an ellipsis glyph. > I think that's another way of saying that it belongs in Pango or below. What are you suggesting?
> Are you sure the ellipsis is a ligature? For better or worse, it fits wikipedia's definition of multiple graphenes in one glyph. > What are you suggesting? Do nothing in gtk+. Consider this in pango if, and if only, there is a visible benefit.
I've been doing a lot of typography of late, and my experience has been that in most fonts the '…' character is poorly rendered. In fact, most fonts seem to know how to combine consecutive single '.' characters appropriately, ie "..." (which, just for example as I type this looks *better*!). That is, of course, a subjective judgement, but that's the way we've been seen it in proportional fonts. In our rendering engines we have reverted use of U+2026 and just use periods. AfC
(In reply to comment #6) > I've been doing a lot of typography of late, and my experience has been that in > most fonts the '…' character is poorly rendered. In fact, most fonts seem to > know how to combine consecutive single '.' characters appropriately, ie "..." > (which, just for example as I type this looks *better*!). As you type it looks better because Bugzilla uses fixed width fonts, but regardless, isn't it better to just fix the fonts?
(In reply to comment #1) > So a prerequisite might be adding some sort of special fallback support in > Pango. (pango internally has code for something like this when ellipsizing > strings) Just noticed it's bug #63633. (In reply to comment #5) > Do nothing in gtk+. Consider this in pango if, and if only, there is a > visible benefit. Doing it in Pango would mean that in situations where three dots are being used correctly (e.g. varargs in a programming editor), the wrong glyph would be used. As I see it, the semantics of "…" and "..." are different; the former is not a ligature for the latter.
So, now that the new HarfBuzz backend has been merged in Pango, we’ve gained compatibility decomposition support, which means that ‘…’ will be automatically decomposed to ‘...’ if the current font doesn’t support the glyph. At the risk of igniting the flames again, shall I update the patch?
With the pango support in place, I'm willing to consider this.
(In reply to comment #10) > With the pango support in place, I'm willing to consider this. I’ll wait until the start of the 3.8 cycle and then update the patch. I guess making the changes now would be too disruptive for translators (and wouldn’t get tested well enough).
I still fear this will look terrible in various circumstances. For example, comment 9 looks awful because the fixed width font includes the ellipsis character with the same width as ".". Is there an actual problem that we're trying to fix here?
(In reply to comment #12) > I still fear this will look terrible in various circumstances. For example, > comment 9 looks awful because the fixed width font includes the ellipsis > character with the same width as ".". But we shouldn’t be using fixed width fonts for displaying running prose (or UIs), which are the only real situations where a Unicode ellipsis should be used. > Is there an actual problem that we're trying to fix here? Two (admittedly minor) problems: • Semantic difference between ‘…’ and ‘...’. One could imagine a screen reader treating the two sequences differently (e.g. not reading ‘…’ out as “period period period”). • Rendering difference between the two. In non-fixed-width fonts, the Unicode ellipsis character renders with uniform spacing between the dots, and ends up being slightly wider than ‘...’, which can end up with non-uniform spacing (which looks icky). For example, I just had the Unicode spec. PDF (version 6.1, page 201) open to look up their advice (which is to use the Unicode ellipsis character), and their example sequence of ‘...’ rendered with the wrong spacing due to the size of the font.
Review of attachment 143465 [details] [review]: Philip, if you want to land this, now would be a good time.
Comment on attachment 143465 [details] [review] Use proper ellipses Updated and committed, thanks. commit ceb866dfe6be6d88b8f83a3cbdb8a2a688419c82 Author: Philip Withnall <philip@tecnocode.co.uk> Date: Mon Nov 26 08:59:27 2012 +0000 Bug 595615 — Use proper ellipses Use ‘…’ instead of ‘...’ in translatable strings. Closes: https://bugzilla.gnome.org/show_bug.cgi?id=595615 gtk/gtk-launch.c | 4 ++-- gtk/gtkappchooserbutton.c | 6 +++--- gtk/gtkcellrendereraccel.c | 4 ++-- gtk/gtkcustompaperunixdialog.c | 2 +- gtk/gtkfilechooserbutton.c | 2 +- gtk/gtkfilechooserdefault.c | 2 +- gtk/gtkpagesetupunixdialog.c | 2 +- gtk/gtkprintunixdialog.c | 4 ++-- 8 files changed, 13 insertions(+), 13 deletions(-)