<div dir="ltr"><div class="gmail_extra">On Tue, Mar 22, 2016 at 9:51 PM, Michal Hoftich <span dir="ltr"><<a href="mailto:michal.h21@gmail.com" target="_blank">michal.h21@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":2pp" class="" style="overflow:hidden">Follow-up Comment #1, bug #274 (project tex4ht):<br>
<br>
That thread has lot of flaming potential, which I don't want to fire up :) But<br>
we probably should clarify some misunderstandings about tex4ht.<br></div></blockquote><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:rgb(51,51,51)"><br>It is more of an impractical approach to tex4ht. The \Configure mechanism in tex4ht relies on seeding of configure hooks in the original macros of a given package used in the document. Here the question is who will do the seeding. Eiten had done it extensively for around 400 and odd packages popular during his time. Every day, several packages get updated, newer packages get released, people do use many of these at their will and freedom. Hence, in the absence of *.4ht's that have hooks-seeded functions of newly released/revised packages, it is obvious that tex4ht will break down. I have seen documents that use packages like xstring, breqn, stackengine, tabstackengine, siunitex, acronym, etc at work and we are expected to generate XML out of these documents. Many packages like siunitex, acronym, breqn are now written in expl3 which is another challenge. <br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:rgb(51,51,51)">I would consider tex4ht as a backend. Many packages sadly lack the driver (*.4ht) for this backend. The best people to write this backend are the authors of these packages since others need more time and in-depth knowledge of these packages to write backend drivers.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:rgb(51,51,51)"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:rgb(51,51,51)">This being the reality, personally I have chosen to redefine macros from different packages, in an add-on configuration to be used for XML/HTML generation. I agree that this is not the right way or preferred way, but practically that is the only solution when one is expected to handle hundreds of documents every day with several funny packages and functions profusely used. This way, tex4ht works wonderfully well with minimal effort for me and I am sure, tex4ht is the best engine among all that would generate another markup from TeX documents. <br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:rgb(51,51,51)">In view of the above, I suggest that we would request authors to provide the backend driver of their packages for tex4ht. This is the only practically feasible solution. An example would be hyperref, the primary author of this package (Sebastian Rahtz) wrote text4ht driver also since Sebastian was a big user and admirer of tex4ht.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:rgb(51,51,51)">The tex4ht team might come up with necessary documentation of how to write .4ht for a package that would largely help authors. If each author spends a few more minutes to do their bit, usage of tex4ht will be pleasure then. Since HTML is gaining more popularity/usage owing to support of smart devices and for its re-flowing ability without losing format features to suit the dimensions of device screens (a severe handicap of PDF), authors shall invest a bit more energy to provide tex4ht support which is as essential as the one provided for outputs like PDF. <br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:rgb(51,51,51)">Secondly, the permissive nature of TeX/LaTeX. $a_{\bf n}$ will create the correct output in pdf, but will not generate the right kind of output in MathML which should be like. <br><br> <math><br> <msub><br> <mrow><br> <mi>a</mi><br> </mrow><br> <mrow><br> <mstyle mathvariant="bold"><br> <mi>n</mi><br> </mstyle><br> </mrow><br> </msub><br> </math><br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:rgb(51,51,51)">The user needs to tag math as $a_{\mathbf{n}}$ for perfect MathML output without intervention. Another common example found in documents is $(a ....$), this would be passed by TeX, but not MathML since the closing parenthesis is outside math. Prof William Hammond has been campaigning for profiled LaTeX for several years now, but many users are hardly bothered since they expect other systems to adopt to their non-standard tagging methods. This can only result in a frustrating experience with tex4ht unfortunately.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:rgb(51,51,51)"> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":2pp" class="" style="overflow:hidden">
Regarding bug reports, I've tried to compile LWARP documentation. It needed<br>
some fixes, there was problem with \label commands used inside \caption, it<br>
totally explodes tex4ht. I am not sure whether \caption{caption<br>
text\label{some label}} is legal construct in LaTeX, but it should compile<br>
without errors.<br></div></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:rgb(51,51,51);display:inline">This is legal tagging and works OK for me.<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":2pp" class="" style="overflow:hidden">
There is also missing cleveref support, which I thought I reported last<br>
summer, but apparently didn't. I have some basic cleveref.4ht file, which<br>
works except for links.<br>
<br>
\fbox contents often overflow the border, it is probably just some CSS issue<br>
<br>
SVG's produced by Tikz are often invalid, especially when font formatting<br>
commands are used in diagrams. I personally use Tikz externalization instead<br>
of built-in tex4ht support, it doesn't work correctly in most cases.<br></div></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:rgb(51,51,51);display:inline">Entirely agree with you. Maybe we can provide an extra package for tikz (owing to its extensive usage) to write out tikz picture sources to an external TeX file to make it easier enough to process separately, generate pdf and convert to desired graphic format. The package will also flag the figures automatically in HTML output. All can be done in one go if the user dares to invoke shell-escape.<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":2pp" class="" style="overflow:hidden"><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:rgb(51,51,51)">[...]</div><br>
PS: we really need some more collaborators to write some documentation, more<br>
configurations, automated regression tests etc. or at least some feedback. it<br>
isn't really motivating that there is almost no activity on tex4ht mailing<br>
list and issue tracker, and then you find elsewhere that something doesn't<br>
work, even when it is described how to get it to work in already existing<br>
documentation.</div></blockquote></div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:rgb(51,51,51)">There are thousands of packages in CTAN that are in popular usage. Nobody can write *.4ht for all these packages. Unless we get support from authors, these packages will not be used if the users want HTML output of their documents using tex4ht. Authors of packages might take note that when PDF dies out of the scene, which I hope will happen sooner than we imagine, their packages will not be as useful as they would have expected unless other output formats are supported.<br></div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:x-small;color:rgb(51,51,51)">Best regards</div><br>-- <br><div class="gmail_signature">Radhakrishnan<br><a href="https://maps.google.com/maps?q=River%20Valley,%20Thiruvananthapuram%20Neyyardam%20Road,%20Kerala,%20India&vector=1" target="_blank">River Valley</a><br><br></div>
</div></div>