#校正校閲用マークアップ言語 は可能か、そして今どこまで求められるか？

mizchi @mizchi

プログラミングと執筆両方やる人間からすると、プログラミング実行環境は厳密すぎて一行一行意味があってdiffが必要だけど、執筆は前後のdiffがあまり意味ある感じにならなくて、「こっちの表現が良いですね」ぐらいの指摘に叱らないので、自然文の差分バージョン管理という発想が微妙な感じがしてます twitter.com/EnJoeToh/statu…

円城塔。カクヨムにもいます。 @EnJoeToh

小説業界にバージョン管理という概念がないのは、電子書籍のバージョン管理がなされていないことからも明らかではないでしょうか。

2020-11-14 17:08:38

tricken（手術後復帰チャレンジ中） @tricken

ははあ、なるほど…… (1)「紙の本における版組の規則自体が、電子蟠桃と根本的に異なる」 (2) 「さらに各出版社はAdobeInDesignの仕様に漫然と身を委ねている可能性が高い【要検証】 (3) 「京極夏彦などごく一部作家は共同チームを作って紙/電子それぞれの処理規約を決めたが全社ができるわけではない

tricken（手術後復帰チャレンジ中） @tricken

円城さんの想定する制作プロセスで紙と電子を同時に取り扱える出版技術をもった企業体は、今後可能なのだろうか。実現してほしいが。まずは「紙書籍と電子書籍とになる前の原データをdiffコマンドでやりとりできる編集部」を組織する必要があるが。商慣習をぶっちぎればできる、はずなんだが。

tricken（手術後復帰チャレンジ中） @tricken

gitはともかく、diffはLinuxさえ自分のマシン環境に用意すれば数分でできるのだからなんとかしてくれと思う。Linux CLIの敷居は見たほど高くない。Linuxコマンド打てるところまでやってくればあとはブルーバックスのLinux本一冊とググりで身につく。どうしてもLinuxいやだとしてもPowerShellでもできる

Awajiya @awajiya

@tricken 余談だけど，diff 代替GUIで，Macには FileMerge，Winにも WinMerge ってありますよな． FileMerge はXCodeデフォルトで入ってるんだけど，なんでか奥の方にあって親しみにくい．

土屋つかさ @t_tutiya

自分もプログラミングと執筆両方する人間として同意見で、ソースコードは厳密なセマンティクスに規定されるという「文章」の中でも特異な性質を持つためにdiffによる差分チェックが可能だけど、そうでない文章では実用的なdiffやプルリク管理はできない（誤植の差分管理くらい）というのが今の所の結論 twitter.com/mizchi/status/…

tricken（手術後復帰チャレンジ中） @tricken

@awajiya あ、触ったことないです。試してみるか……こないだもRGBチェッカー初めて知ったりしたし、10年付き合ってて未だに知らない機能だらけだな……

tricken（手術後復帰チャレンジ中） @tricken

これが実現したらその出版社と仕事します、という小説家の人はどれくらいいるんだろうか。（※伝統として培って来たブランディング能力とか販路はさておくとして、出版事業における製品製作プロセスの合理化についてだけ評価するものとする） twitter.com/tricken/status…

tricken（手術後復帰チャレンジ中） @tricken

円城さんとmizchiさんと土屋さんとで、どちらもソースコード執筆と出版向け自然文（小説and/or（評）論文）書く経験は多少なりとも類似点があるはずなのに、出版プロセスにおけるdiffコマンドの導入に関して意見に差異が出るの、興味深いな。

tricken（手術後復帰チャレンジ中） @tricken

たぶん、円城さんが特に「組版」プロセスの手前で原テキストデータを作り込もうとした時に編集者・印刷業者と諸々ワークフローで非効率な展開に人一倍遭遇して、そこでまず着手できそうなところとして「組版になる前のところでのdiffを」ということになったのだろうけど。

tricken（手術後復帰チャレンジ中） @tricken

で、「組版」に渡された後には20世紀の古式ゆかしきゲラのやりとりに巻き戻ってしまうから、それをデジタル&リモートで（なんならクラウドでも）やりとりするために、バイナリファイルでなくソースコードとして維持されるような特殊なマークアップ言語の発明が求められる、てことなんだろうか。

tricken（手術後復帰チャレンジ中） @tricken

そのような #校正校閲対応マークアップ言語 （と仮に名付ける）は、縦書き日本語をXMLやTeXのように扱え、組版としていつでも出力することができ、gitやdiffを仕掛けられる、というようなものになるはず。

