‘日本語組版処理の要件’ タグのついている投稿

JLREQとCSS(8)

2018/01/02

 こちらのエントリは、JAGAT XMLパブリッシング準研究会で今期の研究テーマとして、W3C文書「日本語組版処理の要件」(JLREQ)と、これに関連してVivliostyleの村上真雄さんたちが提出したW3Cメンバーサブミッション「Web技術を用いた日本語組版の現状」を取り扱っていることに伴い、会員以外の方の意見を広く求めるとともに、記録を残しておく目的で議事録をベースに補足したものを公開するものです。

 間違い、補足などございましたらご意見いただければ幸いです。なお、当ブログはコメント許可制を取っているため、反映に時間がかかります。あらかじめご理解ください。
 方針としましてはW3C文書「日本語組版処理の要件」(JLREQ)を先頭から読んでいき、各要素に対応するCSSが存在するのか、存在するとして実用段階なのか、InDesignなどの組版ソフトではどういった形で機能を実現しているのか(いないのか)、などについて見ています。なお全体に対しての包括的な説明の部分に関しては、細かな部分は次回以降にその部分の説明が出てきた時に掘り下げる、としてスルーしている箇所があります。

 なお、こちらで取り上げております各CSSプロパティはまだドラフト仕様の段階のものも多いため、今現在すぐに使えるものばかりではありません。Webブラウザで使用出来るかどうかはこちらなどでご確認ください。また、電子書籍のRSで使用出来るかどうかは、現在広範に調査した資料がありません。いずれ当研究会の活動として調査を行いたく考えていますが、しばらく時間はかかるかと思います。

JLREQ 4.1.1 見出しの種類

 「見出しは,組版処理の方法で分けると,次の4つになる.
 a.中扉又は半扉
 b.別行見出し
 c.同行見出し
 d.窓見出し」
※同行見出しで見出しと本文との間がJLREQでは「全角」とあるが(図188)、必ずしも全角とは限らないのではないかという指摘があった。活版の時代のルールと思われる。

JLREQ 4.1.2 別行見出しの構成

 「別行見出しの構成については,JIS X 4051では大見出し,中見出し及び小見出しについて,それぞれラベル名,番号,見出し文字列及び副題で構成するとしている(図190).ただし,ラベル名,番号及び副題は,必須要素ではなく,省略してもよいとなっている.」
「なお,これ以外に見出しの前後に記号を付ける,あるいは罫線を見出しの前後に配置する,罫線で見出しを囲むなどといったことも行われている」
※このあたりの記述はデザインの話が入り込んでしまっており、規格文書の記述としてはいらないのではないかという指摘があった。

JLREQ 4.1.3 見出しにアクセントを付ける

 ここもほぼデザインの話。技術的にそう多くのオプションがなかった活版時代のデザインの典型例としては興味深いものがあるが、デザイン回りの話だけに異論も多く出そう。

JLREQ 4.1.4 改丁・改ページ・改段処理

 「大見出しなどでは,区切りを明確にするために新しいページから始める方法も行われている.」
 章扉などで見られるような必ず奇数ページから始める処理が改丁、奇数偶数ページにこだわらず、単にページを改めるのが改ページ。雑誌やムック本などで見られるように必ず偶数ページで始めて見開きで記事を読ませるパターンもある。

CSS:扉などの改ページ
CSS Fragmentation module Level3 3.1. Breaks Between Boxes: the break-before and break-after properties
break-after:autobreak-bofore:autoで通常の改ページ。
いわゆる改丁や見開き始まり指定はright/leftでできるようになるはず。
recto/versoは論理値なのでこれが使えれば縦書き横書き共通で改丁などを指定できる。
見開きの最初のページにするのがverso

 なお現状EPUB3では改丁/見開き始まりはOPFファイル内のspine項目で「properties=”page-spread-left”」のように指定する。ただしこれに対応しているEPUBビューアは現状あまりない(観測範囲ではhonto、kinoppyくらい。BOOK☆WALKERも対応しているという報告があった)。全体としてはリフロー型で、中途に見開きの図が挟まるような本で問題となりがち。

JLREQ 4.1.6 行取りの処理例

 「各ページで行を配置していく場合,基本版面で設定した行位置にそろった方が望ましい.そこで,行送り方向の見出しの占める領域は,基本版面で設定した行位置を基準にして設定する方法が行われている.このような設定方法を行取りという.」(4.1.3 dより)
 ここは4.1.3 dへの参照リンクが欲しい。

