Fri May 7 20:49:24 2021, 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/"
|
Fri May 7 15:49:58 2021, comment #14:
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.
|
Thu May 6 15:36:16 2021, comment #13:
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.
|
Wed May 5 10:24:48 2021, comment #12:
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.
|
Tue May 4 14:02:18 2021, comment #11:
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)
|
Tue May 4 12:52:49 2021, comment #10:
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!
|
Wed Apr 28 14:07:09 2021, comment #9:
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}
|
Wed Apr 28 12:13:15 2021, comment #8:
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.
|
Wed Apr 28 08:14:38 2021, comment #7:
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.
|
Tue Apr 27 22:20:14 2021, comment #6:
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).
|
Tue Apr 27 22:11:15 2021, comment #5:
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.
|
Tue Apr 27 21:57:55 2021, comment #4:
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+"
|
Tue Apr 27 21:22:57 2021, comment #3:
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?
|
Tue Apr 27 21:19:06 2021, comment #2:
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!
|
Tue Apr 27 21:04:37 2021, comment #1:
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.
|
Tue Apr 27 20:27:51 2021, original submission:
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
|