[PATCH 2/2] gnu: Add 'ttf-liberation'.

[PATCH 2/2] gnu: Add 'ttf-liberation'.

[Alex Kost]

[-- Attachment #1: Type: text/plain, Size: 152 bytes --]

Not related to this patch: what about renaming ‘freefont-ttf’ package
into ‘ttf-freefont’ to make all TrueType fonts have a name "ttf-…"?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-gnu-Add-ttf-liberation.patch --]
[-- Type: text/x-diff, Size: 3355 bytes --]

From 5cddcfb5939bd783527194381e4a8e107fc39395 Mon Sep 17 00:00:00 2001
From: Alex Kost <alezost@gmail.com>
Date: Tue, 28 Oct 2014 09:44:16 +0300
Subject: [PATCH 2/2] gnu: Add 'ttf-liberation'.

* gnu/packages/fonts.scm (ttf-liberation): New variable.
---
 gnu/packages/fonts.scm | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)

diff --git a/gnu/packages/fonts.scm b/gnu/packages/fonts.scm
index 825395b..94bf79d 100644
--- a/gnu/packages/fonts.scm
+++ b/gnu/packages/fonts.scm
@@ -203,6 +203,71 @@ package provides the TrueType (TTF) files.")
 10646/Unicode UCS (Universal Character Set).")
    (license license:gpl3+)))
 
