Doc-ja: Adding two sections to NR-ja.

[lilypond.git] / Documentation / ja / usage / updating.itely

@c -*- coding: utf-8; mode: texinfo; documentlanguage: ja -*-

@ignore
    Translation of GIT committish: 42ae342ba877dc8f26cabb5cc3937a6d3cdb4066

    When revising a translation, copy the HEAD committish of the
    version that you are working on.  For details, see the Contributors'
    Guide, node Updating translation committishes..
@end ignore

@c \version "2.13.36"

@c Translators: Yoshiki Sawada
@c Translation status: post-GDP


@node convert-ly を使ってファイルを更新する
@chapter @command{convert-ly} を使ってファイルを更新する
@translationof Updating files with convert-ly

@cindex Updating a LilyPond file (LilyPond ファイルを更新する)
@cindex convert-ly

LilyPond の入力構文は、さまざまな方法で単純化または改善するために、@c
定期的に変更されます。@c
その副作用として、LilyPond のインタプリタは@c
しばしば古い入力ファイルと互換性を持たなくなります。@c
これを救済するために、プログラム @command{convert-ly} を用いることで、@c
たいていの LilyPond のバージョン間での構文変更を処理することができます。


@menu
* 何故構文は変更されるのか？::
* convert-ly を呼び出す::
* convert-ly のコマンド ライン オプション::
* convert-ly の問題点::
* 手動変換::
@end menu

@node 何故構文は変更されるのか？
@section 何故構文は変更されるのか？
@translationof Why does the syntax change?

@cindex convert-ly
@cindex updating old input files (古い入力ファイルを更新する)

LilyPond の入力構文はしばしば変更されます。@c
LilyPond 自体が改良されるため、構文 (入力言語) もそれに合わせて変更されます。@c
変更の目的は、入力ファイルを読みやすく、書きやすくするためであったり、@c
LilyPond に新しい機能を持たせるためであったりします。

例えば、@code{\paper} と @code{\layout} のプロパティ名は
@code{first-second-third} という形式で記述することになっています。@c
しかしながら、バージョン 2.11.60 で @code{printallheaders} プロパティが@c
この規則に従っていないことが判明しました。@c
放置すべきでしょうか？
(新しいユーザはつじつまの合わない入力形式で混乱するでしょう。)
それとも、変更すべきでしょうか？
(既存の楽譜を持つユーザには煩わしいことです。)
このケースでは、プロパティ名を  @code{print-all-headers} に変更することを@c
決断しました。@c
幸運なことに、@c
この変更は @command{convert-ly} ツールで自動的に変換することができます。

