Greg Hellings wrote: On Tue, Mar 10, 2009 at 1:55 AM, Daniel Owens <dhow...@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. 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@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page _______________________________________________ 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_______________________________________________ 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 |
_______________________________________________ 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