+(define-public ttf-liberation
+  (package
+    (name "ttf-liberation")
+    (version "2.00.1")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append "https://fedorahosted.org/releases/l/i/"
+                                  "liberation-fonts/liberation-fonts-ttf-"
+                                  version ".tar.gz"))
+              (sha256
+               (base32
+                "010m4zfqan4w04b6bs9pm3gapn9hsb18bmwwgp2p6y6idj52g43q"))))
+    (build-system trivial-build-system)
+    (arguments
+     `(#:modules ((guix build utils))
+       #:builder
+       (begin
+         (use-modules (guix build utils))
+
+         (let ((tar      (string-append (assoc-ref %build-inputs "tar")
+                                        "/bin/tar"))
+               (PATH     (string-append (assoc-ref %build-inputs "gzip")
+                                        "/bin"))
+               (font-dir (string-append %output "/share/fonts/truetype"))
+               (doc-dir  (string-append %output "/share/doc/" ,name)))
+           (setenv "PATH" PATH)
+           (system* tar "xvf" (assoc-ref %build-inputs "source"))
+           (mkdir-p font-dir)
+           (mkdir-p doc-dir)
+           (chdir (string-append "liberation-fonts-ttf-" ,version))
+           (for-each (lambda (ttf)
+                       (copy-file ttf
+                                  (string-append font-dir "/"
+                                                 (basename ttf))))
+                     (find-files "." "\\.ttf$"))
+           (for-each (lambda (doc)
+                       (copy-file doc
+                                  (string-append doc-dir "/"
+                                                 (basename doc))))
+                     '("AUTHORS" "ChangeLog" "LICENSE" "README" "TODO"))))))
+    (native-inputs
+     `(("source" ,source)
+       ("tar" ,tar)
+       ("gzip" ,gzip)))
+    (home-page "https://fedorahosted.org/liberation-fonts/")
+    (synopsis
+     "Fonts compatible with Arial, Times New Roman, and Courier New")
+    (description
+     "The Liberation font family aims at metric compatibility with
+Arial, Times New Roman, and Courier New.
+
+There are three sets:
+
+- Sans (a substitute for Arial, Albany, Helvetica, Nimbus Sans L, and
+Bitstream Vera Sans);
+
+- Serif (a substitute for Times New Roman, Thorndale, Nimbus Roman, and
+Bitstream Vera Serif);
+
+- Mono (a substitute for Courier New, Cumberland, Courier, Nimbus Mono L,
+and Bitstream Vera Sans Mono).
+
+The Liberation Fonts are sponsored by Red Hat.")
+    (license license:silofl1.1)))
+
 (define-public terminus-font
   (package
     (name "terminus-font")
-- 
2.1.2

Re: [PATCH 2/2] gnu: Add 'ttf-liberation'.

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Not related to this patch: what about renaming ‘freefont-ttf’ package
> into ‘ttf-freefont’ to make all TrueType fonts have a name "ttf-…"?

I think so.  What do others think?  Andreas?

> From 5cddcfb5939bd783527194381e4a8e107fc39395 Mon Sep 17 00:00:00 2001
> From: Alex Kost <alezost@gmail.com>
> Date: Tue, 28 Oct 2014 09:44:16 +0300
> Subject: [PATCH 2/2] gnu: Add 'ttf-liberation'.
>
> * gnu/packages/fonts.scm (ttf-liberation): New variable.

LGTM.

Ludo’.

Re: [PATCH 2/2] gnu: Add 'ttf-liberation'.

[Andreas Enge]

On Tue, Oct 28, 2014 at 09:10:30AM +0100, Ludovic Courtès wrote:
> Alex Kost <alezost@gmail.com> skribis:
> > Not related to this patch: what about renaming ‘freefont-ttf’ package
> > into ‘ttf-freefont’ to make all TrueType fonts have a name "ttf-…"?
> I think so.  What do others think?  Andreas?

So far, we have no special rules for font naming. So...

> > Subject: [PATCH 2/2] gnu: Add 'ttf-liberation'.
> > * gnu/packages/fonts.scm (ttf-liberation): New variable.

...the package should be called liberation-fonts-ttf.

We could install a rule similar to that for python modules, that we always
add ttf in front of true type fonts, or move it in front if it is already
in the name. But I am not convinced this is a good choice: Being truetype
is not inherent to a font, it is just a format, and a package may contain
the same font (or several ones) in different formats. What would we do then?

It would be more reasonable to add "font-" in front. But I am also not too
fond of this.

Andreas

Re: [PATCH 2/2] gnu: Add 'ttf-liberation'.

[Alex Kost]

Andreas Enge (2014-10-30 01:16 +0300) wrote:

> On Tue, Oct 28, 2014 at 09:10:30AM +0100, Ludovic Courtès wrote:
>> Alex Kost <alezost@gmail.com> skribis:
>> > Not related to this patch: what about renaming ‘freefont-ttf’ package
>> > into ‘ttf-freefont’ to make all TrueType fonts have a name "ttf-…"?
>> I think so.  What do others think?  Andreas?
>
> So far, we have no special rules for font naming. So...
>
>> > Subject: [PATCH 2/2] gnu: Add 'ttf-liberation'.
>> > * gnu/packages/fonts.scm (ttf-liberation): New variable.
>
> ...the package should be called liberation-fonts-ttf.

Why should?  What about “ttf-dejavu”?  Should it be called
“dejavu-fonts-ttf” then?

> We could install a rule similar to that for python modules, that we always
> add ttf in front of true type fonts, or move it in front if it is already
> in the name. But I am not convinced this is a good choice: Being truetype
> is not inherent to a font, it is just a format, and a package may contain
> the same font (or several ones) in different formats. What would we do then?

Then it shouldn't be prefixed with "ttf".  I suggest to use "ttf-…" name
only for packages that provide truetype fonts only.  As for the other
font packages, I think they should have "font"/"fonts" in their names,
no matter would it be in the beginning (font-misc-ethiopic) or in the
end (terminus-font).

> It would be more reasonable to add "font-" in front. But I am also not too
> fond of this.
>
> Andreas

Re: [PATCH 2/2] gnu: Add 'ttf-liberation'.

[Andreas Enge]

On Thu, Oct 30, 2014 at 10:27:49AM +0300, Alex Kost wrote:
> Why should?  What about “ttf-dejavu”?  Should it be called
> “dejavu-fonts-ttf” then?

Yes, that was a mistake, maybe inspired from the debian package name.
We should rename it.

> Then it shouldn't be prefixed with "ttf".  I suggest to use "ttf-…" name
> only for packages that provide truetype fonts only.  As for the other
> font packages, I think they should have "font"/"fonts" in their names,
> no matter would it be in the beginning (font-misc-ethiopic) or in the
> end (terminus-font).

Then what if it contains other types of fonts? Texlive-data/texfm-dist/fonts
contains the following 20 subdirectories:
afm  cmap  fea  map   ofm       ovf  pfm  sfd     tfm       type1
cid  enc   lig  misc  opentype  ovp  pk   source  truetype  vf
(not all of them are fonts, some are just metrics and some I do not know).
Would you suggest to use prefixes type1-, opentype-, pk- also?
Only if the package contains exactly one format? I think modifying our
package name rules for fonts will open a can of worms.

Andreas

Re: [PATCH 2/2] gnu: Add 'ttf-liberation'.

[Alex Kost]

Andreas Enge (2014-10-30 10:56 +0300) wrote:

> On Thu, Oct 30, 2014 at 10:27:49AM +0300, Alex Kost wrote:
>> Why should?  What about “ttf-dejavu”?  Should it be called
>> “dejavu-fonts-ttf” then?
>
> Yes, that was a mistake, maybe inspired from the debian package name.
> We should rename it.

I don't understand why you call it a mistake.  It's just a package name
used by some distributions (and I think it's a good name).  Is there a
convention to use “…-fonts-ttf” in Guix?

>> Then it shouldn't be prefixed with "ttf".  I suggest to use "ttf-…" name
>> only for packages that provide truetype fonts only.  As for the other
>> font packages, I think they should have "font"/"fonts" in their names,
>> no matter would it be in the beginning (font-misc-ethiopic) or in the
>> end (terminus-font).
>
> Then what if it contains other types of fonts? Texlive-data/texfm-dist/fonts
> contains the following 20 subdirectories:
> afm  cmap  fea  map   ofm       ovf  pfm  sfd     tfm       type1
> cid  enc   lig  misc  opentype  ovp  pk   source  truetype  vf
> (not all of them are fonts, some are just metrics and some I do not know).
> Would you suggest to use prefixes type1-, opentype-, pk- also?
> Only if the package contains exactly one format? I think modifying our
> package name rules for fonts will open a can of worms.

I think they should be called “texlive-…”.

What I see in "Arch Linux" is a lot of “ttf-…” packages (including
“ttf-liberation” and “ttf-dejavu”).  IIUC Debian uses the same names for
TrueType fonts.  And I like it.  But anyway, if “liberation-fonts-ttf”
is the prefered variant, I'll fix my patch.  But I think “ttf-dejavu”
should be renamed into “dejavu-fonts-ttf” at first.  And what about
“freefont-ttf” and “ttf-bitstream-vera”?

Re: [PATCH 2/2] gnu: Add 'ttf-liberation'.

[Andreas Enge]

On Thu, Oct 30, 2014 at 03:52:50PM +0300, Alex Kost wrote:
> I don't understand why you call it a mistake.  It's just a package name
> used by some distributions (and I think it's a good name).  Is there a
> convention to use “…-fonts-ttf” in Guix?

It may be a good name, but the Guix convention is to not choose names, but
to simply use the upstream name. This is described in the packaging
guidelines, section 6.5.2 of the documentation:
"Both are usually the same and correspond to the lowercase conversion of
the project name chosen upstream, with underscores replaced with hyphens".
So liberation-fonts-ttf-2.00.1.tar.gz becomes liberation-fonts-ttf.
(Admittedly "project name" is a bit vague; it means "tarball name", the
aim is not to call all packages of the x.org system x-org, so that
only one of them could be installed ;-)).

And dejavu-fonts-ttf-2.34.tar.bz2 should become dejavu-fonts-ttf. 

And font-adobe-100dpi-1.0.3.tar.bz2 should have become font-adobe-100dpi,
but apparently I made a mistake and called it font-adobe100dpi.
Another mistake to correct. In particular, it is not called
adobe-100dpi-fonts-pcf.


We have different naming rules for python and perl modules. We could also
agree on different naming rules for fonts. But they would need to be
consistent, in particular over different font formats, and mechanically
applicable. Personally, I do not see a pressing need.

Andreas

Re: [PATCH 2/2] gnu: Add 'ttf-liberation'.

[Alex Kost]

Andreas Enge (2014-10-30 16:36 +0300) wrote:

> On Thu, Oct 30, 2014 at 03:52:50PM +0300, Alex Kost wrote:
>> I don't understand why you call it a mistake.  It's just a package name
>> used by some distributions (and I think it's a good name).  Is there a
>> convention to use “…-fonts-ttf” in Guix?
>
> It may be a good name, but the Guix convention is to not choose names, but
> to simply use the upstream name. This is described in the packaging
> guidelines, section 6.5.2 of the documentation:
> "Both are usually the same and correspond to the lowercase conversion of
> the project name chosen upstream, with underscores replaced with hyphens".
> So liberation-fonts-ttf-2.00.1.tar.gz becomes liberation-fonts-ttf.
> (Admittedly "project name" is a bit vague; it means "tarball name", the
> aim is not to call all packages of the x.org system x-org, so that
> only one of them could be installed ;-)).
>
> And dejavu-fonts-ttf-2.34.tar.bz2 should become dejavu-fonts-ttf.
>
> And font-adobe-100dpi-1.0.3.tar.bz2 should have become font-adobe-100dpi,
> but apparently I made a mistake and called it font-adobe100dpi.
> Another mistake to correct. In particular, it is not called
> adobe-100dpi-fonts-pcf.

Thank you for the explanation, so a package with "Symbola" font
(http://lists.gnu.org/archive/html/guix-devel/2014-10/msg00279.html)
should be called just "symbola"?

Font package naming convention

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> Andreas Enge (2014-10-30 10:56 +0300) wrote:
>
>> On Thu, Oct 30, 2014 at 10:27:49AM +0300, Alex Kost wrote:
>>> Why should?  What about “ttf-dejavu”?  Should it be called
>>> “dejavu-fonts-ttf” then?
>>
>> Yes, that was a mistake, maybe inspired from the debian package name.
>> We should rename it.
>
> I don't understand why you call it a mistake.  It's just a package name
> used by some distributions (and I think it's a good name).  Is there a
> convention to use “…-fonts-ttf” in Guix?

There’s no documented convention (yet), so it’s not a mistake strictly
speaking.  :-)

>>> Then it shouldn't be prefixed with "ttf".  I suggest to use "ttf-…" name
>>> only for packages that provide truetype fonts only.  As for the other
>>> font packages, I think they should have "font"/"fonts" in their names,
>>> no matter would it be in the beginning (font-misc-ethiopic) or in the
>>> end (terminus-font).
>>
>> Then what if it contains other types of fonts? Texlive-data/texfm-dist/fonts
>> contains the following 20 subdirectories:
>> afm  cmap  fea  map   ofm       ovf  pfm  sfd     tfm       type1
>> cid  enc   lig  misc  opentype  ovp  pk   source  truetype  vf
>> (not all of them are fonts, some are just metrics and some I do not know).
>> Would you suggest to use prefixes type1-, opentype-, pk- also?
>> Only if the package contains exactly one format? I think modifying our
>> package name rules for fonts will open a can of worms.
>
> I think they should be called “texlive-…”.
>
> What I see in "Arch Linux" is a lot of “ttf-…” packages (including
> “ttf-liberation” and “ttf-dejavu”).  IIUC Debian uses the same names for
> TrueType fonts.  And I like it.  But anyway, if “liberation-fonts-ttf”
> is the prefered variant, I'll fix my patch.  But I think “ttf-dejavu”
> should be renamed into “dejavu-fonts-ttf” at first.  And what about
> “freefont-ttf” and “ttf-bitstream-vera”?

I think we must settle on a convention, and I would personally prefer to
follow the principle of least surprise–i.e., choose a convention that is
already widespread elsewhere.

WDYT?

Ludo’.

Re: Font package naming convention

[Andreas Enge]

On Thu, Oct 30, 2014 at 06:20:46PM +0100, Ludovic Courtès wrote:
> There’s no documented convention (yet), so it’s not a mistake strictly
> speaking.  :-)

We have a convention for package names, including fonts; so strictly speaking
it is a mistake.

> I think we must settle on a convention, and I would personally prefer to
> follow the principle of least surprise–i.e., choose a convention that is
> already widespread elsewhere.

We need not settle on a convention as we already have one for packages.
But we could choose another one close to the naming of python and perl modules
if enough people wish to have special rules for fonts.

Andreas

Re: Font package naming convention

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Thu, Oct 30, 2014 at 06:20:46PM +0100, Ludovic Courtès wrote:
>> There’s no documented convention (yet), so it’s not a mistake strictly
>> speaking.  :-)
>
> We have a convention for package names, including fonts;

You mean the convention of choosing the upstream name, right?

> But we could choose another one close to the naming of python and perl modules
> if enough people wish to have special rules for fonts.

Yes, it would make sense to take this route for fonts and have something
akin to what Alex just suggested, because the upstream name is only
occasionally going match one’s expectations.

How does that sound?

Ludo’.

Re: Font package naming convention

[Alex Kost]

Ludovic Courtès (2014-10-30 20:20 +0300) wrote:

[...]

> I think we must settle on a convention, and I would personally prefer to
> follow the principle of least surprise–i.e., choose a convention that is
> already widespread elsewhere.

I agree with that and I would prefer to see:

  ttf-bitstream-vera
  ttf-dejavu
  ttf-freefont
  ttf-liberation
  ttf-symbola

instead of (following the upstream name):

  ttf-bitstream-vera
  dejavu-fonts-ttf
  freefont-ttf
  liberation-fonts-ttf
  symbola

-- 
Alex

Re: Font package naming convention

[Alex Kost]

Andreas Enge (2014-10-30 22:17 +0300) wrote:

> On Thu, Oct 30, 2014 at 09:55:34PM +0300, Alex Kost wrote:
>> I agree with that and I would prefer to see:
>>   ttf-bitstream-vera
>>   ttf-dejavu
>>   ttf-freefont
>>   ttf-liberation
>>   ttf-symbola

I suggest this ↑  IIUC it is a common practice in other distributions.

>> instead of (following the upstream name):
>>   ttf-bitstream-vera
>>   dejavu-fonts-ttf
>>   freefont-ttf
>>   liberation-fonts-ttf
>>   symbola

Andreas prefers this ↑

> This is not quite consistent, as you sometimes drop "fonts", sometimes keep
> "font". Adapting the python convention (put "ttf-" in front, drop all other
> occurrences of "ttf" and resulting double dashes) would end up with:
>  ttf-bitstream-vera
>  ttf-dejavu-fonts
>  ttf-freefont
>  ttf-liberation-fonts
>  ttf-symbola

I don't suggest that ↑

> Dropping additonally all occurrences of "fonts" and "font" would end up with:
>  ttf-bitstream-vera
>  ttf-dejavu
>  ttf-free        <-- somewhat silly
>  ttf-liberation
>  ttf-symbola

And I don't suggest that ↑

I'm against any strict binding to an upstream name.  Why should we stick
to a (potentially strange) upstream name if we know better how a package
should be called?

What do other people think?

Re: Font package naming convention

[Andreas Enge]

On Fri, Oct 31, 2014 at 01:02:44AM +0300, Alex Kost wrote:
> I suggest this ↑  IIUC it is a common practice in other distributions.

This is absolutely no argument for us! We have quite a few different
practices from other distributions (and some of them are more logical,
I think, like trying to stick to upstream instead of making our life
more difficult).

> Andreas prefers this ↑

I did not say this. I simply pointed out two different "algorithmic" naming
schemes in the sense that there is an algorithm transforming an upstream name
into a package name. Both have strange effects, I think.

> I'm against any strict binding to an upstream name.  Why should we stick
> to a (potentially strange) upstream name if we know better how a package
> should be called?

This is what we have done so far and it is part of the packaging guidelines.
Otherwise there would be absolutely no limit to renaming and bikeshedding.
What if you think that "foo" should be renamed "bar" and I think it should
be renamed "truc"?

If you want to make a suggestion of a naming scheme that others can follow,
please come up with a description of an algorithm as for python modules -
a transformation of an upstream name into a package name.

To be constructive (which is a bit difficult, as I am still not convinced
we should have a special naming scheme for fonts, but admittedly it has
advantages!), here are a few questions that we should answer:

1)
Do we want to have the font format as part of the name?
Not having it would make things easier for packages containing several
formats; a user looking only for special types of fonts would then have to
go through the package descriptions. We could then prepend "font" or "fonts"
to the package name and drop it from inside (or keep it additionally inside,
which would be somewhat strange, but would avoid strange names occurring for
"unifont", for instance).

2)
Do we distinguish between packages containing one font (possibly in several
variants), prepending it with "font-", and packages containing several
fonts, prepending it with "fonts-", or do we go with a common prefix?

