HTML Output for @table and @multitable and misc.

[Mahlon]

Pat,

On the issue of separating the header line from the table contents, I agree that it is a minor issue. Inside a <table> sequence, the header <th> is bold by default, so it is visually distinct from the non-bold <tl> line items.

The issue of compressed whitespace is a problem without the CSS. For example, (I'll show this in monospace for clarity). What aligns nicely in the info output:

State         Capital        Flower

---------------------------------------------

Georgia       Atlanta        Azalea

California    Sacramento     California Poppy

Delaware      Dover          Peach blossom

Looks like this in unstyled HTML:

State         Capital        Flower

Georgia    Atlanta    Azalea

California Sacramento California Poppy

Delaware   Dover      Peach blossom

Note that the whitespace in the header is retained, while the whitespace in the line items is compressed, which causes vertical misalignment. This is where the post-processing comes into play.

Normally, @sp 1 becomes one <br>, so it should appear?

You're right, that is my mistake.

I don't get it. Why is there always an extra line in the <dl> sequence?

And why never in the <table> sequence? We use rather simple HTML markup

as intended, maybe with some styling, but, in most case it is just plain

HTML markup.

For the @table command, this is just a regrettable issue with the default definition of the <dl> sequence not matching the info output. Again, it can be solved using CSS, so it's nothing to worry about. It's just that casual users of the HTML won't know enough CSS to fix it, so if you have no objection to recommending my CSS definitions, it could save a lot of weekend warriors from styling headaches. For the @multitable, line spacing isn't much of an issue because the default looks pretty good although a bit different from the info output.

In any case, there is something that is certainly sub-optimal, it is the

@itemize with anything else than @bullet, as we remove the bullet from

<li> and then add a symbol in the text. I have no idea how to do

something better, though, opinions welcome.

Finally, the issues with @itemize bullets and @enumerate types other that 1, 2, 3... are a problem I'm still working on.

I'm experimenting with a post-processor that will scan for the embedded bullets that follow the <ul class=“no-bullet”>. I'll let you know if I get any lightbulbs on that one.

Because @enumerate uses only the default <ol> ... </ol> sequence, any enumeration types specified in the texi source are ignored. I think it's important to directly support at least the following in the converter:

@enumerate (default <ol> is ok)

@enumerate 1 (default <ol> is ok)

@enumerate A ( <ol style=“list-style-type:upper-alpha;”> )

@enumerate a ( <ol style=“list-style-type:lower-alpha;”> )

Note that <ul type=...> and <ol type=...> are deprecated constructs in HTML4 and are no longer supported in HTML5, although browsers may continue to support them.

To sum up, if you want to recommend my CSS style file, it should minimize problems for many HTML documenters, and we can consider the other issues for the next major release.

Because I'm a teacher, I get a month off in January, so please let me know if I can help with anything. :-)

Mahlon

On 11/23/2014 07:20 AM, Patrice Dumas wrote:

Hello,

A disclaimer, I don't know CSS at all, so I may be misunderstanding many
issues.


On Sun, Nov 23, 2014 at 06:51:41AM +0800, Mahlon wrote:

Hi Gavin,

I agree that the HTML is straightforward, but here are my specific concerns.

1) In the info output, there is an 'underline' after the header
line, but no underline in HTML.

That's not really an issue.  In Info there is no possibility of bold nor
change in font size, so the underline is the only way to mark a header,
but in HTML and TeX, there are other ways, in my opinion better ways to
mark a header.  The formatting need not be exactly the same, what is
important is that reader connect the 2 formatting, and do not see
different logical organization when looking at HTML, Info or pdf output.

2) HTML compresses whitespace, so line-item columns appear much
closer together than in the info output. Unfortunately it is _only_
the line items that are compressed. The header line retains the
original spacing which throws off the column alignment between
header and line items.

I don't get it at all...

3) Spacing between lines specified in the source does not carry over
to the HTML, even if we insert a '@sp 1' into the source. 

Normally, @sp 1 becomes one <br>, so it should appear?

Some
tables in the source will specify line spacing and some will not. In
the HTML, there is _always_an extra line in the <dl> sequence and
_never_an extra line in the <table> sequence. Unfortunately, a
post-processor has no way of knowing what the source intended
because there is no clue in the HTML output.

I don't get it.  Why is there always an extra line in the <dl> sequence?
And why never in the <table> sequence?  We use rather simple HTML markup 
as intended, maybe with some styling, but, in most case it is just plain
HTML markup.

All of this (except the clairvoyance) is cleanly handled by the
provided CSS, and perhaps it's too much work to handle it with
generated definitions. Still, someone may eventually get a brilliant
idea about how to generate tables that don't need post-processing.

Post-processing for what?


In any case, there is something that is certainly sub-optimal, it is the
@itemize with anything else than @bullet, as we remove the bullet from
<li> and then add a symbol in the text.  I have no idea how to do
something better, though, opinions welcome.

--

Software Sam - software and tools for GNU/Linux

Mahlon Smith,
The Software Samurai
On the Web: http://www.SoftwareSam.us/