Re: ly:output-def-clone not working correctly?

[Thomas Morley]

2017-10-08 13:36 GMT+02:00 David Kastrup <address@hidden>:
> Thomas Morley <address@hidden> writes:
>
>> The foolwing code returns a gs error:
>> \version "2.19.65"
>>
>> #(define-markup-command (clone-test layout props mrkp) (markup?)
>>   (interpret-markup (ly:output-def-clone layout) props mrkp))
>>
>> \markup \clone-test \score { { c'1 } }
>>
>> ->
>> warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28
>> -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
>> -r1200 -sDEVICE=pdfwrite -dAutoRotatePages=/None
>> -sOutputFile=atest-63.pdf -c.setpdfwrite -f/tmp/lilypond-JyFZOH)'
>> failed (256)
>>
>> Looking at ps-files it seems no Emmentaler-font is embedded.
>
> I think using a different layout than the one your output appears in is
> not a supported idea.  Output definitions are hemimetabolic.  They may
> be an "output definition" but it's not like they are being used to
> instantiate a separate "output" type like a context definition is
> instantiated into a context.  Instead, output definitions may receive
> the side effects from their uses (which include managing the writing of
> a Midi/PDF file, and in this case, causing font definitions).



Thanks for your explanations.

In the german forum it was attempted to set 'line-width to some
calculated value relying on the found 'line-width in layout. With
multiple calls the found line-width will become the calculated one
from the previous call not the original, thus the idea of cloning the
layout, similiar to ly:music-deep-copy.

Iiuc, you would say it's a not supported (in this case read: bad) idea.

(Meanwhile I posted a concurrent coding not affecting layout, so this
special problem seems to be solved. But I was interested in the
underlying mechanisms.)

Thanks again,
  Harm