On Thursday, June 02, 2011 02:43:31 PM Greg Hellings wrote: > David, > > On Sat, May 28, 2011 at 7:12 AM, David Haslam <dfh...@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). _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
