2017-10-08 13:36 GMT+02:00 David Kastrup <d...@gnu.org>:
> Thomas Morley <thomasmorle...@gmail.com> 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
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