3)
If we want to add the font format to the package name, which font formats
do we want to "support"? We need a complete list.

4)
For the sake of argument, assume we decided on ttf and otf in 2).
Then packages containing only ttf could be prepended with "ttf" or "ttf-font"
or something like this, likewise for packages containing only otf.
We could use the "file extension" such as "ttf", or any longer version
such as "true-type-fonts".

What would we do for packages containing exactly both?
None of them?
ttf and others?
otf and others?
ttf, otf and others?
There are several solutions to this.
Notice that if our list of font formats has n entries, we have 2^n-1 possible
combinations. So the longer the list, the less reasonable it seems to prepend
all contained formats.
Notice that such a naming scheme also puts the burden on the packager of
determining the exact list of font formats contained in an upstream package.

I think we need to provide answers to these questions and maybe others I
overlooked.

With the hope that this rather long message may advance the discussion,

Andreas

Re: Font package naming convention

[Andreas Enge]

On Fri, Oct 31, 2014 at 06:58:40PM +0100, Andreas Enge wrote:
> On Fri, Oct 31, 2014 at 01:02:44AM +0300, Alex Kost wrote:
> > Andreas prefers this ↑
> I did not say this.

Sorry, I actually did prefer this ;-)  But I am open to discussion.

Andreas

Re: Font package naming convention

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Fri, Oct 31, 2014 at 01:02:44AM +0300, Alex Kost wrote:

