On Sat, 2009-12-05 at 15:27 +0100, Norbert Preining wrote:
> On Sa, 05 Dez 2009, Paul Wise wrote:
> > Yeah, they aren't particularly well standardised. I don't think it
> > matters much which you use.
>
> Hmm, is there no FHS or policy on that?
Not sure about that.
> > You add the symlinks now and then not worry about the fontconfig stuff
> > at all. Xorg will probably get your fonts when #539338 is fixed, the
> > patch needs testing/checking though, not sure if it follows symlinks.
>
> The discussion on the bug report shows that it goes down 100 levels
> of dirs including symlinks.
Cool. That should be enough levels too.
> > Install all your fonts to /usr/share/fonts instead of the current paths
> > and then not worry about the fontconfig stuff at all. Xorg will get your
> > fonts when #539338 is fixed.
>
> No, I don't want to create links for each and every font.
Why would you need to do that?
> > File a bug on fontconfig to get your font paths added to its
> > configuration and triggers. Also file a bug on Xorg to get your font
> > paths added to the default FontPath. The latter is needed to get your
> > fonts into Xorg during the period where it doesn't support fontconfig,
> > which will be quite a while.
>
> Hmm, again I am a bit puzzled.
>
> As far as I see there are two things involved:
>
> 1. fontconfig accessing the fonts
> 2. X accessing the fonts
>
> For 1. I can simply wait until fontconfig is trigger-enabled, at which
> point the fonts will be available to fontconfig immediately.
fontconfig is already trigger-enabled, but it doesn't know about the
non-standard path TeXLive uses for fonts.
> For 2. we need mkfontscale be recursively and trigger enabled, as
> discussed in bug #539338, but that seems to take ages, right?
> But when I put the fonts below truetype and type1 in /u/s/fonts
> they are already in the default font path, so the only thing
> that would be needed is fixing mkfontscale, and there is already
> a bug.
Right.
> So for what I see there are two options. In both cases I drop
> links below /u/s/f/truetype and /u/s/f/type1.
>
> Then
> A. I call fc-cache in every font shipping package
> B. I do NOT call fc-cache ...
You should do B....
> Doing A. would do 1. from above, while doing B. would mean that we
> have to wait for font config triggers to be implemented to get
> fontconfig accessing the fonts
...because fontconfig already has triggers for /u/s/f/
> Regarding 2. X accessing the fonts there are again some options:
> - short term solution:
> register all the fonts manually with X
>
> - mid term solution:
> fix #539338 and the fonts will be available
>
> - long term solution:
> Xorg gets fontconfig support built in
Right.
> The only thing I can take is the short term solution, but I will not
> do that, since that are too many fonts and I don't want to do that
> for all the directories.
Fair enough.
> So my proposal is: link as described above and do nothing else for now
Sounds fine to me I guess.
I guess moving all the fonts to the standard /u/s/f/{t,o}/ directory is
out of the question?
> Effect: fonts will not be available to X, and to fontconfig only after
> someone else has called fc-cache.
The fonts missing from X isn't a regression though, so that is fine.
fontconfig will call fc-cache from the trigger in its postinst, so the
fonts should be available to fontconfig-supporting apps immediately.
> After that is in unstable and we have fixed the billions of RC bugs
> coming in after the first upload to unstable, I will try to add
> the fc-cache calls to the font shipping packages' postinst and postrm
> scripts, which will make the fonts available automatically for fontconfig.
That isn't needed because of the existing fontconfig triggers.
> On the X front I wait for the above to be fixed, or any other solution,
> and do nothing.
Correct.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part