The other type of markup that is list like is for poetry and such stanza-like text. The <lg>, line group, is meant as a container for <l>, lines, where each line can have a level, indicating the indent level. In our wiki on OSIS, we note that if the level attribute is absent, we presume it is level="1", and that a level of 1 means no indent. The <l> element only occurs within <lg>.
One of the peculiarities of <lg> is that it cannot contain text. Text has to be contained by an element. There are some other elements that can be found in a <lg>:
<chapter>
<verse>
<q>
<lb/>
<milestone/>
<index/>
It is intended that <chapter>, <verse> and <q> are milestoned.
We recommend that in writing OSIS that every chapter is a valid, well-formed xml fragment. That is, we don't recommend having <chapter> within <lg>.
<q> is problematic to have outside of <l>. The semantic of line start is not defined by OSIS. It could be that every <l> begins a new line and </lg> finishes the group. Or that </l> starts a new line and that <lg> starts the group. If the quote is outside it may have a newline on the wrong side. The <milestone type="cQuote"/> is provided for continuation quotes and has the same issue.
Post by Chris BurrellIn this module, we have various types of lists and various types of tables.
For example, the start of Genesis 1 is rendered as "list" markup in the source of the module. This is representing as a hanging paragraph in the print version, e.g.
aaaaa d dddd
bbbb c d ddddd dd
cccc ddd d ddd
This seems to be an example of using markup for presentation. In OSIS, we want to represent structure using elements. Presentation markup is held in type and subType attributes.
This probably would be best represented as <p type="x-hanging"> or as <lg> and <l>. Note that by using x-hanging you are pretty much guaranteeing that no front-end will provide a hanging indent. There are only a few x-YYYY values that have meaning in SWORD/JSword.
The <l level="n"> where n is a whole number is the way to do subsequent line indenting. I think this is the only mechanism that SWORD/JSword provide.
Print, large displays and small displays differ in how they respond to presentational markup. Print is a rigid format display governed by margins, font and paper size. Other formats may not be rigid allowing for variations in margin, font and viewport. Even management of the viewport (e.g. page flipping vs continuous scrolling vs scrolling & flipping)
Post by Chris BurrellIn Neh 7, for example, this is rendered as a two-column table, with some items marked as indented, e.g.
This probably should be marked up as a table, since it is tabular data. The particular indent of the verse number 2 is not something that you should expect to control.
Looking through Neh 7, the tabular data I see starts in verse 8. I don't see two rows per verse, but rather 1.
Post by Chris Burrell1 aaaaaaa hhh hhh 18
nnnn 7
2 mmmm 9
jjjj 88
This probably should be something like:
<table>
<row><cell align="start"><lg><l level="1"><verse sID="Neh.7.8" osisID="Neh.7.1"/>aaaaaaa hhh hhh</l></lg></cell><cell align="end">18</cell></row>
<row><cell align="start"><lg><l level="2">nnnn</l><cell><cell align="right">7<verse eID="Neh.7.1" osisID="Neh.7.8"/></cell></row>
<row><cell align="start"><lg><l level="2"><verse sID="Neh.7.9" osisID="Neh.7.2"/>mmmm</l></lg></cell><cell align="end">9</cell></row>
<row><cell align="start"><lg><l level="2">jjjj</l><cell><cell align="right">88<verse eID="Neh.7.2" osisID="Neh.7.9"/></cell></row>
</table>
Note: Having the verse start w/in <l> ensures that the verse number is not orphaned on the previous line. It also means that it can be indented.
Post by Chris BurrellI will try later on to render this as a list. I guess it makes sense that the source module tables may map to the OSIS list types. I suspect the <list> tag would get dropped. Will test.
Chris
It was relevant insomuch that it helped me to understand and clarify the
problem.
And for DM too, as the example from the GNB in the USFM User Reference
illustrates that some modern translations have opted to use tables to
simplify repetitive looking lists in passages such as the one in Numbers.
Can't blame the translators. It's a good idea, even if it departs from a
wooden literalness.
Best regards,
David
PS. There are 11 tables in the Welsh Beibl.net USFM files for the Complete
Bible.
Here's the first example in Numbers 1
\p
\tr \th1 Llwyth \th2 Arweinydd
\tr \tc1 Reuben \tc2 Elisur fab Shede?r
\tr \tc1 Simeon \tc2 Shelwmiel fab Swrishadai
\tr \tc1 Jwda \tc2 Nachshon fab Aminadab
\tr \tc1 Issachar \tc2 Nethanel fab Tsw?r
\tr \tc1 Sabulon \tc2 Eliab fab Chelon
\tr \tc1 Effraim \tc2 Elishama fab Amihwd
\tr \tc1 Manasse \tc2 Gamaliel fab Pedatswr
\m Wedyn,
\tr \tc1 Benjamin \tc2 Abidan fab Gideoni
\tr \tc1 Dan \tc2 Achieser fab Amishadai
\tr \tc1 Asher \tc2 Pagiel fab Ochran
\tr \tc1 Gad \tc2 Eliasaff fab Dewel
\tr \tc1 Nafftali \tc2 Achira fab Enan.?
\m
In none of the tables do they cross verse boundaries.
They all use a verse range before the table begins.
This source text is yet to be made into an updated module, even though we
have had the files since last July.
Tables are not the main obstacle. Nested tags are the unsolved issue in
usfm2osis.py
--
View this message in context: http://sword-dev.350566.n4.nabble.com/Tables-across-verse-boundaries-tp4653761p4653768.html
Sent from the SWORD Dev mailing list archive at Nabble.com.
_______________________________________________
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/20140318/431e7761/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4145 bytes
Desc: not available
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20140318/431e7761/attachment.p7s>
