[sword-devel] Markup Options

Greg Hellings greg.hellings at gmail.com
Thu Dec 2 08:19:35 MST 2010

On Thu, Dec 2, 2010 at 3:08 AM, Ben Morgan <benpmorgan at gmail.com> wrote:
> Hi Greg,
> I wasn't suggesting that each user maintain a stylesheet, but if the
> application lets users supply their own, such a stylesheet could be created
> and distributed (it could even potentially target individual modules).

So then you want per-module, per-user stylesheets?  And why would the
module not be allowed to provide its own default to keep the user from
having to download the module's stylesheet from yet another source and
install it?  What you propose there is identical to my proposal with
one exception: your proposal requires extra steps be done manually by
the user which mine would remove the need for (but still leave as an

> You come at this from a different viewpoint. My viewpoint is that the texts
> in a piece of Bible software should be as consistent as possible. The fact
> one publisher likes a particular font, or has verse numbers 1pt smaller, or
> like dull beige tones on the verse number or footnotes is to me largely
> irrelevant. Print bibles can define their own styling because they stand
> entirely alone - completely different books. Within one user interface (e.g.
> BPBible), switching between Bibles, I want to see consistency. I suspect we
> aren't going to agree on this one though...

To be clear, I'm not actually talking about Bibles.  I'm talking about
commentaries, Lexica and general books - though the changes I propose
could also be used in Bibles if desired.  The formatting need of a
Bible is pretty minimal - line and paragraph breaks, possibly italic
or bold font, small caps/divine name, possibly headings.  (Yes, there
are exceptions of picture Bibles or similar, but the actual text of
the Bible in most of those cases is supplemented by commentary-like or
footnote-like material.  And I'm aware of no such instances among
Crosswire modules.)  The formatting needs of an arbitrary text are not
so minimal - tables, borders, floating images or other figures,
margins, padding, font size, alignment of blocks of text to make a
passage clear, etc.

I'm content to just say "We disagree" over customizing displays of
Bibles, but I think the same "no formatting here" stance towards the
other types of works we support is simply incorrect.

> As to you using inline styling, I don't think you should be doing that (not
> necessarily you in particular, but modules we generally have for
> distribution). I'd agree a per-module external stylesheet would be
> preferable to that.

And that is my point.  We provide this mechanism (perhaps
unconsciously or unawares), so why not provide it consciously and
correctly?  I loathe the inline mechanism that I am forced to support.
 But unless we are going to start allowing external stylesheets and/or
custom per-module OSIS->HTML transforms (not saying this second option
is at all desirable, only that would be a second mechanism that allows
me to accomplish my task) or something similar, I'm going to be stuck
doing this.

> I'd like to say this is a special case, and I'd much prefer if it stayed
> that way. I guess some of this is because I like to have control over the
> way things are in BPBible (which is also why I mostly would prefer people to
> use OSIS if possible - it is easier to work for a lot of things than ThML).
> By the way, what is the types of styling you are doing (color, font,
> layout)?

At least we agree on the premise of the argument: presentation and
formatting is vitally important to on-screen text displays.  Ergo, we
both wish to control as much of it as possible - the application
programmer and the content creator.  To that end your statement that
"OSIS...is easier to work for a lot of things than ThML" is a
one-sided statement.  For you, as the application programmer, it is
much easier because you can easily control the look and be in absolute
command of the module's appearance.

For me, as the module creator, it absolutely sucks presently because I
am unable to even hint at anything more complicated than "bold here,
italics there".  This is not a limitation of OSIS at all, but a
limitation in SWORD's willingness to provide the standard
transformational and presentational tools the XML content provider
expects.  I like XML because of its ease of use for the programmer and
for the presenter.  SWORD effectively presents a choice to the module
creator: either use OSIS/XML and be smiled upon by the repository
maintainers and have your work easily able to be processed
programmatically OR use HTML/ThML fragments with inline styling so
your module looks the way you want but is atrocious to try and do
anything other than display to the user.

I am just wanting to close the gap and provide a way for OSIS/XML to
be put into the system to satisfy the experts who might use SWORD
tools for advanced study and still give the module creator the ability
to format their text by means they are already comfortable with.  I
would like to think this is in line with Troy and Chris and DM's (and
others') advocacy of the semantic nature of OSIS divorced from
presentational directives.  I'm fully on board with that objective,
I'm just giving the requirements that I would need before I could make
OSIS a reality for my own work.

As to what types of styling I'm doing now, most of them boil down to
basic CSS1, AFAIK:
bold/italic/underline/strikethrough (some of which is possible with
OSIS already)
font size
borders, margin, padding
floating, sizing and positioning of images
Sometimes specifying the font to use with foreign texts that might use
codepoints out of the range of normal fonts (remember, my modules come
from Wycliffe, who has the possibility of using some very arcane and
even novel combinations of characters and combining diacritics and the

Nothing terribly earth shattering.  In one instance per module we also
do the background color (teal) for the title of each work, but I have
not noticed any other such background colors.  It's not like I want to
move heaven and earth with the CSS styling and break everything. :)


More information about the sword-devel mailing list