[Pkg-fonts-devel] Greetings

[Nicolas Spalinger]

On 03/31/2017 07:09 AM, Paul Wise wrote:
> On Thu, 2017-03-30 at 22:39 -0600, Bobby de Vos wrote:
> 
>> If Smith and the tools it calls were put into sid, how often are the
>> Debian build agents (I apologize if that is not the correct term)
>> updated with recent updates to smith and the tools?
> 
> Debian package builds for sid happen using the tools/versions available
> in sid at the time of the package build. So not much different to PPAs.

Hi Paul, 

As Bobby has mentioned, the useful thing we have found in the PPA system is the recipes to build directly from the upstream VCS. 
This has significantly reduced the amount of overhead and accelerated the delivery of the software to our users. (it's a manpower issue too).

>> The git repo I mentioned, https://github.com/devosb/fonts-sil-lateefgr,
>> is not the upsteam repo. The upstream repo is at
>> https://github.com/silnrsi/font-lateef . In that upstream repo, there is
>> a binary TTF file that I think is the export from FontLab. It is not the
>> final TTF that would be used on an installed system.
> 
> That sounds like you are using the proprietary FontLab tool as your
> font editor and build tool, I'd encourage you to switch to something
> open like FontForge or Birdfont.
> 
>> NRSI is in the middle of transitioning our tool chain to be more open.
> 
> That is a most welcome change!

:-) 

As you may recall from previous conversations we have been working on this front for years. 
(I was more active in the team a good while ago, sorry I had to disappear for personal reasons and other commitments,
so I'm really glad Daniel and Bobby are picking up our packaging tasks for the benefit of all Debian users).

We are moving from opaque formats to open standards and to reproducible self-contained workflows.
It can't happen overnight though...

In the case of Lateef, there is postprocessing which happens on this TTF file, so it is most definitely considered source. 

We're moving to UFO-centric workflows (http://unifiedfontobject.org/), giving the complexity of our font projects, using Birdfont is not feasible. 
We're using certain features of FontForge already, but for all its power it's lacking certain features that are needed. 
Other utilities are making progress (fonttools for example).

How many of the fonts packaged in pkg-fonts are built with open font editors, have a debian/rules that actually builds from scratch and are actively maintained? 
How many of us in pkg-fonts are proficient with a font editor? How much contact do you have with type designers?
We're have little choice but to be short-term pragmatists...
 
>> The upstream does not contain an TTF files, the packaging repo does.
> 
> That should not be the case at all, the fonts should be built from source.
>
>> Is that that file (LateefGR-1.200.zip) I should be using to do Debian packaging?
> 
> In general, no, Debian packages should start from the source and create
> the binary TTF using the available build tools. Sometimes the binary
> TTF is itself definitely source and a lot of the time only binary TTF
> files are released but we have no indication of what the source is, so
> we just package those without trying to find out what the source is.
> 
>> so until that happens, how should I be making Debian packages of NRSI fonts?
> 
> You can package the binary TTFs in contrib, since packages in Debian
> main have to be buildable using only source and tools in main.

I understand your point of view and on a theoritical level agree with you but... that reality has been escaping us for a while.

I'm pretty sure there are others in the pkg-fonts team and across Debian who respectfully disagree with you 
that all fonts that are not completely self-buildable in Sid must be immediately removed and driven out to be relegated to contrib. 

I agree that fonts should be like any other software and build from source completely and that's the end-goal I (and others) have been working towards.
It's proving MUCH harder than expected.
The difficulty of maintaining fontforge has probably shown Debian maintainers how difficult this whole business of font toolchain actually is...
The work on the licensing layer (establishing the Open Font License) was the first step, we've been tackling the reproducible buildpath for a while now.

Thankfully others in the type design communities are tackling that conundrum too.
IMHO Google's Noto toolchain is one good example. (scoop: they don't use FontForge). 
We are going for something more generic that other projects and maintainers can use.

Are you going to remove every single TTF from main (bar the handful that are really self-built) in the meantime?
Do you think this will be useful for Debian users?
I somehow doubt this is the best course of action. 

Instead, can we count on the knowledge and experience of the pkg-fonts members to help us make our toolchain ready for Debian and available to others? 

>> The source is present in the Harmattan packaging repo, even though it
>> is not used by Debian to build the TTF.
> 
> That sounds like a bug to me.

I have been making the case to my colleagues that a halfway source package is less than ideal as an interim solution. 
And that we should continue working on our open toolchain, and only provide complete source packages to Debian when we can reach the stage where we can fully autobuild them in Debian.
In the meantime we will strive to make the end-user TTF easily available to Debian users, especially users on minority scripts who are not well-served by existing unrestricted fonts. 

I'm keen on hearing what other active members of pkg-fonts think. 

Thanks, 

-- 
Nicolas Spalinger