※ページ先頭に行取りの空改行が入った場合、欧文組版では(上側の)スペースを削除するのが普通で、CSSも現状そうなっている。和文の図201などの処理は行頭でも(右側の)アキを入れる点が違う、という指摘があった。

 図203のような本題と副題が2行の場合、泣き別れを防ぐにはbreak-inside:avoidの指定が必要。

 行取り含めて本文級数×行数で版面を決めて厳密にそれを守る日本語組版では基本となる処理を再現するために、現状議論中のCSS規格で一番近いのはLine-gridなどだが、まだこれも議論中でどうなりそうかはっきりしないとのこと。ここがどうにかならないと、行取りをCSSで指定するといったような話にもならないだろうと思われる。

JLREQ 4.1.7 行取り処理した見出しがページ末にきた場合の処理

 行末に入りきれなかった場合にはブロックごと次ページに。これは行取り処理した見出しに限らず、ページ末尾に見出しが来てしまった場合に次ページに送る処理は一般的に行われている(JLREQ 4.1.4 eの「なりゆき」の記述も参照)。
 なお、見出しと本文の泣き別れを防ぐのはbreak-inside:avoidなどを指定することで可能だが、ノド側に来た場合には見出しと本文との泣き別れを許容する(見開きで次ページの1行目に本文が来るため)ルールを採用しているケースもあるため、そこまでを自動で処理するのはかなり難しそうではある。

JLREQ 4.1.9 同行見出しの処理

 同行見出しはレイアウト的に本文と同一行内に見出しを配置するもののため、例えば

 <p><span class="midashi">見出し</span>本文本文本文本文</p>

 といったような形のマークアップが想起されるが、構造化文書として本来的には

 <hn>見出し</hn>
 <p>本文本文本文本文</p>

 といった形で本文と見出しを記述しておき、CSS指定で同行で見せる方が望ましい。

JLREQ 4.1.10 窓見出しの処理

 これも本来は上記のように<hn>タグと<p>タグを分けてマークアップするべきだが、まだRSの実装的に実際にweb等で再現するのは難しいかもしれない。詳しくは以下参照。

CSS:同行見出し/窓見出し
同行見出し、窓見出しもHTMLの構造としてはhnタグでマークアップした方がよいはず。
そのためのものとして display要素の拡張として Run-In Layout がドラフト規格として考案されている。
display: run-in;
のように指定。

CSS display level3ではdisplayプロパティでdisplay-outsidedisplay-insideを別に指定できるようになっているため、窓見出しの表現も可能になるはず。
display: run-in flow-root;
になるか。floatの指定も必要かもしれない。

JLREQ 4.1.11 段抜きの見出しの処理

 新聞や雑誌で多く見られる段組の複数の段をぶち抜く形の見出し。これはリフローで処理するのは相当負荷が大きそう。一応CSSではできなくはない。

CSS:段抜き見出し
CSS Multi-column Layout Modulecolumn-spanで指定できる。ただし、全段抜きか段抜きをしないかの2択。
なお、multi-column module Level2ではinteger(整数値)での指定も提案されてはいるとのこと。これがもし実用段階に入れば、例えば5段組のうち2段を使った段抜き見出しのようなレイアウトも可能になるだろう。
InDesignでは段落パレットの「段抜きと段分割」で指定できる。ただし、段抜きを行うためにはテキストフレームをひとつにしておかないとならないなどの制約はあり、現状どこまで実用されているかはわからない。

次回 JLREQ 4.2 注の処理 から

(2018.1.5)

JLREQとCSS(7)

2017/12/11

 こちらのエントリは、JAGAT XMLパブリッシング準研究会で今期の研究テーマとして、W3C文書「日本語組版処理の要件」(JLREQ)と、これに関連してVivliostyleの村上真雄さんたちが提出したW3Cメンバーサブミッション「Web技術を用いた日本語組版の現状」を取り扱っていることに伴い、会員以外の方の意見を広く求めるとともに、記録を残しておく目的で議事録をベースに補足したものを公開するものです。

 間違い、補足などございましたらご意見いただければ幸いです。なお、当ブログはコメント許可制を取っているため、反映に時間がかかります。あらかじめご理解ください。
 方針としましてはW3C文書「日本語組版処理の要件」(JLREQ)を先頭から読んでいき、各要素に対応するCSSが存在するのか、存在するとして実用段階なのか、InDesignなどの組版ソフトではどういった形で機能を実現しているのか(いないのか)、などについて見ています。なお全体に対しての包括的な説明の部分に関しては、細かな部分は次回以降にその部分の説明が出てきた時に掘り下げる、としてスルーしている箇所があります。

 なお、こちらで取り上げております各CSSプロパティはまだドラフト仕様の段階のものも多いため、今現在すぐに使えるものばかりではありません。Webブラウザで使用出来るかどうかはこちらなどでご確認ください。また、電子書籍のRSで使用出来るかどうかは、現在広範に調査した資料がありません。いずれ当研究会の活動として調査を行いたく考えていますが、しばらく時間はかかるかと思います。

