Help required for the application installer

[Richard Hughes]

Hi all,

I'm one of the main developers of gnome-software, which is an
application and addon installer which we're installing as a tech
preview in Fedora 20. In F20 the fonts are listed individually, with
untranslated names direct from the font itself. That means we get
several hundred "fonts" with no proper short descriptions, and the
names are less than ideal. For example:

"mnml icons", "M+ 1c black", "Droid Sans Fallback"

So, for Fedora 21 we're working more towards a mockup like
https://raw.github.com/gnome-design-team/gnome-mockups/master/software/ve...
-- don't worry too much about the glyph images in that screenshot, the
basic point I want to get across is that rather than showing
"lato-black-regular, lato-black-italic, lato-thin-regular,
lato-thin-italic" as separate fonts, we want to show "Lato" as a
_single_ addon, with 3 fonts (black, thin, regular) each with separate
styles (bold, italic, etc).

This means I need some extra metadata, and some translated
descriptions. This is where you kind people come in. I've setup a
spreadsheet with 4 columns here:
https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdC05ZlA0dEZTQmYy...

* The ID is what gnome-software uses internally, don't read too much
into the format.

* The  "Parent" is supposed to be the parent font name, so for
instance, "Lato Thin" and "Lato Black" would both have the parent of
"Lato"

* The "Name" is currently set at what the font provides us with, and
we can tweak this if requires, for instance "roadstencil" can become
"Road Stencil"

* The "Summary" is a one line description of the font, for instance
"Lato is a sanserif typeface family". You only need one description
per parent.

* The "Description" is a 2-3 paragraph description of the font, which
is optional as it's not currently shown in the mockup. It's included
here for completeness as it could be shown in the future when the user
clicks "More info".

I would be very grateful of any help, as all of you know two order of
magnitude more about fonts than me. If you also have any comments
about the UI mockups, either reply to this email, or ping me, jimmac
or aday in #gnome-design on GIMPNet.

I've filled in a few details on the spreadsheet[1] already, but feel
free to change what I've already done if it's wrong.

Thanks,

Richard

[1]
https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdC05ZlA0dEZTQmYy...

[Akira TAGOH]

----- Original Message -----
| * The ID is what gnome-software uses internally, don't read too much
| into the format.
| 
| * The  "Parent" is supposed to be the parent font name, so for
| instance, "Lato Thin" and "Lato Black" would both have the parent
of
| "Lato"

That is in fact a long standing issue or a long-term RFE in fontconfig. I'd manage to
fix/improve it though.

| 
| * The "Name" is currently set at what the font provides us with, and
| we can tweak this if requires, for instance "roadstencil" can become
| "Road Stencil"
| 
| * The "Summary" is a one line description of the font, for instance
| "Lato is a sanserif typeface family". You only need one description
| per parent.

Well, I have a plan to have a family class in the cache. it will be able to generate the
summary like the above automatically with it I believe.
That feature isn't yet merged into master because it requires bumping the cache
version.

| * The "Description" is a 2-3 paragraph description of the font, which
| is optional as it's not currently shown in the mockup. It's included
| here for completeness as it could be shown in the future when the user
| clicks "More info".

Why don't you simply pick it up from the package description? it should has enough
wording and having separate metadata looks duplicate to me though.

| 
| I would be very grateful of any help, as all of you know two order of
| magnitude more about fonts than me. If you also have any comments
| about the UI mockups, either reply to this email, or ping me, jimmac
| or aday in #gnome-design on GIMPNet.
| 
| I've filled in a few details on the spreadsheet[1] already, but feel
| free to change what I've already done if it's wrong.
| 
| Thanks,
| 
| Richard
| 
| [1]
|
https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdC05ZlA0dEZTQmYy...
| _______________________________________________
| fonts mailing list
| fonts(a)lists.fedoraproject.org
| https://admin.fedoraproject.org/mailman/listinfo/fonts
| http://fonts.fedoraproject.org/

--
Akira TAGOH

[Richard Hughes]

On 25 October 2013 11:52, Akira TAGOH <tagoh(a)redhat.com&gt; wrote:
>  Well, I have a plan to have a family class in the cache. it will be
> able to generate the summary like the above automatically with it I believe.
>  That feature isn't yet merged into master because it requires bumping the cache
> version. 
Right. I need the font metadata before the font is installed; I'm
currently using fontTools for this.

>  Why don't you simply pick it up from the package description? it
> should has enough wording and having separate metadata looks duplicate to me though.
Yes, I'll probably fall back to this. The big problem is the way some
fonts are split, and I want the description to be of the parent font,
and not the monospace version for example.

Richard.

[Nicolas Mailhot]

Le Ven 25 octobre 2013 13:00, Richard Hughes a écrit :
>  On 25 October 2013 11:52, Akira TAGOH <tagoh(a)redhat.com&gt;
> wrote:
> > Well, I have a plan to have a family class in the cache. it will be able
> > to generate the summary like the above automatically with it I believe.
> > That feature isn't yet merged into master because it requires bumping
> > the cache version.
>
>  Right. I need the font metadata before the font is installed; I'm
>  currently using fontTools for this.
>
> > Why don't you simply pick it up from the package description? it should
> > has enough wording and having separate metadata looks duplicate to me
> > though.
>
>  Yes, I'll probably fall back to this. The big problem is the way some
>  fonts are split, and I want the description to be of the parent font,
>  and not the monospace version for example. 
Monospace *is* a different font family. The CSS and Microsoft-defined
boundaries of a font family are anything that differs from another factor
that width, weight and slope. Please try to follow the specs split and not
invent yet another font classification, it's already hard enough with all
the legacy baggage out there.