tricken（手術後復帰チャレンジ中） @tricken

そのような #校正校閲対応マークアップ言語 は、 (1) あると小説家にとってマジで便利なのか (2) それは（商習慣や技術訓練を抜きにすれば）編集者にとっても望ましいものなのか (3) 現行のXMLやTeXなどの類似マークアップでどこまで擬似的に実装できるのか (4) まったく新たに発明することはできるか

tricken（手術後復帰チャレンジ中） @tricken

(5) 発明できるとして、どのような仕様が（小説家、編集者、校閲者、印刷業者にとって）最低限必要か (6) そのマークアップ言語を読み込むプログラム（エディタや変換プログラム）はどの言語で実現するか のうち、1-5くらいまでは小説出版業界の内部で議論できそうな気がする。

tricken（手術後復帰チャレンジ中） @tricken

円城さんの話に、一部企業はXMLをアレンジしたものをプロプライエタリで持っているらしいという話も少しあった。ということはXMLの延長線上で日本語向けの規則を作り、それに合わせて解釈できるプログラム群をオープンソースで作れれば、新聞書籍などの縦書き産業の業務効率は底上げできるかもしれない

tricken（手術後復帰チャレンジ中） @tricken

この話が実現して嬉しいのは「草稿の書き手」と「校閲校正担当の人」で、校閲校正に関わる度合いの低い編集者と印刷所の人はそんなに嬉しくないかもしれない（余計な新技術が入るだけなのではと鬱陶しく感じ、腰が重くなるかもしれない）のだけど……。

tricken（手術後復帰チャレンジ中） @tricken

原データと校閲校正者の2つの利害関係者の意見がもっと凝集して「これはこんなにソリューションになります！」という風景が共有できたら、#校正校閲対応マークアップ言語 の設計に向けてスタートを切る流れができそうな気がするのだけど。

おーえす @os_hiroaki

@tricken XSLT&XSL-FOですねー。うちは出版ではないですけど商用でマニュアル作るのにアンテナハウスさんのエンジンを使っています。

tricken（手術後復帰チャレンジ中） @tricken

@os_hiroaki ありがとう、これかーっ　antenna.co.jp/AHF/ でもこれと同じようなものの縦書き組版用のルールづくりを既存の（どちらかといえばICTに強くない）大手出版社がやっていけるかというと、色々障害がありそうね……。アンテナハウスのような企業に技術提供してもらいながら練る方向性はありそうだが

tricken（手術後復帰チャレンジ中） @tricken

> XSL-FO による組版の概要 antenna.co.jp/AHF/ahf_public…

tricken（手術後復帰チャレンジ中） @tricken

ああそうか、XMLを利用したXSLTとXSL-FOについてはW3Cの勧告があるけど、縦書きについての議論が乏しいから日本の組版のあるビジネス界隈ではそこだけInDesignその他のデファクトでやってしまいXMLベースでのソースコードのやりとりができない、てことか。Oくんズバッと本質キーワードくれたな。多謝。

tricken（手術後復帰チャレンジ中） @tricken

@os_hiroaki ちなみに現行のXSLT&XSL-FOにおいて、プロプライエタリ/オープンソース、商用非商用問わず、「縦書き日本語文」に関する勧告や議論や実装ってどこまで進んでるんだろう？　アンテナハウスのサイトだと有償サポート枠なみの、オープンソースは当面望めなさそうな領域に見えたけど。

おーえす @os_hiroaki

@tricken 出版業界ミリしらなのですけれど、ツールや技術仕様に引っ張られてルール作るのも本末転倒なので、統一する意志があればテクノロジはそこに向かって作られていくのもアリですね。道具に合わせる方がいいのか、組織や仕組み合わせた方がいいのか二側面ありますが定石不在ならどっちもアリかと思います。

tricken（手術後復帰チャレンジ中） @tricken

@os_hiroaki 今の所、定石なさそうですね。京極夏彦さんみたいな「商業的に成功しているため発言力があり、かつデジタル組版や製作プロセスについて専門的知識がある、しかしソースコードベースでやりとりするタイプの処理は（おそらく）傍に置いてる」ひとが頑張っていて、XMLベースの話まで立案までさえ行かない

おーえす @os_hiroaki

@tricken そこは寡聞に知らないですねえ。あまり縦書き興味ないので全然調べた事がない。AHFormatterの縦書きは独自定義なので、XSLワーキンググループやXSLへの変換エンジン(asciidoctor)のMLとか眺めてみたら何かつかめるかもしれません。

