Joseph Rushton Wakeling <joseph.wakel...@webdrake.net> writes: > I don't see that there is likely to be any big secret around all of > this, because the major details are likely to be almost entirely the > same from publisher to publisher. (In STM publishing, for example, > many of the major rival publishers use the same typesetting services > from the same suppliers. It's not a secret that the typical workflow > is that text is imported or re-typed in Word, which is used for > copyediting; and this is then imported into InDesign, where the layout > is done; and from there it is exported to PDF and XML. It's also > evident why they are ever more favouring these tools over e.g. LaTeX, > because the whole process of typing, checking and editing is much > easier with these tools; LaTeX is being relegated to an input format > rather than a production one.)
The funny thing is that there are publishers for which the production pipeline involved using TeX/LaTeX as an intermediate format for print publication, basically fed from XML->LaTeX converters. If you hand in a LaTeX text, it will tend to get retyped into Word, travel through processes making XML, and will go through LaTeX in the course of the end of the print pipeline again. Nobody would think of copy-editing the hand-written LaTeX, in a similar vein how nobody would think of copy-editing manuscripts submitted in hand-written PostScript. Realistically, this is where LilyPond is heading. So publishers trying to use LilyPond in serious scale and without banking more of their personnel and in-house expertise on LilyPond than necessary will love us for every backend improvement, and hate us for every frontend change affecting the limited LilyPond subset they use in their production pipeline. So in the short- to midterm, the things we can work on are a) improve automatic untweaked typesetting b) try to maintain backward compatibility in core functionality c) facilitate MusicXML input better. If we want to get them hooked on LilyPond as an actual input format a) simplify and improve things across the board b) figure out how to do partial parsing so that post-editing tools can work with a half-usable input representation. Anybody who ever worked with "Tailor" on Nextstep for editing PostScript files? Impressive. c) Collect nice feature sets into blackbox "packages" like LaTeX does d) Make it feasible for publishers to condense their own layouts and rule sets into the equivalent of "document classes". And part/part: Make it easy to define how MusicXML gets mapped to a particular in-house style. If Bärenreiter can just rip off some generic MusicXML and publish it Bärenreiter style (likely also involving in-house fonts), they'll listen. Perhaps. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
