Re: Re:__JLReq-dのドキュ__ メントの構成

田嶋さん、ありがとうございます。ここスレッドをとても興味深く読んでいました。

うちでは、版面制作のツールも作ってきましたが、最近のわたしたちの毎日はデジタルデザイン（スクリーンデザイン）のためのツールが極めてメインになってきて、競争相手はブラウザー上でダイナミックに変わってもちゃんとレイアウトできるツールも作っている中で、うちはブラウザー以上綺麗に（印刷界隈の方でも納得できる）レイアウトや制作しやすくするために手動組版的な細かい調整しなくても済む、というのがゴールの一つだと思います。

本屋とかで見かける組版やグラフィックデザインはなぜ綺麗に見えるのか、いつも考えています。どうして日本語のウエブページが綺麗じゃないのか。綺麗なウエブページをたまに発見したら、その組版とか余白とか、よく見たら静止的に作っているのがほとんどで、その理由は何か。ツールのせい？　ブラウザーやCSSの機能は物足りない？　

フォントは第一の問題で、これはInDesignを開発し始めた時から変わっていない。欧文組版ベースで作られていて、APIも欧文専用的で、日本語のボディーやemboxは後から付けられてほんとんどのソフトはまだ意識していない。行送りの計算が欧文的、行の高さも。行取りという概念もなくて、グリッドの使い方も正方形的じゃなくて、罫線的で。文字の配置については欧文と日本語は１次元と２次元との違いみたいに感じます。

２次元の人間がまるで１次元のツールやレンダリング技術や文字属性の制御を使わせてきたようで、私たちが世界の開発者にその２次元の世界を紹介して、何が大事なのか、どうしてそうしてきたのか、印刷界からきた制限をなくしながら、印刷界の美意識を保つ、がミッションではないでしょうか。

ダイナミックに組版できるレイアウトエンジンを作ろうとしたら、欧文と日本語では何が共通なのか、何が独特なのかもはっきりわかっておかないといけない。混ぜると組版ルールが衝突した場合にどういう関係で優先度をつけないといけないのか。例えば、日本語組版のembox配置モードでは、欧文フォントを同じ行に配置する場合はどうアレンジすればいいのかは今まで手動でやる（スケールやベースラインシフトなど）か、合成フォントを作ってまるで欧文字形を持つ日本語フォントを作る必要があった。その面倒はもっとスムーズにできないか？　

もっと面白いのが、今までの日本語組版ルール（アキ量の調整など）の定義は静止的な版面上で決まっていて、誰もがダイナミックのルールを作っていない。エンジンの中はもちろんダイナミックで動いているから、ある程度行長が変わっても綺麗に組めるはずですが、ユーザは多分意識してなくて、UXはまだオペレーターしか使えないし、静止的な版面上でしか上手く制御できないでしょう。問題は今までのオペレーターはある行長のための設定にしているから、行長が変わると違う設定にするかも知れない。その違いを自動的にする必要があると感じます。アキ量の調整だけじゃなくて、美意識（余白の）を考えて、欧文組版との違いは多い気がします。各行の配置はemboxとどういう関係を持つのか、欧文の120%行送り、行長は別に重要じゃない世界のエンジンをどう改善すべきか。それらのコンセプトをどう説明してどう紹介すればいいかを考えたいです。

ナット
________________________________
From: 田嶋 淳 <junetaj@gmail.com>
Sent: Wednesday, August 3, 2022 19:02
To: Yasuo Kida <kida@mac.com>
Cc: JLReq TF 日本語 <public-i18n-japanese@w3.org>
Subject: Re: Re:__JLReq-dのドキュ__ メントの構成


EXTERNAL: Use caution when clicking on links or opening attachments.


木田さま

早速ありがとうございます。あとは実際にワープロソフトの開発に関わっていた石井さんや当然AdobeのNatさんのご意見も聞きたいところですよね。

***************************************
（株）三陽社
　メディア開発室
　http://www.sanyosha.co.jp/<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sanyosha.co.jp%2F&data=05%7C01%7Cnmccully%40adobe.com%7C01925addcc904b346c0a08da75bd7ce4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637951753975954748%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3NfCdFMnwOnVi3nRH%2F3x0Z83P8BQFD2t7xuj6P0M%2Fz4%3D&reserved=0>

　田嶋　淳
　tajima@sanyosha.co.jp<mailto:tajima@sanyosha.co.jp>

　※ブログ運営中です。
　　ご意見をいただければ幸いです。
　　http://densyodamasii.com/<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdensyodamasii.com%2F&data=05%7C01%7Cnmccully%40adobe.com%7C01925addcc904b346c0a08da75bd7ce4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637951753975954748%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JYm78b2mjwRCGQe14jHNDobBq7G4wHGKdMzC7VUP%2BVg%3D&reserved=0>
***************************************



2022/08/04 10:55、木田泰夫 <kida@mac.com<mailto:kida@mac.com>>のメール:

田嶋さん、ありがとうございます。他の方に見ていただけるのは本当に助かります。自分にとって明確でも、視点によって違ってくるということがよくわかりますし、こうやってフィードバックをいただくと自分の中でもちゃんと整理ができていなかったように思います。

ページの概念は、デジタルになって従来持っていた価値の多くを失ったと思います。冊子形態がその意味（内容のランダムアクセス、本棚への収容と一覧性）の多くを失ったからです。だからと言ってページがすぐになくなるわけではなく、また紙に印刷することもしばらく残るでしょう。物理的媒体との架け橋のためにページの概念や紙への印刷が残っても、それらは特にデジタルでの可能性に制限をかけるようなものではないように感じています。

jlreq デジタル版を開発しなければならない大きな理由はやはり組版自体の変化でしょう。活字時代の制限がなくなり、デジタルテキストでの新しい制限と可能性が存在する。

