Re: landscape orientation differences between versions

[Urs Liska]

Hello Steff,

Am 04.05.19 um 15:48 schrieb address@hidden:
> Hello everybody
>
> I'm working with Lilypond for several months now, and my experiments get
> more and more realistic and interesting ;-)


Great! Welcome to LilyPond.


>   So I will follow up with
> specific questions soon and hope someone may be able to give me advice.
>
> As I'm new to this list, I would like to ask how I should handle the
> following observation:
>
> Let's start with the following code fragment:
>
> {code}
> \version "2.18.2"
>
> \book {
>    \paper {
>      #(set-paper-size "a5" 'landscape)
>    }
>    \score {
>      \new Staff
>      <<
>        { \relative c'{ c d e f}}
>      >>
>      \layout {
>      }
>    }
> }
> {code}
>
> When I render this code with Lilypond v2.18.2, the PDF appears in
> landscape view as expected - be it in Adobe Reader or in the Frescobaldi
> score view.
>
> When I render this code with Lilypnd v2.19.83, the PDF is rendered in
> portrait orientation (and displayed so in the viewers mentionned).
>
> When I change the version hint in the code to
> {code}
> \version "2.19.83"
> {code}
> and render the code with Lilypond v2.19.83, the PDF is rendered in
> portrait orientation.
>
> *Summary*
> File version hint    Lilypond version   PDF orientation
> 2.18.2               2.18.2             landscape
> 2.18.2               2.19.83            portrait
> 2.19.83              2.19.83            portrait
>
> Is this a bug? Where to post it? Or have I missed something?


1)
The \version string is not really a hint as you seem to understand it. 
You should rather take it as an indication for the *minimum* version to 
be use (although that is not the technical meaning of it).
You *can* tell Frescobaldi to use that information to determine which 
installed version to be used for compilation (Frescobaldi will take the 
LilyPond version with the next higher version number), but LilyPond 
itself will only use the string to determine if the document's version 
requirement is set (if your file states \version "2.19.83" and you 
compile it with 2.18.2 it will produce an error message).

2)
What you see is an intended change that happened during the 2.19 
development cycle to remove an inconsistency in the input language.

[but I see others have already answered that ...]

However, for your use case it seems you'll have to decide whether to use 
the 2.18 or the 2.19 version (and learn about the convert-ly tool to 
update existing input files.
Generally you should really go directly for 2.19. Labelling it 
"development version" is really an understatement, and the improvements 
have really been significant.

HTH
Urs


> Thanks in Advance
> Steff
>
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user