headers
John Mandereau | 1 Apr 2008 08:43
Picon

Re: Using \\ in a texinfo macro argument generates \ in html, but \\ in pdf

Le lundi 31 mars 2008 à 13:51 -0700, Graham Percival a écrit :
> On Mon, 31 Mar 2008 22:35:42 +0200
> Reinhold Kainhofer <reinhold <at> kainhofer.com> wrote:

> You'll have to ask somebody else about  <at> value{backslash}; it
> didn't come from me.  I think it was John?

No, it was Werner.  For the sake of brevity,  <at> bs macro which Reinhold
just added is preferable, even if it's not much used.

Cheers,
John
Permalink | Reply | 0 comments |
headers
John Mandereau | 1 Apr 2008 13:54
Picon
Favicon

Re: Using texi2html for the documentation

Reinhold Kainhofer wrote:
> This would only work within the same document (where it already works out of 
> the box anyway). For cross-manual links, there would need to be multiple runs 
> and this data would need to be written out to a temp file after each manual 
> is converted to HTML. Each manual would then need to read in all other such 
> temp files and heavily customize the way cross-refernces are generated.

Perhaps it's convenient to make translated docs compilation depend on a
toplevel make target, which calls a simple script that grabs
( <at> node, <at> translationof) pairs (simply using regexps) in all Texinfo
source files and dumps them to a file e.g.
(top-build-dir)/out/node-translations.LANG.db; then this file could be
loaded by texi2html for use in cross-references formatting routines.  I
could write such a script in Python, but maybe it's more benefitial to
other texi2html users that you write it in Perl so it can be integrated
into Texi2html distribution (or does Texi2html already use Python
somewhere?).

This kind of solution is complicated, but I see no other way; I has
already done something similar for the current system, i.e. collecting
all node names into a PO file.

Btw. if it helps you testing translated docs with all texi2html features
using  <at> translationof, I can convert all translated docs to use
 <at> translationof next week-end in dev/texi2html -- this job can be easily
automated with a slightly modified version of
buildscripts/texi-gettext.py.