tricken（手術後復帰チャレンジ中） @tricken

@os_hiroaki なーるほど、全然専門外領域だ（そもそも自分にIT/ICT系の専門などひとつもないけど……）でも単語や標準化団体名一つもらうだけでググり判定に大きなプラス修正がつくのでありがたかったです。感謝感謝。

おーえす @os_hiroaki

@tricken レイアウトに作家がどこまで責任や志向を持つのか難しいですよね。エンジニアが製品のマニュアルを書くような場合は、かなり楽なんですけど。必ずしも作家がそのケアをした方が良い結果が得られるのかは外野からは難しい判断に見えます。

tricken（手術後復帰チャレンジ中） @tricken

@os_hiroaki 元々は円城塔さんの「編集者や校正校閲側でもdiffで製品に向けた調整できんもんか」という話があり、しかしそのための（=InDesign等のバイナリファイルでなくソースコードで管理できるような）XMLファイルが、そもそも作りづらいよな、という話でした。業界慣習含め、なかなか解決は難しそうですね。

tricken（手術後復帰チャレンジ中） @tricken

技術書の管理でいうと、#数学ガール の結城浩さんは確かTeXでシリーズの執筆をしてたと書いて……いた。medium.com/@hyuki/latex-2… さらにメモも自作のDraftというTeX対応のwebアプリを作って書いてる。gitやdiffもその際に使ってたりするのだろうか。

tricken（手術後復帰チャレンジ中） @tricken

横書きならTeXをgitで管理、でFAなのだろうが、TeXで縦書きはできないし、ルビにも（どう割り付けるかということまで考え始めると）そこまで強くないだろうから……> texファイルをgitで管理する - mash810rのブログ mash810r.hatenablog.com/entry/2018/06/…

tricken（手術後復帰チャレンジ中） @tricken

小説が想定する自然文に対してdiffの有効範囲が（作家と編集者の原データ調整以外に）あまりないといっても、編集者側で気にすべきさまざまな「出版慣習に合わせた処理」は、Pythonのinportで出せる色んなライブラリみたいに出したりできないものかと思う。

tricken（手術後復帰チャレンジ中） @tricken

縦書き日本語文のためにターミナル上で呼び出せる、出版業標準のライブラリ・エコシステム、みたいなのが、#校正校閲対応マークアップ言語 の周辺に環境として充実すれば、いいわけだよな……。ターミナル上ならaptやbrewで入れられ、言語内ならimportですぐ扱えてしまうようなツールたち。

tricken（手術後復帰チャレンジ中） @tricken

縦書き用XMLに関するW3C勧告があるか数分探してみたけど、界隈の勘どころが何もわからなかったのでかすりもしなかった。epub3の規格が商業で普及しているようだが、epubは元の議論における 0. 原データ 1-a. 紙組版データ→2-a. 紙書籍 1-b. 電子組版データ→2-b. 電子書籍 のb側の話だからなあ……。

tricken（手術後復帰チャレンジ中） @tricken

紙用のInDesignデータ（など）にも、電子書籍用のepub3データ（など）にもコンパイルできるような、そういう原データを記述できる縦書き日本語文のXML規格とその為の基本ライブラリ、あたりがオープンソースで成り立てば……。横書きはそれに近いものがなくもない。縦書きになると途端に乏しい。

結城浩 / Hiroshi Yuki @hyuki

@tricken 本を書くときは確かにgitとdiffを駆使してLaTeXを使っていますが、脱稿後は（再校後は）手持ちのソースとの一貫性はそれほど意識してませんね。それをやると編集者や組版する方のパフォーマンスを活かせなくなりますし。

氷川霧霞 @kilica

@tricken 僕は使ったことないからどれくらい実用的なのか知らないけど、縦書き用のTeXもあることはあります。 僕がTeX使ってた頃にも見かけた覚えがあるので、たぶん20年以上前からあるんじゃないかな。 fugenji.org/~thomas/texliv…

氷川霧霞 @kilica

@tricken InDesignも、.icml という独自のXMLマークアップファイルを配置して流し込むことはできます。 流し込みの指定（どのファイルを、どのInDesignフレームに）は手作業だけど、マクロ使えばなんとかなるのかな？ trpg-labo.com/blog/1034

氷川霧霞 @kilica

@tricken 原稿（markdown, html, TeX etc.）から .icml へは、 pandoc というコマンドラインのアプリを使えば可能です。

氷川霧霞 @kilica