[...]

>> I'm against any strict binding to an upstream name.  Why should we stick
>> to a (potentially strange) upstream name if we know better how a package
>> should be called?
>
> This is what we have done so far and it is part of the packaging guidelines.

Yes, and I think we should stick to that for software packages, with the
already-documented exceptions of ‘perl-’ and ‘python-’.

Now, I think a good reason to add an exception for fonts is that it
would make it easier to search for them: a software package can be
searched by keyword quite reasonably (with ‘guix package --search’ &
co.), but this is not the case for a font.  Being able to type ‘guix
package -A ^font’ (say) is convenient.

Furthermore, unlike software packages, what matters here is the actual
name of the font or font collection, not the “system name” or “tarball
name.”

> 1)
> Do we want to have the font format as part of the name?
> Not having it would make things easier for packages containing several
> formats; a user looking only for special types of fonts would then have to
> go through the package descriptions. We could then prepend "font" or "fonts"
> to the package name and drop it from inside (or keep it additionally inside,
> which would be somewhat strange, but would avoid strange names occurring for
> "unifont", for instance).
>
> 2)
> Do we distinguish between packages containing one font (possibly in several
> variants), prepending it with "font-", and packages containing several
> fonts, prepending it with "fonts-", or do we go with a common prefix?
>
> 3)
> If we want to add the font format to the package name, which font formats
> do we want to "support"? We need a complete list.
>
> 4)
> For the sake of argument, assume we decided on ttf and otf in 2).
> Then packages containing only ttf could be prepended with "ttf" or "ttf-font"
> or something like this, likewise for packages containing only otf.
> We could use the "file extension" such as "ttf", or any longer version
> such as "true-type-fonts".

