MIR+FFE: Inclusion of Ubuntu Font Family ~0.69 in Maverick (10.10)

[Alan Bell]

When the new font was announced it was expected to be in 10.10
http://www.markshuttleworth.com/archives/308
"I expect to see that font widely used in 10.10"

and again:
http://design.canonical.com/2010/07/the-ubuntu-font/
"scheduled to be shipped in Ubuntu 10.10"

it isn't in Maverick as yet.

[John Vivirito (gnomefreak)]

not sure if it requires an FFE sice we have past the feature freeze i asked him to file an FFE.

[Scott Kitterman (kitterman)]

Is this even released yet? Is it packaged?

[Alan Bell (alanbell)]

it is packaged in a private PPA https://launchpad.net/~ubuntu-font-beta-testing/+archive/ppa it isn't released generally as yet, but if the plan is still to get it in 10.10 it is probably about time to do something about it!

[Paul Sladen (sladen)]

Yes, we should definitely start writing the Feature Freeze Exception and Main Inclusion Reports, "just in case"! ;-)

[Jonathan Riddell (jr)]

This is a user interface change, needs approval from documentation teams https://wiki.kubuntu.org/UserInterfaceFreeze

What is the regression potential? Will word processing applications use it as their default font? That might confuse some documents which would expect Liberation or Deja fonts.

How much space does it take up, do the various CD images have enough space to include it? Will other fonts be removed?

The MIR will need the licence confirmed.

[Jonathan Riddell (jr)]

Alan, do you actually have anything to do with the release and inclusion of the font or are you just submitting this bug as a hint to the people who do?

[Alan Bell (alanbell)]

Jonathan, nothing to do with me directly, I was asking in #ubuntu+1 about the font and as nobody knew about plans for including it they advised me to raise an FFE.

[Alan Bell (alanbell)]

the size of ubuntu-private-fonts_0.1.10~ppa1_all.deb is 719K

[Steve Langasek (vorlon)]

UI Freeze only applies if this is changing the default UI. I haven't heard that this font will be used by default - obviously that's a much riskier change to land at this point than just including it by default would be.

[Jonathan Riddell (jr)]

Marking as invalid until someone involved in the font development actually wants it in.

[Scott Kitterman (kitterman)]

And usubscribing the release team until there is something to review.

[Mark Shuttleworth (sabdfl)]

We definitely do want it in, and used by default. It's in wide beta now,
accessible to all Ubuntu members, so there's no reason to think it will
throw up more issues than are already being reported on it.

Mark

[Alan Bell (alanbell)]

What we don't have yet is the ubuntubeta mono font, for terminal applications and indeed monospaced comments like this on launchpad.net. This would push up the size of the package for inclusion from 719K to something a bit bigger. I also don't think that many people have been using it as the default desktop font, just as a font in documents and so on. There was as far as I recall no specific request to beta testers to change their theme to use the new font. Having just done so, I think it is pretty nice. This is going to totally upset the documentation people taking screenshots after UI freeze though (although they could easily change the font and then take the screenshots if they have access to the font). I also imagine the name of the font will change from Ubuntubeta to Ubuntu which might have some minor implications.

[Alan Bell (alanbell)]

also the translations teams are going to need to test the desktop with the new font, if there are any glyphs missing in languages we translate to that would be an issue. I know a lot of testing has been done, but I am not sure that full coverage of sans has been tested, I will have a go at a visual test of that.

[Paul Sladen (sladen)]

The version(s) of the typeface available in the next ~1 month window are likely to remain below the ~750kB mark, they will only consist of the four fonts that are presently availabe: Regular, Italic, Bold and Bold Italic in Standard only See the following:

  https://wiki.ubuntu.com/Ubuntu%20Font%20Family#Timeline
  https://wiki.ubuntu.com/Ubuntu%20Font%20Family#Coverage

I can confirm that the documentation issue (of Deja-based screenshots vs. UFF-based screenshots) has been mentioned more than once. If there are any documentation team members who would like access to the PPA fonts, please ask them to request to join the 'ubuntu-typeface-interest' group listed in the instructions at:

  https://wiki.ubuntu.com/Ubuntu%20Font%20Family#Howto

