Style: switch numerals to (pnum/proportional) by default instead of fixed-width (tnum/tabular)

The default numeral glyphs are all the same width, to ensure that tables of numbers line up and look pretty (fixed-width spacing).

However, you'll be please to know that there /are/ "alternate" glyph representations with proportionally-spaced numerals in the font set already. These can either be accessed via an alternate method, or in the case that your software doesn't support the alternate glyph methods, the proportionally-spaced digits are also exposed in the private-use area as U+F800 to U+F809.

Please could you have a look at the attached PDF and confirm that the spacing is what you had in mind.

Paul is correct. The standard (tabular) figures do not space as well as the alternative proportional figures, but tabular figures need to be the standard default selection for applications that require them such as spreadsheet programs.

I suspect this is another manifestation of the tabular-by-default story.

It strikes me that most apps which expect tabular could be coded to ask
for it, why don't we do neat-by-default, with the tabular style as the
option that the app needs to know to ask for?

Mark

Oh hell no, I can't fix it, all I can do is ask questions.

Can we have the tabular number style as the optional one for apps that
know to ask for it? Seems like Monospace would be natural to have spaced
numbers, and Regular should do them sleek-by-default.

Mark

(Note example from dup of "Linux2Go").

It's a policy decision with good arguments for either default (tnum/pnum). It's arguably possible (although long-term and by no means immediate) to fix spreadsheet, list-numbers containing only numerals to request the tnum alternatives and have that request passed back down the stack to Freetype; eg. the design of the font should not be held back by present-day limitations that can be fixed later.

If the policy decision is to

If the policy decision is to switch, then the technical implementation is easy! :)

Yes, please switch to proportional by default, with tabular numbers
available through OpenType tables for conformant applications.

Mark

DM: when you adjust this, please could you leave the existing mapping for proportional numerals at U+F800..F809 intact, and then additionally add new alises for tabular numerals a bit higher-up (eg. U+F820... or thereabouts) so that regardless of the defaults, both tabular and proportional will be directly accessible at consistent codepoints via the Private Use Area.

The current font stack on Linux has no means for requesting non-default OpenType font features, neither GTK/Pango nor Qt support that, so you have to wait the pros and cons of each style; i.e. what is more important having proportional numbers and breaking the look of tables and spread sheets, or making table look good but regular text suboptimal? The number for conformant applications is around zero, there aren't any apart from some modern TeX based typesetting engines. So unless Ubuntu is welling to invest into fixing font rendering stack, depending on OpenType is not a viable option (we have been waiting for what, a decade now?).

And for private use area, no, we should never ever use it for inputting text, this breaks text validity and makes it font dependant, which is a no-no.

Conversely, having a great font which would take advantage of the
feature might act as an incentive to the app developers!

On Thu, Aug 26, 2010 at 01:07:59PM -0000, Mark Shuttleworth wrote:
>
> Conversely, having a great font which would take advantage of the
> feature might act as an incentive to the app developers!

As of there aren't such free fonts, we already have many free fonts that
make use of OpenType features to achive more fine tuned typography,
Linux Libertine for example, and these fonts have been around for a
while now.

Khaled: I think the implication here that the Ubuntu Font Family will be:

 1. a Libre typeface
 2. with OpenType features
 3. deployed (by default) on *alot* of Desktops

at which point the incentive to fix applications is there, which will in-turn mean fixing the whole stack. Is that what you were worried about (the scale of it)? If so, I think it's what's being seen as a net-positive in the long-run from Mark's point-of-view.

Regarding the private-use area (which is clearly marked as such), it provides a stop-gap means for accessing otherwise unmapped glyphs on older systems. It's certainly not to be encouraged, but is it a bad thing to provide that level of compatibility. At the moment, if somebody asks "how do I get such-and-such", we have an answer for them even if their software isn't OpenType alternatives-ready.

Khaled: would you be willing to make a list of relevant applications,
and find out if there are bug reports against each of them to support
the OpenType feature? Also, to figure out if the freetype stack is ready
for it, or if not what need to be done to get it to that point.

Mark

On Fri, Aug 27, 2010 at 10:18:32AM -0000, Paul Sladen wrote:
> Khaled: I think the implication here that the Ubuntu Font Family will
> be:
>
> 1. a Libre typeface
> 2. with OpenType features
> 3. deployed (by default) on *alot* of Desktops
>
> at which point the incentive to fix applications is there, which will
> in-turn mean fixing the whole stack. Is that what you were worried
> about (the scale of it)? If so, I think it's what's being seen as a net-
> positive in the long-run from Mark's point-of-view.

I sincerely hope that will happen sooner than later, but I'm not holding
my breath. I've been around for a while and things has always been
stagnant, we still have famous FOSS DTP applications that no nothing
about OpenType, yet to speak about fine control.

Even so, until then you still have to make a decision, so my initial
comment still applies.

> Regarding the private-use area (which is clearly marked as such), it
> provides a stop-gap means for accessing otherwise unmapped glyphs on
> older systems. It's certainly not to be encouraged, but is it a bad
> thing to provide that level of compatibility. At the moment, if
> somebody asks "how do I get such-and-such", we have an answer for them
> even if their software isn't OpenType alternatives-ready.

I totally agree, but a clear distinction and the implications of using
PUA must pointed to prominently to however using PUA is suggested to.

Khaled: So Scribus, (plus Gnomeric, {OpenOffice.org,Koffice}-Spreadsheet), what other applications, or toolkit/render components?

