Closed BubuXP closed 8 years ago
First time using github. There's also 49-sansserif.conf in the same situation (duplicate upstream), but I don't know how to insert the change in this pull request without making a new one. EDIT: Done, I understand how to do now.
These two files cannot be removed as they are part of the fontconfig-iu
. We are not using upstream configuration files: all the original content of the /etc/fonts/conf.avail
is kept merely for compatibility purposes, while configuration is set with templates from /etc/fonts/conf.avail.infinality
.
I see. Probably I should check the pkgbuild files to understand better.
But at the moment, if I look inside the package in the repo: http://bohoomil.com/repo/i686/fontconfig-infinality-ultimate-2.11.95-3-i686.pkg.tar.xz in conf.d there are your .conf files plus all the standard .conf files from the upstream default configuration, so both configurations are used at the same time (the ultimate configuration integrates the default one, right?). And because the two files are present in both conf.avail folders without changes between them, why don't link directly from the upstream conf.avail instead of duplicate it (as long as ultimate needs upstream fontconfig to exist)?
And please excuse me if I'm being pedantic. I don't have much experience in coding so I shouldn't insist, but I'm curios about a lot of things.
conf.d
is for the actual (active) global configuration being used. conf.avail
and conf.avail.infinality
store configuration templates. As I wrote before, the original upstream conf.avail
is kept mainly for compatibility purposes (it's often required by applications installed from the Arch repos). This is also the destination for all fontconfig
configuration files distributed with our fonts packages and third-party packages from the AUR (because we don't want to mess with config files which should be left alone).
I decided to duplicate certain configuration files simply to avoid the solution you've mentioned (linking some of the files from conf.avail
and some from conf.avail.infinality
) because such an approach is cleaner, easier to maintain and it leaves less room for possible errors. The upstream may change their configuration, they can add or remove config files and we can still use infinality
templates safely. (By the way, a regular user is supposed to edit only and only if necessary user-centered infinality
templates, i.e. nn-foo-custom.conf
ones. Everything else is meant to be left as is for the error-free operation.) When fontconfig-iu
is being built and the patches are being applied, all the necessary changes are being introduced to conf.d
(the stock upstream *.conf
files are removed and replaced by their Infinality equivalents so they are definitely not used simultaneously). Once the user installs fontconfig-iu
and sets a chosen preset active, he/she can forget about fontconfig
as such.
Of course, this is merely my personal realization of the concept whose purpose was to provide a ready to use configuration (as opposed to yet another Infinality DIY toolkit). It was well-tested and has been in use for several years now, and it basically "just works". The only things that are changing are version numbers and occasional bugs are fixed (like those in our case). Still, everyone is allowed to develop their own forks if needed. Sometimes certain changes must be introduced because different distributions may require a modified configuration that follows different standards -- see Ubuntu or Fedora for instance. However, this is not my cup of tea. ;-)
And you're right: I don't feel like changing anything here because... it "just works". ;-)
Thanks for your time to explain, it's very interesting to me. But still I don't understand something... You said:
I decided to duplicate certain configuration files simply to avoid the solution you've mentioned (linking some of the files from conf.avail and some from conf.avail.infinality) because such an approach is cleaner
and:
the stock upstream *.conf files are removed and replaced by their Infinality equivalents so they are definitely not used simultaneously
I'm not using Arch Linux, but I suppose that anyone using it and that installed fontconfig-iu will have a similar output with the command ls -alt /etc/fonts/conf.d/
right?
drwxr-xr-x 2 bubu bubu 1020 apr 21 14:14 .
lrwxrwxrwx 1 bubu bubu 55 apr 21 14:14 66-aliases-wine-free.conf -> ../conf.avail.infinality/free/66-aliases-wine-free.conf
lrwxrwxrwx 1 bubu bubu 52 apr 21 14:14 65-non-latin-free.conf -> ../conf.avail.infinality/free/65-non-latin-free.conf
lrwxrwxrwx 1 bubu bubu 48 apr 21 14:14 60-latin-free.conf -> ../conf.avail.infinality/free/60-latin-free.conf
lrwxrwxrwx 1 bubu bubu 54 apr 21 14:14 37-repl-global-free.conf -> ../conf.avail.infinality/free/37-repl-global-free.conf
lrwxrwxrwx 1 bubu bubu 57 apr 21 14:14 30-metric-aliases-free.conf -> ../conf.avail.infinality/free/30-metric-aliases-free.conf
drwxr-xr-x 5 bubu bubu 140 apr 11 10:57 ..
lrwxrwxrwx 1 bubu bubu 55 apr 11 10:57 10-base-rendering.conf -> /etc/fonts/conf.avail.infinality/10-base-rendering.conf
lrwxrwxrwx 1 bubu bubu 44 apr 11 10:57 10-hinting-slight.conf -> /etc/fonts/conf.avail/10-hinting-slight.conf
lrwxrwxrwx 1 bubu bubu 48 apr 11 10:57 10-scale-bitmap-fonts.conf -> /etc/fonts/conf.avail/10-scale-bitmap-fonts.conf
lrwxrwxrwx 1 bubu bubu 47 apr 11 10:57 20-unhint-small-vera.conf -> /etc/fonts/conf.avail/20-unhint-small-vera.conf
lrwxrwxrwx 1 bubu bubu 45 apr 11 10:57 28-user.conf -> /etc/fonts/conf.avail.infinality/28-user.conf
lrwxrwxrwx 1 bubu bubu 46 apr 11 10:57 29-local.conf -> /etc/fonts/conf.avail.infinality/29-local.conf
lrwxrwxrwx 1 bubu bubu 44 apr 11 10:57 30-metric-aliases.conf -> /etc/fonts/conf.avail/30-metric-aliases.conf
lrwxrwxrwx 1 bubu bubu 41 apr 11 10:57 30-urw-aliases.conf -> /etc/fonts/conf.avail/30-urw-aliases.conf
lrwxrwxrwx 1 bubu bubu 52 apr 11 10:57 35-repl-custom.conf -> /etc/fonts/conf.avail.infinality/35-repl-custom.conf
lrwxrwxrwx 1 bubu bubu 54 apr 11 10:57 37-repl-webfonts.conf -> /etc/fonts/conf.avail.infinality/37-repl-webfonts.conf
lrwxrwxrwx 1 bubu bubu 61 apr 11 10:57 38-repl-webfonts-custom.conf -> /etc/fonts/conf.avail.infinality/38-repl-webfonts-custom.conf
lrwxrwxrwx 1 bubu bubu 38 apr 11 10:57 40-nonlatin.conf -> /etc/fonts/conf.avail/40-nonlatin.conf
lrwxrwxrwx 1 bubu bubu 60 apr 11 10:57 40-non-latin-microsoft.conf -> /etc/fonts/conf.avail.infinality/40-non-latin-microsoft.conf
lrwxrwxrwx 1 bubu bubu 55 apr 11 10:57 40-non-latin-misc.conf -> /etc/fonts/conf.avail.infinality/40-non-latin-misc.conf
lrwxrwxrwx 1 bubu bubu 35 apr 11 10:57 45-latin.conf -> /etc/fonts/conf.avail/45-latin.conf
lrwxrwxrwx 1 bubu bubu 56 apr 11 10:57 45-latin-microsoft.conf -> /etc/fonts/conf.avail.infinality/45-latin-microsoft.conf
lrwxrwxrwx 1 bubu bubu 51 apr 11 10:57 45-latin-misc.conf -> /etc/fonts/conf.avail.infinality/45-latin-misc.conf
lrwxrwxrwx 1 bubu bubu 50 apr 11 10:57 49-sansserif.conf -> /etc/fonts/conf.avail.infinality/49-sansserif.conf
lrwxrwxrwx 1 bubu bubu 34 apr 11 10:57 50-user.conf -> /etc/fonts/conf.avail/50-user.conf
lrwxrwxrwx 1 bubu bubu 35 apr 11 10:57 51-local.conf -> /etc/fonts/conf.avail/51-local.conf
lrwxrwxrwx 1 bubu bubu 35 apr 11 10:57 60-latin.conf -> /etc/fonts/conf.avail/60-latin.conf
lrwxrwxrwx 1 bubu bubu 43 apr 11 10:57 65-fonts-persian.conf -> /etc/fonts/conf.avail/65-fonts-persian.conf
lrwxrwxrwx 1 bubu bubu 38 apr 11 10:57 65-nonlatin.conf -> /etc/fonts/conf.avail/65-nonlatin.conf
lrwxrwxrwx 1 bubu bubu 57 apr 11 10:57 67-override-aliases.conf -> /etc/fonts/conf.avail.infinality/67-override-aliases.conf
lrwxrwxrwx 1 bubu bubu 49 apr 11 10:57 68-override.conf -> /etc/fonts/conf.avail.infinality/68-override.conf
lrwxrwxrwx 1 bubu bubu 37 apr 11 10:57 69-unifont.conf -> /etc/fonts/conf.avail/69-unifont.conf
lrwxrwxrwx 1 bubu bubu 39 apr 11 10:57 80-delicious.conf -> /etc/fonts/conf.avail/80-delicious.conf
lrwxrwxrwx 1 bubu bubu 60 apr 11 10:57 82-no-embedded-bitmaps.conf -> /etc/fonts/conf.avail.infinality/82-no-embedded-bitmaps.conf
lrwxrwxrwx 1 bubu bubu 58 apr 11 10:57 82-no-force-autohint.conf -> /etc/fonts/conf.avail.infinality/82-no-force-autohint.conf
lrwxrwxrwx 1 bubu bubu 57 apr 11 10:57 82-no-ttf-as-bitmap.conf -> /etc/fonts/conf.avail.infinality/82-no-ttf-as-bitmap.conf
lrwxrwxrwx 1 bubu bubu 52 apr 11 10:57 83-yes-bitmaps.conf -> /etc/fonts/conf.avail.infinality/83-yes-bitmaps.conf
lrwxrwxrwx 1 bubu bubu 55 apr 11 10:57 83-yes-postscript.conf -> /etc/fonts/conf.avail.infinality/83-yes-postscript.conf
lrwxrwxrwx 1 bubu bubu 57 apr 11 10:57 88-forced-synthetic.conf -> /etc/fonts/conf.avail.infinality/88-forced-synthetic.conf
lrwxrwxrwx 1 bubu bubu 53 apr 11 10:57 90-non-tt-fonts.conf -> /etc/fonts/conf.avail.infinality/90-non-tt-fonts.conf
lrwxrwxrwx 1 bubu bubu 39 apr 11 10:57 90-synthetic.conf -> /etc/fonts/conf.avail/90-synthetic.conf
lrwxrwxrwx 1 bubu bubu 59 apr 11 10:57 90-tt-fonts-microsoft.conf -> /etc/fonts/conf.avail.infinality/90-tt-fonts-microsoft.conf
lrwxrwxrwx 1 bubu bubu 54 apr 11 10:57 90-tt-fonts-misc.conf -> /etc/fonts/conf.avail.infinality/90-tt-fonts-misc.conf
lrwxrwxrwx 1 bubu bubu 70 apr 11 10:57 92-selective-rendering-microsoft.conf -> /etc/fonts/conf.avail.infinality/92-selective-rendering-microsoft.conf
lrwxrwxrwx 1 bubu bubu 65 apr 11 10:57 92-selective-rendering-misc.conf -> /etc/fonts/conf.avail.infinality/92-selective-rendering-misc.conf
lrwxrwxrwx 1 bubu bubu 56 apr 11 10:57 93-final-rendering.conf -> /etc/fonts/conf.avail.infinality/93-final-rendering.conf
lrwxrwxrwx 1 bubu bubu 53 apr 11 10:57 94-no-synthetic.conf -> /etc/fonts/conf.avail.infinality/94-no-synthetic.conf
lrwxrwxrwx 1 bubu bubu 47 apr 11 10:57 95-reject.conf -> /etc/fonts/conf.avail.infinality/95-reject.conf
lrwxrwxrwx 1 bubu bubu 67 apr 11 10:57 97-selective-rendering-custom.conf -> /etc/fonts/conf.avail.infinality/97-selective-rendering-custom.conf
-rw-r--r-- 1 bubu bubu 2103 apr 11 10:57 README
I still can see linking some of the files from conf.avail and some from conf.avail.infinality, and the stock upstream *.conf files aren't removed. And this goes against what you said. I followed the .INSTALL commands in the Arch package to obtain this result, so I could have missed something. Where I'm wrong?
And now I can see what you mean. Somehow one of the patches was incomplete and the stock configuration files were still activated alongside the Infinality ones. Since their priorities differ, the packages were built correctly anyway, and all the redundant files were neatly stuffed in conf.d
without a single file conflict error. I didn't notice any rendering issues because my fontconfig
configuration is heavily customized so I simply replace the entire /etc/fonts
with a working copy after updating the library. Anyway, thank you so much for a meticulous investigation and the ls
output which helped a great deal! :-)
Happy that I helped somehow. I will close this pull request.
I found also that in the new Arch package the 10-scale-bitmap-fonts.conf
link isn't present in conf.d/
but the file is present in conf.avail/
and conf.avail.infinality/
Is this the expected result? If you forgot to link it and you will use it, have you considered to update it with the updated upstream file?
Yes, 10-scale-bitmap-fonts.conf
is optional and the majority of users will never need it.
I don't know how to get in contact with you, so I will write here (I sent an e-mail days ago on your zoho.com address but it was unanswered and I don't know if you still use it).
In my Debian packages, because I cannot repack all the fonts in the bundle like you do in Arch (I could, but it will be very time-consuming), I simply recommends to install the bundle's fonts that are already included in stock Debian repos.
But each of your fonts packages come with his own .conf files. I could do this only if I pack the fonts by myself and, since I can't do this right now, I simply activated ALL the fonts settings by symlinking all the .conf files in fontconfig-ultimate/fontconfig_patches/
, even if many of the fonts aren't installed in the system.
Do you think this is a viable solution or there could be any problems like conflicting conf?
BTW, I forked and re-organized your github to better fit Debian policy requirements, if you want to check it for the changes I do, please read the main readme file.
[is this] a viable solution or there could be any problems like conflicting conf?
No and yes.
Originally, there were two configuration files that handled rendering settings for TT and non-TT fonts: 90-tt-fonts.conf
& 90-non-tt-fonts.conf
(their numbers might have been different though). It seemed to be a nice and clean solution but pretty problematic when we had two different types of fonts (TTF & OTF) named identically. Even if it was possible to override the given settings in nn-selective-rendering.conf
files if necessary, I found such an approach to be a real trouble maker. As there happened to be double settings for both TT and non-TT fonts at the same time, guessing which ones were actually used by fontconfig
was really a big deal. (This is exactly what happens when you activate all files in fontconfig_patches/fonts-settings
: you will end up with mutually conflicting configurations.) In order to fix this, you had to check which type was installed on the system, inspect 90-{non-}tt-fonts.conf
to rule out the double settings case and then alter the active configuration accordingly. Such a heavily customized configuration was completely unportable, of course, so you could immediately forget about sharing it with others. Besides, unless a user was a fontconfig-infinality
expert, his/her font server was probably severely misconfigured at the end of the day.
I decided to go with the per-package configuration solution because it seemed to be the only way to eliminate the need to manually set the settings depending on the font type being in use and minimize the number of possible rendering errors. I left three fixed-settings files (90-non-tt-fonts.conf
, 90-tt-fonts-ms.conf
and 90-tt-fonts-misc.conf
) mainly for a bunch of popular commercial and non-free fonts. These can be expanded further obviously: I did as much as I was able to before I started getting nuts. (Many fonts will still work nicely with the CFF engine freetype2-iu
is using by default though.) The separate settings are mainly required for fonts which are available in two different formats and ones which may need selective rendering settings applied individually. Other than that, I had to deactivate stock fontconfig
settings distributed with several font packages and use Infinality's instead (and the only way I could achieve this was to repackage them).
As laborious as it may seem to be, such a solution is actually safer, less buggy and easier to maintain because most of the job you do only once. Alternatively, you can use CFF engine by default for most of the fonts, TT and non-TT, regardless of which type a user actually has.
I see...
Isn't possible to use the fontformat
property of a font to distinguish it and apply the desired hinting?
To check a font format: fc-scan /path/to/font/fontname.ext | grep -i format
For example, Cantarell is OTF and has fontformat: "CFF"
while Ubuntu that is TrueType has fontformat: "TrueType"
.
Yes, it is, but as long as there is a way to utilize conditional statements inside fontconfig
configuration files, you won't do much with it anyhow.
Just to notice that 45-croscore-fonts.conf and 45-noto-cros.conf are identical, and so are 90-tt- files too. I don't know if it's intended.
Nope. I will fix this soon. Thanks again!
I will report when I find things that looks odd to me.
By the way, I see that all the legacy Infinality's styles are "hardcoded" in freetype patch. Am I wrong? Can they be used with export INFINALITY_FT=
?
Yes, of course. It's been for quite some time like that. This also means that infinality-settings.sh
is optional now. The only thing you still need to source is Xft settings.
Duplicate file, already present in upstream fontconfig (with a newer version of the file, btw)