make use of $presets_dir in fc-presets

[beniked]

affects packages built with non-default presets directory.

[bohoomil]

Thanks a lot for your feedback and contribution.

I'm actually aware of the problem with presets location (they became obvious when I started playing with ib for Fedora, though). Using a variable instead of a fixed location is obviously the right approach, but before we commit any changes, I'd like to discuss the entire non-Arch-fontconfig case with other non-Archers.

Briefly speaking, I'm still not quite sure about the final layout of the additional config files and the usability of fc-presets itself. The concept works just fine in Arch because this is a DIY distro where you can quite easily substitute a part of the system with its functional alternative (for example, in Arch you don't get a default collection of fonts and fontconfig settings as all the non-obligatory stuff you set up on your own; this is not the case in majority of distributions which a) utilize a desktop design, b) come with a fixed list of defaults, including a working X11 and configuration of the font back end). My fontconfig-iu makes use of fonts that usually can't be found in official repositories (this is an important part of the project because in this way we could solve quite a few issues with proper rendering of Web content, as well as unify the look of fonts in multi-lingual and mixed-scripts documents). In Fedora, openSUSE or Debian/Ubuntu we have predefined font sets we're somehow enforced to use, which is IMO the weakest link in porting Infinality to them (the original Infinality didn't pay enough attention to the problem of a common font base across various distros, leaving it mostly to users; this resulted in a different user experience in different Infinality setups). Finally, the logic of presets being used in fontconfig-iu for Arch and the rest of the Linux world: in Arch it is pretty easy to switch between free/non-free stuff and at the same time mix both just as you wish. Better yet, for 90% of use scenarios, the process can be totally automatic, with zero or very little effort on the end-user side. In other distros, with predefined and unique default fontconfig configurations, you always have a bunch of files that are conceptually a part of the system: you can replace them, but as long as you use your stock repos, they will come back with the next update. Now try to add this up...

So here are my questions, before we proceed:

1. Are we going to use the same, custom font base we have in infinality-bundle for Arch in other distros, or are we bound by the content of their repositories? For best results, using a custom collection of free fonts is highly recommended (we can then re-use the complete free preset from Arch as the base for all and customize it on a per-user basis to any degree we want). If not, we should have a default free preset for non-Archers reflecting the collection of fonts found in their repositories. (An additional side effect: a few font packages may be installed with their own fontconfig rendering instructions, conflicting with infinality-ultimate's.)
2. How many presets, except the default free, are we going to use? This means that we should have a working set of basic files for switching between aliases, which shouldn't be overwritten on system updates. Right now it seems to be a bit difficult because 60-latin.conf, 65-nonlatin.conf and a few others will be overwritten if we don't use a patched fontconfig, which would replace the stock one in every distro.
3. Finally, are we going to use the patched fontconfig or the stock ones with additional Infinality configuration files (in a manner the original fontconfig-infinality did this)? This is the key question because a) the patched one offers a better stability since it doesn't depend on stock config files (it requires a custom font repo, though), b) it means easier maintenance (because we can have a collection of patches updated periodically plus any number of individual rendering instructions for any number fonts), and c) it offers the easiest solution for most users (install and use; customize if you really need to). Using the old style Infinality fontconfig we just leave more room for errors and (possibly) expect more awareness from users.

I'd love to read your opinions, suggestions and most of all find the best solution.

Thanks.

[ahawthorne]

I like the approach of trying to provide a consistent experience across multiple distros re: infinality-bundle fonts vs distro-specific presets, as well as attempting to make the process entirely automatic. This should also be simple for users to revert back to distro-defaults should they choose that they prefer that.

1. Custom infinality-bundle vs distro defaults Where licences allow, lets package any fonts not found in a distro's repositories so they can be installed. The challenge will be conflicts.

2. How many presets? As few as needed. At minimum, a free preset and a distro-specific preset which would use the default fonts could be provided. Less maintenance the better, and since there is lots of room for end-user customization, an opinionated-approach with few presets isn't a terrible thing... in my opinion ;)

3. patched fontconfig vs distro-default I see this being the trickiest issue. In principle, I like using the patched fontconfig. The challenge however is getting a custom fontconfig package installed that doesn't clobber the system. I'm still researching exactly how to create the package for Fedora (and would appreciate input from anyone interested) in a way that is not hack-ish and is reversable. Additionally, I think the option of installing freetype-infinality and using the distro-provided fontconfig should be left intact for those who want to take the DIY config route.

For Fedora, I'd put the the config in /usr/share/fontconfig/conf.avail.infinality to isolate it from the rest of Fedora's font config and to keep consistency with where the rest of the config files are.

[bohoomil]

Thank you very much for taking your time and commenting on the topic.

This is just a little side note to the problem with extra font packages. I was thinking of the ways we could reuse either the Arch packages or at least the build scripts for them (you will find all the Arch stuff in this repo, the pkgbuild branch). We'd need a script to convert/translate either of the two to a new target distro format. This could significantly simplify the workflow and reduce the efforts needed to adopt the current collection of fonts (which is pretty huge already).

Font packages are just simple archives: if we had a script that would repackage them on the fly on users' machines, we could just grab them from the Arch repo instead of creating new ones from scratch for other distros. If possible, users would simply install one extra package that would take care of all the font stuff, more or less like this:

1. uncompress the original {otf|ttf|t1}-foo.pkg.tar.xz archive
2. move fontconfig templates to the distro-specific location (e.g. /usr/share/fontconfig/conf.avail)
3. move font files to the new location (e.g. /usr/share/fonts/TTF/foo-ib{x})
4. create symlinks to the new templates in /etc/fonts/conf.d
5. include additional information for the package manager, like conflicts / provides / replaces (provided that rpm/yum, dpkg and others support this, we could seamlessly substitute original packages with their alternatives, when necessary, and prevent possible conflicts)
6. create a new archive (e.g. {otf|ttf|t1}-foo.f21.noarch.rpm)

With a simple yet clean text UI, any user could install or replace a font package on demand, avoiding compatibility issues and the like.

Speaking of patching: this shouldn't be actually a very challenging task. Basically, the patches modify the makefiles (set new locations, extra template directories, etc.) so they can be tailored specifically for a given distro. The key part of the process is adopting the configuration script, which was originally rewritten for Arch. In order to use it elsewhere, we'd need to implement a few extra options:

1. --with-infinality-template-dir=[DIR]: each distro, be it Fedora or Debian, would use a predefined path to the new set of common *.conf files, a.k.a conf.avail.infinality. They would be used instead of the stock conf.avail (which we still need for compatibility with the rest of the system).
2. --with-presets-dir=[DIR]: this is where we'd install the three base presets (combi, free, ms) needed for the fc-presets when setting default aliases.

fc-presets would simply use the same variables as those set during configuration (as pointed by @beniked; several months ago I started experimenting with configuration variables and they make sense).

Adopting fontconfig-iu to any other distro would be as easy as providing an additional patch/template for it. And again, the library could be used as a drop-in replacement for the stock fontconfig if we could set in their build scripts additional information for their package manages (ergo: conflicts / provides / replaces).

Last but not least: we should remember to keep the new libs fully compatible with your distros' specs, which means that they should be compiled strictly in accordance with the distros' standards and, if necessary, provide additional config files, etc. When done properly, everything should work perfectly well, just like it does on Arch.

Edit

Of course, I forgot about the option with build scripts. :-) In this case, the previous list of tasks for the script to perform would sightly change:

