[sword-devel] x-preverse (was: XHTML Rendering of OSIS Reference Doc - Whitespace)
Troy A. Griffitts
scribe at crosswire.org
Fri May 17 08:30:59 MST 2013
Please forget about x-preverse. It was never intended for module
developers. It is an internal attribute we add to help the SWORD engine
process OSIS. Brief overview without details: SWORD must keep all data
in 'verse' chunks. Hence, the title for a verse goes WITHIN the verse
chunk and we need to mark it somehow that it was really meant be be
rendered 'pre-verse'. This should never be known to anyone but a
developer of the internals of the SWORD engine.
I realize it was added manual by module developers to pragmatically get
titles to display how they wished when their markup was not showing
properly because their titles were not getting the x-preverse tag added
by osis2mod. This was the wrong long-term solution (though I don't need
to be lectured on WHY it was used by module developers; I sympathize
that you just wanted to get something working). The correct solution is
2 fold: to use correct OSIS and make sure osis2mod "Does The Right
On 05/17/2013 08:14 AM, DM Smith wrote:
> You've brought up 3 issues here. Two should be on separate threads.
> Regarding rendering of titles, an OSIS <title> should be transformed into a <h1>, <h2>, ... <hn> element by the SWORD api when rendered to (x)html. If it is, then it will be rendered as a block element and not on the same line. If it does not then this thread is an appropriate place to discuss that. Please note, this thread regards the new xhtml filter, not the current filters. But I think this statement is true of the current html filter.
> If usfm2osis.py does not transform USFM titles into an OSIS <title> then all bets are off. This is the only element which osis2mod considers to be a title. If it does not, please bring up this on a new thread.
> The placement of titles in the prior verse has nothing to do with the SWORD rendering of a module into (x)html. It is a problem with the interaction of your module source and osis2mod. It is osis2mod that chunks the input into verses. SWORD api merely grabs what has been stored in the module and renders it.
> If you can provide (in a new thread please), an example of your problem we can proceed. In that new thread, I'll explain (yet again) how osis2mod handles ambiguity in input regarding headings (titles and intros). Ultimately that should go into the wiki for OSIS Bibles. It will also apply to commentary modules.
> In Him,
> On May 17, 2013, at 7:41 AM, David Haslam <dfhmch at googlemail.com> wrote:
>> Vertical whitespace is one thing - I've certainly seen several modules in
>> which the display has too much of it.
>> But surely a related issue is that the titles in OSIS files generated by
>> usfm2osis.py don't even end up with new line when the OSIS is converted to a
>> module using osis2mod !!!!
>> As Chris's stated aim has been to produce "best practice" OSIS XML, it
>> shouldn't be too much to expect that both SWORD & JSword would know that a
>> title element requires at least a new line, such that it does not get
>> appended to the end of the previous verse text.
>> This applies to titles of all kinds: section titles, parallel passages,
>> acrostic titles, and major section titles, etc., etc.
>> I'll restrict my message to this one point - yet there are many other
>> frustrations that module makers face whenever they attempt to get one to
>> work properly in more than one front-end.
>> View this message in context: http://sword-dev.350566.n4.nabble.com/XHTML-Rendering-of-OSIS-Reference-Doc-Whitespace-tp4652262p4652308.html
>> Sent from the SWORD Dev mailing list archive at Nabble.com.
>> sword-devel mailing list: sword-devel at crosswire.org
>> Instructions to unsubscribe/change your settings at above page
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel