[sword-devel] Poetry and indented lines

[DM Smith]

On Mar 10, 2009, at 4:30 AM, Daniel Owens wrote:

>
>
> Greg Hellings wrote:
>>
>> On Tue, Mar 10, 2009 at 1:55 AM, Daniel Owens <dhowens at pmbx.net>  
>> wrote:
>>
>>> Yes, I considered that means of markup, but it didn't produce the  
>>> result I
>>> was looking for in the front-ends I was targeting, which is why I  
>>> went for
>>> the level="4" attribute. This is one of the tensions with XML-- 
>>> function is
>>> favored over form, leaving the form up to the engine's filters or  
>>> front-end
>>> filters rather than the module developer.
>>>
>> There already is a well-defined mechanism to do exactly this outside
>> of the realm of OSIS or SWORD and general to all XML.  I have
>> repeatedly advocated the use of external CSS files and a standard way
>> of linking them into a module -- either adding a line to the .conf to
>> indicate their location or some other way so that the HTML generated
>> by a front-end can be tied to the CSS file, or the OSIS could be
>> directly displayed and then front-ends would not be forced to render
>> HTML but could directly display the OSIS files.
>>
>>
>
> I know there are issues with versification if you don't compile a  
> module according to the KJV versification (I'm not familiar with how  
> the newer versification model will work, either), but I've always  
> wondered why the source XML files were not just left as-is and  
> displayed using CSS. I know that would pose challenges in terms of  
> parallel display of Bibles and such, but it would mean that module  
> developers wouldn't have to experiment with trial and error to find  
> out what works with the engine as it stands. Also the hacks in terms  
> of headings (which mean that there can be only one heading at a  
> time--a major source of frustration for me as I've encoded several  
> Bibles) could be abandoned. Call me crazy and ignorant of the issues  
> involved, but this is a real question.

I'm going to guess here. HTML is an evolving collection of standards.  
HTML development is also evolving. Early HTML was presentation  
oriented and very little CSS was used. SWORD is around 15 years old.  
I'm guessing that SWORD's HTML filters represent an old way of doing  
things.

>
>
>> Of course, a regular way of linking the OSIS elements to a CSS class
>> or element ID would need to be agreed upon -- perhaps make the CSS
>> class equal to the source element name or some other similar thing
>> (such as name + valueof(level) for the <l> element in this particular
>> discussion).  For example, if the <l> gets transformed into an HTML
>> <li> element, and you had <l level="4">Some Text</l> then perhaps the
>> generated HTML could be <li class="l-4">Some Text</li> and then the
>> module creator could specify .l-4 {float: right} or whatever they
>> wanted in their CSS and that could be linked into the display for
>> those front-ends that support external CSS and HTML displays.
>>
>> Since there are some times when, perhaps, the right-justify may not
>> work well (small screens, whatever), then there could even be  
>> multiple
>> CSS files specified if the module creator desired, so that they could
>> control both the content and display of their module without
>> sacrificing either the semantic power of OSIS or the descriptive  
>> power
>> of CSS to display their modules the way they desire.
>>
>> --Greg
>>
>>
>
> Sure, I could see wanting to give front-end developers the choice to  
> change the display of things based on the requirements of their  
> platform. A conf file could specify what is intended but front-ends  
> could bypass that to their own defaults to fit their situation. CSS  
> makes a lot of sense to me, and it is easier for people like me to  
> learn than diving into cpp files.
>
> Daniel
>
>>> This is probably opening a low-priority can of worms, but what if  
>>> some
>>> controls on the form a module is displayed in were encoded in the  
>>> conf file?
>>> I mean, you could define how certain attributes should be  
>>> displayed to give
>>> module developers more control over how their modules display.  
>>> Otherwise the
>>> filters have to come up with a standard implementation that may or  
>>> may not
>>> match the publisher's intention. Just a thought. I realize that  
>>> may be
>>> creating more work than it's worth, but it might solve the tension  
>>> that
>>> currently exists between form and function. Ideally "selah" should  
>>> be tagged
>>> as the standard suggests, but if that means sacrificing form as a  
>>> module
>>> developer I am reluctant to do that. If I can achieve form without
>>> sacrificing the essential function, I'll do it. If the module  
>>> developer
>>> didn't have to make that sacrifice and could produce good OSIS  
>>> markup, that
>>> would be my ideal.
>>>
>>> Daniel
>>>
>>> Chris Little wrote:
>>>
>>> Daniel Owens wrote:
>>>
>>> One more thing to consider is poetic elements that are right- 
>>> justified. One
>>> of the translations I have worked on preparing for SWORD had  
>>> "Selah" right
>>> justified (VietNVB, in case you're interested). I just encoded it  
>>> like so:
>>>
>>> <l level="4">Sê-la.</l>
>>>
>>> It isn't right-justified, but I think level 3 was the highest  
>>> indented line
>>> I found. There should be a standard way of right-justifying, though.
>>>
>>> Daniel
>>>
>>> It's not a general purpose right-justify directive, but OSIS does  
>>> have a
>>> specific line type for Selah (and Selah-derived) lines:
>>>
>>> <l type="selah">Selah</l>
>>>
>>> --Chris
>>>
>>> _______________________________________________
>>> sword-devel mailing list: sword-devel at crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/sword-devel
>>> Instruct
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20090310/496bdd29/attachment.html>