HTML Output for @table and @multitable

[Mahlon]

20 Nov 2014

RE: HTML output for @table and @multitable

VERSION: makeinfo 5.2 (built from source on Fedora 20 x86_64)

/I sincerely apologize for monopolizing your time.
Only one more to report after this one, I promise (but it's a big one)./


BUG:

Without the application of CSS style, the HTML output for both @table 
and @multitable could be considered unacceptable for two reasons:


1) the formatting of the HTML output is rather embarrassing, and

2) it doesn't much resemble the 'info' output, neither in line spacing 
nor in column spacing


Both of these issues can be corrected with CSS style alone, but you 
might consider what could be done inside the texi-to-HTML converter.


For the CSS, see our definitionsof the HTML  and  elements in 
'infodoc-styles.css'.

Included in the attachment:

[2014_11_20]$ tar -tvf bug_report_2014_11_20.tar.bz2

-rw-r--r-- Mulan/Mulan 6555 2014-11-20 12:52 bug_report.texi

-rw-rw-r-- Mulan/Mulan 5657 2014-11-20 12:55 bug_report.info

-rw-rw-r-- Mulan/Mulan 12293 2014-11-20 12:55 bug_report.html

-rw-rw-r-- Mulan/Mulan 10782 2014-11-20 13:00 bug_report_css.html

-rw-rw-r-- Mulan/Mulan 29510 2014-11-20 13:03 infodoc-styles.css

-rw-r--r-- Mulan/Mulan 214 2014-11-20 12:55 Makefile



Mahlon



--

Software Sam - software and tools for GNU/Linux

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




bug_report_2014_11_20.tar.bz2
Description: application/bzip

HTML output for @quotation + @author

[Mahlon]

20 Nov 2014

RE: HTML output for @quotation + @author commands

VERSION: makeinfo 5.2 (built from source on Fedora 20 x86_64)

BUG:

There are two issues for the HTML output when using the @author command 
within a @quotation:


1) A blank line is generated between the quotation itself and the 
author's name. This extra line is not present in the info output.


2) The author's name (and the emdash) are centered on the page. This 
mirrors the info output, but the author's name looks isolated (lonely?) 
in the HTML output, especially for a short quotation, because the name 
may be considerably beyond the quotation itself.


For the following source:

@quotation

"A penny saved is a penny earned."

@author Benjamin Franklin

@end quotation


currently, the HTML looks like this:



"A penny saved is a penny earned."



— Benjamin Franklin





Logically, the 'author' output should be _inside_ the , 
thus eliminating the extra blank line _and_ beautifying the horizontal 
alignment. For example:




"A penny saved is a penny earned."

— Benjamin Franklin




Note that the '3.2em' indentation is used in the above example because 
it agrees with all the other indentations generated by the texi-to-HTML 
converter. Note also that depending on where the last line of the 
word-wrrapped quotation naturally ends, the  _might_ generate an 
extra blank line anyway, but I don't think we can do anything about that...



Cheers,
Mahlon



--

Software Sam - software and tools for GNU/Linux

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

Re: real subscripts and superscripts?

[Karl Berry]

Maybe I would favor using x^{2}y in textual context too, since there is
no good solution, and it is simpler to implement and explain ...

Ok by me.  Doing the simple way (always add braces) first seems
reasonable; if it turns out that the feature gets used enough and people
really don't like it, the output can always be tweaked later.

I can add these to texinfo.tex and texinfo.texi, etc., easily enough.
Do you have time to add it to makeinfo?

Thanks,
Karl

Re: texinfo documentation? bug

[Karl Berry]

Agreed, I'll make a change along these lines.  Thanks.

k

Re: 'raggedright' command in HTML output

[Patrice Dumas]