I admit that I am not a fan of Ubuntu's tendancy for last-minute UI/theme-related code-drops (even if they are somewhat predictable). In this case it is slightly complicated because there is:

  a. An executive desire that the UFF gets in (1) ships (2) as UI default (see comment #12 above)
  b. An even more executive focus on stylistic/quality values for the typeface
  c. A fifth-party involved.

so effectively we're trying to turn a quality-based release ("when it's ready") into a time-based release (before 10.10.10); with all of the work, bugs, fixes and tweaks having to flow via Dalton Maag in the middle. We have to deliver all of that without anyone getting upset, stressed, burning out, or resigning!

So, on a practical level:
  1. Finalise/harmonise the open-licensing (has been done behind the scenes, so can be effected quickly)
  2. (Specifically) invite documentation team members to agressively test the PPA package
  3. Take a weather reading of what the doc team think the impact of (a) shipping (b) by default as UI font, will be
  4. Ditto for the translations teams.
  5. Ditto for the release team.
  6. Harmonise the versioning (bug #629727)
  7. Harmonise the .deb package naming (tff-something-something)
  8. Harmonise the Typeface family and display name ("Beta" or not, usurp bug #602870)
  9. Upload to main archive (on basis of (1) and (2))
 10. Main Inclusion Report (and hopefully get accepted)
 11. Feature Freeze Exception (on basis of (3), (4) and (5) and hopefully get accepted)
 12. Justify CD seeding (750kB ... check there is room or start the carve up)
 13. Fix 'High' and 'Critical' bugs
 14. Adjust themes to use as User Interface default font setting (on basis of (8), (12), (13))
 15. Say thank you to everyone and offer them relaxing cups of hot tea and chocolate biscuits.

[Alan Bell (alanbell)]

To make the new font the desktop default either the theme could be adapted to load the font, or "sans" which is an alias for a list of preferred fonts could be updated to include ubuntu in the preferences list, I think that is in the fontconfig package and would be a change to /etc/fonts/conf.avail/45-latin.conf and possibly /etc/fonts/conf.avail/40-nonlatin.conf (although I am not familiar with how the whole fontconfig thing works). Anyhow at the moment fontconfig maps sans to DejaVuSans by default.
using sfddiff ttf-dejavu/DejaVuSans.ttf ubuntu-private-fonts/UbuntuRegular.ttf to compare the glyphs gives the attached output (it segfaulted, but not before it did the glyph comparison.)

[Alan Bell (alanbell)]

based on the output of the font diff, and picking out all lines of the form
Glyph "uni????" missing from UbuntuBeta
here is a list of all the missing characters, code points and unicode names.
There are more missing characters, but I don't understand how to parse them and find out what they are.

[Mark Shuttleworth (sabdfl)]

Hmm. I wonder if we should defer the actual use of the font till 11.04?
That list of Paul's was comprehensive (thanks!) and longer than I'd
expected. It may be more realistic to use it as default font in 11.04.

Mark

[Bruno Girin (brunogirin)]

A cursory parse of Alan's missing glyphs file shows that the whole alphabets are missing (Arabic, Armenian, Georgian to name the ones I could spot). The first one in particular would mean that if the Ubuntu font was made the default font, anybody who speaks Arabic, Farsi or Urdu would be out of luck. So maybe it would be less controversial to include the font in 10.10 so that it gets out to as many users as possible but only make it the default in 11.04?

[Mark Shuttleworth (sabdfl)]

 Bruno,

Is there a font substitution map so that missing Ubuntu characters would
be pulled in from the existing fonts?

i.e. can we make Ubuntu the default and have no change for Arabic and
other users?

Mark

[Alan Bell (alanbell)]

Having switched my desktop defaults to the Ubuntu font I actually can't make the missing glyphs break anything. If I download the notinubuntubeta.txt file and look at it in gedit or anything else and set the font to ubuntu beta all the glyphs seem to display (presumably from sans) in fact the only way I can tell the glyphs are missing is to open the ubuntu font in fontforge. I don't know what magic is doing it, but it all seems to work for me.

[Mark Shuttleworth (sabdfl)]

Can we get preliminary feedback that the font substitution should work
in the general case? And if so, reinstate this bug as a goal for Maverick?

Mark

[Alan Bell (alanbell)]

I tried setting my desktop font to the old ubuntu-title font which is a very incomplete font. The attached image of the desktop and gedit shows what the font server does when it comes across a missing glyph (it does the right thing and uses the sans one) on the left is the language selection dialog with arabic script, again working just fine with the missing glyphs substituted.

[Mark Shuttleworth (sabdfl)]

Completely wrong font, Alan :-) The correct one is available to Ubuntu
members and other groups from ppa:ubuntu-font-betatesting/ppa

Mark

[Benjamin Humphrey (humphreybc)]

Mark, I think Alan was using that font because it has a limited character-set as an example of what Ubuntu does when it can't find a glyph.

[Alan Bell (alanbell)]

yeah, just using it as a known example of very distinctive font with a limited set of glyphs so it is easy to see the behaviour of the desktop when it encounters a missing character. I am a member and I have the real font, but I am not sure I would be competent to spot missing characters when running the desktop in Arabic etc. so just a simple proof that font substitution works and the Arabic, Farsi and Urdu desktop users should just get the sans glyphs for those not implemented yet in the new ubuntu font. If I open up the text file I generated with all the missing glyphs and set the gedit font to ubuntu-beta it displays fine using the glyphs from sans. Basically I think the answers to the questions in #20 are "yes", and "yes".

It is still one heck of a user interface freeze exception, but I would love to see it get in and as the default.

[Mark Shuttleworth (sabdfl)]

 On 06/09/10 22:44, Alan Bell wrote:
> It is still one heck of a user interface freeze exception, but I would
> love to see it get in and as the default.

Yes, I agree it's a big change. But we took steps to mitigate it:
screenshotters have easy access to the font. We have had to keep the
font out of the archives because we want the font design to reflect the
core community's preferences rather than all users preferences, but it's
still seen very widespread testing.

If we can confirm the font substitution for Arabic, Indian and Chinese
users, I'd be +1 making the change for 10.10.

Mark

[Alan Bell (alanbell)]

Arabic screenshot, more English than I had expected, but adding the font and setting it as default didn't seem to do any harm at all.

[Alan Bell (alanbell)]

India has a *lot* of languages, I think I picked standard Hindi, again not much of it in evidence on the desktop, but what was there does not seem to be adversely affected by the addition of the new font

[Alan Bell (alanbell)]

Mandarin chinese takes *ages* to install the font (I thought it had crashed) however it did eventually install and here it is, again no issue caused directly by the new font as default. As an aside note, I was a bit disappointed in the extent of the translations of the desktop, I thought it would be a real challenge testing this, but it would be barely inconvenient for me to use any of those languages full time there is so much English on the screen!

[Paul Sladen (sladen)]

We can concentrate on executing the rest of the to-do list above and ensuring that the font family .deb package is available and in the right places to be seeded into the CD images. This is virtually all tediously technical and procedural; eg. tweaking the advertised font name, version, license, display name, crossing tees and dotting eyes.

With the proviso of having got the pieces into place first, the possibility and policy decision of /whether/ to ship as the user-interface default typeface for {Ubuntu,Kubuntu,both} themes can be left until closer to the ship date. Even if an end-decision were to be to just ship on the CDs, this gets UFF out to the wider audience. I think it's been mostly resolved elsewhere that the candidate versions will ship with a minor release number (not be metrics stable); so any decision is coming down to just the user-interface choice question for the moment---I don't think we should run the risk of going with document font defaults (eg. the hinting/layout issues that need researching more for OpenOffice.org).

To allay the fears about ("only"!) having ~1,200 codepoints covered with glyphs at the moment, glyph substitution will fall back to other fonts just as it does today (in particular to Deja), so scripts not covered specifically by the Ubuntu Font Family will display much as they do already. It's perhaps easier to think of it as the Ubuntu Font Family "overriding" the $default rendering /when/ UFF has the coverage available.

Thank you to Alan, Bruno G, et al for working through and double-checking that the substitution is working as expected. There will be a need to do some similar testing shortly, in order to work out technically how to deploy UFF as user-interface default (when/if needed)---the two suggested methods either being an explicit reference to "family=Ubuntu" or the Themes, or by providing an alias for 'Sans'. If you've still got a handle on things, this would be a good next step.

For Kubuntu there are also going to be points 14a./14b. for whether or not the Kubuntu themes would switch to a default user-interface default of Ubuntu in the same timeframe window. I have mailed the Kubuntu council members collectively and it is on their Agenda for future meetings up to the release date:

  https://wiki.kubuntu.org/Kubuntu/Meetings

[Mark Shuttleworth (sabdfl)]

Thanks Paul for lining us up to land if it comes together appropriately.

On 07/09/10 14:20, Paul Sladen wrote:
> I don't think we should run the risk of going with document
> font defaults (eg. the hinting/layout issues that need researching more
> for OpenOffice.org).
>

Agreed - this is interface-only for the moment, if it is used at all in
10.10.

Mark

[Alan Bell (alanbell)]

there are three ways I can think of to deploy it.
 * Set the interface font name in *gconf* /desktop/gnome/interface/font_name UbuntuBeta 10
 * Make it a suggested font in the ambiance and radiance *themes*
 * In *fontconfig* make it one of the fonts that alias to sans (tweaking stuff in /etc/fonts/conf.d)

Switching to the HighContrastLargePrint theme *suggests* a font which can be optionally applied and reverted. With gconf or themes this would mean highcontrastLargePrint would suggest sans, with fontconfig it would use the Ubuntu font family (I checked in #ubuntu-accessibilty, the new font is not seen as worse than sans for low vision use)

I am unsure what would happen if gconf is set to default to sans, but the default theme suggests ubuntu font family. I suspect it would use sans by default and in appearance-preferences you would be able to apply the ubuntu font - not the desired effect at all.

Using fontconfig to redefine sans means it would get used in documents as the default document font is sans. It could also reflow documents existing that expect sans to mean deja-vu-sans, they are not metrically compatible.

I would recommend changing the gconf key /desktop/gnome/interface/font_name and optionally the highcontrastlargeprint theme if you want all the themes to use the new font for the interface.

[Paul Sladen (sladen)]

...Release team reckon that will be 750 kB of sufficient space for the Ubuntu Font Family package from flexing the 'example-content' package until things fit.

[Scott Kitterman (kitterman)]

Has it been released yet?

[Paul Sladen (sladen)]

People have been asking for updates (even ScottK while I've been writing
this!), so I'm going to try and post daily(?) situation reports; I was
originally going to distribute this privately, but at the suggestion of
somebody on the release team, I'll post the updates to the bug report so
that everyone has a clearer picture and nobody gets missed out. Target:

  https://launchpad.net/ubuntu-font-family/+milestone/0.70

Current ETA guessimate: "next week". As follows:

  0a. 'ubuntu-typeface-interest' PPA access

Two websites have been contacted asking them to redirect enthusiastic Ubuntu
users to the instructions for the 'ubuntu-typeface-interest' group
specifically for the purpose: https://wiki.ubuntu.com/Ubuntu_Font_Family#Howto

An article change by the first website resulted in an immediate addition of
>100 new users, followed by ~35 requests per day. (Total now >= 300). The
second website have not replied to Email or IRC messages yet. Attempts to
make contact are continuing.

  1a. Short-term libre-licensing (bug #632411) - Mark + N

Blocker: There was a hectic twenty-four-hour-period on Thursday as an
additional person was brought into the loop. Mark and Nicholas are
working on the licensing. Copyright assignment would be required in
order to allow for progressive relicensing and thus the assignment
procedure will be documented, see (7b).

  1b. Longer-term libre-licensing - Mark + $others

Partial blocker (for documentation): Dave has sent Paul a (large) Google
document covering points that needed to be noted for (1b), Paul doing
comments and dots+commas over the weekend. Will go to Mark after that, but
is needed in the shorter term for license-FAQ writing.

  6. Harmonise the versioning (bug #629727) - Done

Complete: Consenus was reached to use N.MM versioning (minor version of
'00-99'), zeros always present and any small change causes an increment.
This system meets the requirements of (a) the .ttf 'name' table string
format, (b) the .ttf 'head' table binary fraction, (c) the Debian Policy
'Version:' specification. Major number will indicate metrics stability, and
will be in the control of Canonical. The methodology will be documented (7b).

  7a. Harmonise the .deb package naming (bug #633508) - Paul

It needs to be *re-enforced to everyone* that a 1.00 release will absolutely
_not_ be available until sometime in 2011. What (may) be released in time
for Ubuntu 10.10 /will/ continue to evolve and receive changes, even
potentially evasive ones (Greek). Currently the debugging glyphs in the PUA
(giving definitive version and weight) were removed (bug #640623)---
something that was not requested, and it is likely to be preferable to
restore them to aid in on-going debugging.

  7b. Write+Include documentation in source/wiki/.deb - Paul, Dave, ...

Blocker until done: Prepare FAQs on contributing, feedback, design rationale
(collate DM blog posts), stylistic choices, licensing, future direction.
My belief is that the technical risks are lower than the
social/non-technical. Documentation is thus focused towards the latter.

  7c. Stale font version detection - TBC

In order for users to have a stable desktop environment, ...

[Paul Sladen (sladen)]

ETA: "next week".

  0a. 'ubuntu-typeface-interest' PPA access

Further attempts have been made to make contact with the second website.

  7b. Write+Include documentation in source/wiki/.deb - Paul, Dave, ...

Paul has worked on some FAQ documentation material.

[Mark Shuttleworth (sabdfl)]

Apologies for missing the Friday deadline for a view on the legals, I'm
reviewing today.

[Paul Sladen (sladen)]

ETA: "next week"

  0a. 'ubuntu-typeface-interest' PPA access
  7c. Stale font version detection - TBC

The second website have got in contact and been extremely helpful.
In addition to now pointing to the 'ubuntu-typeface-interest' wiki howto,
they have very usefully supplied a definitive set of four .ttf files---it
should be possible fingerprint against these and detect/warn the user
if they have stale versions present and the packaging system can't catch.

  1a. Short-term libre-licensing (bug #632411) - Mark + N

See comment #38 from Mark.

  1b. Longer-term libre-licensing - Mark + $others

Various tweaks in the last 24 hours. I'll let Dave pass this on to Mark
when he's comfortable.

  7b. Write+Include documentation in source/wiki/.deb - Paul, Dave, ...

FAQ additions and some other documentation. Anything about licensing will
have to be created following any decision.

  9. Upload to main archive - Paul

Blocked: lack of "source code" and licence.

Chatting over the weekend about bug #640526 ("DVCS/source layou"), I
suspect what we need to document _first_ is the build process being used
for the Ubuntu Font Family by Dalton Maag---this should then give a
definitive overview of what /software/ (and therefore what multiple-levels
of config/input files) there need to be, for the process to be replicated
by somebody else.

Additionally I have uff-0.68 in-hand, which I've held off uploading to
the PPA because of the missing debug glyphs. ...Although in the matra of
release-early release-often I'm tempted to upload anyway and deal with
the regression afterwards.

[Nicolas Spalinger (yosch)]

What are these longer-terms licensing issues?

[Paul Sladen (sladen)]

ETA: "next week"

  1a. Short-term libre-licensing (bug #632411) - Mark + N

Mark was able to spend some time on licensing work, so this aspect
has been inched forward. It is not finalised, but does appear to
be getting (much) closer. An email noted that even after any
decision(s), time will be needed to prepare documentation.

  1b. Longer-term libre-licensing - Mark + $others

I've replied to Nic's query above. Dave has forwarded his notes on.

  7a. .deb packaging (bug #633508)

Nicolas has noted that there should be a switch to using a
.orig.tar.gz setup, rather than a native .deb package---thus allowing
a more clear separation between what is upstream preparation work (eg.
sample sheets) and what is pure distro-packaging related. Number of
helpful pointers from Debian 'pkg-fonts' experience, so intention to
sort/separate/merge out the issues.

  7b. Write+Include documentation in source/wiki/.deb - Paul, Dave, ...

Good expansion of the FAQs (based on fielding for some /genuine/ asked
questions---some of which were quite fundamental and hard to answer!).

  9. Upload to main archive

Blocked: No licence; no source; upstream prep not done; packaging
not done.

Dalton Maag has added some more information which should move the
source/input files along (VOLT/VTT configuration discussion).

  AOB

uff-0.68 is still in-hand. Have been asked about webfont deployment.

[Mark Shuttleworth (sabdfl)]

 On 21/09/10 03:02, Paul Sladen wrote:
> uff-0.68 is still in-hand. Have been asked about webfont deployment.

I'd be interested in opinions as to whether Google's font directory is
the best place to publish for the webfont, or whether we should do this
off font.ubuntu.com.

Mark

[Paul Sladen (sladen)]

ETA guessimate: "next week"

  9. Upload to main archive

No license, no source. ...For the latter:

I had a good chat with Malcolm today at Dalton Maag---the build
process is much simpler than I'd expected. There are two input files
per font, one .vfb (FontLab) and one extended .ttf containing source
tables belonging to MS-VTT (from the previous revision). The
merging/overwriting is based on keeping a separate (manual) record of
what was changed higher up the stack in FontLab and then not importing
the metadata for those glyphs.

This means in terms of source code, we'd be getting/shipping three
files per weight, the last of which is the compiled .ttf (which people
are already familiar with) and the other two which would go in the
source distribution.

 13. Fix 'High' and 'Critical' bugs

Spent some time exploring fonttools/ttLib from Python and have a
proof-of- concept for re-injecting the debug glyphs from /code/,
rather than human time (much more reliable since they'll definitely
match!). Bug #640623.

  AOB

uff-0.68 is still in-hand. Discussed the issue of webfont deployment
with Mark---providing a working out-of-the-box/centralised offering
will likely encourage web developers and users to use that solution
rather than rolling their own---which more easily solves the problem
of keeping webfonts up-to-date.

[Alan Bell (alanbell)]

As for webfont deployment, I would like to see it on both Google's font directory (more people will find it opportunistically, hosting is fast, reliable, and someone else's problem.) and on font.ubuntu.com (no dependency on Google because who knows when they might start doing evil!).
I can't see any particularly good reason not to do both, possibly browsers will end up caching two copies of the font, one from each location? Not sure if there is the intelligence in the browser to avoid that - but personally I am not too bothered about it anyway, it isn't a vast amount of space and it wouldn't be a user-visible thing. Just like caching multiple copies of jquery and other javascript libraries really, that happens, nobody cares.

[Nicolas Spalinger (yosch)]

About webfonts deployment, I'd recommend you consider doing both Google Font Directory hosting and a dedicated Ubuntu-specific subdomain under the control of Canonical. The Ubuntu-specific subdomain would also allow for useful statistics to be gathered and shared publically.

 It's worth noting that maintainers of the Google Font Directory have a strict policy on licensing: only fonts under Apache2 and OFL1.1 have been considered for inclusion, the vast majority of fonts are released under the OFL (many authors have relicensed to OFL when submitting their creation to the directory). See Raph's introduction post: " Almost all the fonts are under the Open Font License, and in our discussions I've been sensing a huge amount of momentum behind this license. " http://advogato.org/person/raph/diary/420.html

[Paul Sladen (sladen)]

ETA guessimate: "next week" (things are getting uncomfortably tight).

  9. Upload to main archive

No license, no source.

Had a further quick chat with Malcom at Dalton Maag again today; there
is an optimisation step at the end of the process using MS CacheTT.
To recreate the current binary will also need the configuration file
used for this step aswell.

uff-0.68 is still in-hand.

[Alan Bell (alanbell)]

So with the webfont situation I would expect there to be a bit of a time consuming process to get on to the Google font directory, I am sure the font would qualify but licensing and glyph coverage and correctness seem to be things they are serious about validating carefully before hosting it. With the font.ubuntu.com approach we can adopt more of a "just get it done" approach. This would be good from my perspective as I am very keen to get http://ubingo.libertus.co.uk using a webfont deployment of the Ubuntu font by 25th October.

[Paul Sladen (sladen)]

ETA: "next week"

  9. Upload to main archive

Blocked: Lack of Licence

I've had a source code drop for 0.68 from DaltonMaag (thank you
Malcolm) with 4x Fontlab .vfb, 4x Visual TrueType .ttf source,
1x CacheTT configuration and 4x Output .ttfs.

I've had the go-ahead from Mark to upload these materials to the PPA
on the same basis as the current binary .ttfs. (Copyright Canonical,
no explicit Licence to do otherwise---standard Copyright applies).

The intention is to write a midstream (between upstream and
downstream) build step to rearrange the source materials into a native
package .orig.tar, following Nicholas' suggested layout/naming where
possible and incorporating the additional documentation content.

  AOB:

A small HTML-based microsite will be created, linking to
the existing Launchpad/Wiki/PPA locations and providing:

  1. Simple binary .zip containing 4x fonts
  2. Copy-and-paste webfont instructions

[Paul Sladen (sladen)]

ETA: Tuesday; aka Monday 2010-09-27 23:59 UTC

  When:

Robbie has notifed that the deadline is the above, and so that is the
target. Riddell is building CDs and is aware. This leaves 72^W...
60^W... 48^W... 42 hours, of I which I selfishly intend to reserve
some for sleeping.

  What:

The package will ship with the source available and the font-related
files under whatever licence Mark finalises at that point in time.
Documentation and code/script/packaging will be under GPLv3.

  font.ubuntu.com microsite (requested via RT)

The published URL for the Ubuntu Font Family will be
'font.ubuntu.com' and this will include a source .zip file, links to
PPA, Launchpad, Wiki, ... along with a copy-and-paste webfonts
configuration hosted on font.

  Webfonts:

Long term, an automatic build process can build the EOT/WOFF
web-optimised versions, but for the moment, can defer to Richard Lee
for current knowledge from fonttet.design.canonical.com.

The logistics of this /may/ be transferred off to a third party fairly
soon afterwards.

  Currency block:

At Mark's behest, there will be a push to get U+20B9 (the new Indian
Rupee Sign) populated with /something/, even if DM decide this wish
to tweak this later. We'll use this as a testbed for sending a
'patch' upstream, as well as getting it back again downstream:

 * https://bugs.launchpad.net/ubuntu-font-family/+bug/645987

  Documentation:

Collation of blogs/LP replies/off-list replies to cover as many design
rationale choices as possible. These will be GPLv3ed and shipped as
documentation in the "upstream" source tar, and Copyright Canonical.

  .deb

This will be converted to native and built off the expanded upstream
tarball (eg. ubuntu-font-family-0.68+doc) and (hopefully) meeting all
of Nicolas' requests.

  Licence formattting

Need as OOo and txt, for FAQs and markup.

  Licence switch over

Current intention is to patch the output .ttfs using Python to change
the licence, version and Family name inside them as the turnaround via
Dalton Maag might be too long... though as the code is not yet
written, this depends.

  Uploading

This bit is really easy assuming the paperwork checks out:

* Upload package (sladen)
* Source NEWed (riddell)
* Binary NEWed (riddell)
* MIR approval (doko, asac, kees)
* Migrate to main (riddell)
* Add to seeds (sladen)
* Add to meta packages (sladen)
* Upload meta packages (sladen)
* Accept meta packages (riddell)
* Re-build CDs lots (riddell)

  Limitation

Note, the priority here is to get it seeded and on to the CDs. If
some other party wishes to adapt their themes to use this installed
font package, then they will now be able to write their /own/ FFEs for
a theme tweak on their side!

  AOB

Lots of interesting conversations about Right-to-Left, Arabic and
Hebrew over the last couple of days, particularly in response to
Bruno's initial posting of the UFF Hebrew experiments in this
direction.

[Scott Kitterman (kitterman)]

Which ISOs do you believe this plan covers?

[Paul Sladen (sladen)]

ScottK: It is my understanding that seeding applies to Ubuntu Desktop and Ubuntu Alternate. Other derivative distributions, spins and remixes generated from the archive have flexibility over the packages which they choose to ship.

In the case of Kubuntu, when I raised the topic with the Kubuntu Council, the intention was to wait until a tangible package was in the archives under a Libre licence before considering seeding. If you have a list of suggested teams, or individuals which should be notified when/if this becomes the case, I will be happy to send out an appropriate notification, or they could be invited to subscribe to this bug report for updates.

[Nicolas Spalinger (yosch)]

I have now sent feedback to Mark on licensing issues.

[Vish (vish)]

Re-opening Ubuntu task as "someone involved in the font development actually wants it in."
Absence of which was the reason it was closed earlier in comment #10.

[Jonathan Riddell (jr)]

FFe approved