xfs initscript enhancements, take 5

[Mike A. Harris]

On Thu, 9 Oct 2003, Derek P. Moore wrote:

>> Also...  I think I must not be clued in to something here, but why doesn't
>> this script have support for PostScript Type 1 fonts?  Don't they need
>> fonts.dir and fonts.scale files?
>
>Er...  Nevermind.  I didn't read your email fully and missed all the parts
>about "non-opentype/non-truetype fonts".  *grin*
>
>However, the script still doesn't generate fonts.scale for those "other" fonts.
> And if I'm not incorrect, PostScript Type 1 fonts require fonts.scale, too. 
>In any case, I know 'mkfontscale' will put shit about Type 1 fonts into
>fonts.scale.  That's sayin' something, at least.
>
>Okay, I'm done now,

Yes, but as I've said, it would be experimental.


>PS:  Aren't the other font extensions '.bdf', '.pcf', '.pcf.gz', '.pfa',
>'.pfb', '.t1a', '.afm' (other Type 1 extensions include '.mmm' and a few others
>I can't remember, but if those are lyin' around, they should have corresponding
>'.pfa', '.pfb', or '.t1a' files, I think)?  Why don't you test for those
>extensions instead of just test whether or not the directory is empty.

Because we have had 2 beta releases already, and another one 
coming shortly, and it is too late in the development cycle to 
fix any massive breakages that might result from such a change 
this late which have totally unknown quality.


>Then again, I suppose that's a lot o' test-cases, so maybe
>"directory not empty" is good enough.  *grin*

It's definitely not good enough, or that is all the current 
script would do in the first place.  ;o)

>PPS:  In the end, I have a feeling that "mkfontdir $d && mkfontscale $d" would
>be much better than a bunch of test conditions for TTF vs. OTF vs. Other (at
>least, "theoretically".  *smile*

mkfontscale might generate totally bogus crap fonts.scale files
for all we know.  It's never been used in our distribution.  I do 
know 100% though, that for truetype fonts at least, mkfontscale 
and ttmkfdir do NOT generate the same fonts.scale files for all 
fonts, and this would result in user visible font changes of 
unknown consequence, perhaps only in Japanese or Korean, or 
Chinese, or Arabic, or, etc...  I can't possibly test that.  It's 
the type of change that if we're going to consider it, it is 
something that needs to be put into rawhide 10 minutes after 
Fedora Core 1 ships, so that it's being done with up to 6 months 
left to fix any problems that arise or revert the change.

>PPPS:  What's so experimental about 'find' instead of 'ls | grep'?

What's experimental about it is that making such a change 
requires high confidence that the code will result in identical 
behaviour plus the desired enhancement with no risk of 
regression, since this is the end of the development cycle.  I 
can stare at a regular expression all day and run things through 
my mind, but until it is tested on 100000 end users systems out 
there, I can't possibly guess all of the possible random problems 
that it could cause that were unforseen.  Maybe font files with 
spaces in the filenames cause the script to crash and burn all of 
a sudden, or maybe find's regex implementation is slightly 
different in syntax, etc...

The idea here is that you don't make major changes at the last 
minute that you are not 110% sure are not going to break 
anything.  Even the existing changes I'm proposing come with them 
some risk, which is why I was hesitant to include them without 
having 1000 eyes review them in addition to mine.  ;o)  That 
review process has resulted in some bug fixes and improvements 
which have measureable benefits.  The "find" suggestion has less 
measureable benefit and so the risk isn't worth it for me quite 
yet.  I want to test the existing changes out, and if they work, 
they'll go in.  The find change I'd like to leave for the future 
instead.

Feel free to RFE the Type1 thing using mkfontscale in bugzilla if 
you wish so I remember to do it soon into the next development 
cycle (assuming no objections from Owen or others with rational 
counter arguments against the idea).  As for testing every type 
by filename extension, I think that is more or less impossible, 
as there are more font filename extensions than there are IPv6 IP 
addresses.  ;o)

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