The Ubuntu Font Family will /have/ to be under a Free Licence, otherwise it can't get into 'main' for seeding onto the default installs!

On Fri, Aug 27, 2010 at 10:54:14AM -0000, Mark Shuttleworth wrote:
>
> Khaled: would you be willing to make a list of relevant applications,
> and find out if there are bug reports against each of them to support
> the OpenType feature?

Virtually every thing that lays out text; Pango, Qt, OOo, Scribus. All
but Scribus support OpenType default features but don't support
activating/deactivating non-default features. Scribus has no OpenType
support at all.

> Also, to figure out if the freetype stack is ready
> for it, or if not what need to be done to get it to that point.

The problem lays higher in the stack, FT is a renderer not a layout
engines, it renders whatever glyphs you ask for, it is up to the calling
layout engine to select the proper glyph. For Pango and Qt the layout
engine is HarfBuzz, which have been undergoing a rewrite for several
years no (harfbuzz-ng), no idea when it will be done. HarfBuzz have a
quite good OpenType support, but no interface to select non-default
features, the rewrite is ought to address this. When that is available,
higher level code that uses HarfBuzz should provide UIs to control font
features.

Some relevant Pango bugs:
https://bugzilla.gnome.org/show_bug.cgi?id=545510
https://bugzilla.gnome.org/show_bug.cgi?id=547472

I didn't find any relevant Qt bugs.

OOo uses ICU, I don't know much about optional features with it, but
there is an open OOo bug:
http://www.openoffice.org/issues/show_bug.cgi?id=16032

Scribus has no OpenType support at all, there are tens of open tickets
about that, I can't find the exact bug, but this one should suffice:
http://bugs.scribus.net/view.php?id=1413

I think the hardest case would be the web one. A spreadsheet knows when
it's drawing a tabular datum, but a web browser probably doesn't. Zoho's
Word Processor and Zoho's Spreadsheet would need to be able to hint for
the right outcome, accordingly.

Mark

On Fri, Aug 27, 2010 at 11:49:11AM -0000, Paul Sladen wrote:
> Khaled: So Scribus, (plus Gnomeric,
> {OpenOffice.org,Koffice}-Spreadsheet), what other applications, or
> toolkit/render components?

Koffice depends on Qt, Gnomeric on GTK (pango), see my other reply.

> The Ubuntu Font Family will /have/ to be under a Free Licence, otherwise
> it can't get into 'main' for seeding onto the default installs!

I was not questioning the license, but whither it will have any impact
on improving OpenType support or not.

Ironically, Firefox has added support for controlling OpenType font in FF4, as an extension to CSS and are planning to make it part of the standard in some form.
http://hacks.mozilla.org/2009/10/font-control-for-designers/

 On 27/08/10 13:16, Khaled Hosny wrote:
> Ironically, Firefox has added support for controlling OpenType font in FF4, as an extension to CSS and are planning to make it part of the standard in some form.
> http://hacks.mozilla.org/2009/10/font-control-for-designers/

To me, this suggests we should build the font for the future, and
challenge app authors to catch up :)

Using a font with non-tabular numerals creates other small problems in places where the digits are changing. For example, in a progress dialog box with rapidly changing digits, all the text to the right of those digits "jiggles" back and forth as the numbers change. A common example is the "File Operations" progress window in gnome, with its usual text, something like "Duplicating 2,015 files" and "1.7 GB of 19.3 GB -- 11 minutes left".

As another example, the elapsed time display in Banshee (and perhaps other media players) is a centered text saying something like "0:23 of 2:29" underneath a slider. This text will jump around, perhaps 1 or 2 pixels, with each passing second.

I've also come across situations where the whole dialog box changes its width every second as the a counter counts down to zero (but I'm sorry I can't reproduce a case of this).

Right, the question is whether things like Gtk make it really easy to
say "this text should use tabular numerals" and have the font renderer
do the right thing.

Mark

Paul, on this one I'm going to follow DM's guidance, so we can drop it
as a 0.7 requirement.

Mark

It looks to me like there a rock and an unknown: we don't have much of an option of choice at the moment: the toolkit stacks can't do what we're asking yet (pass through alternatives requests).

So, after the Ubuntu (distribution) 10.10 release is out of the way, we probably want to go and get some hard data on what it might take to fix this (eg. by taking the simple use-case of a numerical Gtk+/Qt spinbox and ensuring that the widget can request its rendering as 'tnum'. We should then have a realistic opportunity for analysis, and going with a definitive choice, which might very well be the status quo.

I'd have to disagree with changing the numerals to proportional because of all the applications that look better displaying numbers in a fixed-width manner. A particular place where proportional numerals bother me is where they are changing. Examples include music/media players and clocks (especially if you display seconds). Fixed-width numerals in a non-fixed-width font was one of the things that made me really like using the ubuntu font. They are also helpful when you compare numbers at a glance.

As Michael suggested, if this change is made, and assuming bug 777856 is fixed, indicator-datetime should request the fixed-width numerals. For the clock to change width four times a day (10:00 AM, 12:00 PM, 1:00 PM, 10:00 PM) would be very slightly awkward, but for it to change 14 times every hour (:01, :02, :10, :11, :12, :20, :21, :22, :31, :32, :41, :42, :51, :52) would be much worse. (And horrid if seconds are turned on.) I've added indicator-datetime here because that change would become relevant only if the font is changed.