3.7.2 振分け処理

 「振分けとは,1行の途中に複数の言葉や文を配置する処理である.複数の選択肢を示す場合などに利用されている.学習参考書,マニュアル,解説書などで使用している例がある.振分けを行う場合,複数の行を括弧類でくくることも多い.」この処理自体は見たことがあるが、「振分け」という用語自体にはあまり聞き覚えがなかった。
 「また,同一の振分け行を複数の行に分割した場合の行間は0とする」ここだけずいぶん具体的な行間表記。
 CSS的にはdisplay:inline-blockで表現自体は可能。上下をブレースで囲む表現が今ちょっと難しそうな感じ(border-imageプロパティでできなくはないが)。

3.7.3 字取り処理

 「日本人名の名簿を一覧にする場合など,行中の文字列の一部について全長を指定する例がある.このような場合に,行中の指定された文字列を,字間を調整して,字詰め方向について指定された長さにする処理が字取り処理である.人名など字数の異なる文字列を指定した一定の長さでそろえたい場合に利用できる.」
 「3.5.3 そろえの処理」に関連情報がある。「○○文字分」という考え方になるところが考え方として違うところか。実際に制作の現場には、「○○字取均等割り」といったような形で指定が来る。
※図173と図174は違う処理の例になるのではないか。項を分けた方が良くないかという指摘があった。
CSS的には前出のtext-alignを参照。

3.7.4 等号類と演算記号の処理

 このブロックは数式組版に関する部分であり、JIS X 4051にはない項目になる、とのこと。
※図176の等号類、演算記号の文字の例が全角になっているのに違和感がある、との指摘。プロポーショナルの記号であるべき。(和欧混植で英文ブロックを和文内に入れる場合には欧文ブロックの中は欧文の組版ルールに従うべき、というのと同種の話か)
※図177、演算としてのマイナス符号と負の値を表す符号がこの例だと判別できないという指摘。和文フォントのデザインに表記が引きずられている?
 「別行式で,2行に分割する位置をある程度任意に選択できる場合は,まず等号類の前で2行に分割するとよい.それができない場合は,演算記号の前で2行に分割するとよい.」に関して、数学方面での書籍組版の常識としては、別行式ではJLReqの記述の通りであるが,行中式(インライン)では式が繋がっていることを示すために等号類や演算記号の「後ろ」で改行する、という指摘あり。また、行中式での改行の記述自体が抜けている、という指摘もあった。

3.8.2 詰める処理と空ける処理

 行の調整処理には空き量を詰める処理(追込み処理)と字間を空ける処理(追出し処理)がある。
 「通常,詰める処理(追込み処理)を優先し,それで処理できない場合は空ける処理(追出し処理)を行う.詰める処理(追込み処理)を優先するのは,ベタ組の箇所はできるだけ空けないという考え方による.」書籍組版などでは空ける処理を優先するケースもある。どちらを優先するかはそれぞれの現場でのルール付けによるものと思われる。
 「a.規定されている空き量を詰める処理(追込み処理).追込み処理では,読点類又は終わり括弧類の後ろの二分アキや,始め括弧類の前の二分アキ,欧文間隔などの空き量を規定の範囲内で詰める処理を行う.」とある。
 JLREQの規定では欧文単語間のスペースを3分と規定しているが、実際のフォントのデザインでは0.25em程度にしているパターンが多いため、実際にはほとんど詰まらないことになるのではないか、という指摘。
 現在のDTPの組版では、カタカナ、ひらがな類の前後スペースの調整処理なども行われている。これは技術の進展により、より細かな調整が可能になったためと思う。

 また、この項目の注にぶら下げ組の解説がある。ぶら下げはCSSのボックスモデルの例外的な処理を必要とする要素でもあり、1項立てて解説しても良いのではないかと感じた。ちょっとアンバランスさがある。
 「DTPなどでは,このような句読点を3行目のようにぶら下げ組にする処理を行っている例があるが,不必要な処理といえよう.」
 行末の句読点は全てぶら下げた方が綺麗に揃って見えるという意見もある。これを反映してか、InDesignでは段落パレットの指定でぶら下がりの強制、標準、なしを選べる。

