[sword-devel] Vertical whitespace

[Ben Morgan]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20130202/1ddad443/attachment-0001.html>