-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
デジタルテキストにおける表の組版 #36
Comments
デジタルテキストにおける表の組版 (山口)表の罫線、日本は多めな気がするが、気のせいでしょうか?、それとも罫線を入れる/入れない基準がありますか? binn:Webでは多いかもしれない.書籍では“不必要なケイは入れるな”というのが原則ですが,最近は多く入れている例も見掛ける.書籍の1つの考え方の例を出すと以下 binn:縦ケイは,項目区切りで入れる.ただし,表の最も左右(先頭と末尾)のケイは入れない.英語の本では,項目間を合う程度空けて,項目区切りの縦ケイは入れない方法もある.和文でも,これにならった例はあるが,それほど多くない. (山口)この考え方は表のテキストが横組の場合という理解でよろしいでしょうか?表のテキストが縦組の場合は、この考え方を時計回りに90度回転して縦横入れ替えるのですね。こんな感じです[20231030縦組みの表.pdf]20231030.pdf binn:項目をどう配置するかは,ルールというか,経験で適当に配置します.たぶん,“20231030縦組みの表.pdf”にはしないでしょう.ところで,私が添付した“表の例2_1.pdf”は,縦組でも横組でも,このままの形式で使用します.つまり,縦組でも,表は数字が入る例が多く,このように横組の表にし,縦組では,天側(上側)の小口側(見開きの外側)に図版と同じように配置します.見本の“20231030縦組みの表.pdf”のようにはしないのが普通です.ただし,戦前には漢数字を使用し,見本のように縦組にした表も使用されていました.この形式であれば,段落間にも挿入できます.ただ,小さい表では,縦にした表は,私は,かなり前から,ほとんどというか,まったく見たことがありません.もっとも,年表や年譜のように数ページにわたるようなものは,縦組の本では,だいたい縦組にしています. 山口:スマホにとっては、たいていの表は大きな表になってしまいます。JLReq-dはスマホやスクロール操作を想定すると思いますが、JLReqはそれらを想定してないように読めます。JLReqは最低でもタブレットサイズの画面と、固定レイアウトのページめくり操作を想定しているようです。横組みの表を狭い画面からスクロールで読むと、ヘッダー列は最後に現れるし、ヘッダー行はお尻から見えてきます。「本文が縦組みでも表は数字が多いから横組が多い」ではなく、「本文が縦組みなら表も縦組みが自然だが数字/数表が厄介だ」ではないでしょうか。 山口:Wikipediaの[源氏物語]を元に、縦組みの例を2つ作ってみました。 山口:ちなみに、これらの例の表はHTMLのtable要素ですが、元の横組のHTMLのtable要素のママで、構造を変えていません。文章全体を縦組みに指定(body要素にwriting-mode:vertical-rl;を設定)するだけで、表は行列が転置してこのような縦組みになります。数表は横組みが読みやすいとなれば、個別に横組みに指定することになります。 binn:JLReqは,スクロールは前提にしていない固定レイアウトが前提ですが,jlreq-dでは,違ってきますので,かなり扱いは変わってくるでしょう. binn:まず,ヘッダーの問題は,小さな表ではよいが,大きな表では,どこに表示するか,また,スクロールする場合,どのように表示するかが問題で,ヘッダーはスクロールしないで,固定する方法,あるいは,画面ごとに,複数表示などの工夫が必要でしょう. binn:次に,アラビア数字の場合は,それほど長くならず,また,2行にできません.しかし,例の“源氏物語”の表のようにテキストが主な場合,まず,縦にするか横にするかは,アラビア数字とは別の考えが必要でしょう.そして,年譜とか年表は,縦組の本では,内容によりますが,縦組にする例が多い.さらに,コマ内でどのように折り返すかを考えないといけないように思います.で,こうした表の場合,字詰め方向の列の数がもっと多くなり,そうなると,各コマの字詰め方向の幅をどう設定するか問題になります.例では,折返しをしないで1行で表示していますが,書籍でこうした方を配置する場合,なんとか版面内に入るように字詰め方向の各列の幅を設定します.これが難しい.今ではExcelなどでシミュレーションできますが,昔は,えいやぁ!と適当に決めたものです(年表・年譜などでは年号・年齢など,まず決められる幅を決め,残りを他の列に適当に配分するようにしていた).それが変化するとなるとどうなるんでしょう.パーセントか何かで決めるなどにしないといけないが,年号・年齢などを固定し,残りをパーセントで配分するということも必要になる. binn:その意味では,可変の世界で表を考えることは,表を図版的に考えるか(小さな表はこれですむようにも思うし,縦組でも横組でも表は横組にできる),そうでない場合,本文と同様にスクロールの対象にするか,さらに組方向,ヘッダーの扱い,字詰め方向の列の幅の決め方,ケイの用い方などを含めて,新たな発想を必要とするでしょう. binn:特に数表組は,横に読むというよりは,縦に読むケースが多い. (山口)これは、「何を列にして何を行にするか」の考え方とも読めそうです。例えば、添付していただいた「表の例2_1.pdf」でいうと、名称、寸法、面積が行見出しとして左端に縦に並んで、A列本版などが列見出しとして上端に横に並ぶ組み方はしないということでしょうか、こんな感じです表の行列の転置.pdf。 binn:“何を列にして何を行にするか”ということでもありますが,数表組の場合,だいたい,“表の例2_1.pdf”のようにします.このような表で横に読んでいくと考えると,⑤のように横ケイを全部入れるという考えになる.たしかに横組で横に読むのだが,列単位で縦向きに数字を比較して読む場合が多いんだよ,となれば横ケイは不要になるんだよ,ということです. binn:JLReqの“4.4.1表の構成”に図解して,横組を例に表の名称をつけたものを示していますので,参考にしてみてください.データベースとの関係はわかりません.また,属性というよりは,横組の表では,縦の列を“列”,横の列を“行”(横組の本では,“行”は左から右に横向きに配置します)と呼ぶようです. binn:ご参考までに,だいぶ古い資料ですが,ケイの使い方,文字サイズ,行間をいろいろ組合せたPDFを添付いたします. |
表について、過去に印刷のそっち方面作成部署にいたこともありますので、デジタルテキストで問題になりそうな点を示しておきます。 ・例えば項目数が10項目以上あるような多項目の表をスマートフォンのような小さな画面でどう破綻させずに表示させるか。1項目1文字になってしまうようなケースでは当然まともに表示されない。 個人的な意見としては、これらは元々紙の本というサイズの定まったフォーマットに表をどうにか入れ込むために様々な無理をした結果であるように思うので、これらをそのままデジタルテキストに持ち込む必要はなく、タップしたら別ウィンドウとしてポップアップ表示されるようなデジタル独自に最適化された形になるならそれが望ましいかなと考えます。 |
敏先生の「ケイの使用は,表を主にどちら向きに読んでいくかを考慮しないといけない.」が手がかりになると思うのです。 そこで、JIS X 4051の表の要件に、次のa〜cのような構成を加えると、紙からモバイル(スマホなど)まで、ページめくりからスクロールまで、読み上げや点字などのアクセシビリティ、また縦ケイ・横ケイの要否などをカバーできないでしょうか?。これはたたき台ですが、読み方を示すことがポイントだと思います: a. 表とは行と列によって構造化されたセル(こま)の集まりです。 b. 表は、次のように読めるように組みます(layout or rendering): c. 日本語の表の組版では次に注意: 以下、背景や懸念などを述べます
[1]と[2]を両立させるためには工夫が必要です、なぜなら、[1]は「表に組まれていれば何でも表である」と言ってるのに対して、[2]は「表ではないものが、表に組まれることがある(あった)」と言ってるからです。 [1]は賢明だと思います、なぜなら[1]の目的は「組まれた」表の要件だから…ですよね?。しかし、モバイルや、スクリーンリーダーなどアクセシビリティをスコープに含めるならば一歩踏み出す必要があるかもしれません。とはいえ、「『◯◯という読み方ができること』という要件定義の仕方は大丈夫か?」が懸念です。 例を作りました。ウィンドウを縦方向に縮めたり伸ばしたりして見てください。 表1と表2は実装にすぎませんが、満たそうとしてる要件は前記bで、表1はうまくいってるが、表2は失敗してます。 |
別の例です。どちらもモバイルで表を読ませるための工夫です…このように実装はあるのですが、これらを使った例を見たことないのが困ったところです…
これらは実装にすぎませんが、Column Toggleを開発した人の念頭には要件として前記b3が、Reflowを開発した人の念頭にはb4があったと推測します。 |
スクリーンリーダーの例です。 HTMLとスクリーンリーダーがこのように実装されてるのは、要件b.が念頭にあるからだと思います。要件b.があると表3と表4にダメ出しできます、視覚的には表1や表2と同じでも、です。 iPhoneの人は、次の説明に従うとVoiceOverを試せます(このリンクはiOS 17の場合)。
ぼくは使い慣れてなくて混乱するので、アクセシビリティのショートカットをVoiceOverに設定して、分からなくなったらサイドボタン(またはホームボタン)を3回押し(トリプルクリック)ですぐにVoiceOverのオン/オフを切り替えられるようにしてます。 |
第1に,キャプションは,画面に応じてスクロースしなくても読めるように,2行や3行に変えられないか. 第2に,画面内に入らない場合,いろいろ方法はある.どれを優先させるか,複数の処理を組み合せるのは難しいのかもしれないが,以下,どんな方法が考えられるか,これ以外に何かないかな.
|
調整してみました。 |
“Firefox”で見ていますが,キャプションは折り返します. 少々.細かい注文 |
過去にJAGATのXMLパブリッシング研究会でEPUBビューアの表示テストをした際に、表(テーブル)の表示テストも項目に入っていたのでリンクを貼っておきます。91行目からの「009 Tableによる表の表現」です。2019年なので最新ではないですが参考にはなるかと思います。 https://docs.google.com/spreadsheets/d/1NNYdC4L76-bZXIpSdOVBuGAWGul9k16fj16D_8EQVEU/edit#gid=0 |
いいですね、こういった資料から「何を問題視してるか」を抽出してrequirementsにできないかと思います。
|
そういうガイド的な文書が用意されていなかったこともあってチェック結果に結構揺れが出たので、最終的には私が再チェック含めてまとめた感じでした。多人数でのチェックのためのドキュメントを準備するのもなかなかノウハウがいるなと痛感した次第です。 |
EPUBでの表のセル幅指定ですが、em単位での指定(要は「字取り」)は効かなかったビューアはほとんどなかったかと思います。 |
その前に電書ラボで実施したテストの結果も貼っておきます。こちらは私が個人で行ったテストで、2014年なのでさらに古いです。表の表示テストの項目は4-14です。 |
以前に制作した本の中で実際にテーブル組みの表を使っているので、許可を得れば該当ページの公開は問題なさそうなものを示しておきます。本の性質上話の通りは良いはずです。 |
デジタルテキストにおける表では,どんな問題があり,どのようにしたらよいのか? 問題は多いように思います.
ヘッダーの表示
字詰め方向の列の幅の決め方
変化する場合,その幅はどうすればよいか
これまで,山口さんとbinnの間で,Wikiで何回かのやりとりがある.以下に示しておく.
The text was updated successfully, but these errors were encountered: