[sword-devel] OSIS formatting

[David Blue (Mailing List Addy)]

On Thursday 16 June 2005 03:42 pm, Greg Hellings wrote:
> I have been using Bibletime to display
> highly formatted texts which include colored fonts, backgrounds, borders,
> table spacing and widths, etc and when the information is encoded with ThML
> and style="" tags containing a very wide range of CSS then the formatting
> is preserved beautifully. It is all completely ignored by Bibletime if the
> input is OSIS.
[snip]
> That said, I appreciate most of the formatting that can be done with CSS.
> It allows for a much larger range of display characteristics than OSIS's
> very small selection of text-only formatting. If Bibletime and/or Sword
> would accept CSS formatting from a style="" tag in OSIS, then my problems
> would mysteriously vanish into thin air, but for the time being the wider
> range of ThML-allowed formatting thrrough the availability of CSS has
> influenced my choice of formatting to be ThML. As an alternative, Sword
> might allow a user-defined XSL or even CSS to be specified with each module
> to define formatting on a per-module basis so that the distinction between
> data and presentation (which is inherent to XML's purpose) may be
> maintained.

Doing your own hard-coded formatting in a module isn't always a good thing. 
Take for instance bibletime, we will, in the next release, have a 
high-contrast theme. The current plan is black on white, except for the 
current verse which will be white on black to emphasize it. And some light, 
pastel-y colors that are high contrast on both black and white for footnotes, 
verse numbers, etc. If your module over-rides this, then all of a sudden your 
module becomes useless to those who need high-contrast to be able to use a 
module. If you're using Bibletime 1.5rc1 then read some of the verses in the 
gospels in the ISV module using the High Contrast theme and you'll see what I 
mean. The ISV hard-codes it's font colors in making it hard to present to 
people with specific issues

The point of XML, as opposed to its predecessor, SGML is to separate document 
content and structure from presentation. This allows for other programs to 
reformat the module according to a particular users needs. The best way to 
mark up the module is to use tags to indicate what the content and let the 
front end decide how best to render it, rather than telling the front end how 
to format the module. That way, a text to speech program for instance, can 
format the module in a way that will make sense when red aloud. This example 
is especially important for things like tables. Or, as another example, 
Bibletime can format the module according to it's high-contrast rules, or 
large print rules, or whatever other accessibility needs are required to be 
met. Oh, and we also can't forget programs like PalmBible+, or qpsword, etc. 
which have to reformat everything anyway to accommodate a smaller screen, and 
possibly even a monochrome screen.

The point is, embedding the style data in the module itself isn't always the 
best way to go if you're text is only going to be electronic. Now if it's 
being generated exclusively for print, that is different, but even in that 
one case it could be argued that you encode the module according to content, 
not presentation, and then use stylesheets or the program that prints to do 
all the formatting.

-- 
--David's Mailinglist and Spam Receiver
   Keeping me (fairly) spam free since 2002