[sword-devel] poetry formatting (was Re: Vertical whitespace)
DM Smith
dmsmith at crosswire.org
Sat Feb 2 12:30:33 MST 2013
In the upcoming update to the ESV, the <l> element will be using the level attribute to indicate indentation. A level="1" means first level line, level="2" a second level line, level="3" a third level line. If the level attribute is not present treat it as 1.
That is, level 1 is no indent.
Regarding the psalm 1 <lg> problem, please let me know of problems. This seems to be addressed.
When I get it a bit further along, I'll share it with key application devs so they can proof it in their apps.
In Him,
DM
On Feb 2, 2013, at 12:49 AM, Nic Carter <niccarter at mac.com> wrote:
>
> Thanks heaps for this :)
> I'm getting there, but have encountered a few interesting bits. I'm using the ESV and something I just realised was that Psalm 1 only had a closing <lg> tag at the end of verse 6 & no opening tag:
> <lg eID="w106"/>
> I couldn't find the opening one anywhere in the chapter.
>
> Until I looked at Psalm 1:0
> & then I found it!
>
> Anyway, I have it mostly working (besides for cases like the above, where you _need_ to have the Introductions switched on for the formatting to work correctly).
>
> However, the tricky thing for this to then work with PS is the verse numbers, where you talk about doing some "floating block whitespace" to make it "work more nicely". I'm gonna try to look at what BPBible does in regards to that, cause I'm a novice when it comes to HTML now-a-days...
>
>
> Thanks, ybic
> nic... :)
>
> On 02/02/2013, at 12:02 AM, Ben Morgan <benpmorgan at gmail.com> wrote:
>
>> I've found vertical whitespace can be problematic, and it's often around verse boundaries.
>>
>> osis2mod often seems to put some of the whitespace in the previous verse/chapter, which I think I reported a long time ago and should be fixed. I remember we had trouble finding the right combination of when to start a verse. I have a vague feeling I had suggested some fixes which weren't ever put in - but I can't be sure, and it's possible there might have been some which caused other issues.
>>
>> BPBible does some things like floating block whitespace before verse numbers etc. to make this work more nicely.
>>
>> As for the two-level poetry layout (or 3 level - e.g. ESV 1 Tim 3:16), BPBible has done this for ages (e.g. try opening ESV in psalms). It's not particularly straightforward to implement well though. A brief overview of how it is done:
>>
>> The start tag <l> gets handled something like so:
>> mapping = {
>> # usual poetry indent in ESV
>> "x-indent": 2,
>>
>> # extra indent - 1 Tim 3:16 (ESV) for example
>> "x-indent-2": 4,
>>
>> # declares lines - Declares the Lord, Says the Lord, etc.
>> "x-declares": 6,
>>
>> # doxology - Amen and Amen - Psalms 41:13, 72:19, 89:52 in ESV
>> "x-psalm-doxology": 6,
>>
>> # usual poetry indent in WEB
>> "x-secondary": 2,
>> }
>>
>> level = xmltag.getAttribute("level")
>> if level:
>> # the level defaults to 1 - i.e. no indent
>> indent = 2 * (int(level) - 1)
>> else:
>> indent = mapping.get(xmltag.getAttribute("type"), 0)
>>
>> #if indent:
>> if self.in_indent:
>> dprint(WARNING, "Nested indented l's", self.u.key.getText())
>>
>> self.in_indent = True
>> if not self.in_copy_verses_mode:
>> self.buf += '<div class="indentedline width-%d" source="l">' % indent
>> self.blocklevel_start()
>>
>> and end tag like so:
>> def end_l(self, xmltag):
>> if self.in_indent:
>> self.blocklevel_end()
>> self.buf += "<br>" if self.in_copy_verses_mode else "</div>"
>>
>> <lg> elements are also handled, turning them into blockquotes.
>>
>> This is matched up with CSS like so (note, there's a lot more in it than this to handle floating verse numbers outside of poetry etc):
>> /* Poetry */
>> blockquote.lg
>> {
>> margin: 0.5em 0em 0.5em 3em;
>> }
>>
>> /* We want our indented lines to behave nicely - wrapped lines should be
>> * indented further. text-indent undoes the wide margin only for the first
>> * line */
>> div.indentedline.width-2 {
>> -moz-padding-start: 5em;
>> text-indent: -3em;
>> }
>> div.indentedline.width-4 {
>> -moz-padding-start: 5em;
>> text-indent: -1em;
>> }
>> div.indentedline.width-6 {
>> -moz-padding-start: 7em;
>> text-indent: -1em;
>> }
>>
>> div.indentedline.width-0 {
>> -moz-padding-start: 5em;
>> text-indent: -5em;
>> }
>>
>> God Bless,
>> Ben
>> -------------------------------------------------------------
>> For I have no pleasure in the death of anyone,
>> declares the Lord God; so turn, and live.”
>> Ezekiel 18:32 (ESV)
>>
>>
>>
>> On Fri, Feb 1, 2013 at 9:32 PM, Nic Carter <niccarter at mac.com> wrote:
>>
>> Is this caused by improperly formed modules that have fun with <l> poetry & <lb> ?
>> [I think I have already emailed through what I do after the filter gives me it's result in order to try to reduce the vertical whitespace!]
>>
>> And while I'm on the topic of poetry, in Proverbs you often see couplets (altho are they termed that in the Bible?) where in a printed Bible the 2nd line is indented. Would we be able to do that to some degree? I don't know the OSIS tags that refer to this, but if someone were able to point me in the right direction, I may even be able to hack this together myself? I am looking around line 360 of osishtmlhref.cpp........
>>
>> On 20/01/2013, at 8:12 AM, DM Smith <dmsmith at crosswire.org> wrote:
>>
>> > I've noticed that OSIS modules sometimes render with a lot of vertical whitespace (blank lines).
>> >
>> > I'd like for this to be sorted as part of the next release. I don't think it'd be too hard. I've been in the osishtmlhref filter to see if I could figure it out, but it is beyond me.
>> >
>> > So this is a suggestion for others.
>> >
>> > Using the HTML notion of block and inline elements, I think we can classify OSIS elements as block or inline. Off the top of my head, <div>, <chapter>, <p>, <lb/>, <lg>, <l>, <title>, <table> and <row> are the block elements.
>> > The key feature of a block element is that block elements that follow each other stack one on top of each other.
>> > Some block elements allow nesting, such as <div>.
>> >
>> > In HTML, an empty <div> occupies no vertical space. A nested div does not cause additional vertical space.
>> >
>> > In HTML, a <p> has semantics as to whether it is preceded or followed by whitespace. A <p> at the beginning of a document is not preceded by a blank line. Nor is a </p> at the end of a document. This is also true after a heading element.
>> >
>> > I think that the SWORD renderers always cause a <div> to occupy vertical whitespace.
>> >
>> > The other issue with <div> is that we now have a "pre-verse" div, which is a great way of marking off what stands before a verse, but this <div> really shouldn't have any <div> semantic. It probably would have been better if we used <milestone> instead.
>> >
>> > I seem to remember that there is a "swollow" flag for whitespace (I think it might be for horizontal whitespace.) I think something like this could be used for vertical whitespace.
>> >
>> > The other part to this is when a chapter is shown verse-per-line. If because of rendering the pre-verse content the verse already starts on a new line, I don't think more vertical whitespace should be produced.
>> >
>> >
>> > Together in His Service,
>> > DM
>> > _______________________________________________
>> > sword-devel mailing list: sword-devel at 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 at 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 at 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 at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20130202/3c947d80/attachment.html>
More information about the sword-devel
mailing list