[l2h] table generation problems

Wed, 4 Aug 1999 07:19:24 -0700 

Using the latest development latex2html I get several problems:

a) Tables (made with tabularx) look _bad_

source:

\newcolumntype{Y}{>{\small\raggedright\arraybackslash}X}

\begin{table}[hbtp]
\begin{tabularx}{\linewidth}{|Y|Y|}
\hline
Absolutely insecure & MD2, MD4, SHA \\ \hline Insecure & MD5 \\ \hline
Secure & SHA-1, RIPEMD-160 \\ \hline
\end{tabularx}
\caption{Hash function security}\label{hashes}
\end{table}

Looks like img35.png (attached).

b) My table footnotes look _bad_

source:

\begin{table}[hbtp]
\begin{minipage}{\linewidth}
  \renewcommand{\thefootnote}{\thempfootnote}
\begin{tabularx}{\linewidth}{|Y||Y|Y|Y|Y|}
\hline
 & Symmetric & Asymmetric (RSA modulus) & Asymmetric (Elliptic curve)
& DSA\footnote{modulus size / size of a large subgroup} \\ \hline
\hline Export Grade\footnote{very weak security, do not use} & 40 &
512 & 80 & 512 / 80 \\ \hline Personal Grade\footnote{weak security,
for information that is not very important} & 56 - 64 & 768 & 136 &
768 / 136 \\ \hline Commercial Grade\footnote{considered secure for
valuable but not very sensitive information} & 128 & 1024 & 160 & 1024
/ 160 \\ \hline Military Grade\footnote{sensitive information,
probably secure for at least the next several years unless an
algorithm has a major flaw} & 160 & 2048 & 200 & 2048 / 200 \\ \hline
\end{tabularx}
\caption{Approximately equally secure key lengths in bits for different types
of algorithms (from
\cite{rsa-faq}}\label{cipher-str} 
\end{minipage}
\end{table}



result (img39.png attached, footnode attached)):

<DIV ALIGN="CENTER"><A NAME="cipher-str"></A><A NAME="1328"></A>
<TABLE>
<CAPTION><STRONG>Table 4:</STRONG>
Approximately equally secure key lengths in bits for different types
of algorithms (from
[<A
 HREF="node94.html#rsa-faq">77</A>]</CAPTION>
<TR><TD><IMG
 WIDTH="845" HEIGHT="117" BORDER="0"
 SRC="img39.png"
 ALT="\begin{table}
% latex2html id marker 1282\begin{minipage}{\linewidth}
\renewe...
... 160 &amp; 2048 &amp; 200 &amp; 2048 / 200 \\ \hline
\end{tabularx}\end{minipage}\end{table}"> <A NAME="tex2html27"
 HREF="footnode.html#foot1290"><SUP>0</SUP></A> <A NAME="tex2html28"
 HREF="footnode.html#foot1291"><SUP>0</SUP></A> <A NAME="tex2html29"
 HREF="footnode.html#foot1292"><SUP>0</SUP></A> <A NAME="tex2html30"
 HREF="footnode.html#foot1293"><SUP>0</SUP></A> <A NAME="tex2html31"
 HREF="footnode.html#foot1294"><SUP>0</SUP></A></TD></TR>
</TABLE>
</DIV><P></P>



c) Footnode looks weird:

DT><A NAME="foot2999">...<IMG
 WIDTH="43" HEIGHT="32" ALIGN="MIDDLE" BORDER="0"
 SRC="img100.png"
 ALT="$ Type$"></A><A NAME="foot2999"
 HREF="node81.html#tex2html37"><SUP>0</SUP></A>
<DD>see section <A HREF="node87.html#client-auth">5.5.8</A> for a generic
description of the client authentication exchanges
<PRE>.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
</PRE>
</DL>

(see attached).


Warnings encountered on the run over the whole document:

*********** WARNINGS ***********  
No implementation found for style `german'
No implementation found for style `vmargin'
No implementation found for style `fancyhdr'

redefining command \paragraph 

redefining command \thefootnote 

counter mpfootnote not defined
No support found for 1 language

counter footnote<<197>>"
 HREF="footnode.html#fnm\value<<197>>footnote not defined

Unknown commands: a lfoot rhead let fancyplain footnoterule leftmark rightmark n
ewcolumntype rfoot arraybackslash cfoot lhead cleardoublepage setpapersize
Done.
Title: Footnotes
... developed0
IPSec, TLS (formerly SSL), SSH, PGP, DNSSec, SNMPv3 ... 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... worden0 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... developed0
IPSec, TLS (formerly SSL), SSH, PGP, DNSSec, SNMPv3 ... 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...$ anycast$0
IPv6 only 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...$ broadcast$0
IPv4 only 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...$ multicast$0
Multicast over IPSec is not yet standardized, some unsolved problems remain (see section 3.10) 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...$ addresses$0
high and low values inclusive 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...$ protocol$0
from IPv4 ``Protocol'' or IPv6 ``Next Header'' fields 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... Photuris0
Photuris is an alternative Key Management Protocol. ISAKMP/IKE copied some of its features 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...$ Yes$0
there is a 1 packet window for replay each time the counter cylces, see section 2.3 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...$ (TCP)$0
Due to the way FTP opens data connections tunneling FTP does not work, but SSH offers its own file transfer service 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...$ NAT$0
see section 3.11 for some restrictions on NAT with all protocols discussed here 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...$ Proxies$0
Here Yes means a Proxy can control the information flowing through, No means a Proxy cannot do that and would have to let unknown information pass 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... $ Non-Repudiability$0
depends on authentication method selected, see section 3.7 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... unprotected0
This means IPSec data cannot be passed through application layer proxy applications in encrypted form, it never even reaches the transport layer in encrypted form. 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... hosts0
According to the Birthday Problem, see section 3.11.2 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...$ DSA$0
modulus size / size of a large subgroup 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...$ Grade$0
very weak security, do not use 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...$ Grade$0
weak security, for information that is not very important 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...$ Grade$0
considered secure for valuable but not very sensitive information 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...$ Grade$0
sensitive information, probably secure for at least the next several years unless an algorithm has a major flaw 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... times0
usually using encryptDES-decryptDES-encryptDES and either using two keys (the same key for both encryption runs) or three keys 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...$ Section$0
Section describing the handshake message exchange for this cipher suite 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...$ Type$0
see section 5.5.8 for a generic description of the client authentication exchanges 
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

img35.png

img39.png

Reply via email to