[ << convert-ly を使ってファイルを更新する ] | [Top][Contents][Index] | [ lilypond-book を実行する >> ] |
[ < convert-ly を使ってファイルを更新する ] | [ Up : convert-ly を使ってファイルを更新する ] | [ convert-ly を呼び出す > ] |
2.1 何故構文は変更されるのか？
入力ファイルを読みやすく、書きやすくするために、しばしば構文は変更されますが、時により既存の関数が、新しい機能や改善に合わせて変更されることがあります。
これが実際にあった例です:
\paper と \layout のプロパティ名は全て、first-second-third という形式で記述することになっています。しかしながら、バージョン 2.11.60 で printallheaders プロパティがこの規則に従っていないことが判明しました。放置すべきでしょうか？
(新しいユーザはつじつまの合わない入力形式で混乱するでしょう。)
それとも、変更すべきでしょうか？
(既存の楽譜を持つユーザには煩わしいことです。)
このケースでは、プロパティ名を print-all-headers に変更することを決断しました。そして、昔のユーザは convert-ly コマンドによって既にある入力ファイルを自動的にアップデートすることができました。
しかし、convert-ly はすべての変更を処理できるわけではありません。例えば、バージョン 2.4.2 以前の LilyPond では、アクセント文字と非英語文字を LaTeX の記法を用いて入力していました。
例えば Christmas のフランス語は No\"el のように入力されていました。しかしながら、バージョン 2.6 以降の LilyPond では、特殊文字 ë を UTF-8 文字として直接 LilyPond ファイルに入力しなければならなくなりました。convert-ly はすべての LaTeX の特殊文字を UTF-8 文字に変換することはできません。手動で古い LilyPond 入力ファイルを更新する必要があります。
convert-ly コマンドの変換ルールは、テキストのパターンマッチングと置換によって動作しています (つまり、与えられた入力ファイルの中で何が変更されたかの文脈を‘理解’してはいないということです)。
これはいくつかの結果をもたらします:
- 変換の信頼性は、それぞれの適用されるルールセットの品質と、対応する変更の複雑さ次第です。変換が、追加・手動の修正を要求することがあります。ですから万が一のために、変換前の入力ファイルは比較のために残しておくべきです。
- より新しいバージョンへの構文の変更のみが可能です: LilyPond の昔のバージョンへ変換するルールセットは存在しません。そのため、入力ファイルを更新するのは、昔のバージョンの LilyPond がもうメンテナンスされていない時に限るべきです。繰り返しますが、万が一のために変換前の入力ファイルは残しておくべきです。Git のようなバージョン管理システムを使うと、複数のバージョンの入力ファイルを管理するのに役立つかもしれません。
- LilyPond は処理の際、余計に配置された、あるいは省略された空白に左右されません。しかし、
convert-lyで用いられるルールはコードのスタイルにいくらかの仮定を置く場合があります。ですから、正常な変換を行うために、LilyPond のマニュアルで用いられるスタイルに従うことを推奨します。特にマニュアル自体、すべての例がconvert-lyコマンドで更新されています。