All good points, indeed.

I’m not completely sure we can come up with a strict algorithm for the
naming scheme that we will not want to change two weeks later.  ;-)

Here’s a possible answer to the above questions, informally:

  • Use ‘font-FOUNDRY-FAMILY’ or ‘font-FAMILY’ or
    ‘font-FOUNDRY-COLLECTION’ or ‘font-COLLECTION’ as the name.

    Examples: ‘font-bitstream-vera’, ‘font-liberation’, ‘font-unifont’.

  • Use ‘font-.*-FORMAT’ only when there happens to be separate packages
    for separate formats.  FORMAT would be the format short name, like
    ‘ttf’, ‘otf’, ‘type1’.

WDYT, fellow nitpickers?  :-)

IMO the goal should be to find something convenient for users.
Sometimes, maybe, there will be several valid choices for the package
name, but that’s fine, I think.

Ludo’.

Re: Font package naming convention

[Andreas Enge]

On Fri, Oct 31, 2014 at 10:30:24PM +0100, Ludovic Courtès wrote:
> Furthermore, unlike software packages, what matters here is the actual
> name of the font or font collection, not the “system name” or “tarball
> name.”
> Here’s a possible answer to the above questions, informally:
>   • Use ‘font-FOUNDRY-FAMILY’ or ‘font-FAMILY’ or
>     ‘font-FOUNDRY-COLLECTION’ or ‘font-COLLECTION’ as the name.
>     Examples: ‘font-bitstream-vera’, ‘font-liberation’, ‘font-unifont’.
>   • Use ‘font-.*-FORMAT’ only when there happens to be separate packages
>     for separate formats.  FORMAT would be the format short name, like
>     ‘ttf’, ‘otf’, ‘type1’.
> WDYT, fellow nitpickers?  :-)

This sounds like quite an interesting solution - so we would completely drop
the upstream package name and only go for the font name (which would normally
be some part of the upstream package name, I suppose).

What would be the role of FOUNDRY? Should we try to find it out for most
fonts, or would it only be there to avoid confusions for fonts such as
Garamond?

> IMO the goal should be to find something convenient for users.
> Sometimes, maybe, there will be several valid choices for the package
> name, but that’s fine, I think.

Maybe we could refine the rules once an ambiguity occurs and see if we can
lift it.

One suggestion: I would like to keep the names of the x.org fonts as they
are, following the software package guidelines. I think they are more software
than fonts that actual users would employ to typeset their documents.

Andreas