CSS:ぶら下がり
CSS text module Level3 9.2. Hanging Punctuation: the hanging-punctuation property
force-endが強制、allow-endが標準。firstは段落はじめの開き括弧などを通常位置より外側にはみ出させる処理。日本語だとあまり見ないが、欧文ではそれなりに多い。段落先頭だけに関連する点がtext-spacingとは違う。lastはそれを行末側でやる処理。
参照:Text Level4 10.1.3. Japanese Paragraph-start Conventions in CSS
括弧類が段落始めに来た際の字下げ量の区分
今Kindle(だけ)が段落はじめのカギを天付きとして扱うので扱いが面倒くさい。

3.8.3 詰める処理の優先順位

「詰める処理(追込み処理)を行う場合は,通常,優先順位と詰める限界を決めて行う.詰める処理は,次の順序で行う.
a.欧文間隔を,最小で四分アキまで文字サイズ比で均等に詰める.
b.行末に配置する終わり括弧類,読点類及び句点類の後ろの二分アキをベタ組にする.
c.行末に配置する中点類の前及び後ろの四分アキを一緒にベタ組にする.
d.行中の中点類の前後の四分アキを,最小でベタ組まで文字サイズ比で均等に詰める.
e.行中の始め括弧類の前側,並びに終わり括弧類及び読点類の後ろ側の二分アキを,最小でベタ組まで文字サイズ比で均等に詰める.」

 ツメ処理優先順位の記述が断定的過ぎないかという指摘があった。この順番で必ずツメ処理を行う話ではないのではないか。順不同の箇条書きとしてはわかる。
 また、機械的な処理としてはわかるが実際にはもう少し状況によって臨機応変な処理をしているのでは、との話も。
 なお、ここでのツメ処理はJustificationに関連して起こるもので、デザイン上の必要性からくるツメ組の話とは別枠。CSS的にはText-JutifyのJustification Methodに関連する。

3.8.4 空ける処理の優先順位

 ここの項目への指摘も3.8.3と同じ。CSSとしては同じ項目で扱われている。

 次回は JLREQ 4. 見出し・注・図版・表・段落の配置処理から

(2017.12.12)

JLREQとCSS(6)

2017/11/08

 こちらのエントリは、JAGAT XMLパブリッシング準研究会で今期の研究テーマとして、W3C文書「日本語組版処理の要件」(JLREQ)と、これに関連してVivliostyleの村上真雄さんたちが提出したW3Cメンバーサブミッション「Web技術を用いた日本語組版の現状」を取り扱っていることに伴い、会員以外の方の意見を広く求めるとともに、記録を残しておく目的で議事録をベースに補足したものを公開するものです。

 間違い、補足などございましたらご意見いただければ幸いです。なお、当ブログはコメント許可制を取っているため、反映に時間がかかります。あらかじめご理解ください。
 方針としましてはW3C文書「日本語組版処理の要件」(JLREQ)を先頭から読んでいき、各要素に対応するCSSが存在するのか、存在するとして実用段階なのか、InDesignなどの組版ソフトではどういった形で機能を実現しているのか(いないのか)、などについて見ています。なお全体に対しての包括的な説明の部分に関しては、細かな部分は次回以降にその部分の説明が出てきた時に掘り下げる、としてスルーしている箇所があります。

 なお、こちらで取り上げております各CSSプロパティはまだドラフト仕様の段階のものも多いため、今現在すぐに使えるものばかりではありません。Webブラウザで使用出来るかどうかはこちらなどでご確認ください。また、電子書籍のRSで使用出来るかどうかは、現在広範に調査した資料がありません。いずれ当研究会の活動として調査を行いたく考えていますが、しばらく時間はかかるかと思います。

JLREQ 3.5 段落整形,そろえ及び段落末尾処理

 JLREQ内の表記で段落の定義がちょっと整理されていない感がある(木枝さん)との感想があった。
 横組みで採用されていることがあるという説明文の図版の例は縦組みだったりもするようだ。
 なお、ちょっと気がついたのだが、段落先頭にカギ類が来た際の挙動の説明がここにはない。3.1.5で説明済みだからというのはわかるのだが、JLREQが海外の規格策定/ソフトウェア実装担当者の間で辞書的な使われ方をしている実態がある以上、参照リンク程度の配慮はあってもよいのではないかと思う。全部を読み通さないと全体像が見えないというのはこうした文書の性格上よくないと考える。

