[DS-public] No video codecs for HTML5 because software patents :'(

[Nicolas Mailhot]

Le lundi 10 août 2009 à 17:18 +0200, Benjamin Henrion a écrit :
> On Sat, Aug 8, 2009 at 2:29 PM, Nicolas
> Mailhot<nicolas.mailhot at laposte.net> wrote:

> >> We do have a proposal for embedded fonts, but it did not make it into ODF
> >> 1.2.  We'll consider again for the next release.  But note that even with
> >> embedded fonts, you will not get perfect layout fidelity unless you
> >> specify every detail of the page layout algorithm.  For things such as
> >> line-breaking algorithms there are many choices (
> >> http://en.wikipedia.org/wiki/Word_wrap) and unless you agree to that level
> >> of detail, you will not get identical layouts, even if you had the same
> >> fonts.
> >
> > On the fonts side it is a mistake to think freezing a set of fonts is
> > the solution (freezing either by mandating a fixed set of font or by
> > embedding available fonts at creation time). Text processing and fonts
> > are evolving all the time if only because the Unicode consortium is
> > publishing encoding rule revisions regularly, and because existing fonts
> > do not handle complex/minority scripts in a satisfactory way.
> 
> The purpose of a standard is to freeze the technology at some point in time.

However a font file is not a "technology" it's an "implementation".
There is the same difference between freezing a font file and writing
standards, as between freezing a specific OO.o binary (bugs and all) vs
writing the ODF spec

PS

To answer other people questions,

1. SIL is indeed a libre font pioneer but its font development efforts
are largely in-house and not collaborative. They are contributing a lot
on the technical and legal fronts however 

2. the Greek Font Society publishes many great libre fonts, but is
rather inbred

3. on the Red Hat side Lohit and Liberation are slowly trying to morph
in DejaVu-like community projects, but success is limited so far
(Liberation lacks an energetic team leader to motivate people IMHO, and
Lohit requires complex indic skills to contribute). OTOH Red Hat has
funded for years core contributors to fontconfig, pango, cairo, etc (on
the library side)

4. Google Droid is nicely licensed but pretty much at the state
Liberation was a few years back (opaque code drops, no community
interaction at all)

5. and DejaVu remains the only project that managed to build something
close to a successful free/libre collaborative design effort. Though it
did disprove extensively the lone font creator myth.

The effect of the Open Font library is still to be seen

The main impedences to livre font creations efforts are :

1. the lack of any serious funding. Companies either do not pay anyone
or they pay Ascender /Bitream /URW /
insert-existing-proprietary-foundry-there to re-license/create a font.
There are no openings for talented art student to become paid libre font
designers the way they can hope to become paid libre software writers

2. the lack of buy-in by libre software houses. It takes years for
software companies to accept a font they didn't pay for is worth
redistributing. This is dispiriting to font creators (some people will
still insist today DejaVu is not a professional font even though it was
good enough for Apple to redistribute as Menlo. And Apple does not need
anyone to teach it about fonts)

3. the lack of legal and distributions conventions. A libre font project
will usually do all the mistakes libre software projects have grown out
of years ago: lack of clear licensing, lack of clear feedback channel,
no contributing instructions, magical undocumented build recipes, etc.
It is pretty symptomatic that the three major fonts released those past
years (Vera/Dejavu, Liberation, Droid) have three different licenses you
can not mix safely prohibiting sharing of font components. This makes it
very difficult for the average project to attract new blood

Thus font creation is mostly an organisationnal/social problem, not a
technical one.

-- 
Nicolas Mailhot
http://fonts.fedoraproject.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Ceci est une partie de message
 =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.digistan.org/pipermail/public/attachments/20090908/e51d1a3e/attachment.pgp