On Wed, Nov 19, 2014 at 07:05:58PM +, Gavin Smith wrote:
> On Mon, Nov 17, 2014 at 3:42 AM, Mahlon  wrote:
> > According to the documentation, the @raggedright command does not apply to
> > info and HTML output, obviously because the command applies only to output
> > formats that can produce 'justified' text. The 'info' output correctly
> > processes the paragraph as ordinary paragraph text. Note however, that for
> > some reason, the HTML converter produces no output for the paragraph.
> 
> The patch below appears to fix it, although I don't understand
> everything that is going on and if there are other changes that need
> to be made as well. At line 7289 this will make the condition be true
> because it will have been initialized at line 4609 (revision 5923).
> 
> Index: tp/Texinfo/Convert/HTML.pm
> ===
> --- tp/Texinfo/Convert/HTML.pm  (revision 5923)
> +++ tp/Texinfo/Convert/HTML.pm  (working copy)
> @@ -2482,6 +2482,7 @@
>return $content;
>  }
> 
> +$default_commands_conversion{'raggedright'} = \&_convert_command_noop;
>  $default_commands_conversion{'flushleft'} = \&_convert_command_noop;
>  $default_commands_conversion{'flushright'} = \&_convert_command_noop;
>  $default_commands_conversion{'group'} = \&_convert_command_noop;

That looks good.  The only thing that come to my mind is that, sometime
it may be better to use categories of @-commands defined in
Texinfo/Common.pm, but in that case, the raggedright is in the
"align_command" hash, but center is there too, so I think your patch is
best.

In the HTML converter, all the @-commands are associated with function
references to make them configurable.

Also, please check that the test work correctly before commiting, and if
not regenerate them.

-- 
Pat

Re: texinfo documentation? bug

[Gavin Smith]

On Sun, Nov 16, 2014 at 11:40 PM, Karl Berry  wrote:
> I know it seems weird, but otherwise there is no explanation for the
> example as a whole being indented.  I don't remember, but I may have
> added the aside precisely because someone wondered about that (or maybe
> it was there all along, I dunno).  Anyway, I don't see a good way to
> write the example without it, because the whole point is to show how to
> not-indent a first line after an @example and the example as a whole
> wouldn't come out right without being set off somehow.  I suppose I
> could add ", thus this example's indentation as a whole" to the aside
> but I suspect that would just make things worse.  Do you see a good
> revision to make?

I see what you mean, so it needs to explain why the example is
indented despite the presence of @noindent. Although "@display" and
"@end display" don't actually appear in the example you might imagine
that they are if you are not thinking too clearly. It depends how you
interpret "This whole example is between" - whether the things it is
between are part of the example, or outside of the example.

It might be better not to include the explanation itself within the
indented example, but put it after. Something like the following,
maybe with less clumsy wording:

Index: texinfo.texi
===
--- texinfo.texi(revision 5923)
+++ texinfo.texi(working copy)
@@ -8990,8 +8990,7 @@
 @@noindent
 This line is not indented.  As you can see, the
 beginning of the line is fully flush left with the line
-that follows after it.  (This whole example is between
-@@code@{display@} and @@code@{end display@}.)
+that follows after it.
 @end group
 @end example

@@ -9006,11 +9005,14 @@
 @noindent
 This line is not indented.  As you can see, the
 beginning of the line is fully flush left with the line
-that follows after it.  (This whole example is between
-@code{@@display} and @code{@@end display}.)
+that follows after it.

 @end display

+@noindent
+(The example above is indented as a whole in this manual to mark it as
+an example.)
+
 To adjust the number of blank lines properly in the Info file output,
 remember that the line containing @code{@@noindent} does not generate a
 blank line, and neither does the @code{@@end example} line.

Re: 'raggedright' command in HTML output

[Gavin Smith]

On Mon, Nov 17, 2014 at 3:42 AM, Mahlon  wrote:
> According to the documentation, the @raggedright command does not apply to
> info and HTML output, obviously because the command applies only to output
> formats that can produce 'justified' text. The 'info' output correctly
> processes the paragraph as ordinary paragraph text. Note however, that for
> some reason, the HTML converter produces no output for the paragraph.

The patch below appears to fix it, although I don't understand
everything that is going on and if there are other changes that need
to be made as well. At line 7289 this will make the condition be true
because it will have been initialized at line 4609 (revision 5923).

Index: tp/Texinfo/Convert/HTML.pm
===
--- tp/Texinfo/Convert/HTML.pm  (revision 5923)
+++ tp/Texinfo/Convert/HTML.pm  (working copy)
@@ -2482,6 +2482,7 @@
   return $content;
 }

+$default_commands_conversion{'raggedright'} = \&_convert_command_noop;
 $default_commands_conversion{'flushleft'} = \&_convert_command_noop;
 $default_commands_conversion{'flushright'} = \&_convert_command_noop;
 $default_commands_conversion{'group'} = \&_convert_command_noop;