Re: RFS: fonts-play update
On Tue, 2019-12-03 at 08:30 +0800, Yao Wei (魏銘廷) wrote:
> > On Dec 3, 2019, at 08:21, Yao Wei (魏銘廷) <mwei@debian.org> wrote:
> > https://github.com/alexeiva/play
>
> However I am not sure that if the above is the real upstream, and it
> might be in violation of Reserved Font Names.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776273 had quite a
bit of discussion regarding the "source" of this font and the RFN some
time ago.
My impression at that point in time was that the google fonts directory
was the de-facto upstream of this font.
Dave Crossland (member of the google fonts team) also noted that google
have considered the RFN:
(...)
> I ask people to drop the rfn, but when they refuse, I get permission;
> for Google to use the rfn (and trademark.)
(...)
This *may* indicate that updates are allowed with respect to the RFN
under the google fonts directoy umbrella.
Whether or not alexeiva/play is under this umbrella, I do not know, but
m4rc1e/play which is a fork of this repo belongs to a contractor for
the google fonts directory... Also
https://groups.google.com/forum/#!msg/googlefonts-discuss/NvSTHVa7UcQ/hWqCm1A0DgAJ
indicate least a thumbs-up from the playtype team towards the updates
done in alexeiva/play...
alexeiva/play seems to have started from the 2.000 release of the font,
which I am (wildly) guessing was exported from the google font
directory based on the ttf files that existed at that point?
On Tue, 2019-12-03 at 12:07 +0100, Fabian Greffrath wrote:
> Hi,
>
> Am 02.12.2019 22:31, schrieb Martin Erik Werner:
> > I'm looking for a sponsor for an updated version of the fonts-play
> > package, available via:
>
> sorry, but the packaging raises some questions for me:
>
> * Why again do you take the TTF fonts from the google font directory
> and
> convert them to OTF fonts?
The otf fonts are created for backwards compatibility reasons, the
fonts-play package previously generated ttf and otf fonts from sfd
files and the intention was to ensure that nothing which depended on
the otf files broke due to them missing in this new version of the
package.
Based on RFN considerations, this might not be allowed though?
The sfd files were removed from the google font directory when it
migrated to github and I am assuming that the ttf files were used as
the "source" format from that point on, based on comments by Dave
Crossland in bug #776273:
> > Lastly, and the main point, is there any specifics on how to
> generate the
> > ttf files from sfd sources to make sure they are as similar to the
> google
> > web fonts ttf:s as possible?
> >
>
> The *-TTF.sfd files were the exact TTFs in SFD format, so generating
> them
> more or less directly should do that; the export would need a few
> 'default'
> flags, like this:
>
> https://github.com/ManufacturaInd/tinytypetools/blob/master/fontconvert/fontconvert#L131
On Tue, 2019-12-03 at 12:07 +0100, Fabian Greffrath wrote:
(...)
> * In the copyright file you claim that everything but the source
> files
> and the font generation scripts have been removed from the source
> tarball - but this doesn't seem to be true anymore. If there are
> sources
> available for this font, it is usually considered unacceptable to
> upload
> only the binary formats into the Debian main section!
Yes, this wording will need to be updated.
> * In this context, you point the Homepage field to the google font
> directory. This, however, is most certainly not the homepage for
> this
> font but merely a huge directory where any given font under a
> suitable
> license is archived.
As noted above, for the 1.002 version in the updated package, I am of
the belief that the google fonts directory is/was the de-facto upstream
of the font as of this version.
For versions beyond 2.000, alexeiva/play may be the true upstream, but
with the RFN, we still would need to install the provided ttf and otf
files verbatim since we cannot do any compile/conversion?
> * In the get-orig-source rule in debian/rules you are doing a SVN
> checkout of a GIT repository. Is this supposed to work that way? I
> never
> even tried this out.
The svn access on github allows checking out a subset of a large Git
repository and since the google fonts directory is around 0.5Gb I
figured is was the best way to get at the desired subset.
If we can use alexeiva/play as an upstream, this will of course
unnecessary since the repo is much smaller and also provides Git tag
releases.
--
Martin Erik Werner <martinerikwerner@gmail.com>
Reply to: