3 Practical Problems

3.1 Issues with hyperref and html

The biggest problem here is that hyperref destroys L^ATEX2HTML's ability to generate (links to) section numbers and equation numbers etc. Unfortunately this seems to be due to the way auxilliary files are written, and is not solved by using conditional input (e.g. latexonly type constructions).

The only simple way to get around the problem is

• Not to use any of the commands in the hyperref package in the L^ATEX source. (Actually this is a bonus as many of them don't work with L^ATEX2HTML anyway);
• Running L^ATEX twice and then DVIPDFM;
• Commenting out the \usepackage{hyperref};
• Running L^ATEX twice again and then L^ATEX2HTML.

In an ideal world, one would not have to touch the source file; but in the scheme of things, commenting out one line and rerunning L^ATEX is really only a minor inconvenience.

A number of other minor bugs / peculiarities with these packages are described in the sequel.

3.2 Issues with graphics

Dealing with graphics in a simple way is, unfortunately, much harder.

The overall approach is governed by the fact that DVIPDFM can work with JPEG, PNG and EPS (encapsulated postscript) graphics, i.e. it can pick up graphics in these formats and include them in the final PDF document automatically. I have not really explored the PNG route, which leaves the JPEG and EPS routes, in each of which one runs into difficulties.

EPS Method

This method is described in detail in Appendix A. The main advantage of the method is that L^ATEX and related programs are good at graphics in EPS format:

• L^ATEX will pick them up and use them without even having to specify a bounding box;
• L^ATEX2HTML (with NETPBM) translates them into GIF format automatically -- and the translation sometimes even works (!);
• DVIPDFM and viewers like YAP will also use them;
• They work in L^ATEX2HTML and DVIPDFM (and YAP) by a simple \includegraphics command; there is no need for any conditional input (e.g. htmlonly type constructions).

The main disadvantages are:

• Nothing in Windows really likes EPS format -- one can do a `save as' in most formats but rarely to EPS. For example, the graphics in this document were created with Microsoft Powerpoint, which has no `save as EPS' option.
• As a workaround (described in Appendix A), one can install a dummy postscript printer, and do a `save as' by printing to a file.
• This works well... until the bugs appear. There is either some kind of EPS version conflict both with NETPBM and with DVIPDFM, and / or some general problem with EPS graphics thinking they are in portrait mode when they are in fact in landscape. (To be fair to DVIPDFM, its manual does claim to have only basic postscript support.) The problems are that:
  • NETPBM leaves horrible weird borders around the GIFs;
  • DVIPDFM does strange unpredictable truncations of the images.
• As a workaround one can use postscript graphics and send them through the ghostscript viewer, converting them in effect from PS to EPS. One then seems to get a file that both NETPBM and DVIPDFM like.

For those who need to use EPS graphics (the quality can be somewhat better), the method is set out in Appendix A. However, I personally find that the JPEG method described next is a lot more efficient.

JPEG Method

In this method one starts with a single set of JPEG graphics. DVIPDFM incorporates them automatically, and we tell L^ATEX2HTML to use the JPEG without converting it. The main advantages of this method are:

• JPEG graphics are easily created from most Windows / graphicy programs.
• JPEGs are also easy to manipulate in Windows. For example, shareware programs like IrfanView are good at things like compressing them and altering their size.)
• There really is only one set of graphics files. (With the EPS method, one ends up with two lots of EPS files and one lot of GIFs -- although only the GIFs have to be uploaded to the web.)
• It bypasses L^ATEX2HTML's graphics conversion process, which is slow and fraught.

There are some disadvantages to this method, but they are not too bad:

• One needs to use conditional code, as the \includegraphics command always seems to cause L^ATEX2HTML to try to convert the graphics format. (This is one of the great annoyances of L^ATEX2HTML. It will even try to convert GIFs to GIFs given half a chance. Unfortunately, the developers seem to consider the minor enhancement of being a bit more sensible about this as not worthwhile because it `adds no new functionality'.) To cut a long story short, one needs an \htmladdimg for the HTML version, and an \includegraphics for the DVI/PDF version -- but this is very easily achieved via a macro.
• One needs to supply a `bounding box' for each of the JPEGs so that L^ATEX can understand how much space to give them -- but this is very easily achieved with a program called EBB that comes with DVIPDFM.
• It seems to be impossible to set up YAP to preview the JPEGs; YAP and the DVIPDFM package seem to be fundamentally incompatible (and YAP is not very good at JPEGs anyway.) Note that this is not too much of a restriction: with the bounding box information, the missing graphics are allocated the right amount of space so that the pagination is unaffected; and running DVIPDFM quickly produces the full PDF version for previewing.

In short, the JPEG route is the one that will be considered in the main body of the text.

© Charles Clayton 2000. Please use this information at your own risk.