校正トラブル
発行された論文に関する全責任は筆者にあるわけですが，
すべての関係者がこのことに関して，
高度の認識を持っているとは限らないので，
時にトラブルが発生します．
校正はトラブル防止に良い手段ですが，
当然行われると思っていた手続きが一方的に省略され，
その結果問題が発生してしまったことを経験したことがあるので，
自分の反省と警鐘をかねて，ここで紹介します．
また，これらは，電子入稿に際して起きていますので，
もとの原稿を提示することで，訂正もしたいという希望もあります．
- 最初がこれ．
水野直美，1991．マヤランの試験管内開花をめぐる問題．
ラン懇話会誌6:14-35．
電子入稿で良いということだったのでそうしました．
しかし，実際には，紙に打ち出して，手入力をしたようで，
誤植が多発．おまけに，筆者校正もなかったので，
誤植がそのまま出てしまいました．
原稿を送ったら，必ずその後の予定を聞いて，
絶対に筆者校正をするべきだと思いました．
原稿
- 2回目がこれ．
水野直美．1996. 園芸分野から見たファイトテクノロジーへの期待．
農業機械学会誌58(5):130-135.[1996年9月1日]
これも，電子入稿＆筆者校正なしのパターン．
誤植は1個所．「会章」が「会長」になってしまいました．
本質を鋭く剔る議論が，冗談になってしまいました．
この時は，非常に忙しく，原稿を送った段階で，
すべて忘却の彼方みたいな状況だったので，
前記の「原稿を送ったら，必ずその後の予定を聞いて，
絶対に筆者校正をするべき」という教訓は実行出来ず，
私としては，いきなり出版されて驚いたというわけです．
相手を信用しすぎていたこともあるかも知れません．
原稿(修正有)
まあ，現在では，電子入稿も一般的になってきたので，
こういった，
初歩的な茶番というかドタバタは減ってきていると思います．
更に現在では，原稿をutfで入稿もできて，
業者がちゃんとutfレベルで仕事をしてくれれば，
たとえば，機種依存文字などもなくなり，
大きな問題は発生しなくなってきてはいますが，
まだまだ，安心は出来ません．
つまり，
製作現場はまだそこまでいっていないことが多いようだからです．
つまり，どこかで，
たとえばutf→sjisの変換が行われるということが起き，
トラブルの発生に繋がります．
変換を必要としない体制になっていても，
業者がunicodeのすべてのフォントを持っているとは限りませんし，
異体字の問題もあります．
本当はunicodeを再設計するべきだと思っていますが，
流れはunicodeに収束してきているので，
次善の策として使わざるを得ない状況です．
というわけで，
2009年に自分のパソコンの文字コードを，
uft-8(LF改行)に切り替えることを完了しました．
以前は，普通の文書はsjis，プログラム開発はeucで，
改行文字は双方ともMacintosh標準のCRでしたが，
徐々にuft-8/LFに切り替え，
2009年中頃にすべてのプログラムの新規書類は，
utf-8をデフォルトにしました．
よく使うエディタは，既存書類もutf-8で開く設定です．
自動判定にはしていないので，コードが異なると，
開けなかったり化けたりしますが，
その場合，
補助的に使っている別のエディタが自動判定にしてありますので，
そちらで開き，メインのエディタの方へcopy&pasteします．
コード判定の完全なアルゴリズムはないので，
全書類の自動変換はしません．
あとは，TeXやnamazuがunicodeに完全対応
(現在はコード変換で対応)
してくれれば，
万々歳なのですが…
この結果，すべてのテキスト書類は，ターミナルから，
catで開けますし，grepで特定の文字列を探せるなど，
Macintoshをunixマシンとして使う際の利便性が向上しました．
正面玄関(トップページ)
現行版：2010年1月8日
初 版：2010年1月8日
メールアドレス：nmizuno(アットマーク)affrc.go.jp