<div dir="ltr"><div class="gmail_default" style="font-family:garamond,serif;font-size:large">In usfm, and paratext, each row of a table is independent. That is, several separate "paragraphs" that start \tr are displayed in a grid form, but each row (\tr) is treated separately. <br><br>As you approach 'tables' in OSIS, I think you'll find that you won't have a problem if you consider this the same way, each row is it's own table. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 18, 2019 at 4:54 PM DM Smith <<a href="mailto:dmsmith@crosswire.org">dmsmith@crosswire.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">When ever a non-milestonable construct is not wholly contained in a verse, it will not work as a SWORD module in all contexts.<div><div><br></div><div>From a module perspective, a verse is what is stored as a verse. It includes all the content between what we know as verses, such as titles, sections, paragraphs.</div><div><br></div><div>Basic reason is that modules are verse oriented. Each verse has to be able to display in isolation. When a verse is not well formed XML, then it cannot.</div><div><br></div><div>We recommend that authors of OSIS see the major constructs of a module to be Books, Chapters, Sections and Paragraphs, expressed as containers. And that verses are milestoned.</div><div><br></div><div>osis2mod will reverse this and complain where it cannot.</div><div><br></div><div>Anything that converts a different format to OSIS has to work around this limitation. osis2mod will tell when it is not so.</div><div><br></div><div>One way around this is to have the osisID be for multiple verses and that contain the construct.</div><div><br></div><div>Another way is for the converter to throw away the “offending” construct and just keep the content. That’s what JSword does on a verse by verse basis.</div><div><br></div><div>In Him,</div><div><span class="gmail-m_8513455671888789849Apple-tab-span" style="white-space:pre-wrap"> </span>DM</div><div><br><div><br><blockquote type="cite"><div>On Feb 18, 2019, at 5:34 PM, David Haslam <<a href="mailto:dfhdfh@protonmail.com" target="_blank">dfhdfh@protonmail.com</a>> wrote:</div><br class="gmail-m_8513455671888789849Apple-interchange-newline"><div> <div>Thanks DM.</div><div><br></div><div>Sound advice if you were speaking to a translator but it’s not as if any of us are. </div><div><br></div><div>The context is preparing the text for building a SWORD module for a modern translation done by a third party. </div><div><br></div><div>We’re not at liberty to change the SFM markup already provided. </div><div><br></div><div>We have to deal with things as they are; not with how we’d like them to be. </div><div><br></div><div>And the tables markup is in the USFM. </div><div><br></div><div>David</div><div><br></div><div id="gmail-m_8513455671888789849protonmail_mobile_signature_block">Sent from ProtonMail Mobile</div> <div><br></div><div><br></div>On Mon, Feb 18, 2019 at 22:04, DM Smith <<a href="mailto:dmsmith@crosswire.org" target="_blank">dmsmith@crosswire.org</a>> wrote:<blockquote class="gmail-m_8513455671888789849protonmail_quote" type="cite"> Don’t do it. Tables are often used for presentation when they shouldn’t. Tables should be used for tabular data.<br><br>Basically, nothing should start or end within a verse that is not milestoned or able to be converted to a milestone.<br><br>In Him,<br> DM<br><br>> On Feb 18, 2019, at 10:39 AM, David Haslam <<a href="mailto:dfhdfh@protonmail.com" target="_blank">dfhdfh@protonmail.com</a>> wrote:<br>><br>> Dear all,<br>><br>> Ryan V wrote about a Bible we're looking at for module build.<br>><br>>> As for the nesting errors, I haven't look at all of them yet. But the ones I did look at have verses starting inside a table, and then ending outside of a table. It's not possible to fix the nesting errors that osis2mod reports in that situation.<br>><br>> Now this is rather odd, seeing as ParaTExt/USFM is quite happy for a table in which the above happens.<br>><br>> What advice is there from SWORD developers about how to proceed?<br>><br>> Must we simply accept the warnings, and just accept the consequences?<br>><br>> Best regards,<br>><br>> David<br>><br>> Sent with ProtonMail Secure Email.<br>><br>><br>><br>> _______________________________________________<br>> sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>> <a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>> Instructions to unsubscribe/change your settings at above page<br><br></blockquote><div><br></div><div><br></div>_______________________________________________<br>sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br><a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>Instructions to unsubscribe/change your settings at above page</div></blockquote></div><br></div></div></div>_______________________________________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page</blockquote></div>