<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 09/02/2021 15:33, Joan Moreau wrote:<br>
</div>
<blockquote type="cite"
cite="mid:b0dd487091fc21ff8b33102fcf858188@grosjo.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>If I place the following code in the plugin
fts_backend_xxx_update_build_more function (lucene, squat and
xapian, as solr refuses to work properly on my setup)</p>
<p><span style="font-family: 'courier new', courier, monospace;">
{</span><br>
<span style="font-family: 'courier new', courier, monospace;">
char * s = i_strdup("EMPTY");</span><br>
<span style="font-family: 'courier new', courier, monospace;">
if(data != NULL) { i_free(s); s =
i_strndup(data,20); }</span><br>
<span style="font-family: 'courier new', courier, monospace;">
i_info("fts_backend_update_build_more: data like
'%s'",s);</span><br>
<span style="font-family: 'courier new', courier, monospace;">
i_free(s);</span><br>
<span style="font-family: 'courier new', courier, monospace;">
}</span></p>
<p>and if I send a PDF by email, the data shown in the log is
"%PDF-1.7 "</p>
<p>so it does mean the decoder data is not properly transmitted to
the plugin</p>
<p>Something is wrong in the data transmission</p>
</blockquote>
<p>Joan <br>
</p>
<p>I too see something similar with fts_solr. I do see the raw %PDF
string and PDF binary data being passed through to
fts_backend_xxx_update_build_more function but I disagree with the
conclusion you draw from it. <br>
</p>
<p>After the raw data I also see the decoded data, so at least in my
case it is possible to see both the raw and decoded data in
fts_backend_xxx_update_build_more function. In the rawlog I no
longer see the binary data (but some blank lines), so something is
filtering it. I do see the decoded data in the rawlog. I do get
hits on the solr search for the decoded text.</p>
<p>John</p>
</body>
</html>