CSS:ぶら下がりインデント
CSS Text Module Level3 9.1. First Line Indentation: the text-indent property
CSS Text Module Level3でプロパティが多少変わっている。具体的にはhangingというプロパティが追加されており、従来はpaddingとtext-indentを組み合わせることでぶら下がりインデントのレイアウトを再現していたが、text-indent単独で出来るようになっている。また、each-lineは<br/>で強制改行をした後の処理の指定。each-lineを付けておくと<br/>改行の後もtext-indentの処理が行われる。
※試してみたところ、Chromeでは問題なく使えるものの、Firefox、Safariでダメ。まだまだ実際に使うのは難しい模様。

CSS Lists Module Level3
CSS Lists and Counter ModuleからエディターズドラフトでListsのみ分岐。
3.5. Positioning Markers: The list-style-position property
リストのマーカーをどこに置くかの指定。デフォルト(従来のリストの挙動)はoutsideで、ぶら下がりインデント的な組版になる。insideを指定すると普通に行の先頭にマーカーが配置される。insideを指定した上でぶら下がりインデントにするには別途text-indent等で指定が必要になる。

JLREQ 3.5.2 字下げと字上げ

 段落単位の字下げ、字上げについての解説。InDesignでは段落パレットで設定する部分。
※引用文を本文と区別するために字下げする例の解説がある。これは今日ではよりバリエーション豊かな表現が気軽に行えるようになったため、引用部分のフォントを変えるなどといった処理と併せて行われることが多いと思われる。

JLREQ 3.5.3 そろえの処理

 中央そろえ、行頭そろえ、行末そろえ、均等割りなど各行揃え指定の解説。

CSS:行揃え
CSS Text Module Level 3 7.1. Text Alignment: the text-align shorthand
行揃えはCSSではtext-alignで指定する。CSS Text Module Level 3からtext-alignはshorthand(略式プロパティ)となり、個別プロパティとしてtext-align-alltext-align-lastが策定された。text-align-allが段落全体の行揃えの挙動、text-align-lastが段落最終行の挙動。JLREQの図157の右下のような組版例(均等割り)はtext-align-last:justifyの指定で実現できるはず。この指定でChromeでは全行の均等配置の再現が確認できた。規格としてはtext-align:justify-allでも本来は同じ挙動になるはずだが、まだこれは実装されていない模様。
なおtext-alignのstart、end指定は日本語ではleft、rightと同じ挙動。アラビア語などで位置が入れ替わったりはする。justifyは最後の行以外が均等配置になる。

また、7.4. Justification Method: the text-justify propertyではjusify時にどこを空けて調整するかの指定ができる。日本語は通常わかち書きを行わないため、文字間を均等に空けてjusifyの挙動を実現することになる。これがinter-characterinter-wordは英語などで行われる語間スペース調整によるjusifyの挙動の指定。noneを指定するとjusifyを行わないことになるため、text-align:left指定と同様の組版になるはず。デフォルト値はautoで、言語によって適切と思われるjusifyの処理を行う。

JLREQ 3.5.4 段落末尾処理

 「段落の最終行の文字数が,ある文字数未満になることを避けるための処理のことである.ウィドウ(widow)処理ともいう.」
※「オーファン」という語もある。「参照:ウィドウは一行はみ出ること。オーファンは頭の1行目で改ページ(もしくは改段)になること」。

CSS:ウィドウ・オーファンの処理
CSS Fragmentation Module Level 3 3.3. Breaks Between Lines: orphans, widows
「[ orphans/widows ]プロパティは、ブロックコンテナ内の分断において,その[ 前/後 ]に[ 断片内に残さなければならない最小の行ボックス数 ]を指定する。 後述にて、これらを利用して分断を制御する例を与える。」
widows:2;
orphans:3;
のように指定する。
デフォルト値は2。

JLREQ 3.6 タブ処理

 タブはそもそもかなりの部分が表組みと共通する。もともとの技術的な起源が違うために項目が分かれているだけではないか。
 ただ、いわゆる目次でのリーダー後の同一行ノンブル文末揃えのような組版はタブを使わないと実現できない。これはCSS Generated Content Module Level 3 2.5.1 The leader() functionでできるようになるはず。リーダーを入れず、空白にすることもできる。
 また、タブは項目内での複数行配置を想定しておらず、1次元の配列が折り返していくところが表とは違うのではないかという意見も出た(村上さん)。
 なお図160の図はタブの例としてあまり良くないのではないかという意見もあった。もっと通常の表組みでは実現できない例が欲しい。

