[PlanetCCRMA] Any Spanish-speaking Planet CCRMA users out
there?
Andrew Wilson
djazz@myrealbox.com
Wed Oct 6 18:50:02 2004
--=-9GkysoBZcsoXYURjaV9b
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
I have been doing some more digging around on this issue trying to come
up with a meaningful suggestion. As far as I can tell:
- Work on the various latex to html translators seems to be gradually
coming to a stop, if they haven't stopped already. None of them really
do the whole job. (tex4ht -
http://www.cse.ohio-state.edu/~gurari/TeX4ht/mn.html seems to be another
possibility, however it also does a fairly ordinary job of the
conversion).
This may be because the docbook to html translators are becoming quite
mature and so easy (well "easy" if you know xslt) to enhance.
- While docbook and other have the ability to embed multiple languages
and then select the output based on a formatting parameter, in practice
people don't seem do it. They tend to leave each language in a separate
include files, one section/subsection per file with a common naming
convention, and then just include the appropriate files into the overall
document to build the final output. This has a couple of advantages:
makes parallel working easier, can build the dependencies into a CVS
structure etc.
IMHO I would encourage the "if it ain't broke" don't fix it approach.
So stay in latex (it works) and break it all out into separate files (I
would be surprised if it wasn't structured that way already). Set up a
CVS for the documentation and manage it that way.
Cheers,
Andrew
On Tue, 2004-10-05 at 02:08, Fernando Pablo Lopez-Lezcano wrote:
> On Thu, 2004-09-30 at 11:27, Fernando Pablo Lopez-Lezcano wrote:
> > On Wed, 2004-09-29 at 18:35, Andrew Wilson wrote:
> > > Just some comments from the sidelines. I think the "official" linux
> > > way of approaching this problem is to use docbook for all the
> > > documentation. This already has multi-language support and easily
> > > generates output for html, pdf or whatever you want.
>
> I have been reading up more on docbook. As far as I understand the
> multi-language support is restricted to character sets and all that
> stuff. I could not find anything pertinent to maintaining multiple
> translations simultaneously and/or flagging of translated / untranslated
> / obsolete sections. Let me know if you know this to be a possibility.
>
> > > The layout of
> > > the existing planet documentation is uite straight forward and
> > > wouldn't be that difficult to convert. The files are still text and
> > > this would then open up access to all the various docbook tools out
> > > there for indexing etc. (Fernando: I you want to go this way, I'd
> > > offer to do the initial conversion for you)
> >
> > Docbook is definitely an option. I have to learn more about it.
> >
> > The only problem I see is one of automation (within docbook) for things
> > like link generation and other stuff. For example, in the latex code I
> > posted yesterday:
> >
> > \item[\linkBaseAll{freqtweak}{\freqtweakver}]
> >
> > "linkBaseAll" is a latex command that I created in the same latex file,
> > part of the definition looks like this:
> >
> > \newcommand{\linkBaseAll} [2]{#1-#2
> > [\htmladdnormallink{7.3}{\rpmBaseSevenThree/#1-#2.rh73.ccrma.i386.rpm} |
> > ... more deleted
> >
> > It is a two argument command (the "[2]") and #1 and #2 inserts the
> > arguments into the text. So, that simple original line is expanding
> > through several layers of macros or commands ("\rpmBaseSevenThree" is
> > also a command that I define that inserts the base url for all RH7.3
> > base packages) to the full latex output, which is later translated to
> > html.
> >
> > What you end up seeing in the web page is:
> >
> > freqtweak-0.6.1-1 [7.3 |
> >
> > (with "7.3" being a highlighted link to the rpm)
> >
> > I like this because I can define commands that make it easy to describe
> > what I want without unnecessary verbosity. The other very important side
> > effect is that something like a version number for a certain package is
> > defined in one place and one place only.
> >
> > Is docbook capable of doing something similar? Or would I have to use
> > external preprocessing to achieve similar results?
>
> As far as I can tell from what I have read it is not capable to doing
> macros or anything similar. So all the automation that I currently have
> as a side effect of using latex2html would have to be supplied
> externally somehow.
>
> I also spent a fair amount of time trying to find out more about
> alternatives for latex -> html conversion without much luck. I believe
> that hevea is still the only one that supports conditionals, but I don't
> see newer versions that the one I tried a year and a half or more ago.
>
> Apparently someone at some point wrote something to support ifthenelse
> in latex2html but it would only work for booleans that are defined once
> at the start of the process due to the way the translator works (which
> would be our case, BTW). But there are no references other than a couple
> of posts in the l2h mailing list...
>
> Another (ridiculous?) option would be to write the whole thing as a, for
> example, perl program, using one of the numerous html extension
> packages. That would be very "programmer friendly" but not very "writer
> friendly".
>
> I'll keep looking for options...
> -- Fernando
>
>
> _______________________________________________
> PlanetCCRMA mailing list
> PlanetCCRMA@ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma
>
--=-9GkysoBZcsoXYURjaV9b
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.0.10">
</HEAD>
<BODY>
I have been doing some more digging around on this issue trying to come up with a meaningful suggestion. As far as I can tell:<BR>
<BR>
- Work on the various latex to html translators seems to be gradually coming to a stop, if they haven't stopped already. None of them really do the whole job. (tex4ht - http://www.cse.ohio-state.edu/~gurari/TeX4ht/mn.html seems to be another possibility, however it also does a fairly ordinary job of the conversion). <BR>
<BR>
This may be because the docbook to html translators are becoming quite mature and so easy (well "easy" if you know xslt) to enhance.<BR>
<BR>
- While docbook and other have the ability to embed multiple languages and then select the output based on a formatting parameter, in practice people don't seem do it. They tend to leave each language in a separate include files, one section/subsection per file with a common naming convention, and then just include the appropriate files into the overall document to build the final output. This has a couple of advantages: makes parallel working easier, can build the dependencies into a CVS structure etc.<BR>
<BR>
IMHO I would encourage the "if it ain't broke" don't fix it approach. So stay in latex (it works) and break it all out into separate files (I would be surprised if it wasn't structured that way already). Set up a CVS for the documentation and manage it that way. <BR>
<BR>
Cheers,<BR>
Andrew<BR>
<BR>
<BR>
On Tue, 2004-10-05 at 02:08, Fernando Pablo Lopez-Lezcano wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373"><I>On Thu, 2004-09-30 at 11:27, Fernando Pablo Lopez-Lezcano wrote:
> On Wed, 2004-09-29 at 18:35, Andrew Wilson wrote:
> > Just some comments from the sidelines. I think the "official" linux
> > way of approaching this problem is to use docbook for all the
> > documentation. This already has multi-language support and easily
> > generates output for html, pdf or whatever you want.
I have been reading up more on docbook. As far as I understand the
multi-language support is restricted to character sets and all that
stuff. I could not find anything pertinent to maintaining multiple
translations simultaneously and/or flagging of translated / untranslated
/ obsolete sections. Let me know if you know this to be a possibility.
> > The layout of
> > the existing planet documentation is uite straight forward and
> > wouldn't be that difficult to convert. The files are still text and
> > this would then open up access to all the various docbook tools out
> > there for indexing etc. (Fernando: I you want to go this way, I'd
> > offer to do the initial conversion for you)
>
> Docbook is definitely an option. I have to learn more about it.
>
> The only problem I see is one of automation (within docbook) for things
> like link generation and other stuff. For example, in the latex code I
> posted yesterday:
>
> \item[\linkBaseAll{freqtweak}{\freqtweakver}]
>
> "linkBaseAll" is a latex command that I created in the same latex file,
> part of the definition looks like this:
>
> \newcommand{\linkBaseAll} [2]{#1-#2
> [\htmladdnormallink{7.3}{\rpmBaseSevenThree/#1-#2.rh73.ccrma.i386.rpm} |
> ... more deleted
>
> It is a two argument command (the "[2]") and #1 and #2 inserts the
> arguments into the text. So, that simple original line is expanding
> through several layers of macros or commands ("\rpmBaseSevenThree" is
> also a command that I define that inserts the base url for all RH7.3
> base packages) to the full latex output, which is later translated to
> html.
>
> What you end up seeing in the web page is:
>
> freqtweak-0.6.1-1 [7.3 |
>
> (with "7.3" being a highlighted link to the rpm)
>
> I like this because I can define commands that make it easy to describe
> what I want without unnecessary verbosity. The other very important side
> effect is that something like a version number for a certain package is
> defined in one place and one place only.
>
> Is docbook capable of doing something similar? Or would I have to use
> external preprocessing to achieve similar results?
As far as I can tell from what I have read it is not capable to doing
macros or anything similar. So all the automation that I currently have
as a side effect of using latex2html would have to be supplied
externally somehow.
I also spent a fair amount of time trying to find out more about
alternatives for latex -> html conversion without much luck. I believe
that hevea is still the only one that supports conditionals, but I don't
see newer versions that the one I tried a year and a half or more ago.
Apparently someone at some point wrote something to support ifthenelse
in latex2html but it would only work for booleans that are defined once
at the start of the process due to the way the translator works (which
would be our case, BTW). But there are no references other than a couple
of posts in the l2h mailing list...
Another (ridiculous?) option would be to write the whole thing as a, for
example, perl program, using one of the numerous html extension
packages. That would be very "programmer friendly" but not very "writer
friendly".
I'll keep looking for options...
-- Fernando
_______________________________________________
PlanetCCRMA mailing list
PlanetCCRMA@ccrma.stanford.edu</FONT>
<A HREF="http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma"><U>http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma</U></A>
<FONT COLOR="#737373"></I></FONT></PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-9GkysoBZcsoXYURjaV9b--