<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 4/18/20 2:48 PM, Greg Hellings
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHxvOVJz-OLqpW5iGSfgp_t6XbtOrcxE+kR7NgFXDS1FBSd3yw@mail.gmail.com">
<div dir="auto">This is the HTML header. Not the HTTP header.</div>
</blockquote>
<br>
<font face="FreeSerif">I had thought that's what the </font><tt><meta
http-equiv=\"content-type\" content=\"application/xhtml+xml;
charset=utf-8\"></tt><font face="FreeSerif"> was supposed to
give me, for the case of a directly-loaded text blob that didn't
arrive via HTTP. Apparently not.<br>
<br>
<tt></tt></font>
<blockquote type="cite"
cite="mid:CAHxvOVJz-OLqpW5iGSfgp_t6XbtOrcxE+kR7NgFXDS1FBSd3yw@mail.gmail.com">
<div dir="auto">For manually loading the text you don't have an
HTTP header, but you still tell the widget what content type
when you call wk_html_open_stream or webkit_web_view_load_string
or similar functions. It's this value that is telling Webkit
what to do.</div>
</blockquote>
<br>
<headdesk><br>
<br>
It hadn't occurred to me that this was done other than in the header
directives as I began to fill the widget.<br>
<br>
Unfortunately, still no joy. There are 6 occurrences of "text/html"
in 3 files that do webkit widget loading:<br>
src/editor/editor.c<br>
src/editor/webkit_editor.c<br>
src/webkit/wk-html.c<br>
And the one that is immediately relevant is of course the last,
which has 1 of the 6. Changing them all from "text/html" to
"application/xhtml+xml" had precisely zero effect. The self-closing
<div> still makes my .introMaterial bleed through to the end
of the chapter.<br>
<br>
I can't win. Sorry. I think I'm done with this exercise in madness.<br>
<br>
For the record, this is the patch that restores
<div/>-non-destructive behavior, with which I've been testing
all these variants. The <meta> is gone, all the other
<?xml> and DOCTYPE are gone, all that's added is the namespace
spec, plus the code change proper that simply pastes the engine's
returned content into the widget, rather than engaging the
<div/> wiping.<br>
<br>
Ohwell. I tried.<br>
<br>
<div dir="auto"><tt>--- src/main/display.cc 2020-04-18
16:39:59.743635867 -0400</tt><br>
</div>
<tt>+++ ../databits/display.cc.FAIL 2020-04-18 16:44:35.607215035
-0400<br>
@@ -89,7 +89,7 @@<br>
N_("<br/><br/><center><i>This module
has no content at this point.</i></center>");<br>
<br>
#define HTML_START \<br>
- "<html><head><meta http-equiv=\"content-type\"
content=\"text/html; charset=utf-8\"> \<br>
+ "<html
xmlns=\<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/1999/xhtml\">"http://www.w3.org/1999/xhtml\"</a>><head> \<br>
<style type=\"text/css\"><!-- \<br>
A { text-decoration:none } \<br>
*[dir=rtl] { text-align: right; } \<br>
@@ -1181,6 +1181,12 @@<br>
key->setChapter(i * chapter);<br>
key->setVerse(0);<br>
<br>
+#if 1<br>
+ buf = g_strdup_printf("%s<br />",<br>
+ (strongs_or_morph<br>
+ ?
block_render(imodule.renderText().c_str())<br>
+ : imodule.renderText().c_str()));<br>
+#else<br>
// begin gosh this is gross.<br>
// hunt down self-closing <div ... /> and stomp
them with spaces.<br>
// this is disgustingly special-case, caused by
self-closing <div><br>
@@ -1217,6 +1223,7 @@<br>
g_string_free(divBuf, TRUE);<br>
<br>
// end grossness<br>
+#endif /* 0 */<br>
<br>
swbuf.append(buf);<br>
g_free(buf);<br>
</tt><br>
</body>
</html>