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 <niccar...@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 <benpmor...@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 <niccar...@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 <benpmor...@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 <niccar...@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 <dmsm...@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@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 >> > > _______________________________________________ > 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