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

Re: [RFC] Better font filetype and metadata file detection for xfsinitscript



On Fri, 10 Oct 2003, Thomas Dodd wrote:

>> xfs is "deprecated" in the sense that all new applications will 
>> be using the new Xft/fontconfig infrastructure, and I had this 
>
>I'm curious about that. With out xfs, how do I share fonts between 
>machines?

Use xfs if you need it.  Or, use NFS or SMB.

>I currently have fon't from 3 systems (Linux, Solaris, and
>HP-UX) shared using xfs so I don't have to keep multiple copies.
>There are also potential legal issues in coping the files form
>one OS to another.

NFS/SMB/xfs all exist currently, so I don't see any issue.


>> useable.  In a case like that for example, my XFree86 4.3.0 
>> packages couldn't easily be recompiled for Red Hat Linux 8.0 and 
>> expected to work.  Another option is a font installation script, 
>> but that suffers from the last problem I described also.
>
>External package is needed. Be it a script or a C program.
>When you make the decision to create it, make version fro the systems 
>you plan to continue supporting. So there's the RHL8, RHL9, and FC-x 
>versions, that understand the differences in each setup. Using 
>nonstandard X,GNOME, and such on those systems are unsupportable any 
>way, so If I update my RHL8 system to act like FC1, it's up to me to fix 
>the font installation program. Since the support of older systems is 
>based on your kindness, you set the rules of such support.

We simply don't drop new development of that type into older 
distribution releases.  Security fixes and major bugfixes only.  
Anything "new" goes into rawhide.

I wont waste my time creating any kind of font installation 
script until there is public discussion of all issues that can 
arise with font installation, which ones we can/should solve, and 
discuss proposed solutions, debate them, and come up with a 
proposal and perhaps a sample implementation that does what is 
needed - or multiple implementations and review and pick one.  At 
that point, it has to be made a mandatory font package 
requirement in _all_ packages that provide fonts, and have a 
properly and well documented policy that is religiously followed.  
I'd prefer if this happens that buildsystem tests are also 
created to enforce it, and packages failed at build time if they 
do not follow proper font installation policy.

That's about the only way we'll ever have consistent policy IMHO, 
is via machine automation and checking.  Humans (all of us, 
including me), are susceptible to programmer error, goofing up, 
not realizing some new method must be used, or not remembering it 
6 months later, etc.

Policy is needed, and must be agreed upon first.  Then 
implementation, and testing.


>> I admit that fonts and font related problems in general are a 
>> huge mess, however it isn't limited to our distribution, but is a 
>> result more of XFree86 having archaic font technology for so many 
>> years.  It'll take a few more years to shake the uglies out of 
>> the font infrastructure.
>
>How exactly did X get such a screwed up system?

It was a good system at the time it was created.  It did the job 
and did it fairly well.  Over time, computing usage changed in 
different ways, and X never really followed.

>Why was it never corrected?

2 answers:

1) It was never corrected, because the existing method did the 
job good enough for a very long time.  It is only recently in the 
last 3 years or so where there has been any significant interest 
of Linux/X on the desktop, and font issues have surfaced as 
important.

2) It has been corrected - at least somewhat, by fontconfig and 
   Xft now.

>How do other systems, especially OS-X handle it?

You'll have to ask Apple I guess.


Keep in mind, Apple MacOS was a desktop OS from day 1, as was 
Windows.  X was not really, and hasn't been considered such until 
very recently.  Asking why fonts don't work as good in X as they 
do in OS/X for example is like asking why Windows ME doesn't 
support 16 processor NUMA hardware....  It wasn't designed to do 
so.

;o)


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




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