[sword-devel] Verse number markers

[David Haslam]

Worth noting that adyeths u2o.py converts some related USFM tags to OSIS milestones.

Ideally, we should recognise the attributes allocated therein.

David

Sent from ProtonMail Mobile

On Sat, Nov 24, 2018 at 10:19, refdoc at gmx.net <refdoc at gmx.net> wrote:

> Milestone or some such is exactly what I thought as they can be ignored easily.
>
> There is no issue for non CSS capable front-end, if a front-end is not able to deal with it they simply get switched off. Not different to other features.
>
> The rendering is no challenge and can be left to front-end who want to use it.
>
> VPL would be possible as per CSS at least. It might be not straightforward but currently reversified blobs are not an beautiful thing either. So at worst it will look similarly bad, at best we can achieve for versuche blobs and reordered ranges a nearly equivalent presentation to ordinarily sequenced and marked up verses.
>
> The engine delivers a CSS sheet to the front-end which some, like xiphos (partially) override. Module CSS sheets are part of the module and get delivered together with text, images etc.
>
> As I said, I think I can implement this largely by myself and with no disruption for older front-ends or modules.
>
> The main reason I do not simply start to code is because I want to understand if there is some ideological or principal objection against milestones or similar tags getting deployed.
>
> Peter
>
> Sent from my mobile. Please forgive shortness, typos and weird autocorrects.
>
> -------- Original Message --------
> Subject: Re: [sword-devel] Verse number markers
> From: David Haslam
> To: sword-devel
> CC:
>
>> Could this be done using the existing OSIS milestone element, allocating suitable a new x-attribute to record that [say] the n attribute stores a verse label?
>>
>> cf. We already use milestone elements for particular module features, such as the Pilcrow sign in the KJV.
>>
>> The rendering by front-ends is the greater challenge. Superscripts? Colour?
>>
>> CSS is all very well for Xiphos, but how do you even get the CSS file into a mobile device?
>> It's not as if they are bundled within the module, is it?
>>
>> Likewise, toggling display to verse per line, should we require these to function in this manner too.
>>
>> cf. We might want that for those strange verse labels in AddEsth,
>> but we wouldn't want it for alternative verse numbers that we added because of v11n differences.
>>
>> This topic requires a lot more thought before anyone jumps in to coding.
>>
>> User Requirements must come before Functional Specification in [software] development.
>>
>> Regards,
>>
>> David
>>
>> Sent from ProtonMail Mobile
>>
>> On Sat, Nov 24, 2018 at 08:02, refdoc at gmx.net <refdoc at gmx.net> wrote:
>>
>>> This is a proposal which I think I can largely do at the library end myself, but as it reflects a significant change I would like to have some input and discussion.
>>>
>>> I want to introduce verse number markers as a element separate from the verse tag. By default these should not be shown, but showing them in parts or all can solve all kind of vexing issues.
>>>
>>> 1) reversified verses. We have plenty texts were at least some verses will need recertification. This is unsightly and confusing for the reader. By adding verse markers we can reduce the ghastliness. We do add new versifications probably for a while longer but there are clear limits how many we want to maintain. And unless we allow and provide the infrastructure for dynamic av11n this will stay so. Note that I am not by necessity convinced by dynamic av11n
>>>
>>> 2) reordered translations. Every so often I encounter texts where the translator has in order to improve understanding reordered verses. This is usually captured currently in a verse range, which will then loose the link to the source text somewhat. By providing verse number markers we can reduce the divergence from the print. Underlying the text will still be an OSIS range, but the reordered marker tags will make this more slightly
>>>
>>> 3) alphanumeric verse and consequential numbers. Esther has this a lot and it is a mess. We could have a numeric counter underneath and whatever above it.
>>>
>>> 4) ad hoc module maker fixes. To deal with our limitations as described above module makers have produced all kinds of inconsistent "fixes", dropping bracketed numbers or similar in the text. By using a set of agreed and consistent tags we can sort this.
>>>
>>> In short the verse number mark tag shall have no structural meaning, it shall be simply a tag somewhere which says, if you want you can _present_ here a specific and given verse number. It will carry a number of attributes which will allow ingrained CSS and possibly conf file option etc control and switching on or off.
>>>
>>> The changes this requires are limited and I think I can already more or less see them. I think they should be possible to do that they have no or only limited front-end implications and in particular do not block or duplicate front-end ordinary verse numbering. The changes should also be non disruptive in terms of coexistence of old and new modules.
>>>
>>> The disadvantages are all about user expectation, a request for a particular verse may still produce a verse range in cases of reversification blobs or reordered ranges. In Greek Esther even more so. But to be frank, what we do now is not less messy.
>>>
>>> What do you think?
>>>
>>> Peter
>>>
>>> Sent from my mobile. Please forgive shortness, typos and weird autocorrects.
>>> _______________________________________________
>>> 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
>
> @crosswire.org>@protonmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20181124/48aa04c9/attachment-0001.html>