[sword-devel] Rendering added words for languages that don't use italics?

[David (Mailing List Addy)]

On Thursday, June 02, 2011 02:43:31 PM Greg Hellings wrote:
> David,
> 
> On Sat, May 28, 2011 at 7:12 AM, David Haslam 
<dfhmch at googlemail.com> wrote:
> > Thanks Greg,
> > 
> > That's a very helpful summary of the multiple difficulties, not the
> > least of which is manpower.
> > 
> > It almost makes one wonder how anything got done to support 
added words
> > (even for the KJV), despite having well defined markup tags in both 
USFM
> > and OSIS for several years now. ;>}
> 
> This is because someone just operated under the assumption that 
added
> words meant italics, and produced a straightforward and simple 
mapping
> to the HTML <i> or the RTF equivalent.

This is no different than the assumption that texts will use the KJV 
v11n, and in fact KJV style translations use italics in the print editions 
(or well oblique which is technically different than italic). Also not all 
front-ends make that assumption. Bibletime puts a div or a span or 
something around it (I'd have to check the HTML to know which) and 
lets the user selected style sheet render it how it wants.

> It's probably not of any interest to other software producers. While
> I'm not privvy to most technologies out there, I do know that Logos
> does not wrangle and wring its hands and cry over the possibility 
that
> a module's style sheet might mess with the application's design, etc.
> Every module has a style sheet that uses a technology which 
resembles
> XML-aware sed in its power to insert arbitrary text and styles into
> the module.  I would imagine OliveTree and e-Sword and everyone 
else
> in the field who wants to be taken seriously does as well.
> 
> As an example, the industry standard format for book publishing
> recently released its latest update wherein they adopted HTML5 as 
the
> mechanism for representing a work.  Complete with support for CSS 
and
> JavaScript within the works to allow each book to customize its
> styling.  And here we are wringing our hands over allowing a module 
to
> have a CSS file (which David documents in his just previous email
> would be sufficient for all the problems mentioned here).

If it's not of interest to other software, it should be. I've only used logos 
briefly once, but their interface didn't even use native widgets/tool-kits 
so I would have to question whether these software programs that 
don't have issue with per module style sheets have concerns about 
accessibility. What happens, if say, in the Bibletime High Contrast 
display sheet I have selected the module maker's preferred method of 
showing added text for something else?

Let's use italics as the example since it's come up a lot. In BT's high 
contrast template italics are used to mark words of Christ. I couldn't 
use red because of the background colours I selected (to match 
KDE3's High Contrast system colour theme), so italics for added words 
would be potentially confusing. And overriding that style sheet could 
render a module useless to someone who is using that style sheet 
because they have vision problems and that's the only way they can 
see the text on screen. A similar issue came up with that style sheet 
and (at least older versions of) the ISV as the ISV hard-coded red in for 
the words of Christ.

So which would get preference in a conflict, the front-end's style, the 
module's style, some custom user style to fit their specific need? (For 
the record IIRC the cascade of CSS from least to most important on 
web browsers has the page author's style sheet as least and the 
user's sheet as most).