search

bohoomil / fontconfig-ultimate

freetype2-infinality run-time settings => infinality compatible fontconfig => infinality-bundle
454 stars 38 forks source link

Should ttf-dejavu-ib really provide ttf-dejavu #118

Open thomas001 opened 8 years ago

thomas001 commented 8 years ago

I think I came up with a very specific issue, which nevertheless causes some archlinux packages (at least one: cups-filters) to build incorrectly: ttf-dejavu-ib provides ttf-dejavu, but does not provide the same files, only the same fonts. Thus, package build scripts which depend on the actual file path of the font files will break (cups-filters uses --with-test-font-path=/usr/share/fonts/TTF/DejaVuSans.ttf).

So...

  1. Should ttf-dejavu-ib really provide ttf-dejavu?
  2. If so, should it also provide exactly the same files (perhaps via symlinks)?
  3. Or, is it considered a bug in the cups-filters build script to depend on the actual file path of a font? (I suggested using fontconfig to get the path, but the cups-filters maintainer considers it a bug in ttf-dejavu-ib not to provide the same files)
bohoomil commented 8 years ago

There are no bugs in the scripts. Let me clarify the background a bit.

We're dealing with two different approaches to font management. On one hand we have Xorg's tradition (the older one) with it's default layout:

--with-fontrootdir=/usr/share/fonts

in which the following directories are installed:

/usr/share/fonts/100dpi
/usr/share/fonts/75dpi
/usr/share/fonts/OTF
/usr/share/fonts/TTF
/usr/share/fonts/Type1
/usr/share/fonts/local
/usr/share/fonts/misc

On the other, there is the newer (simpler and more versatile) fontconfig scheme which requires a basic location plus, optionally, an additional one for extra font files:

--with-default-fonts=/usr/share/fonts
--with-add-fonts=/usr/share/fonts

In the latter, there is no other need than your personal preferences to relocate font files into specific directories. I do this for font packages distributed with the bundle merely for maintenance convenience: this way we can easily--visually--find out what is where.

By the way, the latter method should be considered the default one: modern applications rely on fontconfig's, not Xorg's management scheme after all.

As you can see, font management model in Arch may seem a bit inconsistent: even though many TTF and OTF packages are installed into separate subdirectories inside /usr/share/fonts, some still are put in /usr/share/fonts/TTF. Technically, there is nothing wrong with this as fontconfig will use anything inside the root location. However, as long as applications do not depend directly on /usr/share/fonts/TTF, we could start abandoning Xorg's idiosyncrasy which does not really serve any practical purpose. (Xorg apps mostly require bitmap fonts so let them stay where they belong. Nowadays, these are in the minority though.)

Now let us get back to your questions:

Ad 1. I think so. Some apps (VLC for instance) optionally depend on ttf-dejavu (not ttf-font) so provides will be a handy information for pacman to use the package other than the one specified by the maintainer.

Ad 2. The content of ttf-dejavu-ib is exactly the same as in the Arch's stock ttf-dejavu (ib fonts are newer though). Creating additional symbolic links feels like an overkill IMO: if you are going to rebuild a package which otherwise works well, you can simply change the location of the DejaVu fonts to the one used on your machine.

Ad 3. Absolutely not: the location is not hardcoded in the Makefile, it just relies on the old Xorg's font management scheme and can be changed if necessary. If the maintainer of cups-filters considers not obeying his preferences to be a bug, I can only appreciate this as a truly amusing joke. :-)