Re: Font package naming convention

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Fri, Oct 31, 2014 at 10:30:24PM +0100, Ludovic Courtès wrote:
>> Furthermore, unlike software packages, what matters here is the actual
>> name of the font or font collection, not the “system name” or “tarball
>> name.”
>> Here’s a possible answer to the above questions, informally:
>>   • Use ‘font-FOUNDRY-FAMILY’ or ‘font-FAMILY’ or
>>     ‘font-FOUNDRY-COLLECTION’ or ‘font-COLLECTION’ as the name.
>>     Examples: ‘font-bitstream-vera’, ‘font-liberation’, ‘font-unifont’.
>>   • Use ‘font-.*-FORMAT’ only when there happens to be separate packages
>>     for separate formats.  FORMAT would be the format short name, like
>>     ‘ttf’, ‘otf’, ‘type1’.
>> WDYT, fellow nitpickers?  :-)
>
> This sounds like quite an interesting solution - so we would completely drop
> the upstream package name and only go for the font name (which would normally
> be some part of the upstream package name, I suppose).
>
> What would be the role of FOUNDRY? Should we try to find it out for most
> fonts, or would it only be there to avoid confusions for fonts such as
> Garamond?

Some fonts are created by hobbyists rather than a foundry.

Some of the fonts created by foundries are often referred to it using
the foundry’s name, such as “Bitstream Vera”; there are also
counter-examples, like Gentium, Charis, etc. (by SIL.)

So, again very informally, I would suggest to use the foundry name in
cases where people expect to see it, and in cases where it removes
ambiguity with similarly-named fonts.

What do people think?

>> IMO the goal should be to find something convenient for users.
>> Sometimes, maybe, there will be several valid choices for the package
>> name, but that’s fine, I think.
>
> Maybe we could refine the rules once an ambiguity occurs and see if we can
> lift it.

Sure.

> One suggestion: I would like to keep the names of the x.org fonts as they
> are, following the software package guidelines. I think they are more software
> than fonts that actual users would employ to typeset their documents.

Yes, I agree.

Thanks,
Ludo’.

Re: Font package naming convention

[Andreas Enge]

On Sun, Nov 02, 2014 at 06:18:19PM +0100, Ludovic Courtès wrote:
> Some of the fonts created by foundries are often referred to it using
> the foundry’s name, such as “Bitstream Vera”; there are also
> counter-examples, like Gentium, Charis, etc. (by SIL.)
> 
> So, again very informally, I would suggest to use the foundry name in
> cases where people expect to see it, and in cases where it removes
> ambiguity with similarly-named fonts.
> 
> What do people think?

I think it would be nice to add the foundry when it is know, such as
sil-gentium etc.; personally I find it an interesting information to have
(we would get a complete list of all packages sil fonts, for instance).

Andreas

Re: Font package naming convention

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Sun, Nov 02, 2014 at 06:18:19PM +0100, Ludovic Courtès wrote:
>> Some of the fonts created by foundries are often referred to it using
>> the foundry’s name, such as “Bitstream Vera”; there are also
>> counter-examples, like Gentium, Charis, etc. (by SIL.)
>> 
>> So, again very informally, I would suggest to use the foundry name in
>> cases where people expect to see it, and in cases where it removes
>> ambiguity with similarly-named fonts.
>> 
>> What do people think?
>
> I think it would be nice to add the foundry when it is know, such as
> sil-gentium etc.; personally I find it an interesting information to have
> (we would get a complete list of all packages sil fonts, for instance).

OK, it makes sense to me.

If there’s rough consensus on this, the next step would be to write this
informal rule in the manual, and to update package names.

Any volunteer?  Alex?  :-)

Thanks,
Ludo’.

Re: Font package naming convention

[Andreas Enge]

On Mon, Nov 03, 2014 at 09:53:21AM +0100, Ludovic Courtès wrote:
> If there’s rough consensus on this, the next step would be to write this
> informal rule in the manual, and to update package names.
> 
> Any volunteer?  Alex?  :-)

I volunteer, as I feel responsible for the package guidelines.

Andreas

Re: Font package naming convention

[Alex Kost]

Andreas Enge (2014-11-03 12:30 +0300) wrote:

> On Mon, Nov 03, 2014 at 09:53:21AM +0100, Ludovic Courtès wrote:
>> If there’s rough consensus on this, the next step would be to write this
>> informal rule in the manual, and to update package names.
>> 
>> Any volunteer?  Alex?  :-)
>
> I volunteer, as I feel responsible for the package guidelines.

Great!  Thanks and sorry if my messages here were offensive.  I'm going
to update and resend my patch with liberation fonts package for the new
convention when the names of the existing font packages will be updated.

-- 
Alex

Re: Font package naming convention

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Mon, Nov 03, 2014 at 09:53:21AM +0100, Ludovic Courtès wrote:
>> If there’s rough consensus on this, the next step would be to write this
>> informal rule in the manual, and to update package names.
>> 
>> Any volunteer?  Alex?  :-)
>
> I volunteer, as I feel responsible for the package guidelines.

Perfect, thank you!

Ludo’.

Re: Font package naming convention

[Ludovic Courtès]

I think there were a couple of packages submitted, notably the
Liberation font.

What about resubmitting them following the agreed-upon naming
convention, Alex?

Andreas, could you take a look at updating the guidelines?  Do you want
to handle the rename of existing font packages as well?

Thanks,
Ludo’.

Re: Font package naming convention

[Andreas Enge]

