In view of the fact that not all front-end apps currently support Variants,
here is a proposal for managing modules that make use of OSISVariants.
- A module with Variants to be hosted in the CrossWire Beta repository.
- A module without Variants to be hosted in the CrossWire Main repository.
T
The problem of "no spaces" when both readings are shown is very easy to
solve.
Just take proper care when making the module.
I documented this ages ago in the wiki page for OSIS Bibles.
Rather than having (may|can) you'd have ( may| can) - using simplified
notation to illustrate.
It can help al
There is no other option for the front-end.
The engine (SWORD and JSword) will only show one or the other of two variants.
I’m pretty sure JSword doesn’t allow “the other”. To do otherwise means that
the engine has to determine another mechanism which the front-end has to
choose. Example, show
I would agree that makes sense for a front-end that has UI support for
selecting variants,
but otherwise, the user never even gets to see the text for the Secondary
Reading.
Remaining invisible is much worse than any potential confusion!
The problem therefore never gets reported to the app develo
Default should be to show only the first variant. Confusing otherwise.
— DM Smith
> On Oct 15, 2017, at 7:34 AM, David Haslam wrote:
>
> Xiphos already has UI support for OSIS Variants. It works fine for a module
> with variants.
>
> When installed in other apps (such as PocketSword for iO
Xiphos already has UI support for OSIS Variants. It works fine for a module
with variants.
When installed in other apps (such as PocketSword for iOS or And Bible for
Android OS),
such a module should (in theory at least) display All Readings [as the
fall-back default].
NB. Unfortunately, PocketS
Apart from Xiphos, which other front-ends have UI support for variants ?
Any development plans in this area?
Best regards,
David
--
Sent from: http://sword-dev.350566.n4.nabble.com/
___
sword-devel mailing list: sword-devel@crosswire.org
http://www
A further thought...
Might it be feasible to permit to define the variant delimiter markers
somewhere within the conf file?
i.e. As replacements for whatever we decide to use as defaults.
David
--
View this message in context:
http://sword-dev.350566.n4.nabble.com/OSIS-Variants-do-we-need-a-d
Thanks for your positive reception to my suggestion, Chris.
Other less common brackets (also with potential font issues) might be:
⁅ ... ⁆ SQUARE BRACKETS WITH QUILL
❲ ... ❳ TORTOISE SHELL BRACKETS ORNAMENT
⌜ ... ⌟ (or ⌞ ... ⌝) TOP & BOTTOM CORNERS
IMHO, The latter have a certain attractive lo
On 2/18/2014 7:06 AM, David Haslam wrote:
When using a front-end to select All Readings, rather than either Primary
Reading or Secondary Reading, do you think we should have a delimiter
character between the two variant readings?
I think this is a good idea, particularly since it can be impleme
When using a front-end to select All Readings, rather than either Primary
Reading or Secondary Reading, do you think we should have a delimiter
character between the two variant readings?
If we borrow a tip from Backus–Naur Form, then perhaps the vertical bar
character would be appropriate?
If SW
I'm not sure this is an issue with the ThML converter. From using mod2imp,
we have
Mat 1.9:
$$$Matthew 1:9
οζιας δε εγεννησεν τον ιωαθαμ ιωαθαμ δε εγεννησεν τον * αχας | αχαζ | 881 {N-PRI} | αχας αχαζ 881 {N-PRI}*δε εγεννησεν τον εζεκιαν
Mat 9.4 outputs the seg with tags in them. Mat 1.9 outpu
I noticed this a few weeks ago. We should change JSword's ThML converter to
output OSIS as is used in Byz and WHNU. And the xslt to handle it.
When I did the original, there were not any variants in an OSIS text.
In Him,
DM
On Feb 8, 2013, at 1:09 PM, Chris Burrell wrote:
> Hi
>
> Is
The form in Byz and WHNU are what we've settled on for OSIS.
If we find something else in an OSIS module, then we probably should log it in
Jira.
In Him,
DM
On Feb 8, 2013, at 1:09 PM, Chris Burrell wrote:
> Hi
>
> Is there are standard subType pattern that modules are supposed to fo
Hi
Is there are standard subType pattern that modules are supposed to follow?
It seems Byz and WHNU are using x- where n is the variant number.
αχας | αχαζ | 881 {N-PRI} |
αχας
αχαζ
I'm seeing some code taken originally from BibleDesktop which suggests
subType can be x-class-1 ?
A pos
Hi everyone, I have just added two new bullet points to the
http://www.crosswire.org/wiki/Frontends:FeatureList#Search_features Search
features section of http://www.crosswire.org/wiki/Frontends:FeatureList
Frontends:FeatureList in the wiki.
* Option to include/exclude alternative reading
On Sat, Jan 9, 2010 at 5:18 AM, Daniel Owens wrote:
> On 1/8/2010 11:22 AM, Matthew Talbert wrote:
>>
>> On Thu, Jan 7, 2010 at 11:32 PM, Daniel Owens wrote:
>>
>>>
>>> Okay, I think I understand better. I think the main concern with keeping
>>> a
>>> variant as a toggled option is that it be sea
> though, that from a front-end perspective a simple option to include
> variants or footnotes could be added. After all, the notes are with the main
> text in the module. They are just displayed differently in the front-end,
> right? This could be revealing my ignorance, of course. If it is, then
On 1/8/2010 11:22 AM, Matthew Talbert wrote:
On Thu, Jan 7, 2010 at 11:32 PM, Daniel Owens wrote:
Okay, I think I understand better. I think the main concern with keeping a
variant as a toggled option is that it be searchable and able to be queried
for lemma and morphology. As long as that
On Thu, Jan 7, 2010 at 11:32 PM, Daniel Owens wrote:
> Okay, I think I understand better. I think the main concern with keeping a
> variant as a toggled option is that it be searchable and able to be queried
> for lemma and morphology. As long as that can happen in a note, I'm happy
> with keeping
Okay, I think I understand better. I think the main concern with keeping
a variant as a toggled option is that it be searchable and able to be
queried for lemma and morphology. As long as that can happen in a note,
I'm happy with keeping it there. I think it makes sense that way, but I
can see
We have probably got a few Bibles released that use the markup suggested
in the Wiki. It looks like I either forgot to write or forgot to commit
the code to actually make this work in Sword.
How to represent ketiv & qere readings in OSIS depends on how you
interpret them and how you want to di
Troy,
With a hint from David Troidl, I see now that on p. 82 of the OSIS
manual the rdg element can contain w elements. I suppose the markup
could look like this:
lemma="strong:H0318">הוצאsubType="x-qere">הַיְצֵ֣א
Would that link the two sufficiently? I am guessing a bit on the subType
att
Troy,
Thanks for getting back on this so quickly.
In addition to the wiki advice...
Looking at the OSIS manual (pp. 103-105) it seems that variants are a
type of note ("x-variant") or reading (rdg type="x-variant").
The ThML markup (using divs) would seem to work as well if the attribute
we
Daniel,
Thanks for pushing this. I've looked at the OSISVariants filter and it
does indeed look (as stated in the Jira report by you and Chris) that it
has never been used for anything useful. I'll try to nail down the
exact syntax for OSIS variant readings in general (not simply qere, as
we wil
Sorry to answer my own post, but I see that OSISVariants is a global
option filter. I have added that to the wiki. Now to figure out how to
mark it up in OSIS...
Daniel
On 1/7/2010 2:27 PM, Daniel Owens wrote:
I see that SWORD supports ThML variants very well, but I am trying to
create a modu
I see that SWORD supports ThML variants very well, but I am trying to
create a module with variants in OSIS. Consulting the wiki, I see that I
should mark these up as follows:
הוצא
הַיְצֵ֣א
However, since there is no conf option for this, both variants show up
in the text (Xiphos and BibleTim
27 matches
Mail list logo
