Re: makewrapper.sh patch


Subject: Re: makewrapper.sh patch
From: Vlad Harchev (hvv@hippo.ru)
Date: Sat Dec 30 2000 - 06:01:38 CST


On Fri, 29 Dec 2000, Kevin Vajk wrote:

>
> On Fri, 29 Dec 2000, Vlad Harchev wrote:
>
> > Adding all sundirs with fonts it can find is a useless thing unless AW
> > is modified to look for all fonts in all subdirs while booting.
>
> You see through my ruse. That's another change I was interested in
> advocating soon... :)

 Making AW doing so is incorrect, see below.
 
> > Making
> > AW look for all subdirs for fonts is also a very bad idea - different subdirs
> > can provide fonts for different encodings but the same name (e.g. Helvetica) -
> > and since AW doesn't display font's encoding, user will see a 5 fonts named
> > "Helvetica" in font combobox (and will have to guess which one corresponds to
> > some encoding).
>
> Yeah, but abiword certainly won't come this way by default.
>
> I agree this is a problem, but it seems to me like an inherent X-window
> system limitation. If the user places a font in the abiword fonts directory,
> it was done intentionally so that they could use the font with abiword.

 Yes, it's a limitation, but it's not dificult to solve.

 You seem to be forgetting that unix is multiuser system, and can be used by a
lot of users simulatenously. Consider a server at the university with a lot of
foreign students, and that computers are all diskless and run AW via NFS from
the server. If AW will behave as you suggest, every user will get ALL fonts
installed in their comboboxes - and it that case (provided a lot of
locale-specific subdirs are present) EACH user will get a dozen of Helvetica
in their font combobox. Please think admin-wise, not user-wise. We are not MS
or Corel to be so stupid.

> > SO we should make shell script computing all "permutations" of
> > locale-specific subdirectory name.
>
> But why we are only making fonts available if our locale matches?
>
> For my own use, I eventually want to use abiword in my native language locale
> (english) but still be able to type in other scripts (thai in particular).

 You'll just have to set $LANG to something corresponding to Thai, and set
$LC_MESSAGES to "en", and of course configure your X server to accept Thai
character. Please don't invent the wheel.

> > As for not removing fonts from font path - I also told how to detect
> > whether AW is running 20 minutes ago.
> >
> > So someone should write script that will generate all permutations of
> > locale-specific subdir name, add means for detecting whether AW is running and
> > update all 4 scripts that generate AbiWord script.
>
> Ugh. When I get a minute, I'll play around with detecting abiword already
> running. The problem of deleting the font path while abiword is running needs
> to be solved, since we all agree it's a bug. My idea is that if xlsclients
> is available, we do the right thing, but if xlsclients is not available, we
> play it safe and leave the fonts in the path. Sound correct?

 Yes.

 But I think we can solve all our problems by prefixing all font names we ship
with Abi - i.e. instead of
        -AbiSource-Arial-regular-r-normal--0-0-0-0-p-0-iso8859-1
we call them
        -AbiSource-AbiArial-regular-r-normal--0-0-0-0-p-0-iso8859-1
So those stupid Qt-based apps won't use our scalable fonts, and AW, when
reading the list of fonts, will just strip "Abi" prefix, getting "normal" font
names ("Arial" in this case).

 This way, we won't need to remove anything from font path (and admin could
add subdirs with fonts that are shipped with AW to font path permamently).

 Any thoughts on this?

> The other stuff (automatically adding subdirectories) clearly needs more
> discussion. Which is great; I'm far better at discussing than I am at
> actually writing anything. :)

 It's better to discuss first and code after that, than to code first and
discuss how to fix the problem that arose due to insufficient discussion.

> - Kevin Vajk
> <kvajk@ricochet.net>
>
>

 Best regards,
  -Vlad



This archive was generated by hypermail 2b25 : Sat Dec 30 2000 - 06:28:27 CST