Jan Nieuwenhuizen <jann...@gnu.org> writes: > David Kastrup writes: > >>> Maybe the time has finally come to drop convert-ly and implement and >>> fully supported conversions using LilyPond on music stream level. >> >> You still need a parser of the appropriate version at the front end. > > We have perfectly fine ly parsers of each available version available in > executable form from lilypond.org. What we do not yet have, is a handy > or integrated way of dumping the music tree with the original binary > [read: a nice web service -- this could possibly be integrated with a > mutopia revival, I'll be looking into this] reading the music tree with > the current version and a perfect ly-dump function. Eg, I think we may > want to preserve %-comments in the music tree, or other stuff the user > does not want to lose?
For an emergency conversion web service of an archive in case of convert-ly failure, a Scheme-written package diverting all required hooks like toplevel-book-handler, toplevel-bookpart-handler, toplevel-score-handler, toplevel-music-handler, toplevel-text-handler could likely be written. The meaning of spacing variables would need conversion, some overrides likely as well, context definitions and stuff would be a bit tricky to properly detect (but one could just start out with empty context/output defs and consider every change as relevant), but as an emergency measure, I consider the likelihood of getting at least something useful out for a majority of scores when run on the respective original version of LilyPond reasonably high. It would work at the music expression level, not at the stream event level: the latter has already lost too much information. All the input syntax/music function folderol would not be an issue since those have already done their work at the time of calling the handlers. Markup functions might be more tricky. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
