On 03/24/2017 05:48 PM, David Haslam wrote:
> How does this work?
2TGreek was created long before av11n, so it depends on basic KJV v11n,
as did the LXX + TischMorph modules which constitute it. Whatever was
(is) in LXX, that's what's in 2TGreek.
___
sw
On 03/24/2017 01:58 PM, TS wrote:
> as I understand it, Is. 61:1 should not contain any vowel points above the ש
> "Shin" letters.
Not being a Hebrew reader, I can't tell if the display is fully correct.
I see points above ש but don't know if this is right or wrong. Your
opinion? I've attached wi
Hi!
It seems that back in 2013 SVN 2780 introduced the logic to detect
strongs numbers and add padding:
commit d35ffd0642aadb2dfb52039cc3081e59e5f48225
Author: scribe
Date: Fri Feb 1 09:11:52 2013 +
added ability to turn off logic to detect strongs numbers and add
padding.
There is no versification entry in *2tgreek.conf* yet the OT is based on the
LXX.
How does this work?
David
--
View this message in context:
http://sword-dev.350566.n4.nabble.com/2TGreek-module-versification-tp4657014.html
Sent from the SWORD Dev mailing list archive at Nabble.com.
_
Afterthought:
I will upload my copy of *wycliffe.py* to GitHub at some stage, so that
anyone can clone it and adapt it for other Bibles on Wikisource.
It captures the text from the *Special* download pages and converts each of
them to USFM.
Acknowledgements to Chris Little (more than three years
The complete 76 book text for the *Wycliffe Bible* is available on Wikisource
at https:\\en.wikisource.org\wiki\Bible_(Wycliffe)
I have already converted the text to USFM and thence to OSIS XML.
The text had not been altered since I previously captured the text in
January 2014.
Back then I merely
Tim wrote, "It seems though that if one is viewing the 2TGreek module at the
time of the setting change, it requires changing the Bible being used to a
different one and then back again in order to refresh the display of the
text and have the accents shown."
Got it!
And unlike other filter switch
Afterthought
If Bible students using SWORd front-ends wish to have a further option
filter to hide *Sin Dot* and *Shin Dot*, then technically that's feasible,
but I doubt that SWORD developers will be in a hurry to make this, and
front-end developers may have to wait for a long time.
David
Tim is correct in his observation as regards the two diacritics on the Hebrew
letter SHIN in modules such as OSHB.
They are not hidden when the module options are selected to hide them.
Neither the SIN DOT nor the SIN DOT are hidden.
However, his conclusion is unwarranted.
This is not a bug in
The Aleppo module (as is) has no Hebrew diacritics at all.
Of course, the actual codex should have them, but the module was made from a
digital source that lacked them.
If a better digital source became available, and had diacritics, then we
should rebuild the module.
David
--
View this messa
Tim is right.
Modules TR and WHNU do not include this line in the conf file.
GlobalOptionFilter=UTF8GreekAccents
It would be a simple enough task for these modules to be updated to include
this line.
Peter ?
Best regards,
David
--
View this message in context:
http://sword-dev.350566.n4.
Whatever one might think as a textual critic about the presence or absence of
diacritical marks in the original Hebrew of the Tanach, there's a strong
sense that such consideration should not come into this technical
discussion.
The simple truth is that each SWORD module aims to reproduce a clearl
Another possibility is to use Boost.Xpressive [1], which I think
supports the Perl regular expressions at runtime, and also static
regular expressions using C++ syntax:
using namespace boost::xpressive;
// sregex rex = sregex::compile( "(\\w+) (\\w+)!" );
sregex rex = (s1= +_w) >> ' '
It's not just firewalls that can prevent XML validation using a remote schema
location!
Sometimes having a *VPN connection* can also cause problems.
I was getting strange messages from Notepad++ XMLTools plugin today when I
was doing an OSIS validation check.
Earlier today it had worked fine.
I was curious to see if I could use the accent/diacritic marks to my advantage
to find words with the same markings. I used PocketSword. Clucene is the search
engine it uses. When I have all the markings turned on in OSHB, copy a word,
and then try and find the word, I get zero results. If I tur
I have this problem when using PocketSword. The Aleppo module seems correct
though. Does anybody else have this problem with any other frontends ?
For example, as I understand it, Is. 61:1 should not contain any vowel points
above the ש "Shin" letters.
-TS
--Sent from phone--
__
It seems that you are correct regarding the rendering of Tisch on PocketSword,
however if one uses the 2TGreek module which includes Tisch., it does have the
option to show the Greek accents. It seems though that if one is viewing the
2TGreek module at the time of the setting change, it requires
One of the /subtractive/ filters is undocumented apart from being mentioned
in *diatheke* CL help.
I have therefore posted a question in this talk page:
https://crosswire.org/wiki/Talk:DevTools:conf_Files#GlobalOptionFilter.3DUTF8ArabicShaping_.3F
David
--
View this message in context:
http:
Further to the later part of our discussion about OSIS variants, I have just
added an issue about how SWORD handles subtractive filters in terms of
defaults.
http://tracker.crosswire.org/browse/API-202
Best regards,
David
--
View this message in context:
http://sword-dev.350566.n4.nabble.com
Yep, *PocketSword* hides both Hebrew vowels and cantillation. :(
And then there's *UTF8ArabicPoints*.
Yet strangely enough, *PocketSword* does show the points in (say) the
*AraNAV* module.
There's a strange inconsistency within this topic.
I suppose this came to the scene later than Greek & Hebre
On 03/24/2017 06:25 AM, David Haslam wrote:
> e.g. *For UTF8GreekAccents*, the /default/ ought to be to *show* them,
Also Hebrew vowel points and cantillation.
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/list
Even with only two variants supported by SWORD, it manages to get things
wrong!
e.g. Xiphos has module options for selecting variants:
* Primary reading
* Secondary reading
* All readings
Yet when the user selects *Primary*, the *Secondary* reading is displayed,
and /vice versa/!
This is not a
22 matches
Mail list logo