1. Arch build scripts from the pkgbuild branch could be translated to other formats and put in separate per-distro branches
2. the scripts on users machines would
   1. download the appropriate source packages and build scripts from their locations (some modified font files are available at http://bohoomil.com/src)
   2. perform steps 2-6 from the previous listing.

IMO, this is probably the easiest and quickest way to achieve the goal.

[RJVB]

To be honest, bohoomil, I think that the best approach would be to maintain your distribution as you've been doing, just incorporating appropriate elements of whatever feedback you get from packagers working with different distributions.This may be easy for me to say because Ubuntu is hardly different from Arch in the way it lays out freetype and fontconfig related things, and MacPorts is in fact very much comparable to Arch.

On Ubuntu, I encountered only 1 obligatory fontconfig file that's used by update-initramfs; for the rest I have been able to modify the fontconfig packages such that they install the IU versions instead of and in addition to the stock .conf files. I have yet to see a fontconfig update to something newer than I provide in my ppa. I did have to modify some of the fontconfig code patches for my Ubuntu packages, in part because I want to keep Ubuntu's own patches too. That's proven to be tricky the times I had to do it (they concern files like configure.ac, which mere mortals like I prefer to leave alone). It'd be nice if those modified patches could be maintained "upstream" together with the other patches, but I cannot expect bohoomil to do that.

If there's 1 thing that would make maintaining my packages easier, it'd be not setting the date stamp of all files in a release to the release date. Right now I have to do content comparison to determine which files are newer than the files I use in my current package versions. If only the modified files were dated after the previous release date that would simplify things considerably.