OK Karl,
I've committed a fix for this. We handle a bunch of OSIS div types
specifically, but we weren't handling type="introduction" which is what
the ESV used, so the div was simply passed thru. I'm now checking div
types we don't handle and if they are trojan milestones (they include
sID and
On 4/18/20 6:32 PM, Caleb Maclennan wrote:
> ESV modules have been pulled from every public SWORD repository
Uh-huh.
Do you suppose that there aren't several tens of thousands of people who
still have it, including Troy?
___
sword-devel mailing list: swor
On Sun, Apr 19, 2020 at 1:27 AM Karl Kleinpaste wrote:
> On 4/18/20 5:25 PM, Troy A. Griffitts wrote:
>
> Do you have a module and entry key value I can use for testing?
>
> ESV2011, intro commentary paragraphs at every book's 1:1.
>
The ESV modules have been pulled from every public SWORD repos
On 4/18/20 5:25 PM, Troy A. Griffitts wrote:
>
> Do you have a module and entry key value I can use for testing?
>
ESV2011, intro commentary paragraphs at every book's 1:1.
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/m
Hey Karl,
Do you have a module and entry key value I can use for testing?
Troy
On 4/18/20 2:10 PM, Karl Kleinpaste wrote:
> On 4/18/20 2:48 PM, Greg Hellings wrote:
>> This is the HTML header. Not the HTTP header.
>
> I had thought that's what the content=\"application/xhtml+xml; charset=utf-8
On 4/18/20 2:48 PM, Greg Hellings wrote:
> This is the HTML header. Not the HTTP header.
I had thought that's what the was supposed to give
me, for the case of a directly-loaded text blob that didn't arrive via
HTTP. Apparently not.
> For manually loading the text you don't have an HTTP header, b
On Sat, Apr 18, 2020, 07:09 Karl Kleinpaste wrote:
> On 4/17/20 11:43 AM, Greg Hellings wrote:
>
> the HTML WG suggests, and apparently all browsers implement, ignoring
> those directives and instaead caring only about the Content-Type
> header/directive. So if you have that header/directive in X
OK - I now have a workaround:
Using Firefox to access the tracker, I was able to create a new issue.
cf. The problem occurred while I was using Brave.
Best regards,
David
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐ Original Message ‐‐‐
On Saturday, 18 April 2020 17
Thanks Greg,
I just tried again, and the same occurred. Here's a screenshot.
https://www.dropbox.com/s/ghqe9rxlhl5l7ok/Screenshot%202020-04-18%2017.25.24.png?dl=0
Best regards,
David
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐ Original Message ‐‐‐
On Saturday, Apri
Karl, I fear that, even if you get this working, as Greg mentioned earlier, if
any module sends even the smallest error which causes the content not to
strictly validate-- like an open quote which doesn't close at the end of a
verse, that the browser may drop out of XHTML mode. I do find it odd
On 4/17/20 11:43 AM, Greg Hellings wrote:
> the HTML WG suggests, and apparently all browsers implement, ignoring
> those directives and instaead caring only about the Content-Type
> header/directive. So if you have that header/directive in Xiphos, then
> try updating that to the appropriate "appli
11 matches
Mail list logo
