[bt-devel] RE: UTF-8 and new module classes

fred bt-devel@crosswire.org
Fri, 25 May 2001 06:02:03 -0400


As possible fonts are needed only for specific languages or language groups,
could installation of needed fonts be an installmgr function?
Install mgr could check to see if the correct font is installed when installing
a module, and then offer to download it and install it.

This way we would be able to support any module with specal font requirements
that is added to crosswire without having to add the font to the bibletime
installation rpm or tar files.

Fred

Tim Brodie wrote:

> ----- Original Message -----
> From: "Martin Gruner" <mg.pub@gmx.net>
> Subject: Re: [bt-devel] RE: UTF-8 and new module classes
>
> > > When someone does hardcopy publishing, part of the mandate of the
> > > publisher is the selection of the look and feel of the document.
> > > The publisher selects paper, fonts, art, etc which becomes as
> > > much an important part of the document as the word content.
> > >
> > > Is it not also in our mandate to provide a BT "look and feel",
> > > which is part of the publishing of the modules?
> >
> > Well, I personally have to disagree here. We are not using hardcopy, but
> > rather electronic documents. There is no paper, art, and as far as I know
> no
> > module-specific font yet. The purpose of tools like bt is to work with the
> > module, not basically to present it. The user should have the choice when
> it
> > comes to fonts.
>
> I realize that there is a difference between publishing on a computer
> and publishing in the printed media.  Isn't the intent of the sword
> library to provide information?  When I look at the output from sword
> right now, all I see is text.  Text is not presentation.  BT is providing
> the presentation.
>
> I'm also speaking to my direct experience with BT in the linux world.
> In my current environment (Mandrake 8.0 fresh install), I can see
> the greek texts, but have no way to increase their font size.  I have
> to try to deal with the issue of fonts (as a limited compentent user)
> when we could easily install a reasonable base set of these for the user
> (if there is nothing available).
>
> > > What I mean by
> > > this is we could select a specific unicode set for each of the
> > > modules such that all of the modules 'work' together and give
> > > an artistically pleasing result.
> >
> > I do not get what you are saying here, please help me understand.
>
> When I install the PC Study Bible product, they provide a greek
> and hebrew font set for the interlinear texts.  These fonts are
> truetype, and enable the user to cut/paste to other applications.
> The fonts are also very attractive, and enhance the look and feel
> of the software.
>
> A cruddy font can make an otherwise sharp piece of software look
> amateurish.  Also, a good font can make a good piece of software
> look even better.  It's about perception.
>
> > > If the end-user decides to install other fonts and select them
> > > (instead of our defaults), the facility is present in BT.  But
> > > the user really should feel this unnecessary.  The only real
> > > adjustment that would typically be desired would be the point
> > > size, as the most common desktop variable will be the screen size.
> >
> > No. Example: I have a greek module with a fontspecific encoding. I want to
> > copy text into another app. No problem. But if I want to share the
> document I
> > created, each user will have to install this particular font. No
> flexibility.
> > Fonts should not matter, they are just descriptions of how the individual
> > letters should be rendered on the screen. But they should not decide which
> > letter to render (as happens in fontspecific encodings). If you use
> another
> > font the doc will be messed up.
> > If there are reasonable standards, why not use them?
>
> I'm not suggesting a different direction than you, only facilitating
> it with a good installation.  Whatever you use to provide a font
> selection, can we not provide a font to install that will enable BT
> to look good "out of the box"?
>
> > > Example, if we present a non-latin module, most end-users will
> > > not have a font that will necessarily present the module in
> > > a pleasing way.  We should provide the necessary font so that
> > > this module doen't look out of character with the rest of the
> > > modules installed.
> >
> > > The reasoning: I am not a greek, but I use the greek modules for
> > > study and so the fonts are not on my system.  Or I am studying
> > > a German text but my machine is not really set up for a german
> > > locale and thus doesn't present the text well.  Why should I
> > > (as an end-user) care about all of this when really all I want
> > > to do is to study the module?
> >
> > The solution is to make it in a way so that you will not have to install
> any
> > font. You just need one iso8859-7 font (greek encoding) that you prefer.
>
> And if sword provides a module for a "snorgle" New Testament ("snorgle"
> being some new language translation), how will the end user actually
> display the text?  I don't have any font... I now have to spend significant
> time/energy trying to find it when the folks putting together the new
> sword module obviously have one (at least to test).
>
> > bibletime will then use your existing font to display the module.
> > Otherwise you might have to install 2 different fonts for 2 different
> greek
> > modules.
>
> Perhaps, but most likely we could standardize on some base iso's for
> all the existing texts and install these during the installation program.
> The user will always be free to use something else, and we don't need
> to crash over an iso that is already established by the user.
>
> Tim