JLREQ 3.6.2 タブ処理で指定する配置位置にそろえる形式

 タブの揃え位置のバリエーション解説。左(上)そろえタブ、右(下)そろえタブ、中央そろえタブ、指定文字そろえタブ(小数点など)。InDesignのタブ揃えの実装もこれと同様のオプションがある。

CSS:テーブルの中での小数点揃え
CSS Text Module Level 4 9. Alignment and Justification
9.1. Character-based Alignment in a Table ColumnのExample8にあるように、
text-align: "." center;
のような指定でピリオド揃えのセンタリングができるようになる。
text-align: "." right;
なら右揃えで小数点の桁数が揃ってなくても揃えてくれるようになるはず。

JLREQ 3.7 その他の行組版処理

 添え字処理、振分け処理、字取り処理、等号類と演算記号の処理についてそれぞれ解説している。

JLREQ 3.7.1 添え字処理

 添え字処理。まずHTMLのタグとして<sup><sub>がある。いわゆる上付き下付き文字指定。
 複雑なものに関しては数式組版で対応することになる。MathMLなどへの対応が必要か。それでも数字などの細かい位置決めは難しい。Webでの数式組版は現状MathJaxを利用するのが一般的なようだが、これはJavaScriptを用いているため現状EPUB等ではほぼ使えない(電子ペーパー端末でのJavaScriptを用いたインタラクティブ表現の表示再現性の問題や、セキュリティの観点からJavaScriptを禁止しているビューアもある)。

CSS:上付き/下付き
CSS Inline Layout Level3 2.2. Transverse Box Alignment: the vertical-align property
行中での文字の表示位置指定。この項目はvertical-alignがshorthand扱いとなっており、個別プロパティとしてbaseline-shiftalignment-baselineが設定されてはいるが、実際にはshorthandのvertical-alignを使うことという注意書きがある。全体での整合性を取るためにこういった仕様にしたようだ。

alignment-baselineはどのベースラインを基準として上付き下付きにするかの指定。text-topとtop、text-bottomとbottomの挙動の違いはこちらを参照。text-topでは親要素へのline-height指定を継承するので、一見topが下に来たりbottomが上に来たりする挙動になったりするが、ベースラインシフトさせたい部分の文字のline-heightを適切に指定してやればきちんと字義どおりの挙動になるはず。

baseline-shiftはsub、superなどの指定で上付き下付きを指定できるほか、ベースラインシフトの量を絶対値や文字のシフト量をpxの数値やline-heightに対するパーセンテージで指定することができる(これはもうできる)。

今後Level3が勧告の段階に移れば、ベースラインの基準値(alignment-baseline)としてalphabeticideographiccentralmathematicalcenter が指定できるようになるほか、「vertical-align: top 10px」といった形で双方の値を組み合わせて指定できるようになる模様。

なお、化学記号などで上付き/下付きの文字を使う場合には親文字との分離禁止が課題になるが、文字の分離禁止にはいくつかの方法がある。現状無難なのは分割禁止部分をspanでくくってwhite-space:nowrap指定を行う方法。いずれwrap-after:avoid,wrap-before:avoidなどが実装されればそちらでもできるようになるはず(spanで括る必要がなくなる)。また、分割禁止文字を挿入する方法としてU+2060(WORD JOINER)を入れることでも同様の挙動になるはずだが、現状まだChromeではこれは動作しない。

今回はここまで。次回はJLREQ 3.7.2から。

(2017.11.9)

プロフィール
Jun Tajima

こちらにて、電子書籍&Web制作を担当しています。
このブログは、EPUB3をはじめとした電子書籍制作担当オペレータからの、「電子書籍の制作時にたとえばこんな問題が出てきていますよ」的な「現地レポート」です。少しでも早い段階で快適な電子書籍閲覧・制作環境が整うことを願って、現場からの声を発信していこうと目論んでおります。

当ブログ内の記事・資料は、私の所属しております組織の許諾を得て掲載していますが、内容は私個人の見解に基づくものであり、所属する組織の見解を代表するものではありません。また、本ブログの情報・ツールを利用したことにより、直接的あるいは間接的に損害や債務が発生した場合でも、私および私の所属する組織は一切の責任を負いかねます。