Hi
I haven't had any responses to this. I'm considering hard-coding the values
in STEP to ensure I'm not trying to match tagging across versions that have
a different type of mark-up.
Let me know if there is appetite for doing this in a slightly more formal
way?
i.e. the Sword conf files should
I believe we preface strongs numbers with G or H to differentiate.
Chris Burrell ch...@burrell.me.uk wrote:
Hi
I haven't had any responses to this. I'm considering hard-coding the
values
in STEP to ensure I'm not trying to match tagging across versions that
have
a different type of mark-up.
Indeed we do, but that implies one has to read the module content to work
out which set of Strongs is used. Ideally you should be able to tell
without consulting the book contents. For example, I display which features
are available to the user while they pick the version from a dropdown.
Chris
Chris makes an important point.
A few weeks ago, it was discovered that our Finnish modules contain tags
that our software interpreted as linguistic markup, but that were an
artifact from something else.
See http://www.crosswire.org/tracker/browse/MOD-230
David
--
View this message in
Indeed, although looking at the MOD-230, this would only help fix your
issue if the Finish module doesn't also contain strong numbers!
Chris
On 8 February 2013 13:13, David Haslam dfh...@googlemail.com wrote:
Chris makes an important point.
A few weeks ago, it was discovered that our
Hi
I have a second question, slightly unrelated hence the separate thread, on
the contents of the variants. In some instances two variants show an
either/or (e.g. Mat 9.4 WHNU/Byz). That is, by not displaying either of
the variants we effectively end up missing a word in the text.
Unfortunately,
In SWORD the various GlobalOptionFilter values indicate to the SWORD engine
which pieces of code (filters) to enable. Same with some other entries in the
conf.
In JSword, we don't have a filter architecture. We convert everything from the
source type (ThML, Plaintext, GBF, ...) to OSIS. Then
Thanks, that does clarify. Still the problem remains in that we want to be
able to distinguish between different types of tagging (greek, hebrew,
extended greek) by questioning the module. Does the conf file not also
define supported features? Can we not make it so? Or have a flag in there
to
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 ch...@burrell.me.uk wrote:
Hi
Is there are standard subType pattern that modules
For OSIS, the only values to indicate Strong's Numbers are:
GlobalOptionFilter=OSISStrongs
and
Feature=StrongsNumbers
There is nothing defined to further distinguish.
BTW, what is extended Greek? Are you referring to the TVM codes that look like
Strong's Number with a G prefix?
I guess what we
Hi
Because I provide Interlinears, I need to be able to tell the user that for
the combination of LXX and KJV you are unable to see the interlinears in
the OT. The reason being, KJV uses H and LXX uses G. If you're
looking at several texts in interlinears, it simply looks like there is a
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 ch...@burrell.me.uk
12 matches
Mail list logo