不幸なことに、@c
@command{convert-ly} はすべての変更を処理できるわけではありません。@c
例えば、バージョン 2.4 以前の LilyPond では、@c
アクセント文字と非英語文字を LaTeX を用いて入力していました
-- Christmas のフランス語は @code{No\"el} のように入力されていました。@c
しかしながら、バージョン 2.6 以降の LilyPond では、@c
特殊文字 @code{ë} を UTF-8 文字として直接 LilyPond ファイルに@c
入力することになりました。@c
@command{convert-ly} はすべての LaTeX の特殊文字を UTF-8 文字に変換する@c
ことはできません。@c
手動で古い LilyPond 入力ファイルを更新する必要があります。


@node convert-ly を呼び出す
@section @command{convert-ly} を呼び出す
@translationof Invoking convert-ly

@command{convert-ly} は古いバージョン番号を検出するために@c
入力ファイルの @code{version} ステートメントを使用します。@c
たいていの場合、あなたの入力ファイルを更新するには、@c
そのファイルを保持しているディレクトリで以下を実行することで十分です:

@example
convert-ly -e myfile.ly
@end example

@noindent
これにより、@code{myfile.ly} は更新され、@c
オリジナル ファイルは @code{myfile.ly~} に保存されます。

@warning{@command{convert-ly} のバージョンは、@c
それが扱う最新の構文変更に合わせて変更されます。@c
このため、入力ファイルの @code{\version} 番号はたいてい@c
@command{convert-ly} のバージョンよりも低いことになります。}

ディレクトリの中にある入力ファイルをすべて変換するには、@c
以下のようにします:

@example
convert-ly -e *.ly
@end example

オリジナル ファイルをそのまま残しておき、
更新されたファイルに新しいファイル名を指定するには以下のようにします:

@example
convert-ly myfile.ly > mynewfile.ly
@end example

このプログラムは変換元のバージョン番号をリストアップします。
バージョン番号がリストアップされない場合、@c
そのファイルは最新であるということになります。

MacOS@tie{}X ユーザはこのコマンドをメニュー エントリ
(@code{Compile > Update syntax}) 下で実行することになるかもしれません。

Windows ユーザはこれらのコマンドを @q{コマンド プロンプト} ウィンドウから@c
実行する必要があります。@c
コマンド プロンプトは通常、@code{スタート > アクセサリ > コマンド プロンプト}
で見つかります。


@node convert-ly のコマンド ライン オプション
@section @command{convert-ly} のコマンド ライン オプション
@translationof Command line options for convert-ly

一般に、このプログラムは以下のように呼び出されます:

@example
convert-ly [@var{option}]@dots{} @var{filename}@dots{}
@end example


以下のオプションを与えることができます:

@table @code
@item -e,--edit
Apply the conversions direct to the input file, modifying it
in-place.

@item -f,--from=@var{from-patchlevel}
変換元のバージョンをセットします。@c
これがセットされていない場合、@c
@command{convert-ly} は入力ファイルの中にある
@code{version} 文字列を基に推測します。@c
例: @code{--from=2.10.25}

@item -n,--no-version
通常、@command{convert-ly} は @code{\version} インジケータを@c
出力に付け加えます。@c
このオプションを指定すると、それを抑制します。

@item -s, --show-rules
すべての変換を表示して、終了します。

@item --to=@var{to-patchlevel}
変換先のバージョンをセットします。@c
デフォルトは利用可能な最新バージョンです。@c
例: @code{--to=2.12.2}

@item -h, --help
使用方法についてのヘルプを表示します。
@end table

texinfo ファイルの中にある LilyPond 断片を更新するには@c
以下を使用してください:

@example
convert-ly --from=... --to=... --no-version *.itely
@end example

2 つのバージョン間での LilyPond 構文の変更を調べるには、@c
以下を使用してください:

@example
convert-ly --from=... --to=... -s
@end example


@node convert-ly の問題点
@section @code{convert-ly} の問題点
@translationof Problems with convert-ly

Windows の @q{コマンド プロンプト} ウィンドウから@c
スペースを含むファイル名やパスを持つファイルに対して@c
convert-ly を実行する場合、@c
入力ファイル名全体を 3 つ (!) のダブル クォートで囲む必要があります:

@example
convert-ly """D:/My Scores/Ode.ly""" > "D:/My Scores/new Ode.ly"
@end example

@command{convert-ly -e *.ly} コマンドが@c
展開時に長くなりすぎて失敗する場合、@c
@command{convert-ly} コマンドをループさせてやります。@c
以下の例は UNIX 用であり、@c
カレント ディレクトリの中にあるすべての @code{.ly} ファイルを@c
更新します:

@example
for f in *.ly; do convert-ly -e $f; done;
@end example

Windows の @q{コマンド プロンプト} ウィンドウでの@c
上の例に対応するコマンドは以下の通りです:

@example
for %x in (*.ly) do convert-ly -e """%x"""
@end example

言語の変更がすべて処理されるわけではありません。@c
指定できる出力オプションは 1 つだけです。@c
自動的に Scheme と更新することと
LilyPond の Scheme インタフェイスを更新することはまったく異なります。@c
Scheme コードの調整は手動で行う覚悟でいてください。


@node 手動変換
@section 手動変換
@translationof Manual conversions

@c not yet
理論的には、@c
@command{convert-ly} のようなプログラムはすべての構文変更を処理できます。
After all, a computer program interprets the old
version and the new version, so another computer program can
translate one file into another@footnote{At least, this is
possible in any LilyPond file which does not contain scheme.  If
there is scheme in the file, then the LilyPond file contains a
Turing-complete language, and we run into problems with the famous
@qq{Halting Problem} in computer science.}.

しかしながら、LilyPond プロジェクトの資源には限りがあり、@c
すべての変換を自動化することはできません。@c
以下は既知の問題のリストです。

@verbatim
1.6->2.0:
 Doesn't always convert figured bass correctly, specifically things like {<
>}.  Mats' comment on working around this:
   To be able to run convert-ly
   on it, I first replaced all occurrences of '{<' to some dummy like '{#'
   and similarly I replaced '>}' with '&}'.  After the conversion, I could
   then change back from '{ #' to '{ <' and from '& }' to '> }'.
 Doesn't convert all text markup correctly.  In the old markup syntax,
 it was possible to group a number of markup commands together within
parentheses, e.g.
   -#'((bold italic) "string")
   This will incorrectly be converted into
   -\markup{{\bold italic} "string"}
   instead of the correct
   -\markup{\bold \italic "string"}
2.0->2.2:
 Doesn't handle \partcombine
 Doesn't do \addlyrics => \lyricsto, this breaks some scores with multiple
stanzas.
2.0->2.4:
 \magnify isn't changed to \fontsize.
    - \magnify #m => \fontsize #f, where f = 6ln(m)/ln(2)
 remove-tag isn't changed.
    - \applyMusic #(remove-tag '. . .) => \keepWithTag #'. . .
 first-page-number isn't changed.
    - first-page-number no => print-first-page-number = ##f
 Line breaks in header strings aren't converted.
    - \\\\  as line break in \header strings => \markup \center-align <
      "First Line" "Second Line" >
 Crescendo and decrescendo terminators aren't converted.
    - \rced => \!
    - \rc => \!
2.2->2.4:
 \turnOff (used in \set Staff.VoltaBracket = \turnOff) is not properly
converted.
2.4.2->2.5.9
 \markup{ \center-align <{ ... }> } should be converted to:
 \markup{ \center-align {\line { ... }} }
 but now, \line is missing.
2.4->2.6
 Special LaTeX characters such as $~$ in text are not converted to UTF8.
2.8
 \score{} must now begin with a music expression.  Anything else
 (particularly \header{}) must come after the music.
@end verbatim