Re: Nonfree fonts in xsrc

On Mon, Oct 05, 2020 at 02:13:31PM +0000, nia wrote:
 > The device firmware comparison doesn't make sense to me because
 > device firmware is required for the OS to actually talk to devices
 > and work properly, and the device firmware is also isolated into
 > directories like 'external/broadcom'. These pieces of "font software"
 > aren't required for X to work properly, and are incorrectly labelled as
 > being MIT licensed so aren't isolated to the correct license directory.

On the other hand, I don't think there's a whole lot of demand for
being able to modify fonts -- they are technically software, but it's
vanishingly rare for anyone to want to patch one for technical reasons
and if one wants to modify one for aesthetic reasons (that is, because
it's unforgivably ugly) it's almost certainly better to start over.

(I think I've heard of people running into fonts with broken hinting
rules but I think the conclusion in that case was "delete" rather than
"fix".)

I am fine with moving them based on license category, especially if we
can get our SCM migration done first, but I'm not sure removing them
really serves any useful purpose. While bloat is bad in general, it's
not like we have a fixed space budget for installs and I don't think
it's necessary or even reasonable to delete old fonts just to make
space to add new ones.

 > I guess a better question is whether anyone is going to miss a few
 > Type1 fonts that are installable from pkgsrc. We'd like to import some
 > larger BDF fonts and scalable TTF fonts that are BSD/apache2 licensed and
 > have better support for modern rendering features and unicode areas.
 > Getting rid of these would free up some space for that.

There are tacit or implicit assumptions everywhere about what fonts
are available by default, for X in general and also for NetBSD in
particular. It's hard to identify these beforehand. So if we end up
removing these (or any) fonts, please document in UPDATING (not just
CHANGES*) what packages to install if something breaks.

-- 
David A. Holland
[email protected]