On Wed, Nov 19, 2014 at 10:01:15AM +0100, Ludovic Courtès wrote:
> Andreas, could you take a look at updating the guidelines?  Do you want
> to handle the rename of existing font packages as well?

Indeed I had volunteered, but not found the time. I revolunteer ;-)

Andreas

Re: Font package naming convention

[Alex Kost]

Ludovic Courtès (2014-11-19 12:01 +0300) wrote:

> I think there were a couple of packages submitted, notably the
> Liberation font.
>
> What about resubmitting them following the agreed-upon naming
> convention, Alex?

Sure, I'm just waiting for the existing packages to be updated, because
I don't fully understand how the liberation package should be named now.
“font-liberation”?

> Andreas, could you take a look at updating the guidelines?  Do you want
> to handle the rename of existing font packages as well?
>
> Thanks,
> Ludo’.

-- 
Alex

[PATCH] gnu: Add 'font-liberation'.

[Alex Kost]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

Alex Kost (2014-11-20 10:09 +0300) wrote:

> Ludovic Courtès (2014-11-19 12:01 +0300) wrote:
>
>> I think there were a couple of packages submitted, notably the
>> Liberation font.
>>
>> What about resubmitting them following the agreed-upon naming
>> convention, Alex?
>
> Sure, I'm just waiting for the existing packages to be updated, because
> I don't fully understand how the liberation package should be named now.
> “font-liberation”?

Andreas "confirmed" this name in his font convention patch, so I am
resending the updated patch.


[-- Attachment #2: 0001-gnu-Add-font-liberation.patch --]
[-- Type: text/x-diff, Size: 3731 bytes --]

From 93cf792c9ced8763251780cfa159fd999500c307 Mon Sep 17 00:00:00 2001
From: Alex Kost <alezost@gmail.com>
Date: Tue, 28 Oct 2014 09:44:16 +0300
Subject: [PATCH] gnu: Add 'font-liberation'.

* gnu/packages/fonts.scm (font-liberation): New variable.
---
 gnu/packages/fonts.scm | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)

diff --git a/gnu/packages/fonts.scm b/gnu/packages/fonts.scm
index 4ed86d9..0181420 100644
--- a/gnu/packages/fonts.scm
+++ b/gnu/packages/fonts.scm
@@ -2,6 +2,7 @@
 ;;; Copyright © 2013 Ludovic Courtès <ludo@gnu.org>
 ;;; Copyright © 2014 Mark H Weaver <mhw@netris.org>
 ;;; Copyright © 2014 Joshua Grant <tadni@riseup.net>
+;;; Copyright © 2014 Alex Kost <alezost@gmail.com>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -203,6 +204,71 @@ package provides the TrueType (TTF) files.")
 10646/Unicode UCS (Universal Character Set).")
    (license license:gpl3+)))
 
