[sword-devel] Sword support of indents and line breaks

[John Austin]

On Mon, Apr 15, 2013 at 12:38 AM, Peter von Kaehne <refdoc at gmx.net> wrote:

> On Sun, 2013-04-14 at 18:19 +0200, Matěj Cepl wrote:
> >  What
> > should be the SEMANTIC name of the suggested new element?
>
> Please read my post and John's reply.
>
> Most of the occasions where the element is in use it would be sufficient
> for IBT's purposes to fix the whitespace output of the various filters
> and enable language/locale/module dependent, possibly multi-character
> demarcations of certain patterns like quotations and paragraphs or
> alternatively (like Chris and DM have suggested) allow classing and
> enable CSS or some such for such places.
>

> Some, a few, likely very few fall quite rightly under the existing
> <milestone/> element, which is there to encode the arbitrary, marginal,
> bizarre.
>

The <milestone/> element, as described in the OSIS User's Manual, does not
have a predefined type intended for indents, and is itself an empty
element, making it a stretch (although by no means ludicrous) for use as an
indent. Agreed. In defence of its use by IBT, Sword did originally support
<milestone/> for precisely such uses, and so it appeared to be a useful
addition to the original idea. In fact, the push-back has come as a
complete and total surprise. But, it is also understood why Sword would not
want to continue support for something it now considers improper use of the
schema, if that is the case.

There is a concern however, about requiring the addition of paragraph
containers to encode what the translators considered an indent, which were
hand placed to improve comprehension. This has already been discussed
previously in this thread, but I do fear this could have unforeseen
negative consequences. Furthermore, there is a real concern about how
readily IBT's texts will convert to this method, and whether the
implementation would be sufficient or not. There is also a concern that the
amount of work required to convert all of IBT's texts to the <p>...</p>,
<l>...</l> style markup, while successfully retaining their current
fidelity to the translators' texts, could be prohibitive or impossible.
This cannot be known until it is tried, and there are more than 39 modules
on which it would need to be tried. But I have a lot of experience with the
complexities and special situations dotting the SFM projects of many
languages, and my concerns may indeed be real.

So might I propose some kind of backup feature in lieu of the milestone if
it is deemed improper for an indent? One idea is the <seg>...</seg> OSIS
element, which is prescribed to ..."be used, with caution, to mark a
textual feature that is not otherwise provided for by the schema. It should
be noted that this element can only contain very small portions of text and
cannot contain things like verses or paragraphs." Since indents don't seem
to me to be covered by the schema (that I have found) would not an indent
fall under this as a "textual feature", when it is placed for comprehension
(similar to the spaces between words, but separately filterable)?

If Sword rendered whatever is inside the <seg> element UNLESS the raw text,
or strip filter is applied. This would be a good backup plan for IBT and
would play well according to the OSIS manual.

Please note, there is no "demand" for anything in any of this discussion. I
trust whatever you judge best, and that IBT's issues will all work out
eventually by His grace.


> There is no unified semantics of the element and it is not helpful to
> posture and demand semantics - but it is an important language related
> marker for a variety of things - essentially saying something starts
> here - like " in English speech.
>
> Peter
>
>
>
> _______________________________________________
> 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/20130417/dbc457e1/attachment.html>