From f.j.wright at live.co.uk  Thu Apr  1 18:00:18 2021
From: f.j.wright at live.co.uk (Francis Wright)
Date: Thu, 1 Apr 2021 16:00:18 +0000
Subject: [tex4ht] Problem using mjcli on Cygwin
In-Reply-To: <CAOCj1Od6vAuRQLcMD0Jno5vMdegg+k4X6CfD4mp9_5PKLdO7Jw@mail.gmail.com>
References: <AM6PR07MB4598208D8A39C87870A14952E57D9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <20210330190349.t3kgfhzvqm2nymtd@agraulos>
 <AM6PR07MB4598656F72F13AD893602382E57C9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <CAOCj1OdA+paS=xZkBNpuXyAKdCi_wkyGw8m3=0U4WfZGfk2Pvw@mail.gmail.com>
 <AM6PR07MB4598FC89474C5B4C2E1BEF16E57C9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <CAOCj1Od6vAuRQLcMD0Jno5vMdegg+k4X6CfD4mp9_5PKLdO7Jw@mail.gmail.com>
Message-ID: <AM6PR07MB45984E8B9064D03E902BB421E57B9@AM6PR07MB4598.eurprd07.prod.outlook.com>

Thanks. Removing the mathjax option does indeed remove the two redundant script elements relating to MathJax from the output HTML files, although using MathML seems to cause other problems that I need to investigate further.

Best wishes, Francis

-----Original Message-----
From: Michal Hoftich <michal.h21 at gmail.com> 
Sent: Wednesday, 31 March 2021 9:59 pm
To: Francis Wright <f.j.wright at live.co.uk>
Cc: tex4ht at tug.org
Subject: Re: [tex4ht] Problem using mjcli on Cygwin

You don't need to use the "mathjax" option with mjcli extension, it loads the necessary code automatically, but without the JavaScript inclusion.

Best regards,
Michal



From michal.h21 at gmail.com  Thu Apr  1 19:16:58 2021
From: michal.h21 at gmail.com (Michal Hoftich)
Date: Thu, 1 Apr 2021 19:16:58 +0200
Subject: [tex4ht] Problem using mjcli on Cygwin
In-Reply-To: <AM6PR07MB45984E8B9064D03E902BB421E57B9@AM6PR07MB4598.eurprd07.prod.outlook.com>
References: <AM6PR07MB4598208D8A39C87870A14952E57D9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <20210330190349.t3kgfhzvqm2nymtd@agraulos>
 <AM6PR07MB4598656F72F13AD893602382E57C9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <CAOCj1OdA+paS=xZkBNpuXyAKdCi_wkyGw8m3=0U4WfZGfk2Pvw@mail.gmail.com>
 <AM6PR07MB4598FC89474C5B4C2E1BEF16E57C9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <CAOCj1Od6vAuRQLcMD0Jno5vMdegg+k4X6CfD4mp9_5PKLdO7Jw@mail.gmail.com>
 <AM6PR07MB45984E8B9064D03E902BB421E57B9@AM6PR07MB4598.eurprd07.prod.outlook.com>
Message-ID: <20210401171658.ubxysihh2av3ha7e@agraulos>

What problems do happen? MathML shouldn't be used unless you explicitly 
use the "mathml" option. There are some notorious issues with sub and 
super scripts with the MathML option, TeX4ht needs to enclose the base 
and exponent in {} in order to work correctly, for example. I am sure 
there are many more problems.

Best regards,
Michal

>Thanks. Removing the mathjax option does indeed remove the two 
>redundant script elements relating to MathJax from the output HTML 
>files, although using MathML seems to cause other problems that I need 
>to investigate further.
>
>Best wishes, Francis
>

From f.j.wright at live.co.uk  Fri Apr  2 17:17:46 2021
From: f.j.wright at live.co.uk (Francis Wright)
Date: Fri, 2 Apr 2021 15:17:46 +0000
Subject: [tex4ht] Problem using mjcli on Cygwin
In-Reply-To: <20210401171658.ubxysihh2av3ha7e@agraulos>
References: <AM6PR07MB4598208D8A39C87870A14952E57D9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <20210330190349.t3kgfhzvqm2nymtd@agraulos>
 <AM6PR07MB4598656F72F13AD893602382E57C9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <CAOCj1OdA+paS=xZkBNpuXyAKdCi_wkyGw8m3=0U4WfZGfk2Pvw@mail.gmail.com>
 <AM6PR07MB4598FC89474C5B4C2E1BEF16E57C9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <CAOCj1Od6vAuRQLcMD0Jno5vMdegg+k4X6CfD4mp9_5PKLdO7Jw@mail.gmail.com>
 <AM6PR07MB45984E8B9064D03E902BB421E57B9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <20210401171658.ubxysihh2av3ha7e@agraulos>
Message-ID: <AM6PR07MB45988E2AFADADBD8AE204EC8E57A9@AM6PR07MB4598.eurprd07.prod.outlook.com>

Dear Michal,

I didn't explicitly use the "mathml" option. I wanted to use LaTeX input to MathJax (because I've had problems with the MathML generated by TeX4ht before), so I originally used the mathjax option, but that included MathJax <script> elements in the generated HTML files, so you advised me not to use it. I assumed that make4ht would then use MathML because your document "The make4ht build system", Version v0.3g, says in section 7.6 that:
-----
mjcli detects whether to use MathML or LATEX input by use of the mathjax
option for make4ht. By default, it uses MathML. LATEX input can be required
using:
make4ht -f html5+mjcli filename.tex "mathjax"
-----

I used the command

make4ht -f html5+mjcli manual reduce,3,xhtml " -cunihtf -utf8" -cvalidate

At the end of the run, make4ht reported several errors that all have this form:
-----
[WARNING] domfilter: DOM parsing of manualse28.html failed:
[WARNING] domfilter: ...ive/2020/texmf-dist/tex/luatex/luaxml/luaxml-mod-xml.lua:175: Unbalanced Tag (/mstyle) [char=51491]

D:\Program Files\mjcli-main\node_modules\mathjax-full\js\core\HandlerList.js:58
        throw new Error("Can't find handler for document");
        ^

Error: Can't find handler for document
    at HandlerList.handlesDocument (D:\Program Files\mjcli-main\node_modules\mathjax-full\js\core\HandlerList.js:58:15)
    at HandlerList.document (D:\Program Files\mjcli-main\node_modules\mathjax-full\js\core\HandlerList.js:62:21)
    at Object.document (D:\Program Files\mjcli-main\node_modules\mathjax-full\js\mathjax.js:10:41)
    at Object.<anonymous> (D:\Program Files\mjcli-main\bin\mjcli.js:127:22)
    at Module._compile (internal/modules/cjs/loader.js:1063:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:72:12)
    at internal/main/run_main_module.js:17:47
-----
Each of the HTML files referenced in a similar message is empty and the other messages reference the tags /msup, /mrow, and /munderover, which all look to me like MathML tags.

On the non-empty output pages, some of the maths looks fine but some if it is rendered noticeably differently from the version rendered by MathJax running in a browser. The maths all looks slightly bigger, some brackets are too tall, and the calligraphic font looks very different. In fact, I'm wondering whether the browser is picking up the wrong font files. I haven't investigated further yet.

Francis

-----Original Message-----
From: Michal Hoftich <michal.h21 at gmail.com> 
Sent: Thursday, 1 April 2021 6:17 pm
To: Francis Wright <f.j.wright at live.co.uk>
Cc: tex4ht at tug.org
Subject: Re: [tex4ht] Problem using mjcli on Cygwin

What problems do happen? MathML shouldn't be used unless you explicitly use the "mathml" option. There are some notorious issues with sub and super scripts with the MathML option, TeX4ht needs to enclose the base and exponent in {} in order to work correctly, for example. I am sure there are many more problems.

Best regards,
Michal

>Thanks. Removing the mathjax option does indeed remove the two 
>redundant script elements relating to MathJax from the output HTML 
>files, although using MathML seems to cause other problems that I need 
>to investigate further.
>
>Best wishes, Francis
>


From michal.h21 at gmail.com  Fri Apr  2 21:03:19 2021
From: michal.h21 at gmail.com (Michal Hoftich)
Date: Fri, 2 Apr 2021 21:03:19 +0200
Subject: [tex4ht] Problem using mjcli on Cygwin
In-Reply-To: <AM6PR07MB45988E2AFADADBD8AE204EC8E57A9@AM6PR07MB4598.eurprd07.prod.outlook.com>
References: <AM6PR07MB4598208D8A39C87870A14952E57D9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <20210330190349.t3kgfhzvqm2nymtd@agraulos>
 <AM6PR07MB4598656F72F13AD893602382E57C9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <CAOCj1OdA+paS=xZkBNpuXyAKdCi_wkyGw8m3=0U4WfZGfk2Pvw@mail.gmail.com>
 <AM6PR07MB4598FC89474C5B4C2E1BEF16E57C9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <CAOCj1Od6vAuRQLcMD0Jno5vMdegg+k4X6CfD4mp9_5PKLdO7Jw@mail.gmail.com>
 <AM6PR07MB45984E8B9064D03E902BB421E57B9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <20210401171658.ubxysihh2av3ha7e@agraulos>
 <AM6PR07MB45988E2AFADADBD8AE204EC8E57A9@AM6PR07MB4598.eurprd07.prod.outlook.com>
Message-ID: <20210402190319.atlkq4lhyo56zpnt@agraulos>

Dear Francis,

ah I see. It seems that I was wrong, mjcli uses MathML by default. When 
you use the "mathjax" option, it uses the LaTeX math syntax for the 
command line MathJax, but it doesn't remove the MathJax <script> element 
from the HTML file. You can remove the MathJax <script> using following 
.mk4 build file:

--------------------------------------
local domfilter = require "make4ht-domfilter"

local process = domfilter {
   function(dom)
     for _, el in ipairs(dom:query_selector("#MathJax-script")) do
       el:remove_node()
     end
     return dom
   end
}

Make:match("html$", process)
------------------------------------

Then there is the issue with MathML. It seems that there is an issue 
with the LaTeX to MathML conversion in your case, so several things 
fail.

First, make4ht process MathML and fixes some common issues. It fails, as 
it reports the issue "Unbalanced Tag (/mstyle)". I suppose that the 
mjcli error is caused by the invalid MathML too.

Could you try to make a MWE that runs into this issue? As I said, there 
can be some issues that need to be fixed in the LaTeX source in the 
worst cases.

Best regards,
Michal


>I didn't explicitly use the "mathml" option. I wanted to use LaTeX 
>input to MathJax (because I've had problems with the MathML generated 
>by TeX4ht before), so I originally used the mathjax option, but that 
>included MathJax <script> elements in the generated HTML files, so you 
>advised me not to use it. I assumed that make4ht would then use MathML 
>because your document "The make4ht build system", Version v0.3g, says 
>in section 7.6 that:
>-----
>mjcli detects whether to use MathML or LATEX input by use of the mathjax
>option for make4ht. By default, it uses MathML. LATEX input can be required
>using:
>make4ht -f html5+mjcli filename.tex "mathjax"
>-----
>
>I used the command
>
>make4ht -f html5+mjcli manual reduce,3,xhtml " -cunihtf -utf8" -cvalidate
>
>At the end of the run, make4ht reported several errors that all have this form:
>-----
>[WARNING] domfilter: DOM parsing of manualse28.html failed:
>[WARNING] domfilter: ...ive/2020/texmf-dist/tex/luatex/luaxml/luaxml-mod-xml.lua:175: Unbalanced Tag (/mstyle) [char=51491]
>
>D:\Program Files\mjcli-main\node_modules\mathjax-full\js\core\HandlerList.js:58
>        throw new Error("Can't find handler for document");
>        ^
>
>Error: Can't find handler for document
>    at HandlerList.handlesDocument (D:\Program Files\mjcli-main\node_modules\mathjax-full\js\core\HandlerList.js:58:15)
>    at HandlerList.document (D:\Program Files\mjcli-main\node_modules\mathjax-full\js\core\HandlerList.js:62:21)
>    at Object.document (D:\Program Files\mjcli-main\node_modules\mathjax-full\js\mathjax.js:10:41)
>    at Object.<anonymous> (D:\Program Files\mjcli-main\bin\mjcli.js:127:22)
>    at Module._compile (internal/modules/cjs/loader.js:1063:30)
>    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
>    at Module.load (internal/modules/cjs/loader.js:928:32)
>    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
>    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:72:12)
>    at internal/main/run_main_module.js:17:47
>-----
>Each of the HTML files referenced in a similar message is empty and the other messages reference the tags /msup, /mrow, and /munderover, which all look to me like MathML tags.
>
>On the non-empty output pages, some of the maths looks fine but some if it is rendered noticeably differently from the version rendered by MathJax running in a browser. The maths all looks slightly bigger, some brackets are too tall, and the calligraphic font looks very different. In fact, I'm wondering whether the browser is picking up the wrong font files. I haven't investigated further yet.
>
>Francis
>

From f.j.wright at live.co.uk  Sat Apr  3 13:05:46 2021
From: f.j.wright at live.co.uk (Francis Wright)
Date: Sat, 3 Apr 2021 11:05:46 +0000
Subject: [tex4ht] Problem using mjcli on Cygwin
In-Reply-To: <20210402190319.atlkq4lhyo56zpnt@agraulos>
References: <AM6PR07MB4598208D8A39C87870A14952E57D9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <20210330190349.t3kgfhzvqm2nymtd@agraulos>
 <AM6PR07MB4598656F72F13AD893602382E57C9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <CAOCj1OdA+paS=xZkBNpuXyAKdCi_wkyGw8m3=0U4WfZGfk2Pvw@mail.gmail.com>
 <AM6PR07MB4598FC89474C5B4C2E1BEF16E57C9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <CAOCj1Od6vAuRQLcMD0Jno5vMdegg+k4X6CfD4mp9_5PKLdO7Jw@mail.gmail.com>
 <AM6PR07MB45984E8B9064D03E902BB421E57B9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <20210401171658.ubxysihh2av3ha7e@agraulos>
 <AM6PR07MB45988E2AFADADBD8AE204EC8E57A9@AM6PR07MB4598.eurprd07.prod.outlook.com>
 <20210402190319.atlkq4lhyo56zpnt@agraulos>
Message-ID: <AM6PR07MB45984C501D251118CBB4950EE5799@AM6PR07MB4598.eurprd07.prod.outlook.com>

Dear Michal,

Thanks for the code. I'll try to construct a MWE for the MathML issues but that may take a while.

Best wishes, Francis

