[sword-devel] Markup Options
jonmmorgan at gmail.com
Sun Dec 5 05:06:44 MST 2010
On Fri, Dec 3, 2010 at 2:19 AM, Greg Hellings <greg.hellings at gmail.com>wrote:
> 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
> > 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
> > in a piece of Bible software should be as consistent as possible. The
> > one publisher likes a particular font, or has verse numbers 1pt smaller,
> > 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
> > BPBible), switching between Bibles, I want to see consistency. I suspect
> > 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.
I agree that it is a little less important and likely to break (though don't
under-estimate our ability to mix and match in weird and wonderful ways and
break module CSS even in Genbooks).
My biggest concern when dealing with arbitrary formatting for things like
this is that people want to make it "just like a book", and I'm not
convinced that leads to the best electronic reading experience. That being
said, nor do I think a screen dump of text without any attempt at presenting
it is very helpful.
> > As to you using inline styling, I don't think you should be doing that
> > 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
> > use OSIS if possible - it is easier to work for a lot of things than
> > 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
Sizing and positioning of images potentially conflicts with programs like
Xiphos that helpfully resize massive images to fit the screen size. It may
also affect its display on devices with different form factors (e.g. iPhone
and Android, which may not affect you, but also netbook resolutions). Do
you want images to be displayed at a different size from their physical
resolution ever? If so, why?
My experience with floats tends to suggest that a float could accidentally
break a layout, but at the same time they probably make sense.
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
If it's something you need for the entire module, you might be better
advised to use the Font config option, which is more designed to do that. I
don't know which programs support it, though (I only found out about it very
recently, and I don't think BPBible supports it).
While I realise that strange codepoints may require strange fonts, I'm a
little concerned about font being controlled by the module creator when it
ends up inconsistent with everything else they have on screen and with their
personal preference (for example, I would just about always have mine set to
Verdana, which is a little ugly, but very readable). If you are doing it
for sections of the text rather than the whole text there may also be places
that look completely out of place.
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. :)
Sorry, we're software developers. Either it cannot break anything, or it
has the potential to break something so we have to ban it because it
probably will. :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sword-devel