Am 13.08.2015 um 15:12 schrieb Orm Finnendahl: > Hi Barry, > > thanks for the answer. I might have been unclear: > > In a chamber music piece I'm writing, the first line of the score is > (and should be) indented. > > While working on the score I want to typeset just the last part of the > score and use > > Score.skipTypesetting = ##f > > in the beginning and set > > Score.skipTypesetting = ##t > > in some later part, e.g. after a \pageBreak. > > lilypond renders this partial score with the first line indented which > is suboptimal as the beginning of this page will *not* get indented in > the final (non partial) score. > > I was just proposing to fix that in case it's not very > complicated. But as this is not a bug and I can circumvent this easily > by setting the indentation to #0 when rendering partial scores I don't > really want to start a bikeshed...
Actually this is what I wanted to say too. Score.skipTypesetting is most surely used as a means for optimizing the workflow, and ideally you'd have the output a real excision of the compiled score - which is of course inherently impossible. But I would also prefer the output of such a compilation start with a regular (i.e. non-first) staff, that is without indentation, instrument names hidden measure number, and perhaps even time signature. I think this should be rather trivial to implement, either as skipTypesetting's default behaviour or in a new wrapper function. More involved (but maybe not impossible) would be the wish to automatically add missing spanner parts, e.g. starting dynamics or slurs etc. One thing I want to implement in Frescobaldi (rather soon, when our current "manuscript viewer" is finished) is a compilation mode where - one compilation writes the line and page breaks to a log file - subsequently any single system can be recompiled through skipTypesetting - while Frescobaldi determines the proper points for this using the log file - The compiled line will be replaced in the music view. For this I want to create a new viewing mode where a score is composed of a chain of systems without the notion of a page. This will work as long as the changes don't require the line breaking to change - which should be detectable. I hope that this will significantly smooth the user experience, although I know it's far from "instant" (for example LilyPond still has to interpret the whole score first, so engraving one system out of a 300 system score still takes a significant amount of time. For such an undertaking having the partially compiled score start just like from within the score (instead of creating a "complete" score) would be quite useful, although I can easily see a workaround (for my case): Compile one additional measure before and after the current system and insert manual line breaks. So I second Orm's feature request. Urs > > -- > Orm > > Am Donnerstag, den 13. August 2015 um 13:57:44 Uhr (+0100) schrieb Kevin > Barry: >> Hi Orm, >> >> On Tue, Aug 11, 2015 at 3:13 PM, Orm Finnendahl >> <orm.finnend...@selma.hfmdk-frankfurt.de> wrote: >>> As the instrument names are short, lilypond must know that it isn't at >>> the beginning of the piece. It would be preferrable to have unindented >>> first staffs, as that would better resemble the final layout, if the >>> typesetting (re)starts at linebreaks. >> LilyPond won't really try to guess something like this based on >> instrument names. If you start a new \score block LilyPond will create >> a new score, indented, at bar 1 etc., which is as it should be IMO >> (i.e. it behaves consistently rather than trying to guess your >> intentions). Multi-movement forms (suites, sonatas) frequently do this >> (start a new indented score on the same page). Sometimes it can be a >> good solution to use a new \score block in place of a line break in an >> existing score, in which case the best thing to do would be to >> continue as you are. If you post a snippet illustrating the problem >> then perhaps someone could suggest an alternative that you haven't >> thought of. >> >> hth, >> Kevin >> >> _______________________________________________ >> lilypond-user mailing list >> lilypond-user@gnu.org >> https://lists.gnu.org/mailman/listinfo/lilypond-user > _______________________________________________ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
