Re: Issue 872 in lilypond: Changes split-page has broken images

[Graham Percival]

On Mon, Oct 26, 2009 at 12:38:46PM +0100, John Mandereau wrote:
> Le samedi 24 octobre 2009 à 17:13 +0000, address@hidden a
> écrit :
> > Maybe those aren't good reasons... I have no objection to keeping such TODO 
> >  
> > items to
> > myself in the future, if that's desired.
> 
> What about the wiki for this kind of stuff?

I think that having multiple "issue" lists would be a mistake.  I
really think that as long as they're not tagged as type-defect
(and I'm pretty certain I gave this one type-other), there's no
problem using the google tracker.

I agree that discussing it there is silly, but the simple "here is
a task" message is fine.

> > Anyway, for this specific issue: if changes.tely is a non-splitted manual,  
> > then the
> > html page from general/manual.itexi @section Changes  will overwrite the  
> > non-splitted
> > version of changes.itely.  I figured that the simplest way to fix this  
> > would be to
> > make Changes a split manual, thereby putting changes-one-page.html in the  
> > main doc
> > source output, and also giving us changes/index.html.
> 
> How ugly, this gives two almost identical HTML documents
> changes-one-page.html and changes/index.html.

Yes.

> > There was also an issue with the xref produced by @rchanges{Top,blah}  
> > inside general,
> > that has to do with the broken html refs that I'm avoiding with that  
> > disgusting find
> > | xargs sed trick.
> 
> One purpose of postprocess_html is avoiding messing with make and shell
> to do such tricks.

Oh, ok.  BTW, what's the difference between python/auxiliar/ and
scripts/build/ ?

> > In general (umm, I mean, "as a summary", not anything to do with  
> > general.texi), I'd
> > like to avoid manual-specific hacks; I like the idea of only having two  
> > types of
> > manuals: general.texi, which goes in the top output dir, and all the other  
> > manuals,
> > which are all treated the same.
> 
> There are two distinct documentation targets: online (lilypond.org) and
> offline (downloadable docball).
> 
> As for the offline target, I don't understand why you want to make
> General go at the top output dir: why should the directory structure
> match the hierarchy between HTML Info manuals?

I've never understood the online/offline distinction.  My sole
knowledge comes from "go to top dir.  type make doc.  look in
out-www/offline-root/".

>  The only grounds I can
> see for doing so would be
> - navigating directories/typing URL by hand,
> - reading the URL to see where you are because the docs structure is not
> obvious from the HTML pages themselves.
> 
> I hope we put enough effort into the usability of our docs and new web
> site so these grounds are not valid.

Yes, but it would also be nice if the links (if people posted in
the mailist, for example) weren't long.  For example, I'd really
like it if bug maintainers could say

"Sorry, please construct a tiny example as described on
lilypond.org/bugs.html
"

> Moving HTML output of General one directory up suits none of the two
> targets, so it should be abandoned.  However, we should generate each
> output of General twice, removing for the offline target the download
> page and other pages that make sense only for the online web site; I'm
> willing to take over this, but not for the to-be-dead build system.

I'm more than willing to have you take over it.  As you know, I
quite dislike hacking the build system; I only did it because I
wanted to resolve all (?) broken links for 2.13.6, and nobody else
was touching the build system.
(I _think_ I've resolved them all, and I've checked with make
xref-check, but I haven't tested it with any other tool)


What's the timeframe of the new build system?  In particular, is
the January deadline still relevant?  How much math work are you
doing already?  What's the copyright status of your work once you
officially become a student?  How many gorgeous Italian girls have
you met so far?  Does Italian wine have a higher alcohol content
than French wine?

(you don't need to answer all those questions; just take them into
account when answering the first one :)

Cheers,
- Graham