Re: [GLISS] why the hell all this fuss

[David Kastrup]

Joseph Rushton Wakeling <address@hidden> 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