> The add_html_footer.py needs to be adjusted to texi2html anyway (e.g. the 
> footer can be automatically added directly by texi2html, the <body> tag gets
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Mandereau | 1 Apr 2008 13:59
Picon

Re: Using \\ in a texinfo macro argument generates \ in html, but \\ in pdf

Graham Percival wrote:
> BTW, are the other issues getting fixed in texinfo CVS / SVN /
> whatever they use?  If so, do you feel like installing it on
> kainhofer.com, so that we can see what the docs look like with all
> these bugfixes included?

I regularly update texinfo.tex in Lily sources from Texinfo CVS -- last
time was this morning -- so bugfixes will quickly show in PDF output
anyway, and we're going to switch to texi2html for translated docs, so I
don't think it's so urgent.  Anyway, Texinfo 4.12 is planned for very
soon (current pretest is 4.11.95).

> The bugfixes won't show up on the official 2.11 docs on
> lilypond.org, but hopefully texinfo 2.13 will be out before lily
> 2.12.  And it would be nice to tell people "look at the docs on
> the GDP server, and let us know if you find *any* errors".
>
> There's no urgency in this; waiting a month will be fine.
> Actually, we should probably do the introducion of texi2html on
> -user and get all those issues settled first, anyway.

Bugfixes in Texinfo PDF output will actually show up in officially
distributed docs.  As for HTML output, I hope we'll be able to switch to
texi2html before 2.12 -- this should even be a thing to be done before
2.12 IMHO.

Cheers,
John
Permalink | Reply | 0 comments |
headers
Francisco Vila | 2 Apr 2008 18:13
Picon

Program usage, three issues

Hello. In 3.2.1 Invoking lilypond it reads

When filename.ly is processed it will produce filename.tex as output...

I think it should read that it will produce filename.pdf.

Then I try to run it using a dash to accept stdin input, but it
doesn't seem to work:
echo '\version "2.11.43" {c d e }' | lilypond - -o test
Processing `-'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to
`-.ps'.../usr/local/lilypond/usr/share/lilypond/current/scm/framework-ps.scm:750:9:
In procedure simple-format in expression (ly:warning (_ "cannot
convert <stdout> to ~S" "PDF")):
/usr/local/lilypond/usr/share/lilypond/current/scm/framework-ps.scm:750:9:
FORMAT: Missing argument for ~S

Then I try to use the tex backend on a trivial file (has it ever worked?)

$ lilypond -dbackend=tex test.ly
GNU LilyPond 2.11.43
Processing `test.ly'
Parsing...
Interpreting music...
(Continue reading)

Permalink | Reply | 4 comments |
headers
Graham Percival | 2 Apr 2008 18:23
Picon

Re: renamed snippets

General note: in the past few months, there's been way too many
private emails coming to me.  I know that some people are shy, but
we should really keep these on -devel.  Many people here have good
ideas and can find potential problems.

Documentation updates should still come directly to me, but other
than that, let's keep things public (and archived).

On Wed, 2 Apr 2008 17:12:36 +0100
"Neil Puttock" <n.puttock <at> gmail.com> wrote:

> Incidentally, since the snippets are effectively part of the
> documentation, should they conform more strictly to the documentation
> guidelines? There's a wide variation in style as a result of their
> origin as LSR snippets.

I've discussed this briefly with Valentin.  Perhaps we should
split the "WRITING LILYPOND" part of writing-texinfo.txt into a
separate file, which could be used as a guidelines for snippets as
well.

... in fact, we might potentially add this to LM 5.

As for the doc-ness of snippets... this is where I wish that we
had been a bit more cautious about marking things as "docs".  Any
snippet that appears in the manual directly should of course
conform to our standards (although since it's easy to fix these
later, I'm not being strict about this)

Ideally, snippets which appear in the Snippet list in the docs
(Continue reading)

Permalink | Reply | 1 comment |
headers
Graham Percival | 2 Apr 2008 18:50
Picon

Re: Program usage, three issues

On Wed, 2 Apr 2008 18:13:24 +0200
"Francisco Vila" <paconet.org <at> gmail.com> wrote:

> I could send three separate messages for these, but I wonder that the
> response is simply that "program usage is outdated" for all three.
> 
> I could update it if only I knew the response...

The reponse is "AU is outdated, and will be completely rewritten
when GDP gets to it".  We're still working on NR 1, so it will be
a few months before we get to it.

As for the tex backend, IIRC this worked in the 1.x days, but is
now obsolete.  This is the kind of detail that we'll check when
GDP gets around to this book.

Cheers,
- Graham
Permalink | Reply | 0 comments |
headers
Neil Puttock | 2 Apr 2008 19:36
Picon

Re: renamed snippets

On 02/04/2008, Graham Percival <gpermus <at> gmail.com> wrote:

>  As for the doc-ness of snippets... this is where I wish that we
>  had been a bit more cautious about marking things as "docs".  Any
>  snippet that appears in the manual directly should of course
>  conform to our standards (although since it's easy to fix these
>  later, I'm not being strict about this)
>
>  Ideally, snippets which appear in the Snippet list in the docs
>  should also conform to our standards.

I agree. So far, I've restricted my changes mainly to spelling and
grammar, with a few rewrites for particularly glaring examples such as
contemporary-glissando.ly.

>  As for other snippets... I'm not too concerned.  I certainly don't
>  think that we should withhold snippets from LSR until they
>  rigorously match our guidelines.  It would be nice if the LSR
>  editors could rewrite every single snippet that people submit to
>  make it match our guidelines, but I'm not certain you have that
>  amount of time -- and even if you *do* have the time, I'm certain
>  that I could find better uses for it.  :)

Though I've tweaked a few examples mentioned on -user, I wasn't for a
moment advocating extending GDP guidelines to cover general LSR
snippets. It would be a mammoth task and take up far too much valuable
time.  :)

Regards,
Neil
(Continue reading)

Permalink | Reply | 0 comments |
headers
Han-Wen Nienhuys | 2 Apr 2008 20:46
Picon

Re: Program usage, three issues

2008/4/2, Francisco Vila <paconet.org <at> gmail.com>:
>  [tex / ps output and '-' input]

Hi,

we used to output to .tex; when we switched to PS, Werner asked me to
retain some tex functionality.   It hasn't been used since.  If it is
broken, we should remove it.

The '-' for stdin was a nice idea, but I haven't ever heard anyone use
it, and it complicates file name handling.  I vote for scrapping it.

--

-- 
Han-Wen Nienhuys - hanwen <at> xs4all.nl - http://www.xs4all.nl/~hanwen
Permalink | Reply | 2 comments |
headers
Werner LEMBERG | 2 Apr 2008 20:50
Picon

Re: Program usage, three issues


> we used to output to .tex; when we switched to PS, Werner asked me
> to retain some tex functionality.  It hasn't been used since.  If it
> is broken, we should remove it.

I agree.  LilyPond has become powerful enough to no longer need a TeX
interface.

    Werner
Permalink | Reply | 0 comments |
headers
John Mandereau | 2 Apr 2008 21:47
Picon

Re: Program usage, three issues

Le mercredi 02 avril 2008 à 15:46 -0300, Han-Wen Nienhuys a écrit :
> 2008/4/2, Francisco Vila <paconet.org <at> gmail.com>:
> >  [tex / ps output and '-' input]

> The '-' for stdin was a nice idea, but I haven't ever heard anyone use
> it, and it complicates file name handling.  I vote for scrapping it.

'-' for stdin works if an output file name is specified with -o.  It
could be a bit more useful if it could be used to send several ly scores
to be compiled one by one (i.e. each score would be compiled as soon as
EOF is caught, and two EOFs would close stdin reading) through a pipe.
I'm not volunteering to implement this in the near future (less than 4
months) though, and I don't mind at all if you scrap current '-'
handling.

Cheers,
John
Permalink | Reply | 0 comments |

Gmane