@tricken カタログみたいに、単純に文章をダラダラと流し込んだだけでは作れないものは、InDesign のスクリプト機能を使って json から一括で置換できるようにしました（小説や新書みたいなのだとほとんど不要ですが）。 trpg-labo.com/blog/1056

tricken（手術後復帰チャレンジ中） @tricken

@kilica 縦書TeXと.icmlの情報ありがとうございます。pandocは確かに現行できる「原データ」管理の最適解のひとつだと、未明に書きながら思ってました。

tricken（手術後復帰チャレンジ中） @tricken

@kilica jsonファイルの使い方も素敵ですね！　これ、TRPGの特技や呪文やエネミーのデータをjson形式でいつでもexportできるようにしておくと、わかるひとが活かす余地もでてきそう（このメタデータで自作シナリオのデータを自動組版で吐かせるとかを草の根でやってもらえる、とか）。

tricken（手術後復帰チャレンジ中） @tricken

@hyuki 補足ありがとうございます！実は (1)「（縦書き日本語文のための）構成校閲用マークアップ言語を新たに設定して」 (2) 「【紙の組版】と【電子書籍の組版】の双方を作る前の原データを校正校閲者の方（編集者含む）とソースコードベースで詰めてゆく工程にする」 ことが今後可能かと、思弁してました。

tricken（手術後復帰チャレンジ中） @tricken

@hyuki 自分自身が今後その工程に関わるわけではないのですが、縦書日本語文で優れた作品を作られる商業作家の方や、縦書きが好きな同人作家の方が、校正校閲の局面や紙/電子出版に向けた作業時、プログラミングの恩恵を受けられず困ってるのをみて、技術的に解決できたらいいのにな……と思ってたのでした。

tricken（手術後復帰チャレンジ中） @tricken

@hyuki とはいえ初稿が仕上がった後、編集者さん/校正校閲者さん/印刷業者さんそれぞれにとって重要かつuniqueなノウハウがあることは、素人ながら十分承知してます。それらの実務を邪魔せずに済む程度に、縦書XSLT & XSL-FOのオープンソースでの整備が進むといいな、と思ってました（縦書TeXの実用化でも可）

tricken（手術後復帰チャレンジ中） @tricken

PDFまでならおそらくこうした工程で問題ないんだろうけど（pandocはまじつよなんですよね）、紙書籍のマンパワーと連携できなさそうなのが現行のイシューと噛み合わない。>Pandoc + LaTeX で markdownからB6縦書き・小説本のPDFを作成 - adbird（広告鳥） 備忘録 adbird.hatenablog.com/entry/2017/01/…

tricken（手術後復帰チャレンジ中） @tricken

昨日の午後から今朝未明にかけて書かれた話の文脈RTsです。#校正校閲対応マークアップ言語 。話題の中心は円城塔さんが以前から仰ってるdiffあらまほしき論なんですが、これを可能にしようとすると技術的問題だけでなく、商慣習やIT系文化政策にも踏み込まないといけない可能性もある広がりがある

土屋つかさ @t_tutiya

XHTMLはweb上にあるテキストにセマンティクスを与えて「再演算可能な文書（土屋が過去に書いた同人誌「再演算される書物」に詳しい。入手は不可能だろうけど）」を作る壮大な計画だったのだろうけど、現時点では<p>～</p>タグで挟むパラグラフの概念ですら文化を超えて定義を共有できなかった

tricken（手術後復帰チャレンジ中） @tricken

@t_tutiya 紙面組版の規則が、epub3では再現できないほど特殊、なのかしら。「日本語-紙面-縦書-組版と日本語-電子-縦書-組版との間が、(1)どこがどこまで、どのように違って、(2)しかもそれが紙と電子とで一致させることを決定的に不可能にさせているのか」を明らかにできれば、まずは第一歩になるのかなあ？

土屋つかさ @t_tutiya

ｎ個の<p>～</p>タグからなるパラグラフ群の改行位置を変えてm個の<p>～</p>タグに更新した場合、前者と後者はどういう関係を持つのか。diffを取れば当然pタグの階層レベルで差分が出るけどその情報がなにを提供するのか。そうとう難しい問題だと思う。

tricken（手術後復帰チャレンジ中） @tricken

@t_tutiya 図書館情報学に「組版学（紙部門・電子部門）」があれば、そしてワーキンググループとかが数年がかりで動いてデジュールスタンダードを定めるなど、文化庁かどこかのトップダウンで変えてゆく方向性ができそうだけど……。（実務寄りでフォント研究等やってる人はよく見るけど、組版そのものは知らない