そう考えると、範囲外だとすべきなのは印刷の組版の再現であって、印刷することやページではないですね。


下のような感じにしてみましたがわかりやすくなったでしょうか？
–––––––––––––––––––––––––––––––––––––––––––––––
対象とするアプリケーション

JLReq-d は従来印刷で行われていた組版の再現を目的としない。これは紙への印刷に限らず、出力先が画面やPDFであっても同様である。モティベーションの項で述べたように、デジタルテキストにおいては、活字・写植の機構やワークフローから来る組版への制限がなくなり、デジタルならではの新たな制限や可能性が生まれる。それを反映するのが本文書の目的だからである。例えば下記のような応用は対象外となる：

  *   書籍など印刷紙面の作成を本来の目的とした組版アプリケーション
  *   印刷された書籍の見掛けの再現が重要な電子書籍アプリケーション

従来の印刷における組版の再現が必要な場合は JLReq が対応する。


JLReq-d は印刷で行われていた組版の再現を目的としない下のようなアプリケーションを念頭に置く：

  *   メールやメモなど日常のテキスト：組版指定なし、または簡単なスタイルのみ。典型的に行頭揃え
  *   Web ページ：リフロー、スクロールするもの
  *   デジタル文書作成が目的であるワードプロセッサーなど：ページの概念のあるもの
  *   電子書籍：書籍としての構成を持つもの。印刷された書籍の再現を目的としないもの
  *   アクセシビリティの重要なWebページや教科書

–––––––––––––––––––––––––––––––––––––––––––––––

木田

2022/08/04 9:02、田嶋 淳 <junetaj@gmail.com<mailto:junetaj@gmail.com>>のメール:


木田さま
みなさま

SNS等でもそれとなく聞いてみましたが意見百出でいかに見分けが付きにくくなっているかがよくわかりました。ただ、使用者目線での混同であってソフトウェア開発者の視点での本来の開発目的には明確な違いがあると思いますので、そこを文言に入れてはどうかなと思います。
「テキスト文書の作成を本来の目的としたワードプロセッサーアプリケーション」「書籍などの印刷用紙面の作成を本来の目的とした組版アプリケーション」みたいな感じでしょうか。



2022/07/29 20:01、田嶋淳 <junetaj@gmail.com<mailto:junetaj@gmail.com>>のメール:

木田さま

ありがとうございます。私はよいと思いますが、意見の大元は研究会の木枝さんなのでそちらのSlackに振ってみますね。お待ちください。

2022/07/29 18:43、木田泰夫 <kida@mac.com<mailto:kida@mac.com>>のメール:

とはいえ例があるとわかりやすいと思うので下のようにドラフトしてみました。いかがでしょう？

–––––––––––––––––––––––––––––
対象とするアプリケーション

一般にデジタルデバイス上のテキストを扱うアプリケーション。下記対象外の場合を参照のこと。

  *   メールやメモなど日常のテキスト：組版指定なし、また簡単なスタイルのみ。行頭揃えが多い
  *   Web ページ：リフロー、スクロールするもの
  *   ワードプロセッサー文書：ページのあるもの
  *   電子書籍：書籍としての構成を持つもの
  *   アクセシビリティの重要なWebページや教科書

<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fjlreq-d%2Fedit%2Fgh-pages%2FREADME.md%23%25E5%25AF%25BE%25E8%25B1%25A1%25E5%25A4%2596&data=05%7C01%7Cnmccully%40adobe.com%7C01925addcc904b346c0a08da75bd7ce4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637951753975954748%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6D66%2Fsg8CSNaNNyxBYID%2Bs0fSIiYak5wbBKjrkT1yJY%3D&reserved=0>対象外

JLReq-d は印刷組版の再現を目的とせず、その用途には JLReq が対応する。これは紙への印刷に限らず出力先が画面やPDFであっても同様。例えば：

  *   ページレイアウトアプリケーション
  *   ワードプロセッサーで印刷組版の再現が重要な場合
  *   印刷された書籍の見掛けの再現が重要な電子書籍アプリケーション

–––––––––––––––––––––––––––––




2022/07/28 9:56、田嶋淳 <junetaj@gmail.com<mailto:junetaj@gmail.com>>のメール:

木田さま

まあもちろん今後みなさんの意見を聞きながら充実させていけばいいのだと思います。このあたり面白いですし、印刷界隈でも区分がよくわかっていない人が多そうで割と大変なことにはなっている気がするので何かこちらでも書いてみたい気はしています。

2022/07/28 9:28、木田泰夫 <kida@mac.com<mailto:kida@mac.com>>のメール:


2022/07/28 8:56、田嶋　淳 <junetaj@gmail.com<mailto:junetaj@gmail.com>>のメール:
本来は執筆のツールであって版面作成のツールではないと思います

なるほど！確かに。

その執筆のツールが、GUI / WYSIWYG の考えのもとに最終的なページのイメージを作るツールになったのですね。ただしあくまでも印刷のプロのためのツールというよりは、書く人寄りのツールなので版面という意識はおそらくない。

この辺り、過去に関わっておられた石井さんがどのように捉えておられたのか、聞いてみたい気がします。

Webネイティブの方の感覚的には印刷の組版って何、みたいな

そっかー、今の若い人が昔の受話器📞とか、フロッピーディスク💾とかを見て、あれ何、って言うような物ですかね。時代はどんどん先へ進んでいますね。

概念的には一番冒頭で違いを説明しているのですが、具体例がなくわかりにくいですよね。まあ、jlreq-d 本文の中で、印刷ではこうだった、なんて note が挟まる場合もあるでしょうし、その辺りは読んでゆくとそのうち緩く解決する感じでどうでしょう。

木田