[sword-devel] Rendering added words for languages that don't use italics?
David (Mailing List Addy)
davidslists at gmx.net
Thu Jun 2 15:36:32 MST 2011
On Thursday, June 02, 2011 02:43:31 PM Greg Hellings wrote:
> 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
> > (even for the KJV), despite having well defined markup tags in both
> > and OSIS for several years now. ;>}
> This is because someone just operated under the assumption that
> words meant italics, and produced a straightforward and simple
> 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
> a module's style sheet might mess with the application's design, etc.
> Every module has a style sheet that uses a technology which
> XML-aware sed in its power to insert arbitrary text and styles into
> the module. I would imagine OliveTree and e-Sword and everyone
> 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
> mechanism for representing a work. Complete with support for CSS
> styling. And here we are wringing our hands over allowing a module
> 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).
More information about the sword-devel