The problem of a table per row is that cell widths may vary from one row to the
next.
In Him,
DM
> On Feb 19, 2019, at 3:15 AM, ref...@gmx.net wrote:
>
> I think Michael's advice might be sound.
>
> Which texts are set in this way?
>
> I presume stuff like the population counts in Exodus etc? Or genealogy?
>
> Sent from my mobile. Please forgive shortness, typos and weird autocorrects.
>
>
> -------- Original Message --------
> Subject: Re: [sword-devel] OSIS files with Tables and Nesting warnings from
> osis2mod
> From: Michael H
> To: SWORD Developers' Collaboration Forum
> CC:
>
>
> 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.
>
> 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.
>
> On Mon, Feb 18, 2019 at 4:54 PM DM Smith <dmsm...@crosswire.org
> <mailto:dmsm...@crosswire.org>> wrote:
> When ever a non-milestonable construct is not wholly contained in a verse, it
> will not work as a SWORD module in all contexts.
>
> 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.
>
> 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.
>
> 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.
>
> osis2mod will reverse this and complain where it cannot.
>
> Anything that converts a different format to OSIS has to work around this
> limitation. osis2mod will tell when it is not so.
>
> One way around this is to have the osisID be for multiple verses and that
> contain the construct.
>
> 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.
>
> In Him,
> DM
>
>
>> On Feb 18, 2019, at 5:34 PM, David Haslam <dfh...@protonmail.com
>> <mailto:dfh...@protonmail.com>> wrote:
>>
>> Thanks DM.
>>
>> Sound advice if you were speaking to a translator but it’s not as if any of
>> us are.
>>
>> The context is preparing the text for building a SWORD module for a modern
>> translation done by a third party.
>>
>> We’re not at liberty to change the SFM markup already provided.
>>
>> We have to deal with things as they are; not with how we’d like them to be.
>>
>> And the tables markup is in the USFM.
>>
>> David
>>
>> Sent from ProtonMail Mobile
>>
>>
>> On Mon, Feb 18, 2019 at 22:04, DM Smith <dmsm...@crosswire.org
>> <mailto:dmsm...@crosswire.org>> wrote:
>>>
>>> Don’t do it. Tables are often used for presentation when they shouldn’t.
>>> Tables should be used for tabular data.
>>>
>>> Basically, nothing should start or end within a verse that is not
>>> milestoned or able to be converted to a milestone.
>>>
>>> In Him,
>>> DM
>>>
>>> > On Feb 18, 2019, at 10:39 AM, David Haslam <dfh...@protonmail.com
>>> > <mailto:dfh...@protonmail.com>> wrote:
>>> >
>>> > Dear all,
>>> >
>>> > Ryan V wrote about a Bible we're looking at for module build.
>>> >
>>> >> 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.
>>> >
>>> > Now this is rather odd, seeing as ParaTExt/USFM is quite happy for a
>>> > table in which the above happens.
>>> >
>>> > What advice is there from SWORD developers about how to proceed?
>>> >
>>> > Must we simply accept the warnings, and just accept the consequences?
>>> >
>>> > Best regards,
>>> >
>>> > David
>>> >
>>> > Sent with ProtonMail Secure Email.
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > sword-devel mailing list: sword-devel@crosswire.org
>>> > <mailto:sword-devel@crosswire.org>
>>> > http://www.crosswire.org/mailman/listinfo/sword-devel
>>> > <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
>> <mailto:sword-devel@crosswire.org>
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> <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
> <mailto:sword-devel@crosswire.org>
> http://www.crosswire.org/mailman/listinfo/sword-devel
> <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