https://blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-comp...

Regards,


-- 
Nicolas Mailhot

[Richard Hughes]

On 25 October 2013 12:55, Nicolas Mailhot <nicolas.mailhot(a)laposte.net&gt; wrote:
> > Yes, I'll probably fall back to this. The big problem is the
> way some
> > fonts are split, and I want the description to be of the parent font,
> > and not the monospace version for example.
>  Monospace *is* a different font family. 
Yes, sorry. A poor choice of example on my part. sans/serif would be a
better example.

Richard.

[Nicolas Mailhot]

Le Ven 25 octobre 2013 14:57, Richard Hughes a écrit :
>  On 25 October 2013 12:55, Nicolas Mailhot
> <nicolas.mailhot(a)laposte.net&gt;
>  wrote:
> >> Yes, I'll probably fall back to this. The big problem is the way some
> >> fonts are split, and I want the description to be of the parent font,
> >> and not the monospace version for example.
> > Monospace *is* a different font family.
>
>  Yes, sorry. A poor choice of example on my part. sans/serif would be a
>  better example. 
sans / sans serif are also two different font families. You have one
design with serifs and another without. That some designs have been made
by the same persons to work together does not change the fact you're
dealing with two objects (you'll note Microsoft never pretended its serif
and sans serif fonts where somehow the same family, they have very
different names).

A font family is a single design, where the only variables are weight,
width and slant. That permits CSS operators like bolder, lighter, wider,
narrower, oblique, italic. Anything else, that is not concrete enough to
define a software operator for, is too nebulous to base reliable
separations on. And you need reliable separations if you don't want your
app store to degenerate into the usual swamp font repositories are.

Sorry, it's easy to get confused :p

-- 
Nicolas Mailhot

[Nicolas Mailhot]

Le Ven 25 octobre 2013 12:52, Akira TAGOH a écrit :
>  ----- Original Message -----
>  | * The ID is what gnome-software uses internally, don't read too much
>  | into the format.
>  |
>  | * The  "Parent" is supposed to be the parent font name, so for
>  | instance, "Lato Thin" and "Lato Black" would both have the parent
> of
>  | "Lato"
>
>  That is in fact a long standing issue or a long-term RFE in fontconfig.
>  I'd manage to fix/improve it though. 
Also we already hide stuff like Droid fallback in fontconfig rules, it's a
pity it's not been completely plumbed into rpm. Right now the fontconfig
to rpm metadata exports only low-level font names not the preferred human
name.

And, unfortunately (++) not all font packages make the effort to unify
family names like Droid does, I've noticed a resurgence of per-script font
packages lately (will have to look at it more whenever personal life gaves
me the possibility)

>  | * The "Name" is currently set at what the font provides
> us with, and
>  | we can tweak this if requires, for instance "roadstencil" can become
>  | "Road Stencil" 
I'm not sure tweaking is a good idea here.

>  | * The "Summary" is a one line description of the font,
> for instance
>  | "Lato is a sanserif typeface family". You only need one description
>  | per parent.
>
>  Well, I have a plan to have a family class in the cache. it will be able
>  to generate the summary like the above automatically with it I believe.
>  That feature isn't yet merged into master because it requires bumping the
>  cache version. 
That would be great especially if you expose the WWS family name (after
the cleanups specified by Microsoft) and not the raw family name. That
would also help package reviews I fear a lot of persons do not understand
what a font family is despite the documentation efforts we've made in
guidelines. They just make a package by normal/bold/italic/bolditalic
quartets including when the font has been artificially split upstream to
workaround legacy non-linux software

>  | * The "Description" is a 2-3 paragraph description of the
> font, which
>  | is optional as it's not currently shown in the mockup. It's included
>  | here for completeness as it could be shown in the future when the user
>  | clicks "More info".
>
>  Why don't you simply pick it up from the package description? it should
>  has enough wording and having separate metadata looks duplicate to me
>  though. 
Ideally, the package description and the store description would match
upstream font metadata, unfortunately font metadata state is usually quite
bad.

Regards,

-- 
Nicolas Mailhot

[Behdad Esfahbod]

On 13-10-25 01:51 PM, Nicolas Mailhot wrote:
>  Also we already hide stuff like Droid fallback in fontconfig rules,
> it's a
>  pity it's not been completely plumbed into rpm. Right now the fontconfig
>  to rpm metadata exports only low-level font names not the preferred human
>  name. 
Initially the fontconfig+rpm hook was done using fc-query.  My plan was to one
day switch it to fc-scan, which applies configuration to the resulting
pattern, but then we need to make sure it 1. uses pristine config, not
whatever's on the system, and 2. use the current package's configuration in
addition to the default config.

Anyway, I'm sure someone can make it work, and I really hope Richard can find
a way to use fontconfig for what he's doing.  Having separate metadata
extraction paths is recipe for disaster.

Cheers,
-- 
behdad
http://behdad.org/