Re: ttmkfdir

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 7 Nov 2002, Gene C. wrote:

>On Wednesday 06 November 2002 16:00, Mike A. Harris wrote:
>> 2-3 years without documentation, and one person asking for it
>> isn't too bad.  I guess if it was hard to write, it should be
>> hard to use too.
>
>This is probably as good a mailing list to ask these questions as any and 
>maybe even more appropriate.
>
>We haven't needed to ask about documentation very much because we did not need 
>to with our 15 year old font system.  However, this is not changing with Xft 
>and fontconfig.  Until the Red Hat manuals can be updated (code before 
>documentation), I believe a bit more info is needed.
>
>Mike, the explanation of the font situation (on the psyche mailing list) is 
>very good.  However, I believe that there are a few questions to clarify 
>things:
>
>1. I did not know that the ttmkfdir program even existed until I examined the 
>--scripts for the XFree87-truetype-fonts package.  I had previously build 
>fonts.scale files by hand for truetype fonts I installed.  The ttmkfdir and 
>mkfontscale programs produce different lists given the same set of .ttf 
>files.  Which is more "correct".

The one that produces the best results that you are looking for 
is the more correct one.

>2.  When you use ttmkfdir -m 100 you get a lot more fonts since some some of 
>the strange fonts do not have a full character set.  Is this a good idea?  
>When mkfontscale is "ready" to replace ttmkfdir, what will be done about this 
>capability or will all be listed even those that are a bit sparse?

I have no idea.  I'm not in any way involved in the development 
of mkfontscale.


>3.  I can easily tell what fc-list does and how to use it but how about 
>fc-cache?  In the 8.0 RELEASE-NOTES, there is a brief description of 
>installing some fonts into ~/.fonts and then running fc-cache <directory> but 
>it does not say anything else.  When do we need to run fc-cache.  I see that 
>~/.fonts-cache-1 is automatically created when a new user logs in or when 
>~/.fonts-cache-1 has been deleted.  I assume that ~/.fonts-cache-1 is a 
>"directory" to available fonts.  Is this correct because I do not see this 
>documented anywhere.  However, if it exist, it is not recreated for every 
>login.  While the RELEASE-NOTES says to run fc-cache when you update 
>~/.fonts, what happens when a new package of fonts is installed?

fc-cache is an optional step, and that is why it isn't ran 
everywhere yet, and things still work.  It creates a fontconfig 
cache of font info.


>4.  Does the new Xft/fontconfig still require the running ttmkfdir and 
>mkfontdir?  No mention is made of them by the procedure in RELEASE-NOTES.

No.  I don't believe that level of detailed information about 
anything in the OS is something sensible or required to put into 
RELEASE-NOTES.  Few people read RELEASE-NOTES as it is already, 
and the longer the file gets, the less likelyhood of a person 
actually reading it.  Since regardless of wether or not we 
document something in RELEASE-NOTES or our manuals, or not - we 
still end up with users complaining by large that things aren't 
documented (again, even if they are documented), so the 
difference is sadly small wether or not things are documented.

I think the best solution all around for as many things as 
possible, is to make things as automatic as possible, thus hiding 
the various changes and improvements from users as much as 
possible.  Only if someone _wants_ or needs to know how something 
works should they be required to read the docs.  When is the last 
time anyone ever read the font section of a M$ Windows manual?  
When is the last time anyone ever read a Windows manual, or 
release-notes?  Does it even have a manual anymore?  I dunno, but 
hopefully fontconfiguration in Linux will be very much the same 
soon enough.

>I must say that you are making the new font capability (as well
>as the old xfs one) be as correctly configured as possible
>without the intervension of a user.  This is very good!

That's the goal, yes.


-- 
Mike A. Harris		ftp://people.redhat.com/mharris
OS Systems Engineer
XFree86 maintainer
Red Hat Inc.



_______________________________________________
xfree86-list mailing list
xfree86-list@redhat.com
https://listman.redhat.com/mailman/listinfo/xfree86-list
IRC: #xfree86 on irc.redhat.com

[Red Hat General]     [Red Hat Watch]     [Red Hat Development]     [Kernel Development]     [Yosemite Camping]

  Powered by Linux