[tex4ht] [bug #274] tex4ht features vs. lwarp vs. ...

[Radhakrishnan CV]

On Tue, Mar 22, 2016 at 9:51 PM, Michal Hoftich <michal.h21 at gmail.com>
wrote:

> Follow-up Comment #1, bug #274 (project tex4ht):
>
> That thread has lot of flaming potential, which I don't want to fire up :)
> But
> we probably should clarify some misunderstandings about tex4ht.
>
​
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.

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.

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.

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.

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.

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.

      <math>
        <msub>
          <mrow>
            <mi>a</mi>
          </mrow>
          <mrow>
            <mstyle mathvariant="bold">
              <mi>n</mi>
            </mstyle>
          </mrow>
        </msub>
      </math>

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.


> Regarding bug reports, I've tried to compile LWARP documentation. It needed
> some fixes, there was problem with \label commands used inside \caption, it
> totally explodes tex4ht. I am not sure whether \caption{caption
> text\label{some label}} is legal construct in LaTeX, but it should compile
> without errors.
>

​This is legal tagging and works OK for me.
​


> There is also missing cleveref support, which I thought I reported last
> summer, but apparently didn't. I have some basic cleveref.4ht file, which
> works except for links.
>
> \fbox contents often overflow the border, it is probably just some CSS
> issue
>
> SVG's produced by Tikz are often invalid, especially when font formatting
> commands are used in diagrams. I personally use Tikz externalization
> instead
> of built-in tex4ht support, it doesn't work correctly in most cases.
>

​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.
​


> ​[...]​
>
> PS: we really need some more collaborators to write some documentation,
> more
> configurations, automated regression tests etc. or at least some feedback.
> it
> isn't really motivating that there is almost no activity on tex4ht mailing
> list and issue tracker, and then you find elsewhere that something doesn't
> work, even when it is described how to get it to work in already existing
> documentation.
>

​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.

​Best regards​

-- 
Radhakrishnan
River Valley
<https://maps.google.com/maps?q=River%20Valley,%20Thiruvananthapuram%20Neyyardam%20Road,%20Kerala,%20India&vector=1>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/tex4ht/attachments/20160326/536c026b/attachment-0001.html>