+(define-public font-liberation
+  (package
+    (name "font-liberation")
+    (version "2.00.1")
+    (source (origin
+              (method url-fetch)
+              (uri (string-append "https://fedorahosted.org/releases/l/i/"
+                                  "liberation-fonts/liberation-fonts-ttf-"
+                                  version ".tar.gz"))
+              (sha256
+               (base32
+                "010m4zfqan4w04b6bs9pm3gapn9hsb18bmwwgp2p6y6idj52g43q"))))
+    (build-system trivial-build-system)
+    (arguments
+     `(#:modules ((guix build utils))
+       #:builder
+       (begin
+         (use-modules (guix build utils))
+
+         (let ((tar      (string-append (assoc-ref %build-inputs "tar")
+                                        "/bin/tar"))
+               (PATH     (string-append (assoc-ref %build-inputs "gzip")
+                                        "/bin"))
+               (font-dir (string-append %output "/share/fonts/truetype"))
+               (doc-dir  (string-append %output "/share/doc/" ,name)))
+           (setenv "PATH" PATH)
+           (system* tar "xvf" (assoc-ref %build-inputs "source"))
+           (mkdir-p font-dir)
+           (mkdir-p doc-dir)
+           (chdir (string-append "liberation-fonts-ttf-" ,version))
+           (for-each (lambda (ttf)
+                       (copy-file ttf
+                                  (string-append font-dir "/"
+                                                 (basename ttf))))
+                     (find-files "." "\\.ttf$"))
+           (for-each (lambda (doc)
+                       (copy-file doc
+                                  (string-append doc-dir "/"
+                                                 (basename doc))))
+                     '("AUTHORS" "ChangeLog" "LICENSE" "README" "TODO"))))))
+    (native-inputs
+     `(("source" ,source)
+       ("tar" ,tar)
+       ("gzip" ,gzip)))
+    (home-page "https://fedorahosted.org/liberation-fonts/")
+    (synopsis
+     "Fonts compatible with Arial, Times New Roman, and Courier New")
+    (description
+     "The Liberation font family aims at metric compatibility with
+Arial, Times New Roman, and Courier New.
+
+There are three sets:
+
+- Sans (a substitute for Arial, Albany, Helvetica, Nimbus Sans L, and
+Bitstream Vera Sans);
+
+- Serif (a substitute for Times New Roman, Thorndale, Nimbus Roman, and
+Bitstream Vera Serif);
+
+- Mono (a substitute for Courier New, Cumberland, Courier, Nimbus Mono L,
+and Bitstream Vera Sans Mono).
+
+The Liberation Fonts are sponsored by Red Hat.")
+    (license license:silofl1.1)))
+
 (define-public terminus-font
   (package
     (name "terminus-font")
-- 
2.1.3

Re: [PATCH] gnu: Add 'font-liberation'.

[Ludovic Courtès]

Alex Kost <alezost@gmail.com> skribis:

> From 93cf792c9ced8763251780cfa159fd999500c307 Mon Sep 17 00:00:00 2001
> From: Alex Kost <alezost@gmail.com>
> Date: Tue, 28 Oct 2014 09:44:16 +0300
> Subject: [PATCH] gnu: Add 'font-liberation'.
>
> * gnu/packages/fonts.scm (font-liberation): New variable.

Please push.  Thanks for your patience!

Ludo’.

Re: Font package naming convention

[Alex Kost]

Andreas Enge (2014-10-31 20:58 +0300) wrote:

> On Fri, Oct 31, 2014 at 01:02:44AM +0300, Alex Kost wrote:

>> I'm against any strict binding to an upstream name.  Why should we stick
>> to a (potentially strange) upstream name if we know better how a package
>> should be called?
>
> This is what we have done so far and it is part of the packaging guidelines.
> Otherwise there would be absolutely no limit to renaming and bikeshedding.
> What if you think that "foo" should be renamed "bar" and I think it should
> be renamed "truc"?

I think the majority should decide.  So if the most of guix people think
that it should be named "bar", then let it be so.

> If you want to make a suggestion of a naming scheme that others can follow,
> please come up with a description of an algorithm as for python modules -
> a transformation of an upstream name into a package name.

I wrote what seems appropriate to me at
<http://lists.gnu.org/archive/html/guix-devel/2014-10/msg00457.html>:
If a package provides only truetype font(s), name it “ttf-…”, other
font packages should contain "font" in their names; or ...

Ludovic Courtès (2014-11-01 00:30 +0300) wrote:

> I’m not completely sure we can come up with a strict algorithm for the
> naming scheme that we will not want to change two weeks later.  ;-)
>
> Here’s a possible answer to the above questions, informally:
>
>   • Use ‘font-FOUNDRY-FAMILY’ or ‘font-FAMILY’ or
>     ‘font-FOUNDRY-COLLECTION’ or ‘font-COLLECTION’ as the name.
>
>     Examples: ‘font-bitstream-vera’, ‘font-liberation’, ‘font-unifont’.
>
>   • Use ‘font-.*-FORMAT’ only when there happens to be separate packages
>     for separate formats.  FORMAT would be the format short name, like
>     ‘ttf’, ‘otf’, ‘type1’.
>
> WDYT, fellow nitpickers?  :-)
>
> IMO the goal should be to find something convenient for users.
> Sometimes, maybe, there will be several valid choices for the package
> name, but that’s fine, I think.

... I agree with this point, and perhaps it would be good to follow a
single simple rule:

    A package that provides fonts (only fonts, not some big product with
    a couple of fonts), should have "font(s)" in its name, for example:
    “freefont”, “font-bitstream-vera”, “terminus-font”,
    “liberation-fonts”.

However, I still think that having the following packages would be the
best:

  ttf-bitstream-vera
  ttf-dejavu
  ttf-freefont
  ttf-liberation
  ttf-symbola

and the following (according to the current convention) would be the
worst:

  ttf-bitstream-vera
  dejavu-fonts-ttf
  freefont-ttf
  liberation-fonts-ttf
  symbola

-- 
Alex

Re: Font package naming convention

[Andreas Enge]

Alex,

On Sat, Nov 01, 2014 at 12:36:30PM +0300, Alex Kost wrote:
> I think the majority should decide.  So if the most of guix people think
> that it should be named "bar", then let it be so.

for this we would need an "infrastructure": a social contract, a voting
system and what else not, which seems a bit like overkill to decide on package
names. Even debian does not hold general resolutions for the names of their
packages...

> However, I still think that having the following packages would be the
> best:
>   ttf-bitstream-vera
>   ttf-dejavu
>   ttf-freefont
>   ttf-liberation
>   ttf-symbola

Okay, could you please formulate your suggestion into a rule that we could
follow for other font packages than these five?

Andreas

Re: Font package naming convention

[Alex Kost]

Andreas Enge (2014-11-01 12:45 +0300) wrote:

> Alex,
>
> On Sat, Nov 01, 2014 at 12:36:30PM +0300, Alex Kost wrote:
>> I think the majority should decide.  So if the most of guix people think
>> that it should be named "bar", then let it be so.
>
> for this we would need an "infrastructure": a social contract, a voting
> system and what else not, which seems a bit like overkill to decide on package
> names. Even debian does not hold general resolutions for the names of their
> packages...

I don't see a need in the infrastructure: there is guix-devel ML and
there are only few people who is doing the most of work: you, Ludovic,
Mark, Eric, Nikita, John, Cyril, David.  So a majority of you should
decide (IMO).

>> However, I still think that having the following packages would be the
>> best:
>>   ttf-bitstream-vera
>>   ttf-dejavu
>>   ttf-freefont
>>   ttf-liberation
>>   ttf-symbola
>
> Okay, could you please formulate your suggestion into a rule that we could
> follow for other font packages than these five?

My only rule is: the upstream name shouldn't always be blindly taken as a
package name; if Guix developers think there is a more appropriate name,
then use it.