[sword-devel] poetry formatting (was Re: Vertical whitespace)

Sun Feb 3 14:31:00 MST 2013

Some of it is going to require CSS support anyway to do the layout.
If there's just a div with a CSS class, frontends can handle that as they
require, and the indenting support shouldn't cause an issue.

BTW, with the Proverbs 28 issue, my guess is the opening <lg> is a few
chapters earlier.

In the <l> handling code, I have these lines:
if not self.in_lg:
 dprint(WARNING, "l outside lg??? (or block doesn't contain lg)")
self.start_lg(None)

In other words, we always have an implicit <lg> if there wasn't one in the
current chapter and we got to an <l>.
This seems to work very well.

Looking forward to seeing poetry support in PocketSword...

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 Mon, Feb 4, 2013 at 12:25 AM, Nic Carter <niccarter at mac.com> wrote:

>
> Thanks heaps for this, Ben :)
>
> Appears I had a little bug in the previous patch I emailed around. When
> closing the div on line 379 of osishtmlhref.cpp I had added a "<br />"
> which shouldn't be there!
>
> I like how you have BPBible displaying this stuff, and so it's inspired me
> to fix up some of the formatting in PS. :) I've even rewritten how I do
> highlighting to do it "properly" & not break the HTML badly so that this
> will work :P
> I've had to have different css stuff for PS based on whether it's on a
> small iPhone screen or a larger iPad screen & after hacking this myself, I
> saw your 500px versions & incorporated them as well :)
>
> All this to say, perhaps in the SWORD API we should have apps be able to
> flag whether they want poetry indenting on or off, cause it is quite
> possible that it will break formatting that the different front-ends do,
> and so if we have it off by default, front-ends will have to accommodate it
> and then manually switch it on, thereby not breaking how things
> look/work...?  ;)
> [or, at least, I've spent much more time fixing PS to work with the
> changes I made to SWORD than I did implementing the poetry indentation in
> SWORD!]
>
> Thanks heaps, ybic
> nic...  :)
>
>
> On 02/02/2013, at 10:14 PM, Ben Morgan <benpmorgan at gmail.com> wrote:
>
> Hi Nic,
>
> Structural content in verse 0 is another good example why you shouldn't
> turn introductions off - I think they should always be on, just the
> headings inside them (when non-canonical) should be able to be turned off.
>
> As for floating the whitespace around, this is a post-process and mostly
> done using regular expressions.
> See SmartBody here:
> https://code.google.com/p/bpbible/source/browse/trunk/backend/verse_template.py#49
>
> This allows the verse number to be put in at a logical point in the
> whitespace flow (e.g. If a paragraph starts at the start of a verse, you
> want the verse number to be inside the paragraph).
>
> As to the floating the verse number in poetry it uses this CSS to put it
> in the left margin of the <lg>:
>
> https://code.google.com/p/bpbible/source/browse/trunk/css/bpbible_chapter_view.css
> .chapterview blockquote.lg > a.versenumber,
> .chapterview blockquote.lg > span.had_highlight > a.versenumber
> {
> position: relative;
>  float: left;
> left: -4em;
> width: 3em;
>  text-align: center;
> line-height: inherit;
> }
>
> .chapterview blockquote.lg a.chapternumber
> {
> width: 1.5em;
> text-align: center;
> -moz-margin-start: -2em;
>  line-height: 100%;
> font-size: 150%;
> }
>
> Disclaimer on my CSS:
> I put in what made it work - no guarantees that it is nice/efficient. It
> does appear to be mostly functional
> It's specifically mozilla oriented, and may not work elsewhere.
>
> That said, it can work elsewhere - I've got the poetry layout with verse
> numbers etc. working on my Kindle. I haven't checked in the code yet which
> generates the epub to be transformed for Kindle, but some of the CSS
> changes I made for that make it less mozilla oriented.
>
> 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 Sat, Feb 2, 2013 at 4:49 PM, 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
>>
>
> _______________________________________________
> 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/20130204/5b3104d3/attachment-0001.html>