The normal method to display Bible text added by the translators (implemented
in OSIS by the transChange element) is to use italics at the rendering
stage. I guess that job falls to the front-end developers.
Yet some writing systems do not have italics.
In Chinese, for example, I'm informed that
Gary, if you add this line to your test program (which I suspect Bibletime did
similarly at some point) you should get similar values in tmpKey at that point:
return -1;
}
((VerseKey *)book-getKey())-Headings(true);
book-setPosition(TOP);
return 0;
Thanks Chris,
Is there a way to move existing issues in API to MODTOOLS?
Or were you just thinking of expecting folk to create future issues for
Sword utilities in the new project?
David
--
View this message in context:
On Fri, Mar 2, 2012 at 7:02 AM, Brian J Dumont brian.j.dum...@gmail.com wrote:
Hi all,
I've struggled with large commentaries before. It always seemed that once
commentary sections get too big, then random sections of text start
disappearing.
I'm currently almost done repackaging a part of
From memory -s 4 perhaps?
Cent from my fone so theer mite be tipos. ;)
On Mar 2, 2012, at 8:02 AM, Brian J Dumont brian.j.dum...@gmail.com wrote:
Hi all,
I've struggled with large commentaries before. It always seemed that once
commentary sections get too big, then random sections of
I think osis2mod should detect the problem, output an error and a clear
suggestion to use -s 4.
Cent from my fone so theer mite be tipos. ;)
On Mar 2, 2012, at 8:06 AM, Greg Hellings greg.helli...@gmail.com wrote:
On Fri, Mar 2, 2012 at 7:02 AM, Brian J Dumont brian.j.dum...@gmail.com
On 03/02/2012 08:06 AM, Greg Hellings wrote:
On Fri, Mar 2, 2012 at 7:02 AM, Brian J Dumontbrian.j.dum...@gmail.com wrote:
Hi all,
I've struggled with large commentaries before. It always seemed that once
commentary sections get too big, then random sections of text start
disappearing.
I'm
That would be super-keen DM. It would be nice if it also noted the need
for ModDrv RawCom4 to go along with -s 4
Thanks,
Brian
On 03/02/2012 08:15 AM, DM Smith wrote:
I think osis2mod should detect the problem, output an error and a clear
suggestion to use -s 4.
Cent from my fone so theer
On 2.3.2012 14:02, Brian J Dumont wrote:
I'm not compiling it into a compressed format. My command/output is:
[bjdasc@ascpc5] osis2mod mod debug.osis.xml
You are running osis2mod: $Rev: 2671 $
SUCCESS: osis2mod: has finished its work and will now rest
Interesting. Either it is in the version
Hi Matej,
The difference is that you compiled it as a compressed module. This
makes the limit to be 64kb per section after it is zipped. If you
triple the contents of the div then you'd have the same trouble.
I avoided using a zipped module so that the issue wasn't confused, but
it also
2012/3/2 Brian J Dumont brian.j.dum...@gmail.com:
Hi Matej,
The difference is that you compiled it as a compressed module. This makes
the limit to be 64kb per section after it is zipped. If you triple the
contents of the div then you'd have the same trouble.
I avoided using a zipped
At some point in the middle-distant past Troy was working on some JNI
bindings for the engine and built a minimalistic proof-of-concept
Android application to demonstrate them. I know the application was
not intended for regular usage but I have two questions regarding it:
1) Where is the latest
On 03/02/2012 09:13 AM, Greg Hellings wrote:
2012/3/2 Brian J Dumontbrian.j.dum...@gmail.com:
Hi Matej,
The difference is that you compiled it as a compressed module. This makes
the limit to be 64kb per section after it is zipped. If you triple the
contents of thediv then you'd have the
The JNI bindings should be ready to go. I finished them to within
epsilon of my goal for Android. Maybe a few rough edges to iron out.
They are located in the bindings/ folder of the API.
Though for a web application, I'm not sure they would be best. The
inherent multithreaded nature of
Troy,
I found it takes both of these conditions to cause the problem.
key-Headings(true);
book-setSkipConsecutiveLinks(true);
The program below outputs Malachi 1:1
Should BibleTime do something different or is this a sword issue.
Gary
#include iostream
#include swmgr.h
On 03/02/2012 06:58 AM, Brian J Dumont wrote:
On 03/02/2012 09:13 AM, Greg Hellings wrote:
2012/3/2 Brian J Dumontbrian.j.dum...@gmail.com:
Hi Matej,
The difference is that you compiled it as a compressed module. This
makes
the limit to be 64kb per section after it is zipped. If you
16 matches
Mail list logo