-----Original Message-----
From: Michal Hoftich <michal.h21 at gmail.com> 
Sent: Friday, 2 April 2021 8:03 pm
To: Francis Wright <f.j.wright at live.co.uk>
Cc: tex4ht at tug.org
Subject: Re: [tex4ht] Problem using mjcli on Cygwin

Dear Francis,

ah I see. It seems that I was wrong, mjcli uses MathML by default. When you use the "mathjax" option, it uses the LaTeX math syntax for the command line MathJax, but it doesn't remove the MathJax <script> element from the HTML file. You can remove the MathJax <script> using following
.mk4 build file:

--------------------------------------
local domfilter = require "make4ht-domfilter"

local process = domfilter {
   function(dom)
     for _, el in ipairs(dom:query_selector("#MathJax-script")) do
       el:remove_node()
     end
     return dom
   end
}

Make:match("html$", process)
------------------------------------

Then there is the issue with MathML. It seems that there is an issue with the LaTeX to MathML conversion in your case, so several things fail.

First, make4ht process MathML and fixes some common issues. It fails, as it reports the issue "Unbalanced Tag (/mstyle)". I suppose that the mjcli error is caused by the invalid MathML too.

Could you try to make a MWE that runs into this issue? As I said, there can be some issues that need to be fixed in the LaTeX source in the worst cases.

Best regards,
Michal


>I didn't explicitly use the "mathml" option. I wanted to use LaTeX 
>input to MathJax (because I've had problems with the MathML generated 
>by TeX4ht before), so I originally used the mathjax option, but that 
>included MathJax <script> elements in the generated HTML files, so you 
>advised me not to use it. I assumed that make4ht would then use MathML 
>because your document "The make4ht build system", Version v0.3g, says 
>in section 7.6 that:
>-----
>mjcli detects whether to use MathML or LATEX input by use of the 
>mathjax option for make4ht. By default, it uses MathML. LATEX input can 
>be required
>using:
>make4ht -f html5+mjcli filename.tex "mathjax"
>-----
>
>I used the command
>
>make4ht -f html5+mjcli manual reduce,3,xhtml " -cunihtf -utf8" 
>-cvalidate
>
>At the end of the run, make4ht reported several errors that all have this form:
>-----
>[WARNING] domfilter: DOM parsing of manualse28.html failed:
>[WARNING] domfilter: 
>...ive/2020/texmf-dist/tex/luatex/luaxml/luaxml-mod-xml.lua:175: 
>Unbalanced Tag (/mstyle) [char=51491]
>
>D:\Program Files\mjcli-main\node_modules\mathjax-full\js\core\HandlerList.js:58
>        throw new Error("Can't find handler for document");
>        ^
>
>Error: Can't find handler for document
>    at HandlerList.handlesDocument (D:\Program Files\mjcli-main\node_modules\mathjax-full\js\core\HandlerList.js:58:15)
>    at HandlerList.document (D:\Program Files\mjcli-main\node_modules\mathjax-full\js\core\HandlerList.js:62:21)
>    at Object.document (D:\Program Files\mjcli-main\node_modules\mathjax-full\js\mathjax.js:10:41)
>    at Object.<anonymous> (D:\Program Files\mjcli-main\bin\mjcli.js:127:22)
>    at Module._compile (internal/modules/cjs/loader.js:1063:30)
>    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
>    at Module.load (internal/modules/cjs/loader.js:928:32)
>    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
>    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:72:12)
>    at internal/main/run_main_module.js:17:47
>-----
>Each of the HTML files referenced in a similar message is empty and the other messages reference the tags /msup, /mrow, and /munderover, which all look to me like MathML tags.
>
>On the non-empty output pages, some of the maths looks fine but some if it is rendered noticeably differently from the version rendered by MathJax running in a browser. The maths all looks slightly bigger, some brackets are too tall, and the calligraphic font looks very different. In fact, I'm wondering whether the browser is picking up the wrong font files. I haven't investigated further yet.
>
>Francis
>


From f.j.wright at live.co.uk  Sat Apr  3 19:12:40 2021
From: f.j.wright at live.co.uk (Francis Wright)
Date: Sat, 3 Apr 2021 17:12:40 +0000
Subject: [tex4ht] MathML errors using TeX4ht
Message-ID: <AM6PR07MB45982BAA3DAD1855AFBB81B3E5799@AM6PR07MB4598.eurprd07.prod.outlook.com>

Attached is a MWE illustrating the MathML generation errors that I detected originally when using make4ht with mjcli. They appear to fall into two classes: text in a different font with a super- or sub-script; use of {} with a super- or sub-script. Please see also the comments at the end of the attached file.

Francis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex4ht/attachments/20210403/bebef3ad/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MathML-bugs.tex
Type: application/x-tex
Size: 762 bytes
Desc: MathML-bugs.tex
URL: <https://tug.org/pipermail/tex4ht/attachments/20210403/bebef3ad/attachment.tex>

From michal.h21 at gmail.com  Sat Apr  3 21:18:11 2021
From: michal.h21 at gmail.com (Michal Hoftich)
Date: Sat, 3 Apr 2021 21:18:11 +0200
Subject: [tex4ht] MathML errors using TeX4ht
In-Reply-To: <AM6PR07MB45982BAA3DAD1855AFBB81B3E5799@AM6PR07MB4598.eurprd07.prod.outlook.com>
References: <AM6PR07MB45982BAA3DAD1855AFBB81B3E5799@AM6PR07MB4598.eurprd07.prod.outlook.com>
Message-ID: <20210403191811.hwtgeuwp43sqbeav@agraulos>

Dear Francis, 

these are the common issues that I mentioned in one of my previous 
e-mails. TeX4ht doesn't support \mathbf{xxx}^x. Valid input is 
{\mathbf{xxx}}^x. The {}_x issue is something different, this is really 
known bug that I don't know how to fix. 

Here are some other known issues: https://tug.org/tex4ht/doc/mml.html

Anyway, as these issues are really common and it isn't realistic to fix 
them in already existing documents, here is a workaround. We can use Lua 
script to preprocess the TeX file and fix these issues.

Here it is, filter.lua:

