bug-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problematic indentation in HTML output of makeinfo


From: Thomas Keller
Subject: Re: Problematic indentation in HTML output of makeinfo
Date: Sun, 22 Nov 2009 23:54:29 +0100
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4

Am 22.11.09 23:40, schrieb Patrice Dumas:
> On Sun, Nov 22, 2009 at 11:20:38PM +0100, Thomas Keller wrote:
>>>
>>> The issue is that it doesn't allow for imbrication of 'preformatted' styles.
>>> For example
>>>
>>> @example
>>>
>>> The example
>>>
>>> @display 
>>> this part is displayed
>>> @end display
>>>
>>> End of the example
>>>
>>> @end example
>>
>> Its not clear to me what you mean by "imbrication" - makeinfo creates
>> the following HTML for that:
>>
>> <pre class="example">
>>      The example
>>      <pre class="display">          this part is displayed
>> </pre>
>>
>>      <p>End of the example
>>
>> </pre>
> 
> This is invalid html. Many html elements cannot be in pre.

I see, my reference basically only lists inline elements, but also weird
stuff like iframe.

> That's
> why in texi2html, I distinguish the complex format and each 'preformatted
> elements' that are in the format, delimited by imbricated format begin 
> and end. So the above would be (if there was no table), in texi2html along
> 
> <pre class="example">
> The example
> </pre><pre class="display">this part is displayed
> </pre>
> <pre  class="example"> 
> End of the example
> </pre>
> 
> There is one 'preformatted' in the display, with content
> this part is displayed
> 
> and 2 preformatted in the @example, one with content
> 
> The example
> 
> the other with content
> 
> End of the example

As you already said in your other mail, if there are restrictions in the
output target (in this case HTML) wrt element nesting which is allowed
in texinfo, the usage of <pre> should probably just be replaced by some
block element like <div> with preformatted font to keep the HTML valid.

>> If I remove the unwanted whitespace from this example, then you're
>> right, all contents are shifted to the left by default - but hey, thats
>> why we have CSS, right? Putting
>>
>> pre { margin-left: 3.2em; }
>>
>> in the style definition gives us back the original 5 whitespace
>> indentation between the inner and the outer preformatted area.
> 
> Indeed, but there should be 10 whitespace when in the @display.

Yes, sorry, I only counted the five additional ones between @example and
@display, but you're right, both margins add up to a total of 10
whitespaces.

>>> Also other kind of nesting wouldn't be that good if the indentation was done
>>> for each preformatted fragment. For example for a @multitable in @example,
>>> I think that it is better to indent the whole @example and not the 
>>> individual preformatted fragments in the @multitable. To be honest, this is
>>> not clear that this is correct texinfo, but such constructs happen in 
>>> manuals.
>>
>> Can you give me a specific example?
> 
> Something like (a real life example is in the lilypond manual).
> 
> @example
> @multitable @columnfractions .5 .5
> @headitem foo @tab bar
> @item foofoo @tab barbar
> @end multitable
> @end example
> 
> In that case, each cell is in a 'preformatted', and I think that it is 
> better to have the multitable indented, but not each multitable cell.

I see, the output of makeinfo is rather messy here as well (especially
since it wraps the whole table again in an unclosed <p> paragraph).

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]