Le 17/07/2019 à 23:14, David Haslam a écrit :
> Several other non-Roman scripts have their own digit characters
> corresponding to our 0-9.
>
> IMHO the possibilities for using non-Roman digits ought to be
> facilitated in the back-end.
>
> Even so, each front-end would then require a new UI cont
Thank you, Michael!
Exodus 3:22 looks fine now after upgrading from engNET2016eb 25.2 to 25.4.
Best regards,
Tobias
On 18.07.19 02:51, Michael Johnson wrote:
Mea culpa. Sorry about that. The engNET2016eb module has been updated to get
rid of some residual XHTML notes at ends of chapters that
I just checked how the "plaintext" version of engNET2016eb Exodus 3:22
looks like.
Whereas all the other verses are actually returned with no markup, this
particular verse is still returned like this (using module->stripText()):
Every woman will ask her neighbor and the one who happens to be
That is a rather sizeable patch. I don't want to just apply it wholesale to
the Sword engine without some input from people who know more about the
code than I do. It should, however, be workable if Troy doesn't have a more
permanent fix in mind.
--Greg
On Wed, Jul 17, 2019 at 4:52 PM Jaak Ristio
Mea culpa. Sorry about that. The engNET2016eb module has been updated to get
rid of some residual XHTML notes at ends of chapters that were missed in the
first filtering process. Oddly enough, the result was actually valid XML
syntax, but its semantics were wrong.
On 7/16/19 9:36 PM, David Hasl
In Sword++ we fixed [1] this by using the fixed-width integer types
provided by . Note also that some certain names containing
underscores are reserved to the C++ implementation [2], e.g. names
beginning with underscores and names containing adjacent underscores.
Best regards,
Jaak
[1]: Feel fr
Thanks, David! To have this broken note shown in the middle of the Bible text
without being asked for is rather distracting in my opinion. I'd rather choose
the "validate and fall back to plain text" option recommended by Peter.
Best regards,
Tobias
Am 17. Juli 2019 22:19:13 MESZ schrieb David
Several other non-Roman scripts have their own digit characters corresponding
to our 0-9.
IMHO the possibilities for using non-Roman digits ought to be facilitated in
the back-end.
Even so, each front-end would then require a new UI control to select which
script should be used to display the
Hello,
I'm still working on a modern NT-Ps-Pr translation in Burmese. My
friends from Myanmar send me the text. But they don't use the arab
numbers, they hava their own numbers.
It could be very important for them to write in they own numbers (If I
had tu use their I will be lost ;) ).
Is it possib
I installed the aforementioned module in PocketSword and sent a screenshot of
the invalid XML verse to Tobias via Facebook Messenger.
It does seem to display the errant markup text as best it can, with footnote
references shown as links, etc.
David
Sent from ProtonMail Mobile
On Wed, Jul 17,
Thanks David!
On 17.07.19 09:36, David Haslam wrote:
Hi Tobias,
OSIS Modules submitted for release by CrossWire should always be
validated prior to submission. They would be rejected if the XML
cannot be validated to one of the OSIS schemas that SWORD supports.
All the more so if the input
Thanks, good advice! Especially the idea about dynamically validating
markup text and then going for the plain text version as a fallback.
I'll think about using that option in node-sword-interface (Ezra
Project's SWORD integration library).
Best regards,
Tobias
On 17.07.19 13:59, Peter Von K
I got an automated report this week that Sword 1.8.1 has begun failing to
build on ppc64le architecture with type redefinition errors. The errors are
reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1730318
To copy from that link, the relevant error is:
/usr/include/asm-generic/int-l64
1) The best way is to recognise it and either fall back to something sane or refuse to deal with the module without crashing. You could presumably if an xml chunk is delivered by the engine to you and is not internally valid ask the engine to re-render it plainly and spit out some message to that e
Hi Tobias,
OSIS Modules submitted for release by CrossWire should always be validated
prior to submission. They would be rejected if the XML cannot be validated to
one of the OSIS schemas that SWORD supports. All the more so if the input file
fails to pass an XML syntax check.
CrossWire has no
15 matches
Mail list logo