--------------
for line in io.lines() do
   -- fix primes
   line = line:gsub([[%'%^(.-)%_]], [[^{\prime %1}_]])
   -- fix \mathrm{hello}^2
   line = line:gsub([[(\[a-zA-Z]-)(%b{})([%^%_])]], [[{%1%2}%3]])
   -- fix x_\mathrm{hello}
   line = line:gsub([[([%_%^])(\[a-zA-Z]-)(%b{})]], "%1{%2%3}")
   -- fix 10^2
   line = line:gsub("([%d])([%_%^])", "{%1}%2")
   -- fix {}_x
   line = line:gsub("{}([%_%^])", "{\\HCode{}}%1")
   print(line)
end
-------------

It can be executed in this way:

$ texlua filter.lua < MathML-bugs.tex | make4ht -f html5+mjcli -j MathML-bugs -

It seems to work on your sample. I plan to include support for TeX file 
preprocessing in a future make4ht version. It should be easier to run 
such code then.

Best regards,
Michal

>Attached is a MWE illustrating the MathML generation errors that I 
>detected originally when using make4ht with mjcli. They appear to fall 
>into two classes: text in a different font with a super- or sub-script; 
>use of {} with a super- or sub-script. Please see also the comments at 
>the end of the attached file.
>
>Francis



From 1019191262 at qq.com  Sat Apr 10 09:02:14 2021
From: 1019191262 at qq.com (=?gb18030?B?ysC8zbP1tcTEp8r1?=)
Date: Sat, 10 Apr 2021 15:02:14 +0800
Subject: [tex4ht] =?gb18030?b?Q2Fuoa90IGZpbmQvb3BlbiBmaWxlIKGueHh4LmR2aaGv?=
 =?gb18030?b?IG9yIKGueHh4Lmxnoa8=?=
Message-ID: <tencent_B63FFF0379350314AE7FCF373BBFA0DC180A@qq.com>

hello, I got this error when i try to use tex4ebook to convert arxiv paper source to epub.
I found a solution in https://www.tug.org/tex4ht/doc/mn3.html, which sugget install htcmd.c. But I could not find htcmd, could you give me some advice? by the way my system is ubuntu14.
Morever, when i use tex4ebook to convert some sigle tex file, it worked. And it didn't produce dvi too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex4ht/attachments/20210410/70af4ac6/attachment.html>

From michal.h21 at gmail.com  Sat Apr 10 20:21:52 2021
From: michal.h21 at gmail.com (Michal Hoftich)
Date: Sat, 10 Apr 2021 20:21:52 +0200
Subject: [tex4ht]
 =?utf-8?b?Q2Fu4oCZdCBmaW5kL29wZW4gZmlsZSDigJh4eHguZHZp?=
 =?utf-8?b?4oCZIG9yIOKAmHh4eC5sZ+KAmQ==?=
In-Reply-To: <tencent_B63FFF0379350314AE7FCF373BBFA0DC180A@qq.com>
References: <tencent_B63FFF0379350314AE7FCF373BBFA0DC180A@qq.com>
Message-ID: <20210410182152.zk72jrwk565fzbeb@agraulos>

Hello,

>hello, I got this error when i try to use tex4ebook to convert arxiv 
>paper source to epub.
>I found a solution in https://www.tug.org/tex4ht/doc/mn3.html, which sugget install htcmd.c. But I could not find htcmd, could you give me some advice? by the way my system is ubuntu14.
>Morever, when i use tex4ebook to convert some sigle tex file, it worked. And it didn't produce dvi too.

Can you point me to the file that causes that error? And also exact 
command line options you used for tex4ebook? Do you use TeX Live shipped 
with Ubuntu? It seems like quite old version.

Best regards,
Michal


From 1019191262 at qq.com  Sun Apr 11 04:03:43 2021
From: 1019191262 at qq.com (=?gb18030?B?ysC8zbP1tcTEp8r1?=)
Date: Sun, 11 Apr 2021 10:03:43 +0800
Subject: [tex4ht]
 =?gb18030?b?Q2Fuoa90IGZpbmQvb3BlbiBmaWxlIKGueHh4LmR2aaGv?=
 =?gb18030?b?IG9yIKGueHh4Lmxnoa8=?=
In-Reply-To: <20210410182152.zk72jrwk565fzbeb@agraulos>
References: <tencent_B63FFF0379350314AE7FCF373BBFA0DC180A@qq.com>
 <20210410182152.zk72jrwk565fzbeb@agraulos>
Message-ID: <tencent_0317F21BBAE73FA0E966FCC2D36FBC669007@qq.com>

I used the source attached to the annex, or you can download it from https://arxiv.org/format/2104.03341.
the command I use is "./tex4ebook -f epub3 draft.tex". since i never used lua before, I don't know how to configure the location of tex4ebook(I tried adding package.path='/usr/local/lib/lua/5.2/?.lua;/home/amo/epub/tex4ebook/?.lua;' to tex4ebook, which didn't work), make4ht, and luaxml. So I just copy the source code of make4ht and luaxml to tex4ebook, and untar the arxiv source in tex4ebook. This is not elegant, but it's what I could finish for now. For texlive, mk4ht, htlatex I installed them by sudo apt-get.





------------------&nbsp;Original&nbsp;------------------
From:                                                                                                                        "Michal Hoftich"                                                                                    <michal.h21 at gmail.com&gt;;
Date:&nbsp;Sun, Apr 11, 2021 02:21 AM
To:&nbsp;"??????"<1019191262 at qq.com&gt;;
Cc:&nbsp;"tex4ht"<tex4ht at tug.org&gt;;
Subject:&nbsp;Re: [tex4ht] Can?t find/open file ?xxx.dvi? or ?xxx.lg?



Hello,

&gt;hello, I got this error when i try to use tex4ebook to convert arxiv 
&gt;paper source to epub.
&gt;I found a solution in https://www.tug.org/tex4ht/doc/mn3.html, which sugget install htcmd.c. But I could not find htcmd, could you give me some advice? by the way my system is ubuntu14.
&gt;Morever, when i use tex4ebook to convert some sigle tex file, it worked. And it didn't produce dvi too.

Can you point me to the file that causes that error? And also exact 
command line options you used for tex4ebook? Do you use TeX Live shipped 
with Ubuntu? It seems like quite old version.

Best regards,
Michal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex4ht/attachments/20210411/aa1ea0af/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: src.tar.gz
Type: application/octet-stream
Size: 1226583 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex4ht/attachments/20210411/aa1ea0af/attachment-0001.obj>

From michal.h21 at gmail.com  Sun Apr 11 16:34:34 2021
From: michal.h21 at gmail.com (Michal Hoftich)
Date: Sun, 11 Apr 2021 16:34:34 +0200
Subject: [tex4ht]
	=?utf-8?b?Q2Fu4oCZdCBmaW5kL29wZW4gZmlsZSDigJh4eHguZHZp?=
	=?utf-8?b?4oCZIG9yIOKAmHh4eC5sZ+KAmQ==?=
In-Reply-To: <tencent_0317F21BBAE73FA0E966FCC2D36FBC669007@qq.com>
References: <tencent_B63FFF0379350314AE7FCF373BBFA0DC180A@qq.com>
 <20210410182152.zk72jrwk565fzbeb@agraulos>
 <tencent_0317F21BBAE73FA0E966FCC2D36FBC669007@qq.com>
Message-ID: <CAOCj1OcOMP8EHOEjmjcmKTa01OeEQeU6KC8vmC7mGcknfJ=Sng@mail.gmail.com>

I've originally sent my reply only to OP, so here it is again. Sorry
for the noise.

Hi,

I get the same error as you with this TeX file, so the issue is not
caused by a wrong installation of teX4ebook or make4ht. I've found
that the fatal error is caused by this line at the beginning of the TeX
file:

\pdfoutput=1

As TeX4ht works in the DVI mode, this causes everything to fail. I don't
think that it has any meaning, so I would remove it. If it has some use,
you can disable it just for TeX4ht, using:

\ifdefined\HCode\else
\pdfoutput=1
\fi

With this change, I can compile the file. There are still problems
though. One seems to be caused by a wrong configuration for eqnarray,
the other is caused by \maketitle redefinition in the custom package.

Here is the mycfg.cfg file, it should fix these issues:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\Preamble{xhtml}
\ConfigureEnv{eqnarray}
     {\ifvmode\IgnorePar\fi\EndP\HCode{<div class="eqnarray">}}
     {\ifvmode\IgnorePar\fi\EndP\HCode{</div>}\par}{}{}

% fix clash with \maketitle
\Configure{maketitle}{\ifvmode\IgnorePar\fi\EndP\HCode{<div
class="maketitle">}}{}{}{}{}{}{}{}
% close <div> before \tableofcontents
\renewcommand\beforetochook{\ifvmode\IgnorePar\fi\EndP\HCode{</div>}}
% put \title in <h1> element
\renewcommand\afterProceedingsSpace{\ShowPar\par\HCode{<h1>}}%
\renewcommand\afterTitleSpace{\HCode{</h1>}}
% disable \hrule
\special{t4ht at _}
\begin{document}
\EndPreamble
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Compile the document using:

tex4ebook -c mycfg.cfg -f epub3+dvisvgm_hashes draft

I've used the `dvisvgm_hashes` extension. It requires the SVG output for
math and included PDF images. It is also faster, as it converts several
images at once.

Best regards,
Michal

On Sun, Apr 11, 2021 at 4:03 AM ?????? <1019191262 at qq.com> wrote:
>
> I used the source attached to the annex, or you can download it from https://arxiv.org/format/2104.03341.
> the command I use is "./tex4ebook -f epub3 draft.tex". since i never used lua before, I don't know how to configure the location of tex4ebook(I tried adding package.path='/usr/local/lib/lua/5.2/?.lua;/home/amo/epub/tex4ebook/?.lua;' to tex4ebook, which didn't work), make4ht, and luaxml. So I just copy the source code of make4ht and luaxml to tex4ebook, and untar the arxiv source in tex4ebook. This is not elegant, but it's what I could finish for now. For texlive, mk4ht, htlatex I installed them by sudo apt-get.
>
>


From 1019191262 at qq.com  Sun Apr 11 17:46:22 2021
From: 1019191262 at qq.com (=?utf-8?B?MTAxOTE5MTI2Mg==?=)
Date: Sun, 11 Apr 2021 23:46:22 +0800
Subject: [tex4ht]
 =?utf-8?b?Q2Fu4oCZdCBmaW5kL29wZW4gZmlsZSDigJh4eHguZHZp?=
 =?utf-8?b?4oCZIG9yIOKAmHh4eC5sZ+KAmQ==?=
Message-ID: <tencent_26AE31475433A7AD3C4D8EC1@qq.com>

it worked,but i got this warnning, and the pdf are not appeared as pictures but white space. any idea i can fix this? I might not have much time spenting on this idea, anyway thank you for your helpful reply.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex4ht/attachments/20210411/eee3174b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_2021-04-11-23-22-56-233_org.connectbot.png
Type: application/octet-stream
Size: 960770 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex4ht/attachments/20210411/eee3174b/attachment-0001.obj>

From michal.h21 at gmail.com  Sun Apr 11 19:53:52 2021
From: michal.h21 at gmail.com (Michal Hoftich)
Date: Sun, 11 Apr 2021 19:53:52 +0200
Subject: [tex4ht]
 =?utf-8?b?Q2Fu4oCZdCBmaW5kL29wZW4gZmlsZSDigJh4eHguZHZp?=
 =?utf-8?b?4oCZIG9yIOKAmHh4eC5sZ+KAmQ==?=
In-Reply-To: <tencent_26AE31475433A7AD3C4D8EC1@qq.com>
References: <tencent_26AE31475433A7AD3C4D8EC1@qq.com>
Message-ID: <20210411175352.oqtignvey7st2x3k@agraulos>

It seems like a wrong make4ht installation. It cannot load any 
extensions. You may try instead this:

tex4ebook -c mycfg.cfg draft "svg" 

It should still produce SVG images for PDF files, but the compilation 
will be slower.

The generated Epub file is quite large, here is a link:
https://www.transfernow.net/dl/20210411NhZs7evV

Best regards,
Michal

>it worked,but i got this warnning, and the pdf are not appeared as pictures but white space. any idea i can fix this? I might not have much time spenting on this idea, anyway thank you for your helpful reply.



From lorenzo.digregorio at gmail.com  Fri Apr 16 10:22:32 2021
From: lorenzo.digregorio at gmail.com (Lorenzo Di Gregorio)
Date: Fri, 16 Apr 2021 10:22:32 +0200
Subject: [tex4ht] Double headings in table of contents
Message-ID: <CALRKyGAFYRbBXqzmK8k84tCGXQjuNwdq-CpK3jU8u3KpD3kNXQ@mail.gmail.com>

Hello,

I see many (not all) entries of my TOC in HTML as duplicated.  The elements
are:

<span class="subsectionToc">1.1.1 <a href="#x1-260001"
id="QQ2-1-65">Undisclosed text</a></span>

<span class="subsectionToc"><a href="#Q1-1-66">1.1.1
Undisclosed text</a></span>

of course I don't see this in pdfLaTeX.

I'm working on a rather complex setting including some confidential
content, so I can't produce a MVE, but perhaps the id names mean something
to you and you can spot a known pathology and post some hints at how to
troubleshoot and fix the issue?

Best Regards,
Lorenzo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex4ht/attachments/20210416/821b0ca7/attachment.html>

From michal.h21 at gmail.com  Fri Apr 16 11:29:37 2021
From: michal.h21 at gmail.com (Michal Hoftich)
Date: Fri, 16 Apr 2021 11:29:37 +0200
Subject: [tex4ht] Double headings in table of contents
In-Reply-To: <CALRKyGAFYRbBXqzmK8k84tCGXQjuNwdq-CpK3jU8u3KpD3kNXQ@mail.gmail.com>
References: <CALRKyGAFYRbBXqzmK8k84tCGXQjuNwdq-CpK3jU8u3KpD3kNXQ@mail.gmail.com>
Message-ID: <20210416092937.nsgztizlkpr76p4o@agraulos>

Hello Lorenzo,

>
>I see many (not all) entries of my TOC in HTML as duplicated.  The elements
>are:
>
><span class="subsectionToc">1.1.1 <a href="#x1-260001"
>id="QQ2-1-65">Undisclosed text</a></span>
>
><span class="subsectionToc"><a href="#Q1-1-66">1.1.1
>Undisclosed text</a></span>
>
>of course I don't see this in pdfLaTeX.
>
>I'm working on a rather complex setting including some confidential
>content, so I can't produce a MVE, but perhaps the id names mean something
>to you and you can spot a known pathology and post some hints at how to
>troubleshoot and fix the issue?
>
this is not expected, it will be probably caused by some package you 
use. I think that you can construct a MWE by using your document 
preamble and few dummy sections. We cannot tell much more without that.

Best regards,
Michal

From puszcza-hackers at gnu.org.ua  Thu Apr 22 22:36:56 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Thu, 22 Apr 2021 22:36:56 +0200
Subject: [tex4ht] [bug #505] Provide way to produce odt file without dynamic
	contents
In-Reply-To: <20210408-105807.sv7444.64160@puszcza.gnu.org.ua>
References: <20210408-105807.sv7444.64160@puszcza.gnu.org.ua>
Message-ID: <20210422-233656.sv189.71704@puszcza.gnu.org.ua>

Follow-up Comment #1, bug #505 (project tex4ht):

Hi J?rgen,

sorry for the late reply. I didn't notice this message earlier. There were
some issues with mail notifications from the bug tracker.

I think that this should be possible using Lua post-processing. It would be
much harder on the TeX level. I will try to come with something, probably in
the form of make4ht extension.

Best regards,
Michal



    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?505>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Thu Apr 22 23:54:14 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Thu, 22 Apr 2021 23:54:14 +0200
Subject: [tex4ht] [bug #505] Provide way to produce odt file without dynamic
	contents
In-Reply-To: <20210422-233656.sv189.71704@puszcza.gnu.org.ua>
References: <20210408-105807.sv7444.64160@puszcza.gnu.org.ua>
 <20210422-233656.sv189.71704@puszcza.gnu.org.ua>
Message-ID: <20210423-005414.sv189.21576@puszcza.gnu.org.ua>

Follow-up Comment #2, bug #505 (project tex4ht):

I don't know if it is enough, but the attached make4ht build file removes
links. TeX sample is attached as well. I don't know if the removing of links
is enough. 

Compile as 

make4ht -e build.lua -f odt sample.tex

(file #404, file #405)
    _______________________________________________________

Additional Item Attachment:

File name: build.lua                      Size:0 KB
File name: sample.tex                     Size:0 KB


    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?505>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Fri Apr 23 07:10:18 2021
From: puszcza-hackers at gnu.org.ua (=?UTF-8?B?SsO8cmdlbg==?= =?UTF-8?B?U3BpdHptw7xsbGVy?=)
Date: Fri, 23 Apr 2021 07:10:18 +0200
Subject: [tex4ht] [bug #505] Provide way to produce odt file without dynamic
	contents
In-Reply-To: <20210423-005414.sv189.21576@puszcza.gnu.org.ua>
References: <20210408-105807.sv7444.64160@puszcza.gnu.org.ua>
 <20210422-233656.sv189.71704@puszcza.gnu.org.ua>
 <20210423-005414.sv189.21576@puszcza.gnu.org.ua>
Message-ID: <20210423-081018.sv7444.26761@puszcza.gnu.org.ua>

Follow-up Comment #3, bug #505 (project tex4ht):

Thanks, this does remove the links, though it does not turn the bibliography
and the toc from fields to static text.

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?505>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Fri Apr 23 10:26:27 2021
From: puszcza-hackers at gnu.org.ua (=?UTF-8?B?SsO8cmdlbg==?= =?UTF-8?B?U3BpdHptw7xsbGVy?=)
Date: Fri, 23 Apr 2021 10:26:27 +0200
Subject: [tex4ht] [bug #507] Two KOMA issues
Message-ID: <20210423-112627.sv7444.84238@puszcza.gnu.org.ua>

URL:
  <http://puszcza.gnu.org.ua/bugs/?507>

                 Summary: Two KOMA issues
                 Project: tex4ht
            Submitted by: jspitzm
            Submitted on: Fri Apr 23 11:26:27 2021
                Category: None
                Priority: 5 - Normal
                Severity: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Hi again

I found two issues when compiling a scrartcl document to ODT:

1. The subtitle is not output
2. the abstract is output as Standard paragraph rather than "abstract"

The latter is probably due to KOMA not having an abstract heading by default.
When using the class option abstract=true (which switches on the heading) the
abstract is output correctly.

MWE with ODT output attached.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Fri Apr 23 11:26:27 2021  Name: scrartcl-test.tex  Size: 253B   By:
jspitzm
MWE
<http://puszcza.gnu.org.ua/bugs/download.php?file_id=406>
-------------------------------------------------------
Date: Fri Apr 23 11:26:27 2021  Name: scrartcl-test.odt  Size: 7kB   By:
jspitzm
MWE
<http://puszcza.gnu.org.ua/bugs/download.php?file_id=407>

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?507>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Tue Apr 27 11:11:34 2021
From: puszcza-hackers at gnu.org.ua (Ulrich =?UTF-8?B?TcO8bGxlcg==?=)
Date: Tue, 27 Apr 2021 11:11:34 +0200
Subject: [tex4ht] [bug #508] Error after loading hyperref from a class file
Message-ID: <20210427-121134.sv340.62041@puszcza.gnu.org.ua>

URL:
  <http://puszcza.gnu.org.ua/bugs/?508>

                 Summary: Error after loading hyperref from a class file
                 Project: tex4ht
            Submitted by: ulm
            Submitted on: Tue Apr 27 12:11:34 2021
                Category: None
                Priority: 5 - Normal
                Severity: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

When loading the hyperref package from a class file, I get the following error
when the first \label is encountered:

! Argument of \strip at prefix has an extra }.
<inserted text> 
                \par 
l.3 \label{foo}

To reproduce, run "mk4ht xhlatex bug" with the attached bug.tex and
bugclass.cls. The full log file is attached too.

I see this problem with TeX Live 2021 but not with 2020.

As a workaround, I postpone loading of hyperref:
\g at addto@macro\@documentclasshook{\RequirePackage{hyperref}}
So looks like load order matters.




    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Tue Apr 27 12:11:34 2021  Name: bug.tex  Size: 74B   By: ulm

<http://puszcza.gnu.org.ua/bugs/download.php?file_id=408>
-------------------------------------------------------
Date: Tue Apr 27 12:11:34 2021  Name: bugclass.cls  Size: 96B   By: ulm

<http://puszcza.gnu.org.ua/bugs/download.php?file_id=409>
-------------------------------------------------------
Date: Tue Apr 27 12:11:34 2021  Name: bug.log  Size: 20kB   By: ulm

<http://puszcza.gnu.org.ua/bugs/download.php?file_id=410>

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?508>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Tue Apr 27 15:02:02 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Tue, 27 Apr 2021 15:02:02 +0200
Subject: [tex4ht] [bug #508] Error after loading hyperref from a class file
In-Reply-To: <20210427-121134.sv340.62041@puszcza.gnu.org.ua>
References: <20210427-121134.sv340.62041@puszcza.gnu.org.ua>
Message-ID: <20210427-160202.sv189.3902@puszcza.gnu.org.ua>

Follow-up Comment #1, bug #508 (project tex4ht):

This is caused by the fact that TeX4ht is not active in the class file, and it
doesn't include hyperref-hooks.4ht file. It seems that it works when I move
code from hyperref-hooks.4ht to hyperref.4ht, so I will update the sources and
it should fix the issue. 

In the meantime, you can try the following bugclass.4ht file:

\@ifpackageloaded{nameref}{}
{%
   \let\sv:label\label
   \RequirePackage{nameref}%
   \let\label\sv:label
}
\endinput

This is the code from hyperref-hooks.4ht

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?508>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Tue Apr 27 22:27:51 2021
From: puszcza-hackers at gnu.org.ua (Julianus Pfeuffer)
Date: Tue, 27 Apr 2021 22:27:51 +0200
Subject: [tex4ht] [bug #509] Incompatibilities with Tikz generated by
	menukeys package
Message-ID: <20210427-232751.sv7888.19658@puszcza.gnu.org.ua>

URL:
  <http://puszcza.gnu.org.ua/bugs/?509>

                 Summary: Incompatibilities with Tikz generated by menukeys
package
                 Project: tex4ht
            Submitted by: julepf
            Submitted on: Tue Apr 27 23:27:51 2021
                Category: None
                Priority: 5 - Normal
                Severity: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Hi!

I am trying to convert a document where I am using the menukeys package to
HTML. It seems to use Tikz internally to draw the menu/key "buttons".
make4ht creates an svg for every usage of such a button but they seem to be
broken. For some of them, I get red lines, indicating a parse error. For
others, I get the box without the text, since there seem to be additional <g>
elements in the <text>.

I tried both drivers from your git repo already
%\def\pgfsysdriver{pgfsys-tex4ht-updated.def}
\def\pgfsysdriver{pgfsys-dvisvgm4ht.def}

The second, pgfsys-dvisvgm4ht.def only creates the text and no boxes but seems
to have no errors as far as I could see.

Not sure if this is an error that can be addressed in this package or its
helpers but this is the first package in the hierarchy I guess.

An example can be as minimal as:

\documentclass[a4paper,12pt]{article}
\usepackage{menukeys}
\begin{document}
Hello world.
\menu{FOOO}
\end{document}

which compiles fine with e.g. pdflatex.
I am using TL2021.

Thanks in advance for any help!
J




    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?509>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Tue Apr 27 23:04:38 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Tue, 27 Apr 2021 23:04:38 +0200
Subject: [tex4ht] [bug #509] Incompatibilities with Tikz generated by
	menukeys package
In-Reply-To: <20210427-232751.sv7888.19658@puszcza.gnu.org.ua>
References: <20210427-232751.sv7888.19658@puszcza.gnu.org.ua>
Message-ID: <20210428-000437.sv189.90669@puszcza.gnu.org.ua>

Follow-up Comment #1, bug #509 (project tex4ht):

Hi, 

I don't have TL 2021 yet, but I think that TeX4ht should now load
pgfsys-dvisvgm4ht.def by default, unless you specify \def\pgfsysdriver
earlier. There were several versions of pgfsys-dvisvgm4ht.def in TeX Live, so
it is possible that a wrong version is loaded on your system. What does the
following command say?

kpsewhich pgfsys-dvisvgm4ht.def

You can try to download the most recent version from Github and to place it to
the directory with your file. It should ensure that the correct version is
used. 

Anyway, I've tried to compile your MWE and it seems to compile correctly with
the recent driver.

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?509>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Tue Apr 27 23:19:06 2021
From: puszcza-hackers at gnu.org.ua (Julianus Pfeuffer)
Date: Tue, 27 Apr 2021 23:19:06 +0200
Subject: [tex4ht] [bug #509] Incompatibilities with Tikz generated by
	menukeys package
In-Reply-To: <20210428-000437.sv189.90669@puszcza.gnu.org.ua>
References: <20210427-232751.sv7888.19658@puszcza.gnu.org.ua>
 <20210428-000437.sv189.90669@puszcza.gnu.org.ua>
Message-ID: <20210428-001906.sv7888.77784@puszcza.gnu.org.ua>

Follow-up Comment #2, bug #509 (project tex4ht):

Hi, and thanks for the quick reply.

When I remove the local copy from your github, kpsewhich says:
/usr/local/texlive/2021/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-dvisvgm4ht.def

When I look inside, the contents differ from your github.
If I run the document without this local copy but still with
\def\pgfsysdriver{pgfsys-dvisvgm4ht.def} I get:

[ERROR]   htlatex: Compilation errors in the htlatex run
[ERROR]   htlatex: Filename	Line	Message
[ERROR]   htlatex:
/usr/local/texlive/2021/texmf-dist/tex/generic/pgf/libraries/pgflibraryfadings	31	
Undefined control sequence.
...
[ERROR]   htlatex:
/usr/local/texlive/2021/texmf-dist/tex/generic/pgf/libraries/pgflibraryfadings	57	
Undefined control sequence.
--- warning --- Ignoring \special{t4ht.html}
...

With the driver from github it succeeds but does not display the gray
"background boxes" for the button correctly. Do you see this box in your
result? You can e.g. compare it to the PDF version.

Thanks again!

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?509>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Tue Apr 27 23:22:57 2021
From: puszcza-hackers at gnu.org.ua (Julianus Pfeuffer)
Date: Tue, 27 Apr 2021 23:22:57 +0200
Subject: [tex4ht] [bug #509] Incompatibilities with Tikz generated by
	menukeys package
In-Reply-To: <20210428-001906.sv7888.77784@puszcza.gnu.org.ua>
References: <20210427-232751.sv7888.19658@puszcza.gnu.org.ua>
 <20210428-000437.sv189.90669@puszcza.gnu.org.ua>
 <20210428-001906.sv7888.77784@puszcza.gnu.org.ua>
Message-ID: <20210428-002257.sv7888.98735@puszcza.gnu.org.ua>

Follow-up Comment #3, bug #509 (project tex4ht):

I just noted something else that I kind of ignored as a warning before! I am
getting the following with the newest driver:

    processing of PostScript specials is disabled (Ghostscript not 
    found)
    pre-processing DVI file (format version 2)
    processing page 2
      WARNING: 50 PostScript specials ignored. The resulting SVG 
    might look wrong.

Do you think a PostScript-enabled version of dvisvg is necessary?

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?509>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Tue Apr 27 23:57:55 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Tue, 27 Apr 2021 23:57:55 +0200
Subject: [tex4ht] [bug #509] Incompatibilities with Tikz generated by
	menukeys package
In-Reply-To: <20210428-002257.sv7888.98735@puszcza.gnu.org.ua>
References: <20210427-232751.sv7888.19658@puszcza.gnu.org.ua>
 <20210428-000437.sv189.90669@puszcza.gnu.org.ua>
 <20210428-001906.sv7888.77784@puszcza.gnu.org.ua>
 <20210428-002257.sv7888.98735@puszcza.gnu.org.ua>
Message-ID: <20210428-005755.sv189.95827@puszcza.gnu.org.ua>

Follow-up Comment #4, bug #509 (project tex4ht):

I think that I get gray boxes in both PDF and HTML. But as you get the
Ghostscript errors, this may be some issue with yout TeX distribution, because
it should include Ghostscript. 

You can try the tikz+ option, which uses native Dvisvgm commands instead of
Dvips commands that are used by default. I think this option has some other
issues, which is the result why it isn't used by default, but it may work in
your case. Try:

make4ht -m draft filename.tex "tikz+"



    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?509>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Wed Apr 28 00:11:15 2021
From: puszcza-hackers at gnu.org.ua (Karl Berry)
Date: Wed, 28 Apr 2021 00:11:15 +0200
Subject: [tex4ht] [bug #509] Incompatibilities with Tikz generated by
	menukeys package
In-Reply-To: <20210428-005755.sv189.95827@puszcza.gnu.org.ua>
References: <20210427-232751.sv7888.19658@puszcza.gnu.org.ua>
 <20210428-000437.sv189.90669@puszcza.gnu.org.ua>
 <20210428-001906.sv7888.77784@puszcza.gnu.org.ua>
 <20210428-002257.sv7888.98735@puszcza.gnu.org.ua>
 <20210428-005755.sv189.95827@puszcza.gnu.org.ua>
Message-ID: <20210428-011115.sv118.45755@puszcza.gnu.org.ua>

Follow-up Comment #5, bug #509 (project tex4ht):

By accident, there were two versions of pgfsys-dvisvgm4ht.def in the original
release of TL21, one in pgf and one in webquiz. The one in webquiz has
Michal's changes (I don't know where it came from originally). And the one in
webquiz is the one I was advised to remove by Ulrike Fischer, so I did (a few
days ago).

I don't know why this can't get fixed for real. It's been a problem for quite
a while, it seems to me.

Michal, maybe you could submit an issue at
https://github.com/pgf-tikz/pgf/issues (if not already done) to do what needs
to be done. Thanks.



    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?509>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Wed Apr 28 00:20:14 2021
From: puszcza-hackers at gnu.org.ua (Julianus Pfeuffer)
Date: Wed, 28 Apr 2021 00:20:14 +0200
Subject: [tex4ht] [bug #509] Incompatibilities with Tikz generated by
	menukeys package
In-Reply-To: <20210428-011115.sv118.45755@puszcza.gnu.org.ua>
References: <20210427-232751.sv7888.19658@puszcza.gnu.org.ua>
 <20210428-000437.sv189.90669@puszcza.gnu.org.ua>
 <20210428-001906.sv7888.77784@puszcza.gnu.org.ua>
 <20210428-002257.sv7888.98735@puszcza.gnu.org.ua>
 <20210428-005755.sv189.95827@puszcza.gnu.org.ua>
 <20210428-011115.sv118.45755@puszcza.gnu.org.ua>
Message-ID: <20210428-012014.sv7888.31044@puszcza.gnu.org.ua>

Follow-up Comment #6, bug #509 (project tex4ht):

Yes! linking to Ghostscript finally shows the boxes, too.

I am on macOS. During installation of MacTex you need to click on "Customize",
include the Ghostscipt Dynamic Libraries, and afterward set the LIBGS variable
for it to be picked up.

Thanks for your help. I think then just the issue of the driver in pgf
remains.

I can see that it is on the develop branch since 16 days but I think there was
no release yet that includes it (but I might be mistaken).

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?509>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Wed Apr 28 10:14:39 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Wed, 28 Apr 2021 10:14:39 +0200
Subject: [tex4ht] [bug #509] Incompatibilities with Tikz generated by
	menukeys package
In-Reply-To: <20210428-012014.sv7888.31044@puszcza.gnu.org.ua>
References: <20210427-232751.sv7888.19658@puszcza.gnu.org.ua>
 <20210428-000437.sv189.90669@puszcza.gnu.org.ua>
 <20210428-001906.sv7888.77784@puszcza.gnu.org.ua>
 <20210428-002257.sv7888.98735@puszcza.gnu.org.ua>
 <20210428-005755.sv189.95827@puszcza.gnu.org.ua>
 <20210428-011115.sv118.45755@puszcza.gnu.org.ua>
 <20210428-012014.sv7888.31044@puszcza.gnu.org.ua>
Message-ID: <20210428-111438.sv189.2841@puszcza.gnu.org.ua>

Follow-up Comment #7, bug #509 (project tex4ht):

Karl, I updated the driver on Github a few weeks ago, and also posted it to
the TikZ repo. So it should be installed in TL in the next TikZ update. I
think they don't post updates too often, unfortunately. But the driver
included in TikZ isn't that bad, it just doesn't enable the tikz+ option, so
it always use Dvips specials.

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?509>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Wed Apr 28 12:49:50 2021
From: puszcza-hackers at gnu.org.ua (Ulrich =?UTF-8?B?TcO8bGxlcg==?=)
Date: Wed, 28 Apr 2021 12:49:50 +0200
Subject: [tex4ht] [bug #510] Error with hyperref and \include
Message-ID: <20210428-134950.sv340.74202@puszcza.gnu.org.ua>

URL:
  <http://puszcza.gnu.org.ua/bugs/?510>

                 Summary: Error with hyperref and \include
                 Project: tex4ht
            Submitted by: ulm
            Submitted on: Wed Apr 28 13:49:49 2021
                Category: None
                Priority: 5 - Normal
                Severity: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

As in bug #508, I load hyperref from a class file. Additionally, the main file
uses \include to include a separate file.

This results in the following error:

! Extra \else.
\@include ...ediate \closeout \@partaux \fi \else 
                                                  \deadcycles \z@ \@nameuse
...
l.3 \include{buginclude}

To reproduce, run "mk4ht xhlatex bug" with the attached bug.tex, bugclass.cls,
and buginclude.tex. The full log file is attached too.

I am using r59007 from the texlive repository:
https://www.tug.org/svn/texlive?view=revision&revision=59007




    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Wed Apr 28 13:49:50 2021  Name: bugclass.cls  Size: 96B   By: ulm

<http://puszcza.gnu.org.ua/bugs/download.php?file_id=413>
-------------------------------------------------------
Date: Wed Apr 28 13:49:50 2021  Name: bug.log  Size: 20kB   By: ulm

<http://puszcza.gnu.org.ua/bugs/download.php?file_id=414>
-------------------------------------------------------
Date: Wed Apr 28 13:49:49 2021  Name: bug.tex  Size: 78B   By: ulm

<http://puszcza.gnu.org.ua/bugs/download.php?file_id=411>
-------------------------------------------------------
Date: Wed Apr 28 13:49:49 2021  Name: buginclude.tex  Size: 22B   By: ulm

<http://puszcza.gnu.org.ua/bugs/download.php?file_id=412>

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?510>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Wed Apr 28 12:51:30 2021
From: puszcza-hackers at gnu.org.ua (Ulrich =?UTF-8?B?TcO8bGxlcg==?=)
Date: Wed, 28 Apr 2021 12:51:30 +0200
Subject: [tex4ht] [bug #508] Error after loading hyperref from a class file
In-Reply-To: <20210427-160202.sv189.3902@puszcza.gnu.org.ua>
References: <20210427-121134.sv340.62041@puszcza.gnu.org.ua>
 <20210427-160202.sv189.3902@puszcza.gnu.org.ua>
Message-ID: <20210428-135130.sv340.18126@puszcza.gnu.org.ua>

Follow-up Comment #2, bug #508 (project tex4ht):

Thank you, this has fixed the original bug.

Unfortunately, a new issue with hyperref has surfaced. I've filed bug #510 for
it.


    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?508>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Wed Apr 28 13:37:39 2021
From: puszcza-hackers at gnu.org.ua (Ulrich =?UTF-8?B?TcO8bGxlcg==?=)
Date: Wed, 28 Apr 2021 13:37:39 +0200
Subject: [tex4ht] [bug #510] Error with hyperref and \include
In-Reply-To: <20210428-134950.sv340.74202@puszcza.gnu.org.ua>
References: <20210428-134950.sv340.74202@puszcza.gnu.org.ua>
Message-ID: <20210428-143739.sv340.32871@puszcza.gnu.org.ua>

Additional Item Attachment, bug #510 (project tex4ht):

File name: buginclude.aux                 Size:0 KB


    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?510>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Wed Apr 28 14:13:15 2021
From: puszcza-hackers at gnu.org.ua (Julianus Pfeuffer)
Date: Wed, 28 Apr 2021 14:13:15 +0200
Subject: [tex4ht] [bug #509] Incompatibilities with Tikz generated by
	menukeys package
In-Reply-To: <20210428-111438.sv189.2841@puszcza.gnu.org.ua>
References: <20210427-232751.sv7888.19658@puszcza.gnu.org.ua>
 <20210428-000437.sv189.90669@puszcza.gnu.org.ua>
 <20210428-001906.sv7888.77784@puszcza.gnu.org.ua>
 <20210428-002257.sv7888.98735@puszcza.gnu.org.ua>
 <20210428-005755.sv189.95827@puszcza.gnu.org.ua>
 <20210428-011115.sv118.45755@puszcza.gnu.org.ua>
 <20210428-012014.sv7888.31044@puszcza.gnu.org.ua>
 <20210428-111438.sv189.2841@puszcza.gnu.org.ua>
Message-ID: <20210428-151315.sv7888.94504@puszcza.gnu.org.ua>

Follow-up Comment #8, bug #509 (project tex4ht):

Hi again,

my enthusiasm was a bit too early. While the menu commands from the package
work, the directory command (which paints a little directory icon in front of
a path) fails with:


--- warning --- Improper groups in \special{t4ht+}... idv[2]
pre-processing DVI file (format version 2)
processing page 2
  DVI error: stack not empty at end of page


The MWE is:

\documentclass[a4paper,12pt]{article}
\def\pgfsysdriver{pgfsys-dvisvgm4ht.def} % to use the local copy
\usepackage{menukeys}
\renewmenumacro{\directory}{pathswithfolder}
\begin{document}
Hello world.
\directory{C, Users} % fails
\menu{File > Open} % works
\end{document}


I wonder if you can reproduce that.

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?509>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Wed Apr 28 16:07:10 2021
From: puszcza-hackers at gnu.org.ua (Julianus Pfeuffer)
Date: Wed, 28 Apr 2021 16:07:10 +0200
Subject: [tex4ht] [bug #509] Incompatibilities with Tikz generated by
	menukeys package
In-Reply-To: <20210428-151315.sv7888.94504@puszcza.gnu.org.ua>
References: <20210427-232751.sv7888.19658@puszcza.gnu.org.ua>
 <20210428-000437.sv189.90669@puszcza.gnu.org.ua>
 <20210428-001906.sv7888.77784@puszcza.gnu.org.ua>
 <20210428-002257.sv7888.98735@puszcza.gnu.org.ua>
 <20210428-005755.sv189.95827@puszcza.gnu.org.ua>
 <20210428-011115.sv118.45755@puszcza.gnu.org.ua>
 <20210428-012014.sv7888.31044@puszcza.gnu.org.ua>
 <20210428-111438.sv189.2841@puszcza.gnu.org.ua>
 <20210428-151315.sv7888.94504@puszcza.gnu.org.ua>
Message-ID: <20210428-170709.sv7888.20764@puszcza.gnu.org.ua>

Follow-up Comment #9, bug #509 (project tex4ht):

Also keys that include mathsymbols seem to have a superfluous "/>" HTML end
tag if you try this:

\documentclass[a4paper,12pt]{article}
\def\pgfsysdriver{pgfsys-dvisvgm4ht.def}
\usepackage{menukeys}
\renewmenumacro{\directory}{pathswithfolder}
\begin{document}
Hello world.
Go to \directory{C, Users} \\
Select \menu{File > Open} \\
Press \keys{\shift + K} \\
\end{document}

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?509>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Tue May  4 14:52:49 2021
From: puszcza-hackers at gnu.org.ua (Julianus Pfeuffer)
Date: Tue, 4 May 2021 14:52:49 +0200
Subject: [tex4ht] [bug #509] Incompatibilities with Tikz generated by
	menukeys package
In-Reply-To: <20210428-170709.sv7888.20764@puszcza.gnu.org.ua>
References: <20210427-232751.sv7888.19658@puszcza.gnu.org.ua>
 <20210428-000437.sv189.90669@puszcza.gnu.org.ua>
 <20210428-001906.sv7888.77784@puszcza.gnu.org.ua>
 <20210428-002257.sv7888.98735@puszcza.gnu.org.ua>
 <20210428-005755.sv189.95827@puszcza.gnu.org.ua>
 <20210428-011115.sv118.45755@puszcza.gnu.org.ua>
 <20210428-012014.sv7888.31044@puszcza.gnu.org.ua>
 <20210428-111438.sv189.2841@puszcza.gnu.org.ua>
 <20210428-151315.sv7888.94504@puszcza.gnu.org.ua>
 <20210428-170709.sv7888.20764@puszcza.gnu.org.ua>
Message-ID: <20210504-155249.sv7888.28576@puszcza.gnu.org.ua>

Follow-up Comment #10, bug #509 (project tex4ht):

Hi!

Any updates on this or an idea how to debug/ give you further info?

I tried opening the produced *.idv in a viewer but it crashes already, so it
seems like the produced dvi is indeed corrupt somehow.

Unfortunately, I have no idea where it starts to go wrong
(tikz/pgf?,menukeys?,tex4ht?,dvisvgm?).

The tikzpictures drawn by the menukeys package are actually very very simple
and work on their own. They are concatenated with text or other tikzpictures
by simple hspaces.

Maybe tex4ht can not handle tikzpictures produced by commands correctly? Do I
maybe need some custom \Configure to convert everything inside a \menu or \key
command together?

Thanks a lot in advance!

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?509>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Tue May  4 15:53:12 2021
From: puszcza-hackers at gnu.org.ua (Jon Hood)
Date: Tue, 4 May 2021 15:53:12 +0200
Subject: [tex4ht] [bug #511] awesomebox support (fontawesome issues)
Message-ID: <20210504-165312.sv7891.14297@puszcza.gnu.org.ua>

URL:
  <http://puszcza.gnu.org.ua/bugs/?511>

                 Summary: awesomebox support (fontawesome issues)
                 Project: tex4ht
            Submitted by: squinky86
            Submitted on: Tue May  4 16:53:12 2021
                Category: None
                Priority: 5 - Normal
                Severity: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Originally, I thought this was on my end, but it is reproducible on all
systems I've tried: https://tex.stackexchange.com/questions/595503

When building the .dvi file for the above example, tex4ht results in a "sh:
.tfm: command not found" error, seeming to not understand that
[FontAwesome5Free-Solid-900.otf]:script=latn; should be interpreted as an OTF
file.




    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?511>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Tue May  4 16:02:18 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Tue, 4 May 2021 16:02:18 +0200
Subject: [tex4ht] [bug #509] Incompatibilities with Tikz generated by
	menukeys package
In-Reply-To: <20210504-155249.sv7888.28576@puszcza.gnu.org.ua>
References: <20210427-232751.sv7888.19658@puszcza.gnu.org.ua>
 <20210428-000437.sv189.90669@puszcza.gnu.org.ua>
 <20210428-001906.sv7888.77784@puszcza.gnu.org.ua>
 <20210428-002257.sv7888.98735@puszcza.gnu.org.ua>
 <20210428-005755.sv189.95827@puszcza.gnu.org.ua>
 <20210428-011115.sv118.45755@puszcza.gnu.org.ua>
 <20210428-012014.sv7888.31044@puszcza.gnu.org.ua>
 <20210428-111438.sv189.2841@puszcza.gnu.org.ua>
 <20210428-151315.sv7888.94504@puszcza.gnu.org.ua>
 <20210428-170709.sv7888.20764@puszcza.gnu.org.ua>
 <20210504-155249.sv7888.28576@puszcza.gnu.org.ua>
Message-ID: <20210504-170218.sv189.65569@puszcza.gnu.org.ua>

Follow-up Comment #11, bug #509 (project tex4ht):

Hi,

I took a fresh look at this issue and found a solution. We just need to insert
code that makes pictures into each menukeys style. In this way, we will
support not only TikZ pictures, but also text.

Try the attached menukeys.4ht file.


(file #416)
    _______________________________________________________

Additional Item Attachment:

File name: menukeys.4ht                   Size:1 KB


    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?509>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Wed May  5 12:24:48 2021
From: puszcza-hackers at gnu.org.ua (Julianus Pfeuffer)
Date: Wed, 5 May 2021 12:24:48 +0200
Subject: [tex4ht] [bug #509] Incompatibilities with Tikz generated by
	menukeys package
In-Reply-To: <20210504-170218.sv189.65569@puszcza.gnu.org.ua>
References: <20210427-232751.sv7888.19658@puszcza.gnu.org.ua>
 <20210428-000437.sv189.90669@puszcza.gnu.org.ua>
 <20210428-001906.sv7888.77784@puszcza.gnu.org.ua>
 <20210428-002257.sv7888.98735@puszcza.gnu.org.ua>
 <20210428-005755.sv189.95827@puszcza.gnu.org.ua>
 <20210428-011115.sv118.45755@puszcza.gnu.org.ua>
 <20210428-012014.sv7888.31044@puszcza.gnu.org.ua>
 <20210428-111438.sv189.2841@puszcza.gnu.org.ua>
 <20210428-151315.sv7888.94504@puszcza.gnu.org.ua>
 <20210428-170709.sv7888.20764@puszcza.gnu.org.ua>
 <20210504-155249.sv7888.28576@puszcza.gnu.org.ua>
 <20210504-170218.sv189.65569@puszcza.gnu.org.ua>
Message-ID: <20210505-132448.sv7888.59340@puszcza.gnu.org.ua>

Follow-up Comment #12, bug #509 (project tex4ht):

Hello,

thank you so much for the quick solution. I appreciate your help. It almost
fixes all the problems. I think what remains broken are paths/menus that span
multiple lines:
E.g. when inserting the following line:

```
Go to \directory{C / Program Files / Prog / Loooooooooooooooooooooong / 
Loooooooooooooooooooooong / Loooooooooooooooooooooong}
```

Maybe we need to hook into first, mid, last of each style instead? But that
would probably yield many little svgs right? I think that would be okay for
now, if there is no other solution.

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?509>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Thu May  6 17:36:17 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Thu, 6 May 2021 17:36:17 +0200
Subject: [tex4ht] [bug #509] Incompatibilities with Tikz generated by
	menukeys package
In-Reply-To: <20210505-132448.sv7888.59340@puszcza.gnu.org.ua>
References: <20210427-232751.sv7888.19658@puszcza.gnu.org.ua>
 <20210428-000437.sv189.90669@puszcza.gnu.org.ua>
 <20210428-001906.sv7888.77784@puszcza.gnu.org.ua>
 <20210428-002257.sv7888.98735@puszcza.gnu.org.ua>
 <20210428-005755.sv189.95827@puszcza.gnu.org.ua>
 <20210428-011115.sv118.45755@puszcza.gnu.org.ua>
 <20210428-012014.sv7888.31044@puszcza.gnu.org.ua>
 <20210428-111438.sv189.2841@puszcza.gnu.org.ua>
 <20210428-151315.sv7888.94504@puszcza.gnu.org.ua>
 <20210428-170709.sv7888.20764@puszcza.gnu.org.ua>
 <20210504-155249.sv7888.28576@puszcza.gnu.org.ua>
 <20210504-170218.sv189.65569@puszcza.gnu.org.ua>
 <20210505-132448.sv7888.59340@puszcza.gnu.org.ua>
Message-ID: <20210506-183616.sv189.62765@puszcza.gnu.org.ua>

Follow-up Comment #13, bug #509 (project tex4ht):

Ah, I see. It seems that replacing 

\Configure{menukey#1}{\Picture+{}}{\EndPicture}

by 

\Configure{menukey#1}{\Picture*{}}{\EndPicture}

does the trick and supports even the long line. I will update the sources.

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?509>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Thu May  6 21:23:10 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Thu, 6 May 2021 21:23:10 +0200
Subject: [tex4ht] [bug #511] awesomebox support (fontawesome issues)
In-Reply-To: <20210504-165312.sv7891.14297@puszcza.gnu.org.ua>
References: <20210504-165312.sv7891.14297@puszcza.gnu.org.ua>
Message-ID: <20210506-222310.sv189.2757@puszcza.gnu.org.ua>

Follow-up Comment #1, bug #511 (project tex4ht):

I've posted detailed answer to TeX.sx. I've just added the code from that
answer to TeX4ht source code, so it should work correctly soon.

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?511>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Fri May  7 17:49:59 2021
From: puszcza-hackers at gnu.org.ua (Julianus Pfeuffer)
Date: Fri, 7 May 2021 17:49:59 +0200
Subject: [tex4ht] [bug #509] Incompatibilities with Tikz generated by
	menukeys package
In-Reply-To: <20210506-183616.sv189.62765@puszcza.gnu.org.ua>
References: <20210427-232751.sv7888.19658@puszcza.gnu.org.ua>
 <20210428-000437.sv189.90669@puszcza.gnu.org.ua>
 <20210428-001906.sv7888.77784@puszcza.gnu.org.ua>
 <20210428-002257.sv7888.98735@puszcza.gnu.org.ua>
 <20210428-005755.sv189.95827@puszcza.gnu.org.ua>
 <20210428-011115.sv118.45755@puszcza.gnu.org.ua>
 <20210428-012014.sv7888.31044@puszcza.gnu.org.ua>
 <20210428-111438.sv189.2841@puszcza.gnu.org.ua>
 <20210428-151315.sv7888.94504@puszcza.gnu.org.ua>
 <20210428-170709.sv7888.20764@puszcza.gnu.org.ua>
 <20210504-155249.sv7888.28576@puszcza.gnu.org.ua>
 <20210504-170218.sv189.65569@puszcza.gnu.org.ua>
 <20210505-132448.sv7888.59340@puszcza.gnu.org.ua>
 <20210506-183616.sv189.62765@puszcza.gnu.org.ua>
Message-ID: <20210507-184959.sv7888.11720@puszcza.gnu.org.ua>

Follow-up Comment #14, bug #509 (project tex4ht):

Great! Yes that seems to have fixed all occurrences that I have.
What is the difference between "+" and "*" here?

Short related question (sorry to hijack this thread):
How could I force the svgs to be produced in a subfolder (e.g.
graphics/mytex-1.svg, graphics/mytex-2.svg) instead of the root folder

Other than that, I think this can be closed.

Thanks a lot again for that quick help.

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?509>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Fri May  7 19:20:43 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Fri, 7 May 2021 19:20:43 +0200
Subject: [tex4ht] [bug #511] awesomebox support (fontawesome issues)
In-Reply-To: <20210506-222310.sv189.2757@puszcza.gnu.org.ua>
References: <20210504-165312.sv7891.14297@puszcza.gnu.org.ua>
 <20210506-222310.sv189.2757@puszcza.gnu.org.ua>
Message-ID: <20210507-202042.sv189.75248@puszcza.gnu.org.ua>

Update of bug #511 (project tex4ht):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?511>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Fri May  7 22:49:24 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Fri, 7 May 2021 22:49:24 +0200
Subject: [tex4ht] [bug #509] Incompatibilities with Tikz generated by
	menukeys package
In-Reply-To: <20210507-184959.sv7888.11720@puszcza.gnu.org.ua>
References: <20210427-232751.sv7888.19658@puszcza.gnu.org.ua>
 <20210428-000437.sv189.90669@puszcza.gnu.org.ua>
 <20210428-001906.sv7888.77784@puszcza.gnu.org.ua>
 <20210428-002257.sv7888.98735@puszcza.gnu.org.ua>
 <20210428-005755.sv189.95827@puszcza.gnu.org.ua>
 <20210428-011115.sv118.45755@puszcza.gnu.org.ua>
 <20210428-012014.sv7888.31044@puszcza.gnu.org.ua>
 <20210428-111438.sv189.2841@puszcza.gnu.org.ua>
 <20210428-151315.sv7888.94504@puszcza.gnu.org.ua>
 <20210428-170709.sv7888.20764@puszcza.gnu.org.ua>
 <20210504-155249.sv7888.28576@puszcza.gnu.org.ua>
 <20210504-170218.sv189.65569@puszcza.gnu.org.ua>
 <20210505-132448.sv7888.59340@puszcza.gnu.org.ua>
 <20210506-183616.sv189.62765@puszcza.gnu.org.ua>
 <20210507-184959.sv7888.11720@puszcza.gnu.org.ua>
Message-ID: <20210507-234924.sv189.87021@puszcza.gnu.org.ua>

Update of bug #509 (project tex4ht):

             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #15:

\Picture+ works as inline command, \Picture* can contain paragraphs.

It is possible to specify graphics path using "imgdir:path" option (like
`make4ht filename.tex "imdir:img/"`), but the images are not copied
automatically to this place. You can use the following build file:


----------------------------------
local log = logging.new("build file")

local imgdir 

local function get_imgdir(par)
  -- try to find imgdir:path in tex4ht options
  local imgdir = par.tex4ht_sty_par:match("imgdir:([^,]+)")
  if not imgdir then
    imgdir = ""
    log:warning("Cannot find imgdir")
    log:warning('Please use: make4ht ' .. par.input .. ' "imgdir:path"')
  end
  return imgdir
end

local function make_img_name(name, par)
  imgdir = imgdir or get_imgdir(par)
  -- don't make new name if the image name already contains imgdir path
  if string.find(name, imgdir, 1, true) then return name end
  local name_parts = {}
  -- construct output image name from make4ht output dir, imgdir and image
name
  if imgdir ~= "" then name_parts[#name_parts+1] = imgdir end
  name_parts[#name_parts + 1] = name
  -- turn name parts into path and normalize slashes
  local newname = table.concat(name_parts, "/"):gsub("/+", "/")
  return newname
end


local function copy_img(name, par)
  local newname = make_img_name(name, par)
  -- copy imge to the output dir
  if newname ~= name then
    if par.outdir~="" then newname = table.concat({par.outdir, newname}, "/")
end
    mkutils.copy(name, newname)
    return false, "Copy generated images to " .. imgdir
  end
end



Make:match("svg$", copy_img)
Make:match("png$", copy_img)
Make:match("jpg$", copy_img)

----------------

Call it as:

make4ht -e build.lua filename.tex "imgdir:graphics/"

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?509>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From arkbene.ph at gmail.com  Thu May 20 02:03:39 2021
From: arkbene.ph at gmail.com (Arkady Benediktov)
Date: Thu, 20 May 2021 03:03:39 +0300
Subject: [tex4ht] pzdr.htf
In-Reply-To: <20210223172258.qnhmy67yjc66rksi@agraulos>
References: <33A79150-7D82-44D9-81CA-1B5978C12142@gmail.com>
 <20210223172258.qnhmy67yjc66rksi@agraulos>
Message-ID: <41C68038-27EA-4C18-AD5A-C24067A71B64@gmail.com>

Dear Eitan,

Just noticed an empty line (after the footer) in pzdr.htf. As far as I could guess, the footer was supposed to be the last line of an htf file, so this may be a problem.

> On 23 Feb 2021, at 20:22, Michal Hoftich <michal.h21 at gmail.com> wrote:
> 
> Dear Arkady,
> 
>> Thanks for the great tool!
>> 
>> Just a small suspected typo report: it appears that in the cmcbx.htf the Unicode fo the glyph \x19 should be U+2116 (Numero sign), not U+2216 (Set minus). I am attaching the output of pdftex testfont for your convenience.
> 
> Thank you for the report and your kind words. You are right, there was a typo.  I've fixed that in the TeX4ht sources.
> 
> Best regards,
> Michal



From arkbene.ph at gmail.com  Thu May 20 02:05:34 2021
From: arkbene.ph at gmail.com (Arkady Benediktov)
Date: Thu, 20 May 2021 03:05:34 +0300
Subject: [tex4ht] pzdr.htf
In-Reply-To: <41C68038-27EA-4C18-AD5A-C24067A71B64@gmail.com>
References: <33A79150-7D82-44D9-81CA-1B5978C12142@gmail.com>
 <20210223172258.qnhmy67yjc66rksi@agraulos>
 <41C68038-27EA-4C18-AD5A-C24067A71B64@gmail.com>
Message-ID: <192F33D9-C503-41F9-B6C5-E4B70C4442A9@gmail.com>

Dear Michal, sorry about the wrong name (pasted in a hurry).


> On 20 May 2021, at 03:03, Arkady Benediktov <Arkbene.ph at gmail.com> wrote:
> 
> Dear Eitan,
> 
> Just noticed an empty line (after the footer) in pzdr.htf. As far as I could guess, the footer was supposed to be the last line of an htf file, so this may be a problem.
> 
>> On 23 Feb 2021, at 20:22, Michal Hoftich <michal.h21 at gmail.com> wrote:
>> 
>> Dear Arkady,
>> 
>>> Thanks for the great tool!
>>> 
>>> Just a small suspected typo report: it appears that in the cmcbx.htf the Unicode fo the glyph \x19 should be U+2116 (Numero sign), not U+2216 (Set minus). I am attaching the output of pdftex testfont for your convenience.
>> 
>> Thank you for the report and your kind words. You are right, there was a typo.  I've fixed that in the TeX4ht sources.
>> 
>> Best regards,
>> Michal
> 



From michal.h21 at gmail.com  Thu May 20 11:42:00 2021
From: michal.h21 at gmail.com (Michal Hoftich)
Date: Thu, 20 May 2021 11:42:00 +0200
Subject: [tex4ht] pzdr.htf
In-Reply-To: <41C68038-27EA-4C18-AD5A-C24067A71B64@gmail.com>
References: <33A79150-7D82-44D9-81CA-1B5978C12142@gmail.com>
 <20210223172258.qnhmy67yjc66rksi@agraulos>
 <41C68038-27EA-4C18-AD5A-C24067A71B64@gmail.com>
Message-ID: <20210520094200.bha2wigitkebkcky@agraulos>

Dear Arkady,

this should be OK, most of .htf files contain extra lines at the end and 
it doesn't seem to cause issues for the tex4ht DVI font processing.

>Just noticed an empty line (after the footer) in pzdr.htf. As far as I 
>could guess, the footer was supposed to be the last line of an htf 
>file, so this may be a problem.

Best regards,
Michal

From puszcza-hackers at gnu.org.ua  Sat May 29 23:57:35 2021
From: puszcza-hackers at gnu.org.ua (Karl Berry)
Date: Sat, 29 May 2021 23:57:35 +0200
Subject: [tex4ht] [bug #512] \href undefined after hyperref included in
	class file; Unicode nbsp
Message-ID: <20210530-005735.sv118.79086@puszcza.gnu.org.ua>

URL:
  <http://puszcza.gnu.org.ua/bugs/?512>

                 Summary: \href undefined after hyperref included in class
file; Unicode nbsp
                 Project: tex4ht
            Submitted by: karl
            Submitted on: Sun May 30 00:57:35 2021
                Category: None
                Priority: 5 - Normal
                Severity: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

Hi Michal - I ran htlatex on the upcoming LaTeX news ltnews33.tex (attached),
and there was an error that \href was an undefined control sequence. I assume
because it is ltnews.cls that includes hyperref, rather than the document
itself. When I added \usepackage{hyperref} to the document, it generally
worked ok.

One minor problem I noticed was that the <title> used the Unicode &#x00A0;
even though the output was 8859-1 (I forgot to give the options for UTF-8):

<head><title>LaTeX&#x00A0;News</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

The incorrect &#x00A0; is used in other places, too. I suppose it's hardly
worth worrying about other encodings nowadays, though. --thanks, karl.







    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Sun May 30 00:57:35 2021  Name: ltnews33.tex  Size: 33kB   By: karl

<http://puszcza.gnu.org.ua/bugs/download.php?file_id=417>

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?512>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From arkbene.ph at gmail.com  Sun May 30 00:26:39 2021
From: arkbene.ph at gmail.com (Arkady Benediktov)
Date: Sun, 30 May 2021 01:26:39 +0300
Subject: [tex4ht] bbold.htf
In-Reply-To: <20210520094200.bha2wigitkebkcky@agraulos>
References: <33A79150-7D82-44D9-81CA-1B5978C12142@gmail.com>
 <20210223172258.qnhmy67yjc66rksi@agraulos>
 <41C68038-27EA-4C18-AD5A-C24067A71B64@gmail.com>
 <20210520094200.bha2wigitkebkcky@agraulos>
Message-ID: <1DD1790D-821B-447D-BA64-C3A82D03447D@gmail.com>

Dear Michal,

I?m writing to suggest fixes/improvements to bbold.htf.

My current version is the latest version available from CTAN on my system: bbold.htf 2020-05-27-14:14

My proposed version differs from the current version above in a few code points.The cut-out of the diff (current vs. proposed HTF file) with comments is below:

> '&#x213F;' ''    5 % Double-Struck Capital Pi; replaces: U+03A0 Greek Capital Letter Pi ???
> '&#x2140;' ''    6 % Double-Struck N-Ary Summation; replaces: U+213F Double-Struck Capital Pi ???
> '&#x03A5;' ''    7 % Greek Capital Letter Upsilon: replaces: U+2140 Double-Struck N-Ary Summation ???
> '&#x03B8;' ''   18 % Greek Small Letter Theta; replaces: U+1D703 Mathematical Italic Small Theta
> '&#x213C;' ''   25 % Double-Struck Small Pi; replaces: 03C0 Greek Small Letter Pi
> '&#x2985;' ''   40 % Left White Parenthesis; replaces: U+2987 Z Notation Left Image Bracket
> '&#x2986;' ''   41 % Right White Parenthesis; replaces: U+2988 Z Notation Right Image Bracket
> '&#x2E30;' ''   61 % Ring Point; replaces "=" ???
> '&#x27EA;' ''   94 % Mathematical Left Double Angle Bracket; replaces U+02C6 Modifier Letter Circumflex Accent ("^") ???
> '&#x27EB;' ''   95 % Mathematical Right Double Angle Bracket; replaces U+005F Low Line ("underscore") ???
> '&#x2013;' ''  123 % En Dash; replaces U+007B Left Curly Bracket ???
> '&#x2AFE;' ''  124 % White Vertical Bar; replaces U+007C Vertical Line 
> '&#x2014;' ''  125 % Em Dash; replaces U+007D Right Curly Bracket ???

The code point is in the third column. The ????? at the end of the line indicates a suggested bug fix (i.e. cases where the current version is obviously off). The other lines improve fidelity of the unicode representation of the font.

References:

https://www.ctan.org/pkg/bbold <https://www.ctan.org/pkg/bbold>
https://en.wikipedia.org/wiki/Blackboard_bold <https://en.wikipedia.org/wiki/Blackboard_bold>

For convenience, the mapping tables (with changes highlighted) are printed below:

Current version of bbold.htf:

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ! ? # $ % & ? ? ? * + , - . /
? ? ? ? ? ? ? ? ? ? : ; < = > ?
@ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? \ ? ? _
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? { | } ? ?

My proposed version:

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ! ? # $ % & ? ? ? * + , - . /
? ? ? ? ? ? ? ? ? ? : ; < ? > ?
@ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? \ ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

The output of pdftex testfont is also attached which, together with the two tables above, clearly shows the bugs in the current version of bbold.htf as well as the improvements introduced by the proposed changes:




Best regards,
? Arkady.


> On 20 May 2021, at 12:42, Michal Hoftich <michal.h21 at gmail.com> wrote:
> 
> Dear Arkady,
> 
> this should be OK, most of .htf files contain extra lines at the end and it doesn't seem to cause issues for the tex4ht DVI font processing.
> 
>> Just noticed an empty line (after the footer) in pzdr.htf. As far as I could guess, the footer was supposed to be the last line of an htf file, so this may be a problem.
> 
> Best regards,
> Michal

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex4ht/attachments/20210530/3a370b46/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bbold.pdf
Type: application/pdf
Size: 31988 bytes
Desc: not available
URL: <https://tug.org/pipermail/tex4ht/attachments/20210530/3a370b46/attachment-0001.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex4ht/attachments/20210530/3a370b46/attachment-0003.html>

From puszcza-hackers at gnu.org.ua  Mon May 31 12:31:27 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Mon, 31 May 2021 12:31:27 +0200
Subject: [tex4ht] [bug #512] \href undefined after hyperref included in
	class file; Unicode nbsp
In-Reply-To: <20210530-005735.sv118.79086@puszcza.gnu.org.ua>
References: <20210530-005735.sv118.79086@puszcza.gnu.org.ua>
Message-ID: <20210531-133127.sv189.60879@puszcza.gnu.org.ua>

Follow-up Comment #1, bug #512 (project tex4ht):

Hi Karl, this is because you don't load hyperref in ltnews.cls with TeX4ht. In
particular, the branch \ifcase\pdfoutput\else is not executed. It works if I
put \Require{hyperref} before \else.

Regarding non-breaking space, you can try the following configuration that
replaces it with <span> element that contains regular space, but it acts as a
non-breaking space thanks to CSS:

\Preamble{xhtml}
\begin{document}
\Configure{ }{\HCode{<span class="nbsp"> </span>}}
\Css{span.nbsp{white-space:pre;}}
\EndPreamble


    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?512>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From michal.h21 at gmail.com  Mon May 31 20:38:25 2021
From: michal.h21 at gmail.com (Michal Hoftich)
Date: Mon, 31 May 2021 20:38:25 +0200
Subject: [tex4ht] bbold.htf
In-Reply-To: <1DD1790D-821B-447D-BA64-C3A82D03447D@gmail.com>
References: <33A79150-7D82-44D9-81CA-1B5978C12142@gmail.com>
 <20210223172258.qnhmy67yjc66rksi@agraulos>
 <41C68038-27EA-4C18-AD5A-C24067A71B64@gmail.com>
 <20210520094200.bha2wigitkebkcky@agraulos>
 <1DD1790D-821B-447D-BA64-C3A82D03447D@gmail.com>
Message-ID: <20210531183825.3wprzoo2myettbcm@agraulos>

Dear Arkady,

thank you for the report. You are right, some characters are really 
wrong. I've updated TeX4ht sources with your proposed fixes, so they 
should be included in TeX Live soon.

Best regards,
Michal

>
>I?m writing to suggest fixes/improvements to bbold.htf.
>
>My current version is the latest version available from CTAN on my 
>system: bbold.htf 2020-05-27-14:14
>
>My proposed version differs from the current version above in a few 
>code points.The cut-out of the diff (current vs. proposed HTF file) 
>with comments is below:
>

From puszcza-hackers at gnu.org.ua  Mon May 31 23:21:07 2021
From: puszcza-hackers at gnu.org.ua (Karl Berry)
Date: Mon, 31 May 2021 23:21:07 +0200
Subject: [tex4ht] [bug #512] \href undefined after hyperref included in
	class file; Unicode nbsp
In-Reply-To: <20210531-133127.sv189.60879@puszcza.gnu.org.ua>
References: <20210530-005735.sv118.79086@puszcza.gnu.org.ua>
 <20210531-133127.sv189.60879@puszcza.gnu.org.ua>
Message-ID: <20210601-002107.sv118.86761@puszcza.gnu.org.ua>

Update of bug #512 (project tex4ht):

             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #2:

Thanks Michal. I'll have to tell the latex people about the ltnews.cls
problem.

Regarding the nbsp, thanks for the workaround. I guess my basic point was that
tex4ht shouldn't be generating unicode output when the specified encoding is
not unicode. but, as i say, it's probably not worth the time to look into. (in
practice, if we were to actually do this, we would surely generate utf8
anyway; i just forgot to give the options).

closing, thanks.


    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?512>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Mon May 31 23:44:39 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Mon, 31 May 2021 23:44:39 +0200
Subject: [tex4ht] [bug #512] \href undefined after hyperref included in
	class file; Unicode nbsp
In-Reply-To: <20210601-002107.sv118.86761@puszcza.gnu.org.ua>
References: <20210530-005735.sv118.79086@puszcza.gnu.org.ua>
 <20210531-133127.sv189.60879@puszcza.gnu.org.ua>
 <20210601-002107.sv118.86761@puszcza.gnu.org.ua>
Message-ID: <20210601-004439.sv189.78056@puszcza.gnu.org.ua>

Follow-up Comment #3, bug #512 (project tex4ht):

I would change the code in ltnews.cls to something like:

 
\ifx\pdfoutput\@undefined
  \let\pdfoutput\outputmode
  \protected\def\pdfinfo{\pdfextension info }
\fi
\ifx\pdfoutput\@undefined
\else
  \ifx\pdfoutput\relax
  \else
    \ifcase\pdfoutput
      \ifdefined\HCode
        \RequirePackage{hyperref}
      \fi
    \else
      \pdfinfo{%
        /Title (LaTeX News)
        /Author (The LaTeX Project)
      }
      \IfFileExists{hyperref.sty}{%
        \RequirePackage[hidelinks]{hyperref}}{}
    \fi
  \fi
\fi



    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?512>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Thu Jun  3 10:08:19 2021
From: puszcza-hackers at gnu.org.ua (Ulrich =?UTF-8?B?TcO8bGxlcg==?=)
Date: Thu, 3 Jun 2021 10:08:19 +0200
Subject: [tex4ht] [bug #513] Missing vertical space after first paragraph in
	lists
Message-ID: <20210603-110819.sv340.77264@puszcza.gnu.org.ua>

URL:
  <http://puszcza.gnu.org.ua/bugs/?513>

                 Summary: Missing vertical space after first paragraph in
lists
                 Project: tex4ht
            Submitted by: ulm
            Submitted on: Thu Jun  3 11:08:19 2021
                Category: None
                Priority: 5 - Normal
                Severity: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

If a list item has multiple paragraphs, then there is no vertical space
between the first and second paragraph. Subsequent paragraphs
are o.k.

(Looking at the output, the first paragraph isn't a paragraph in HTML.)

See attached minimum example.




    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Thu Jun  3 11:08:19 2021  Name: bug.tex  Size: 78B   By: ulm

<http://puszcza.gnu.org.ua/bugs/download.php?file_id=418>
-------------------------------------------------------
Date: Thu Jun  3 11:08:19 2021  Name: bug.html  Size: 1kB   By: ulm

<http://puszcza.gnu.org.ua/bugs/download.php?file_id=419>
-------------------------------------------------------
Date: Thu Jun  3 11:08:19 2021  Name: bug.css  Size: 5kB   By: ulm

<http://puszcza.gnu.org.ua/bugs/download.php?file_id=420>

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?513>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Thu Jun  3 10:13:52 2021
From: puszcza-hackers at gnu.org.ua (Ulrich =?UTF-8?B?TcO8bGxlcg==?=)
Date: Thu, 3 Jun 2021 10:13:52 +0200
Subject: [tex4ht] [bug #513] Missing vertical space after first paragraph in
	lists
In-Reply-To: <20210603-110819.sv340.77264@puszcza.gnu.org.ua>
References: <20210603-110819.sv340.77264@puszcza.gnu.org.ua>
Message-ID: <20210603-111352.sv340.41904@puszcza.gnu.org.ua>

Additional Item Attachment, bug #513 (project tex4ht):

File name: bug.tex                        Size:0 KB
File name: bug.html                       Size:1 KB
File name: bug.css                        Size:5 KB


    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?513>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Thu Jun  3 10:35:47 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Thu, 3 Jun 2021 10:35:47 +0200
Subject: [tex4ht] [bug #513] Missing vertical space after first paragraph in
	lists
In-Reply-To: <20210603-111352.sv340.41904@puszcza.gnu.org.ua>
References: <20210603-110819.sv340.77264@puszcza.gnu.org.ua>
 <20210603-111352.sv340.41904@puszcza.gnu.org.ua>
Message-ID: <20210603-113547.sv189.99283@puszcza.gnu.org.ua>

Follow-up Comment #1, bug #513 (project tex4ht):

Hello Ulrich,

thanks for the report. you are right, paragraphs are not started for the first
paragraphs in item environments. I will update that in TeX4ht sources. In the
meantime, you can try the attached .cfg file.

Best regards,
Michal

(file #424)
    _______________________________________________________

Additional Item Attachment:

File name: mycfg.cfg                      Size:0 KB


    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?513>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Thu Jun  3 11:14:58 2021
From: puszcza-hackers at gnu.org.ua (Ulrich =?UTF-8?B?TcO8bGxlcg==?=)
Date: Thu, 3 Jun 2021 11:14:58 +0200
Subject: [tex4ht] [bug #513] Missing vertical space after first paragraph in
	lists
In-Reply-To: <20210603-113547.sv189.99283@puszcza.gnu.org.ua>
References: <20210603-110819.sv340.77264@puszcza.gnu.org.ua>
 <20210603-111352.sv340.41904@puszcza.gnu.org.ua>
 <20210603-113547.sv189.99283@puszcza.gnu.org.ua>
Message-ID: <20210603-121457.sv340.5592@puszcza.gnu.org.ua>

Follow-up Comment #2, bug #513 (project tex4ht):

Thank you for the quick response.

That .cfg file fixes the problem for me.


    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?513>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Thu Jun  3 11:30:17 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Thu, 3 Jun 2021 11:30:17 +0200
Subject: [tex4ht] [bug #513] Missing vertical space after first paragraph in
	lists
In-Reply-To: <20210603-121457.sv340.5592@puszcza.gnu.org.ua>
References: <20210603-110819.sv340.77264@puszcza.gnu.org.ua>
 <20210603-111352.sv340.41904@puszcza.gnu.org.ua>
 <20210603-113547.sv189.99283@puszcza.gnu.org.ua>
 <20210603-121457.sv340.5592@puszcza.gnu.org.ua>
Message-ID: <20210603-123017.sv189.85618@puszcza.gnu.org.ua>

Follow-up Comment #3, bug #513 (project tex4ht):

That was fortunately easy fix, unlike issues with Hyperref :/ I've updated the
sources, so the fix should be included in TL soon.

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?513>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Thu Jun  3 11:30:24 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Thu, 3 Jun 2021 11:30:24 +0200
Subject: [tex4ht] [bug #513] Missing vertical space after first paragraph in
	lists
In-Reply-To: <20210603-123017.sv189.85618@puszcza.gnu.org.ua>
References: <20210603-110819.sv340.77264@puszcza.gnu.org.ua>
 <20210603-111352.sv340.41904@puszcza.gnu.org.ua>
 <20210603-113547.sv189.99283@puszcza.gnu.org.ua>
 <20210603-121457.sv340.5592@puszcza.gnu.org.ua>
 <20210603-123017.sv189.85618@puszcza.gnu.org.ua>
Message-ID: <20210603-123024.sv189.53545@puszcza.gnu.org.ua>

Update of bug #513 (project tex4ht):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?513>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From nma at 12000.org  Fri Jun 11 16:47:27 2021
From: nma at 12000.org (Nasser M. Abbasi)
Date: Fri, 11 Jun 2021 09:47:27 -0500
Subject: [tex4ht] why has the spacings between enumeration lists increased
 in TL 2021 vs. TL 2020 with tex4ht?
Message-ID: <df12ab8d-c04b-bd09-0b31-cc6b9b6c33ae@12000.org>


I just updated to TL 2021 last night. I noticed the first thing when
compiling some existing latex file that now the vertical spacing
between enumeration list items is much larger than before. All other
things being the same.

Here is a MWE from my actual latex file.

===============
\documentclass[12pt]{article}
\begin{document}
\section{Listing of CAS systems tested}

The following systems were tested at this time.

\begin{enumerate}
\item Mathematica 12.3 (64 bit) on windows 10.
\item Rubi 4.16.1 in Mathematica 12 on windows 10.
\item Maple 2021.1 (64 bit) on windows 10.
\item Maxima 5.44 on Linux. (via sagemath 9.3)
\item Fricas 1.3.6 on Linux (via sagemath 9.3)
\item Sympy 1.8 under Python 3.7.9 using Anaconda distribution.
\item Giac/Xcas 1.7 on Linux. (via sagemath 9.3)
\item Mupad using Matlab 2021a with Symbolic Math Toolbox Version 8.7 under windows 10 (64 bit)
\end{enumerate}

\end{document}
====================

I compiled using  make4ht foo3.tex "htm,mathjax"

The HTML now (2021) uses this for each time

================
...
<p class='noindent'>The following systems were tested at this time.</p>
<!-- l. 14 -->
<p class='indent'></p>
<ol class='enumerate1'>
<li class='enumerate' id='x1-1002x1'>
<!-- l. 15 -->
<p class='noindent'>Mathematica 12.3 (64 bit) on windows 10.</p>
</li>

etc....
================

Before in 2020 it generated

================
.....
<p class='noindent'>The following systems were tested at this time.</p>
<!-- l. 51 -->
<p class='noindent'></p>
<ol class='enumerate1'>
<li class='enumerate' id='x2-2002x1'>
Mathematica 12.3 (64 bit) on windows 10.
</li>
etc...
================

Notice the difference. Now it puts the item in a <p></p>
while before it did not. This explains the extra vertical spacing.

I find the extra vertical spacing between the lines too large and like the earlier
one little more.

Is there a way to reduce/control this or revert to how tex4ht did it before?

>which tex4ht
/usr/local/texlive/2021/bin/x86_64-linux/tex4ht

Thanks
--Nasser

From michal.h21 at gmail.com  Sat Jun 12 10:56:01 2021
From: michal.h21 at gmail.com (Michal Hoftich)
Date: Sat, 12 Jun 2021 10:56:01 +0200
Subject: [tex4ht] why has the spacings between enumeration lists
 increased in TL 2021 vs. TL 2020 with tex4ht?
In-Reply-To: <df12ab8d-c04b-bd09-0b31-cc6b9b6c33ae@12000.org>
References: <df12ab8d-c04b-bd09-0b31-cc6b9b6c33ae@12000.org>
Message-ID: <20210612085601.4ovnlbykbkcdievr@agraulos>

Hi Nasser,

>I just updated to TL 2021 last night. I noticed the first thing when
>compiling some existing latex file that now the vertical spacing
>between enumeration list items is much larger than before. All other
>things being the same.
>
>Notice the difference. Now it puts the item in a <p></p>
>while before it did not. This explains the extra vertical spacing.
>
>I find the extra vertical spacing between the lines too large and like the earlier
>one little more.
>

The original output was buggy, as it didn't play well with \item that 
cointained multiple paragraphs. So we start paragraph explicitly for 
each \item now.

You can remove the spacing using the following configuration file:

\Preamble{xhtml}
\Css{li p:first-child{margin-bottom:0}}
\begin{document}
\EndPreamble

Best regards,
Michal

From puszcza-hackers at gnu.org.ua  Sun Jun 13 04:44:08 2021
From: puszcza-hackers at gnu.org.ua (Nasser M. Abbasi)
Date: Sun, 13 Jun 2021 04:44:08 +0200
Subject: [tex4ht] [bug #514] tex4ht gives error on code that compiles OK
	with lualatex
Message-ID: <20210613-054408.sv199.34038@puszcza.gnu.org.ua>

URL:
  <http://puszcza.gnu.org.ua/bugs/?514>

                 Summary: tex4ht gives error on code that compiles OK with
lualatex
                 Project: tex4ht
            Submitted by: nma123
            Submitted on: Sun Jun 13 05:44:08 2021
                Category: None
                Priority: 5 - Normal
                Severity: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

reference and images

https://tex.stackexchange.com/questions/601030/tex4ht-in-tl-2021-gives-error-on-code-that-compiles-ok-with-lualatex

Here is a MWE to reproduce it

============================
\documentclass[12pt]{article}
\usepackage{graphicx}
\begin{document}
The following is plot of solution 

\begin{figure}[h]
\centering
\includegraphics[scale=0.45]{example-image}
\caption{$\displaystyle {y \left(x \right) =
-\frac{\left(\left(\left\{\begin{array}{cc}
{\mathrm e}^{-2 x} & x \le 1 
\\
 {\mathrm e}^{-2} & 1<x  
\end{array}\right.\right)-7\right) {\mathrm e}^{2 x}}{2}}$
}
\end{figure}                 
\end{document}
=================

The above compiles OK with lualatex

The same file in tex4ht gives this error in TL 2021

(/usr/local/texlive/2021/texmf-dist/tex/generic/tex4ht/html4-math.4ht)
(/usr/local/texlive/2021/texmf-dist/tex/generic/tex4ht/html5.4ht))
(./foo3.aux)
[1] [2]
l.16 --- TeX4ht warning --- File `"example-image.xbb"' not found ---
l.16 --- TeX4ht warning --- Cannot determine size of graphic in
"example-image.
xbb" (no BoundingBox) ---
! Argument of \im:g has an extra }.
<inserted text>
                \par
l.22 }

?

This is on Linux. 





    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?514>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From nma at 12000.org  Sun Jun 13 09:09:13 2021
From: nma at 12000.org (Nasser M. Abbasi)
Date: Sun, 13 Jun 2021 02:09:13 -0500
Subject: [tex4ht] Can make4ht locate .cfg files from same path used for
 TEXINPUTS? or some other PATH?
Message-ID: <9e9f7952-a8c1-6e1a-dda1-7d301a3a1387@12000.org>


Currently, for the command

   make4ht -c  my_config.cfg   foo.tex

I have to copy the file my_config.cfg in $HOME so that it can find it.

Is it possible to make it use TEXINPUTS to locate these .cfg files?

So that I do not have to clutter my $HOME folder with copies of
my .cfg which reside in different folder and having to remember to
copy it each time I make a change to the .cfg file in the original folder
which is not $HOME?

I looked at docs for make4ht but did not see any type of path
to use for this.

https://ctan.math.washington.edu/tex-archive/support/make4ht/make4ht-doc.pdf

Thanks
--Nasser

From news3 at nililand.de  Sun Jun 13 10:55:05 2021
From: news3 at nililand.de (Ulrike Fischer)
Date: Sun, 13 Jun 2021 10:55:05 +0200
Subject: [tex4ht] why has the spacings between enumeration lists
 increased in TL 2021 vs. TL 2020 with tex4ht?
In-Reply-To: <20210612085601.4ovnlbykbkcdievr@agraulos>
References: <df12ab8d-c04b-bd09-0b31-cc6b9b6c33ae@12000.org>
 <20210612085601.4ovnlbykbkcdievr@agraulos>
Message-ID: <885574466.20210613105505@nililand.de>

>>I just updated to TL 2021 last night. I noticed the first thing when
>>compiling some existing latex file that now the vertical spacing
>>between enumeration list items is much larger than before. All other
>>things being the same.

>>Notice the difference. Now it puts the item in a <p></p>
>>while before it did not. This explains the extra vertical spacing.
>>

> The original output was buggy, as it didn't play well with \item that 
> cointained multiple paragraphs. So we start paragraph explicitly for 
> each \item now.

There is some discussion going on related to "well tagged pdf" if
list item bodies are paragraphs or not.

Basically the answer is, "it depends":
In lists with short topics you don't want a paragraph tagging, but
you do in long list items with multiple paragraphs.

We will probably have to offer more control for users here.

But imho as *default* it makes more sense if tex4ht doesn't insert
paragraphs, but offer some command that allows to mark list item
bodies as real paragraphs. Lists with short, non-paragraph items are
more common than lists with long texts.



-- 
Mit freundlichen Gr??en
Ulrike Fischer



From michal.h21 at gmail.com  Sun Jun 13 15:06:39 2021
From: michal.h21 at gmail.com (Michal Hoftich)
Date: Sun, 13 Jun 2021 15:06:39 +0200
Subject: [tex4ht] why has the spacings between enumeration lists
 increased in TL 2021 vs. TL 2020 with tex4ht?
In-Reply-To: <885574466.20210613105505@nililand.de>
References: <df12ab8d-c04b-bd09-0b31-cc6b9b6c33ae@12000.org>
 <20210612085601.4ovnlbykbkcdievr@agraulos>
 <885574466.20210613105505@nililand.de>
Message-ID: <20210613130639.iykyvdv7fcg6xmv5@agraulos>

Hi Ulrike,

>There is some discussion going on related to "well tagged pdf" if
>list item bodies are paragraphs or not.
>
>Basically the answer is, "it depends":
>In lists with short topics you don't want a paragraph tagging, but
>you do in long list items with multiple paragraphs.
>
>We will probably have to offer more control for users here.
>
>But imho as *default* it makes more sense if tex4ht doesn't insert
>paragraphs, but offer some command that allows to mark list item
>bodies as real paragraphs. Lists with short, non-paragraph items are
>more common than lists with long texts.

TeX4ht used to not start paragraphs explicitly in lists, but it caused 
issues with items that contained multiple paragraphs, so I changed that 
recently. It is possible to remove any paragraph spacing if item 
contains just one paragraphs, so it doesn't make any visual difference 
to the version without paragraph. 

I can make a DOM extension for make4ht that removes paragraphs in items 
that contain just one paragraph. It should be quite easy and more robust 
than any handling of this issue on the TeX side. 

Best regards,
Michal


From michal.h21 at gmail.com  Sun Jun 13 15:14:01 2021
From: michal.h21 at gmail.com (Michal Hoftich)
Date: Sun, 13 Jun 2021 15:14:01 +0200
Subject: [tex4ht] Can make4ht locate .cfg files from same path used for
 TEXINPUTS? or some other PATH?
In-Reply-To: <9e9f7952-a8c1-6e1a-dda1-7d301a3a1387@12000.org>
References: <9e9f7952-a8c1-6e1a-dda1-7d301a3a1387@12000.org>
Message-ID: <20210613131401.dxsepv3j6bjxcwu4@agraulos>

Hi Nasser,

>I have to copy the file my_config.cfg in $HOME so that it can find it.
>
>Is it possible to make it use TEXINPUTS to locate these .cfg files?
>
>So that I do not have to clutter my $HOME folder with copies of
>my .cfg which reside in different folder and having to remember to
>copy it each time I make a change to the .cfg file in the original folder
>which is not $HOME?
>
>I looked at docs for make4ht but did not see any type of path
>to use for this.
>
>https://ctan.math.washington.edu/tex-archive/support/make4ht/make4ht-doc.pdf
>

make4ht uses the kpse library to locate a .cfg file. You can put it in 
your TEXMF dir, for example:

$HOME/texmf/tex/latex/mycfgfolder/helloworld.cfg

Best regards,
Michal

From puszcza-hackers at gnu.org.ua  Sun Jun 13 15:15:38 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Sun, 13 Jun 2021 15:15:38 +0200
Subject: [tex4ht] [bug #514] tex4ht gives error on code that compiles OK
	with lualatex
In-Reply-To: <20210613-054408.sv199.34038@puszcza.gnu.org.ua>
References: <20210613-054408.sv199.34038@puszcza.gnu.org.ua>
Message-ID: <20210613-161538.sv189.37910@puszcza.gnu.org.ua>

Follow-up Comment #1, bug #514 (project tex4ht):

I've posted my answer on TeX.sx and fixed this issue in TeX4ht sources. The
issue is that some commands cause errors when used in \caption and \section
commands, so you can either use \protect, or \fixmathjaxtoc macro. 

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?514>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From nma at 12000.org  Sun Jun 13 15:55:36 2021
From: nma at 12000.org (Nasser M. Abbasi)
Date: Sun, 13 Jun 2021 08:55:36 -0500
Subject: [tex4ht] Can make4ht locate .cfg files from same path used for
 TEXINPUTS? or some other PATH?
In-Reply-To: <20210613131401.dxsepv3j6bjxcwu4@agraulos>
References: <9e9f7952-a8c1-6e1a-dda1-7d301a3a1387@12000.org>
 <20210613131401.dxsepv3j6bjxcwu4@agraulos>
Message-ID: <16fed292-4613-1066-8d1c-dbb9eb224aa1@12000.org>

On 6/13/2021 8:14 AM, Michal Hoftich wrote:

>>
>> I looked at docs for make4ht but did not see any type of path
>> to use for this.
>>
>> https://ctan.math.washington.edu/tex-archive/support/make4ht/make4ht-doc.pdf
>>

> 
> make4ht uses the kpse library to locate a .cfg file. You can put it in
> your TEXMF dir, for example:
> 
> $HOME/texmf/tex/latex/mycfgfolder/helloworld.cfg
> 
> Best regards,
> Michal
> 

Thanks Michal;

Sounds like a good idea will do that now.

Does the above also work if I put the .mk4 files there also?
Currently I copy it to $HOME.

Btw, does one still needs to use .mk4 file in latest versions of make4ht?

This is the one I have now, I think I got it from you years ago:

------------  new.mk4 -----------------
filter_settings "dvisvgm_hashes" {
   options = "-n --exact -c 1.2,1.2"
}
if mode == "draft" then
   Make:htlatex {}
else
   Make:htlatex {}
   Make:htlatex {}
   Make:htlatex {}
   Make:htlatex {}
end
-----------------------------

And I use it as follows

          make4ht .....  -e  $HOME/new.mk4 ....

Btw, I just noticed, if I do not have it on the path, my Latex still compiles
to HTML OK and make4ht does not complain it can't find the mk4 files.

So the questions I have are
1) is the above .mk4 still needed? What difference if I do not use it?
btw, I do not use svg now for math, I only use mathjax.
2) if I put in $HOME/texmf/tex/latex/mycfgfolder/new.mk4
Will make4ht finds it like it will for the .cfg files?

Thank you,
--Nasser

From michal.h21 at gmail.com  Sun Jun 13 16:42:57 2021
From: michal.h21 at gmail.com (Michal Hoftich)
Date: Sun, 13 Jun 2021 16:42:57 +0200
Subject: [tex4ht] Can make4ht locate .cfg files from same path used for
 TEXINPUTS? or some other PATH?
In-Reply-To: <16fed292-4613-1066-8d1c-dbb9eb224aa1@12000.org>
References: <9e9f7952-a8c1-6e1a-dda1-7d301a3a1387@12000.org>
 <20210613131401.dxsepv3j6bjxcwu4@agraulos>
 <16fed292-4613-1066-8d1c-dbb9eb224aa1@12000.org>
Message-ID: <20210613144257.nufxvejrpavulpee@agraulos>

>Sounds like a good idea will do that now.
>
>Does the above also work if I put the .mk4 files there also?
>Currently I copy it to $HOME.

Yes, but it looks in scripts tree, so something like:

$HOME/texmf/scripts/lua/mybuild/filename.mk4



>Btw, does one still needs to use .mk4 file in latest versions of make4ht?

You need it only when you want to change default settings, add a 
cimpilation step, like BibTeX, etc. It is not needed in general.
>
>This is the one I have now, I think I got it from you years ago:
>
>------------  new.mk4 -----------------
>filter_settings "dvisvgm_hashes" {
>  options = "-n --exact -c 1.2,1.2"
>}
>if mode == "draft" then
>  Make:htlatex {}
>else
>  Make:htlatex {}
>  Make:htlatex {}
>  Make:htlatex {}
>  Make:htlatex {}
>end
>-----------------------------
>
>And I use it as follows
>
>         make4ht .....  -e  $HOME/new.mk4 ....
>

I think you don't need it. First of all, it compiles your TeX file four 
times, instead of default three times, so it is slower. And as you don't 
use SVG math anymore, you don't really need to configure 
`dvisvgm_hashes` extension.


>So the questions I have are
>1) is the above .mk4 still needed? What difference if I do not use it?
>btw, I do not use svg now for math, I only use mathjax.
>2) if I put in $HOME/texmf/tex/latex/mycfgfolder/new.mk4
>Will make4ht finds it like it will for the .cfg files?
>

I hope I answered your questions :)

Best,
Michal

From puszcza-hackers at gnu.org.ua  Wed Jun 30 13:34:35 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Wed, 30 Jun 2021 13:34:35 +0200
Subject: [tex4ht] [bug #514] tex4ht gives error on code that compiles OK
	with lualatex
In-Reply-To: <20210613-161538.sv189.37910@puszcza.gnu.org.ua>
References: <20210613-054408.sv199.34038@puszcza.gnu.org.ua>
 <20210613-161538.sv189.37910@puszcza.gnu.org.ua>
Message-ID: <20210630-143435.sv189.43108@puszcza.gnu.org.ua>

Update of bug #514 (project tex4ht):

                  Status:                    None => Fixed                  


    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?514>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Wed Jun 30 15:03:35 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Wed, 30 Jun 2021 15:03:35 +0200
Subject: [tex4ht] [bug #478] clash between cleveref and amsthm
In-Reply-To: <20200727-202913.sv189.49232@puszcza.gnu.org.ua>
References: <20200727-013054.sv189.96919@puszcza.gnu.org.ua>
 <20200727-200007.sv118.9220@puszcza.gnu.org.ua>
 <20200727-202913.sv189.49232@puszcza.gnu.org.ua>
Message-ID: <20210630-160335.sv189.72880@puszcza.gnu.org.ua>

Update of bug #478 (project tex4ht):

                  Status:                    None => Fixed                  

    _______________________________________________________

Follow-up Comment #3:

The recent updates to cleveref.4ht and cleveref-hooks.4ht fixed these issues.
There is still one issue, but it is caused by a local macro definition at the
end of the sample file, so it is not possible to fix it from TeX4ht side.

    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?478>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Wed Jun 30 15:09:03 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Wed, 30 Jun 2021 15:09:03 +0200
Subject: [tex4ht] [bug #514] tex4ht gives error on code that compiles OK
	with lualatex
In-Reply-To: <20210630-143435.sv189.43108@puszcza.gnu.org.ua>
References: <20210613-054408.sv199.34038@puszcza.gnu.org.ua>
 <20210613-161538.sv189.37910@puszcza.gnu.org.ua>
 <20210630-143435.sv189.43108@puszcza.gnu.org.ua>
Message-ID: <20210630-160903.sv189.39042@puszcza.gnu.org.ua>

Update of bug #514 (project tex4ht):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?514>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/


From puszcza-hackers at gnu.org.ua  Wed Jun 30 15:09:15 2021
From: puszcza-hackers at gnu.org.ua (Michal Hoftich)
Date: Wed, 30 Jun 2021 15:09:15 +0200
Subject: [tex4ht] [bug #478] clash between cleveref and amsthm
In-Reply-To: <20210630-160335.sv189.72880@puszcza.gnu.org.ua>
References: <20200727-013054.sv189.96919@puszcza.gnu.org.ua>
 <20200727-200007.sv118.9220@puszcza.gnu.org.ua>
 <20200727-202913.sv189.49232@puszcza.gnu.org.ua>
 <20210630-160335.sv189.72880@puszcza.gnu.org.ua>
Message-ID: <20210630-160914.sv189.72385@puszcza.gnu.org.ua>

Update of bug #478 (project tex4ht):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://puszcza.gnu.org.ua/bugs/?478>

_______________________________________________
  Message sent via/by Puszcza
  http://puszcza.gnu.org.ua/