texi2html-bug
[Top][All Lists]
Advanced

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

Re: [Texi2html-bug] Some more questions about texi2html


From: Patrice Dumas
Subject: Re: [Texi2html-bug] Some more questions about texi2html
Date: Wed, 19 Mar 2008 11:15:59 +0100
User-agent: Mutt/1.5.17 (2007-11-01)

On Wed, Mar 19, 2008 at 12:40:55AM +0100, Reinhold Kainhofer wrote:
> Hi Patrice,
> I hope this is the right mailing list for such questions. If not, please tell 
> me where to send such questions...

It is the right place.

> I'm currently trying to make lilypond's documentation build entirely with 
> texi2html so that we can finally switch from makeinfo to texi2html. 
> My current attempts are at:
>     http://kainhofer.com/~lilypond/texi2html-out/
> The init file used for this output (containing some really nasty hacks...) is:
>    http://kainhofer.com/~lilypond/texi2html-out/lilypond-texi2html.init

Very nice. As a side note, the init file should be interpreted in the
Texi2HTML::Config namespace, so you should not need to namespace your
variables. It doesn't hurt, though.

> -) I modified the navigation buttons to cover two table rows (using some 
> nasty 
> hacks in the init file). However, since we are splitting by numbered sections 
> (i.e. unnumbered subsections are put into the same file, thanks to the 
> element_file_name you gave back in October), I'd like to have the chapter 
> navigation ('FastBack', 'FastForward', 'Top',  etc.) line only in the very 
> first navigation panel, but not in the panels beween subsections. See e.g.
> http://kainhofer.com/~lilypond/texi2html-out/Writing-pitches.html#Relative-octave-entry

Ok. This is certainly doable. To be sure that I get it, in the
  Absolute octave entry 
header you only want
[ < Writing pitches ]   [ Up: Writing pitches ] [ Relative octave entry > ]

Looks possible or even easy. Something along defining another set of
buttons and in print_element_header calling print_navigation with these
buttons instead of address@hidden This could even make sense to do
it in the default case (but with th esame arrays in the default case).
Indeed wanting to have different buttons for the page head and foot and
for elements within a page makes sense.


Could you please send or post an archive containing the lilypond .texi
files and the init file, and also tell me how you invoke texi2html?

> -) We want our translated files to have the same chapter/section file names 
> (and IDs) as the english version. Currently (i.e. with makeinfo), we have to 
> leave all section names untranslated and later on use a python script to 
> replace the HTML tags with the proper translations. Of course, we'd like to 
> get rid of this had with texi2html. We thought about something like

This is not easy to do that, since the node to ID is defined at the 
texinfo level. And everything that is texinfo is done without much 
control from the user during the first 2 passes. And the file names 
are determined between the second and the third pass, and so there is no
hook for the user to have some perl code run when a macro, like
@translationof is encountered. It can be done easily in the third pass,
when output is generated, but it is too late, in this case.

Looking at the code, it looks like it would be trivial to do the same
than in the third pass during the second pass. And it even makes sense
because if you add a macro you want to treat especially you may want to do
it in both passes.

> @node Übung
> @chapter Übung
> @translationof Tutorial
> texi2html would use @nodetranslation for HTML file names and anchors,
> and @node for printing it text.
> Apparently, in the the element_file_name I don't have access to the contents 
> of the current element. How can I do this?
> Even better would be, of course, if we could write the @translationof macro 
> so 
> that it sets the translationof key of the $element hash that is passed to 
> element_file_name.

This should be possible once there is a hook in the second pass. This
will certainly require messing with the texi2html internals, but this is
not a real issue.

> -) Does texi2html have any support for access keys, i.e. navigating the pages 
> with the keyboard (Alt-U for up, Alt-P for previous, Alt-1 for first menu 
> entry and so on)? The HTML code looks like
> 
> <a rel="next" accesskey="n" 
> href="Musical-notation.html#Musical-notation">Musical notation</a>
> 
> <a accesskey="1" href="Musical-notation.html#Musical-notation">Musical 
> notation</a>

That is something that would be nice, I even would like to have it in the
standard html output (conditonal on a variable being set). I'll have a 
look at it on the week end.
 
> -) Is there any way to get a customized TOC? In particular, the TOC in the 
> left "frame" (it's actually a <div> with absolution positioning) is way too 
> long, while the overview with only the top-level sections is way too short. 
> Idially, each page would get a TOC with the first two levels expanded, plus 
> the whole path to the current page expanded.

This is possible, but you have to do it more or less yourself. You can
have a look at examples/book.init where something similar (though not
exactly the same) is done. The code for the body of the table of
contents is not in texi2html.init, but in texi2html.pl, because I
excerpted it from an older code, and so is GPL, contrary to what is in
texi2html.init which is public domain. The function is called
T2H_GPL_toc_body. But I guess that looking a book.init would be a better
starting point (book.init is also public domain).

> Also, I would like to add a class="current_toc_page" to the <li> for the 
> current page. Is this possible somehow?

Only if you do your toc body yourself. But it shouldn't be hard.

> -) Not that we need it in our documentation, but still something that I 
> noticed: AFAICS, the files names ($docu_toc_frame_file and $docu_frame_file) 
> for the frame pages are hardcoded and cannot be adjusted with 
> element_file_name, right?

This is just because the frame stuff is more or less abandonned. But it
would be much better, sure, I'll certainly fix it over the week end.

> Cheers,
> Reinhold
> 
> PS: The fact that we can deal with such questions shows how awesome texi2html 
> is! it is really a pleasure and so easy to work with it! Thanks for it!

Thanks.

--
Pat




reply via email to

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