未分類 | 電書魂

‘未分類’ カテゴリーのアーカイブ

IDMLでの自動組版を試してみる

2017/09/05

　先日、知人の@macneko_ayuさんたちが開催した「DTPerのスクリプトもくもく会 #2」に参加してきました。まあセミナーじゃないのでその場でみんなもくもく何かを作ってるだけなんですが、家で一人でやるっていうとどうしても気が散るのでなかなかよい会だったかなと。で、#3も近いことなので、当日もくもく作ってたものを出しておこうかなと思います。

IDMLを使った自動組版処理の初歩的実験

IDMLファイルの中身

　InDesignから書き出せるファイル形式のひとつにIDML（InDesign Markup Language）というものがあります。これはInDesignの通常の記録ファイルと完全な互換性はないのですが、ほとんどの内部情報を保ったまま下位バージョンで開けるようになるため、やむを得ず下位バージョンでデータを開くような場合に使われたりしています。で、このIDMLは実はZIPのパッケージファイルで、解凍すると中にXMLファイルや画像ファイルが階層化されて収納されているのが確認できます。
　であるならば、

あらかじめ決められた名称で差し替え部分のテキストを作ったInDesignのデータを作り
それをテンプレートとしてIDML形式で書き出し
IDMLをテンポラリ領域にプログラムで解凍し
別途差し替え用のテキストデータを（CSVなどで）読み込んで、解凍したIDML内テキストに対して置換処理を行い
置換処理完了後のIDMLをリネームして出力する

　というような手順で簡単な自動組版処理ができるのではないかなと考えました。

普通に再圧縮してもダメ

普通に圧縮しても開けない

　まず最初にこの手順を手動でやってみたのですが、どうやら普通にZIP形式で再圧縮してもInDesignで読み込めないようです。ちょっと調べてみるとこちらのフォーラムに情報が。
　なるほど、mimetypeを非圧縮の状態でZIPファイルの先頭に置かなきゃダメと。要はEPUBと同じですね。話が早い。

　ということで作ってみたコードが以下。macのターミナル画面で

perl csv2idml.pl CSVファイルのパス IDMLテンプレートファイルのパス最終出力先フォルダのパス

　と入力すれば動くはず。ああ、CSVを扱うためのモジュールとしてText::CSV_XSを使ってますのでCPANから入れる必要があります。このあたり参考にどうぞ。

#! /usr/bin/perl
use utf8;
use Encode qw/encode decode/;
use Text::CSV_XS;
use File::Basename qw/basename dirname/;
use Archive::Extract;
use File::Path;
use File::Find;

#変換CSVファイルのパスを取得
my $convertCsvFilePath = $ARGV[0];
$convertCsvFilePath = decode('UTF-8', $convertCsvFilePath);

#IDMLテンプレートファイルのパスを取得
my $idmlTemplatePath = $ARGV[1];
$idmlTemplatePath = decode('UTF-8', $idmlTemplatePath);

#最終出力先のパスを取得
my $exportFolderPath = $ARGV[2];
$exportFolderPath = decode('UTF-8', $exportFolderPath);

#idml一時解凍フォルダ名を拡張子抜きで取得
my $idmlTmpFolderName = basename ($idmlTemplatePath, ".idml");
#idml一時解凍フォルダパスの合成
my $idmlTmpFolderPath;
$idmlTmpFolderPath = '/tmp/' . $idmlTmpFolderName;
#同一フォルダが存在したら連番をつける処理
my $mynum = 1;
if (-d $idmlTmpFolderPath){
  while (-d $idmlTmpFolderPath){
    $idmlTmpFolderPath = ('/tmp/' . $idmlTmpFolderName . '_' . $mynum);
    $mynum++;
  }
}

#出力IDMLファイルの連番指定
my $exportIdmlNum = 1;

#各CSVファイルを展開
open(IN,"$convertCsvFilePath");
@eachLineTxts = <IN>;
close (IN);

my @xmlfilePaths;
#最初の1回目用のidml置換処理一時フォルダをtmpに作成
@xmlfilePaths = & unzipIdml2Tmp ($idmlTmpFolderPath);

my $countNum = 0;
foreach $eachline(@eachLineTxts){
  #カウントが10だったらIDMLを出力／IDML出力番号加算／tmpフォルダの中身を消す／新たにテンプレートからidmlをコピー／カウントをリセット
  if ($countNum == 10){
    #idmlファイル出力
    #出力先パスの決定
    my $idmlExportPath = $exportFolderPath . "/" . "file" . $exportIdmlNum . ".idml";
    #出力実行
    my $syscommand = 'cd ' . '"' . $idmlTmpFolderPath . '"' . ';zip -0 -X ../tmpIdmlFile.idml mimetype;zip -r ../tmpIdmlFile.idml * -x mimetype */.DS_Store */*/.DS_Store */*/*/.DS_Store;cd ..;mv -f tmpIdmlFile.idml ' . '"' . $idmlExportPath . '"';
    system $syscommand;
    $exportIdmlNum++;
    #一時ファイルの削除
    rmtree($idmlTmpFolderPath);
    #idml置換処理一時フォルダをtmpに作成
    my @xmlfilePaths = & unzipIdml2Tmp ($idmlTmpFolderPath);
    $countNum = 1;
  } else {
      $countNum++;
  }

  #置換処理
  #CSVをパースして変数に入れる
  my $csvRef = Text::CSV_XS->new({binary => 1});
  $csvRef->parse($eachline);
  my @eachparameters = $csvRef->fields;
  my $titleNameString = $eachparameters[0];
  my $fullNameString = $eachparameters[1];
  #名前が空欄だったら処理せず、そうでなければ置換実行
  if ($fullNameString eq ""){
    next;
  } else {
    & idmlReplace ($titleNameString,$fullNameString,$countNum,\@xmlfilePaths);
  }
}

#idmlファイル出力（余り部分）
#出力先パスの決定
my $idmlExportPath = $exportFolderPath . "/" . "file" . $exportIdmlNum . ".idml";
#出力実行
my $syscommand = 'cd ' . '"' . $idmlTmpFolderPath . '"' . ';zip -0 -X ../tmpIdmlFile.idml mimetype;zip -r ../tmpIdmlFile.idml * -x mimetype */.DS_Store */*/.DS_Store */*/*/.DS_Store;cd ..;mv -f tmpIdmlFile.idml ' . '"' . $idmlExportPath . '"';
system $syscommand;
#一時ファイルの最終削除
rmtree($idmlTmpFolderPath);
exit;

#IDMLをテンポラリフォルダに解凍
sub unzipIdml2Tmp {
  my $idmlTmpFolderPath = $_[0];
  #解凍実行
  my $idmlArchive = Archive::Extract->new(archive => $idmlTemplatePath,type => 'zip') or die;
  $idmlArchive->extract(to => $idmlTmpFolderPath);
  #IDML一時作業フォルダ内の各XMLファイルのパスリストを取得
  my @xmlfilePaths;
  find(\&getEachFile, $idmlTmpFolderPath);
  sub getEachFile {
    my $file = $_;
    my $path = $File::Find::name;
    push(@xmlfilePaths,$path) if ($path =~ /^.*?\/Story_.*?\.xml$/);
  }
  return @xmlfilePaths;
}

#IDML置換サブルーチン
sub idmlReplace {
  #置換テキストの取得
  my $titleName = $_[0];
  my $fullName = $_[1];
  my $replaceNum = $_[2];
  my @xmlfilePaths = @{$_[3]};

  my $titlenameMarge = "■■■肩書き" . $replaceNum . "■■■";
  my $fullnameMarge = "■■■名前" . $replaceNum . "■■■";
  foreach $openFilePath(@xmlfilePaths){
    open(IN,"$openFilePath");
    #連結処理
    my @eachXmlLineTxts = <IN>;
    my $joinedTxt = join("",@eachXmlLineTxts);
    $joinedTxt = decode('UTF-8', $joinedTxt);
    close (IN);
    #置換処理
    $joinedTxt =~ s@$titlenameMarge@$titleName@g;
    $joinedTxt =~ s@$fullnameMarge@$fullName@g;
    #出力
    $joinedTxt = encode('UTF-8', $joinedTxt);
    open(OUT,"> $openFilePath");
    print OUT $joinedTxt;
    close (OUT);
  }
}

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

#! /usr/bin/perl

use utf8;

use Encode qw/encode decode/;

use Text::CSV_XS;

use File::Basename qw/basename dirname/;

use Archive::Extract;

use File::Path;

use File::Find;

#変換CSVファイルのパスを取得

my $convertCsvFilePath = $ARGV[0];

$convertCsvFilePath = decode('UTF-8', $convertCsvFilePath);

#IDMLテンプレートファイルのパスを取得

my $idmlTemplatePath = $ARGV[1];

$idmlTemplatePath = decode('UTF-8', $idmlTemplatePath);

#最終出力先のパスを取得

my $exportFolderPath = $ARGV[2];

$exportFolderPath = decode('UTF-8', $exportFolderPath);

#idml一時解凍フォルダ名を拡張子抜きで取得

my $idmlTmpFolderName = basename ($idmlTemplatePath, ".idml");

#idml一時解凍フォルダパスの合成

my $idmlTmpFolderPath;

$idmlTmpFolderPath = '/tmp/' . $idmlTmpFolderName;

#同一フォルダが存在したら連番をつける処理

my $mynum = 1;

if (-d $idmlTmpFolderPath){

while (-d $idmlTmpFolderPath){

$idmlTmpFolderPath = ('/tmp/' . $idmlTmpFolderName . '_' . $mynum);

$mynum++;

}

#出力IDMLファイルの連番指定

my $exportIdmlNum = 1;

#各CSVファイルを展開

open(IN,"$convertCsvFilePath");

@eachLineTxts = <IN>;

close (IN);

my @xmlfilePaths;

#最初の1回目用のidml置換処理一時フォルダをtmpに作成

@xmlfilePaths = & unzipIdml2Tmp ($idmlTmpFolderPath);

my $countNum = 0;

foreach $eachline(@eachLineTxts){

#カウントが10だったらIDMLを出力／IDML出力番号加算／tmpフォルダの中身を消す／新たにテンプレートからidmlをコピー／カウントをリセット

if ($countNum == 10){

#idmlファイル出力

#出力先パスの決定

my $idmlExportPath = $exportFolderPath . "/" . "file" . $exportIdmlNum . ".idml";

#出力実行

my $syscommand = 'cd ' . '"' . $idmlTmpFolderPath . '"' . ';zip -0 -X ../tmpIdmlFile.idml mimetype;zip -r ../tmpIdmlFile.idml * -x mimetype */.DS_Store */*/.DS_Store */*/*/.DS_Store;cd ..;mv -f tmpIdmlFile.idml ' . '"' . $idmlExportPath . '"';

system $syscommand;

$exportIdmlNum++;

#一時ファイルの削除

rmtree($idmlTmpFolderPath);

#idml置換処理一時フォルダをtmpに作成

my @xmlfilePaths = & unzipIdml2Tmp ($idmlTmpFolderPath);

$countNum = 1;

} else {

$countNum++;

}

#置換処理

#CSVをパースして変数に入れる

my $csvRef = Text::CSV_XS->new({binary => 1});

$csvRef->parse($eachline);

my @eachparameters = $csvRef->fields;

my $titleNameString = $eachparameters[0];

my $fullNameString = $eachparameters[1];

#名前が空欄だったら処理せず、そうでなければ置換実行

if ($fullNameString eq ""){

next;

} else {

& idmlReplace ($titleNameString,$fullNameString,$countNum,\@xmlfilePaths);

}

#idmlファイル出力（余り部分）

#出力先パスの決定

my $idmlExportPath = $exportFolderPath . "/" . "file" . $exportIdmlNum . ".idml";

#出力実行

system $syscommand;

#一時ファイルの最終削除

rmtree($idmlTmpFolderPath);

exit;

#IDMLをテンポラリフォルダに解凍

sub unzipIdml2Tmp {

my $idmlTmpFolderPath = $_[0];

#解凍実行

my $idmlArchive = Archive::Extract->new(archive => $idmlTemplatePath,type => 'zip') or die;

$idmlArchive->extract(to => $idmlTmpFolderPath);

#IDML一時作業フォルダ内の各XMLファイルのパスリストを取得

my @xmlfilePaths;

find(\&getEachFile, $idmlTmpFolderPath);

sub getEachFile {

my $file = $_;

my $path = $File::Find::name;

push(@xmlfilePaths,$path) if ($path =~ /^.*?\/Story_.*?\.xml$/);

}

return @xmlfilePaths;

}

#IDML置換サブルーチン

sub idmlReplace {

#置換テキストの取得

my $titleName = $_[0];

my $fullName = $_[1];

my $replaceNum = $_[2];

my @xmlfilePaths = @{$_[3]};

my $titlenameMarge = "■■■肩書き" . $replaceNum . "■■■";

my $fullnameMarge = "■■■名前" . $replaceNum . "■■■";

foreach $openFilePath(@xmlfilePaths){

open(IN,"$openFilePath");

#連結処理

my @eachXmlLineTxts = <IN>;

my $joinedTxt = join("",@eachXmlLineTxts);

$joinedTxt = decode('UTF-8', $joinedTxt);

close (IN);

#置換処理

$joinedTxt =~ s@$titlenameMarge@$titleName@g;

$joinedTxt =~ s@$fullnameMarge@$fullName@g;

#出力

$joinedTxt = encode('UTF-8', $joinedTxt);

open(OUT,"> $openFilePath");

print OUT $joinedTxt;

close (OUT);

}

このように変換された

　テスト用のIDMLのファイルとCSVファイルもセットで置いときます。ごく簡単な名刺のテンプレートですがまあテストなので。CSVの氏名はダミーとして自動生成させたものです。

◇

　今回のテストで簡単な置換処理ならIDMLベースでやれることがわかりました。まあInDesignのファイル結合とかでも同じことは当然できますが、これのポイントは自動処理の過程に一切InDesignそのものは噛ませてないことでしょうかね。つまりサーバ内に仕込んでも動くはず。もちろんお仕事として自動処理をやるにはこの程度のコード量では済まないでしょうが。なにしろ今回ロクにIDMLそのものの解析すらしてない（笑）。
　あ、@macneko_ayuさん、助言ありがとうございます。おかげで動きました。

（2017.9.6）

タグ: IDML, 自動組版
カテゴリー: 未分類 | コメントはまだありません »

JLREQとCSS（4）

2017/09/04

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

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

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

JLREQ 3.1.10 g 分割禁止

　改行による泣き別れを抑止する文字についての記述。
　gは「ルビ」について。ルビ文字と親文字はバラさない。モノルビは親文字単位ではバラしてよい。グループルビは全体を分割禁止する。ルビ自体に関しては後で詳しくやるのでここではこれまで。
　i 添え字。これも添え字と親字の分割は禁止。
　j 注の合印の分離禁止。HTML的にはa要素で合印を囲む形になるか。CSSでwhite-space:nowrapで合印内を分割禁止にできる。

　また、「○○（1）」のようなパターンでCSSを用いて合印とその直前の文字との間を分割禁止にするには、CSS Text Module Level4で論議中のwrap-before:avoidが使えるようになれば可能になるはず。

　あるいは現状で使える方法として、ノーブレークスペース（ ）を入れてもよい。また、U+2060（Word Joiner）も同様の効果を持つはずだが、こちらは一般的な日本語フォントにはコードポイントの割り当てがないようだ。

JLREQ 3.1.11 行の調整処理で字間を空ける処理に使用しない箇所

　文字のアケ処理について書いてある項目。空けすぎてはいけない部分などに関しての記述がある。「行の調整処理の際に，字間を空けて処理する場合，次の字間には空き量を入れることは避ける（分離禁止ともいう）」とある。分割禁止と分離禁止の用語の違いに注意。
　「規定された調整処理では処理できない場合に限り，欧字の単語の字間を空けることを許容する考え方もある」とあるが、欧文組版では組版調整に単語の字間を真っ先に使うのが普通。ここは昔ながらの欧文の字間は3分アキとしてきた日本の活版の慣習が残っている部分か。

　「b. 上記以外では，次も行の調整処理で字間を空ける箇所としては避ける．　1. 始め括弧類（cl-01）及び終わり括弧類（cl-02）の前及び後ろ．」
　ここは表記がちょっと不明瞭か。始め括弧類の後、終わり括弧類の前、ではないか。直後の注で補足してあるが。

JLREQ 3.1.12 行の調整処理例

　ツメ処理、アケ処理の具体的な適用例の記述がある。
　なお、CSS Text Module Level4で議論中の「text-spacing」で「no-compress」を指定すると、justificationでのツメ処理をしない。これを指定しないと文字ツメ処理が行われる。
　このあと3.8で文字ツメに関してはより詳しくやるのでここではここまで。

JLREQ 3.2.1 和文と欧文との混植

　日本語の文章内に欧文の文字を入れる際のバリエーションに関する記述がある。大別すると全角の文字を使っての正立表示、欧文の文字をそのまま入れて横転表示、数字などで使われる縦中横の3種類がある。

JLREQ 3.2.2 横組の和欧文混植に用いる文字

　「なお，欧文間隔は，三分アキを原則とする．」との記述があるのだが、ここは本来はそれぞれ欧文フォントが持つスペースのプロポーショナルな幅に従うべきとの意見が出た。この記述自体は古い日本の活版のルールが起源だと思われる。伝統的なルールの記録という意味でJLREQにこの記述があることは間違っていないが、現時点でそれに盲従すべきでもないと考える。

CSS：数字の字形の種類の指定
　font-variant-numericは数字の字形の指定項目。Old-Style、Tabuler（等幅）、Lining（高さが揃う）などが指定できる。ただし、もちろんフォント側がそのバリエーションを持っている必要はある。minionやGaramond Proなど新しいフォントは情報を持っているはず。例えばCentury OldStyleなどは作られた時期が古いため、こういったバリエーションは持っていない。

JLREQ 3.2.3 縦組の和欧文混植に用いる文字

　「プロポーショナルな文字を用い，全角のスペースに正常な向きにして配置する方法もある．」との記述があるが、「正常な向きにして」はちょっと表現的にどうだろうか。「正立させて」あたりが順当だと思う。雑感だが何を持って正常とするのかという宗教論争に発展しかねないと思う。

CSS：文字の正立／横転
　text-orientationで指定できる。uprightで正立、sidewaysで横転。段落全体に対して指定もできる。なお、関連する話として、UTR#50で論議されてきた縦書き時の文字の向きの既定値の話がある。これは最近Unicode10.0.0に正式に規格として入った。今後Webブラウザではこれをベースに何も指定しなかった際の文字の正立／横転の向きが決められるものと思われる。ただし、InDesignやWordなど、既存のアプリとの文字の向きの差異はずっと残ると思われる（過去のデータの互換性を考えると簡単に変更はできない）。

CSS：縦中横
　EPUB3策定前後でプロパティ名が目まぐるしく変わった項目。今の正式プロパティはtext-combine-uprightだが、昔はtext-combineでそのあとtext-combine-horizontalになっている。多くのRSでは古いプロパティでも縦中横になるが、今後はtext-combine-uprightを指定しておくのがもちろん正しいと思う。
　なお、text-combine-uprightでは単純に指定範囲を縦中横にする指定、「text-combine-upright:all」以外に、いわゆる自動縦中横の対応として「text-combine-upright: digits 2」といったような指定も可能になっている。ただしまだ数字の縦中横のみが想定されており、アルファベットや小数点はは範囲外。今後の提案と拡張が必要と思われる部分か。

JLREQ 3.2.4 全角のモノスペースの欧字及び全角のモノスペースのアラビア数字の配置方法

　図100に関連して「全角のモノスペースのアラビア数字の途中に小数点として中点[・] (KATAKANA MIDDLE DOT)を用いる場合は，漢数字の場合と同様に，原則としてその前後をベタ組とする．」とある。これは組版調整ありきで固定された版面をつくるための方法を記録したJLREQの記述としては良くわかるのだが、Webや電子書籍など組版調整が難しい分野でその中点が小数点なのかそうでないのかを自動判別して処理するのは難しそうである。「二、三点」などの場合に用いられる読点のベタ処理も同様。InDesignにはここの処理のために「連数字処理」というチェック項目があるが、組版処理的な弊害もあるため一律に使っておけば良いというものでもなく、難しそう。

JLREQ 3.2.5 縦中横の処理

　Opentypeのフォントは等幅半角字形、等幅3分字形、等幅4分字形などの情報を持っている。これらは縦中横組版の際に綺麗に1文字の幅に数字やアルファベットを収めるために作られたと思われるもので、InDesignでは字形パレットを通じて文字種を切り替えることができる。CSSではまだ十分に整備はされていないが、font-feature-settingsでOpenTypeのプロパティを直接指定すれば切り替わるかもしれない。等幅半角字形のプロパティは「hwid」、等幅3分字形は「twid」、等幅4分字形は「qwid」。ただし表示フォント側がそれに対応する字形の情報を持っていなければ当然適用はされない。ちょっと見てみた感じでは、一般的なAdobe-Japan1規格の日本語フォントでは、数字は等幅4分字形までの情報を持ち、英文字は等幅半角字形までの情報を持っているようだ。その他かな／カナも等幅半角字形にすることができそう。

CSS：縦中横でたくさん文字が入った場合の圧縮ルール
CSS Writing Modes Level 3に 「9.1.3 Compression Rule」として、縦中横でたくさん文字が入った場合の圧縮ルールの規定がある。それによれば、CSSでは全体で1emに収めることを規定している。ここはJLREQとは違うが、後から手動で組版調整ができないWebの特質を考慮すれば妥当と思う。また、表示フォント側にhwid、twid、qwidの情報がある場合はそれを使うことというような規定もある。なければ変形してどうにか1emに押し込む、という方針のようだ。

JLREQ 3.2.6 プロポーショナルな欧字を用いた和欧文混植処理

　「b.追込み処理で字間を詰める場合，その処理対象として欧文間隔を優先的に使用し，追出し処理で字間を空ける場合も，その処理対象として欧文間隔を優先的に使用する．」
　ここでは和欧間のスペースは3分という前提なら多少ツメてもよいだろうが、JIS X 4051の規定では和欧間のスペースは4分であるため、それを踏襲するのであれば4分よりもツメるのはツメすぎではないか、という意見が出た。なお現状Webや電子書籍などでは和欧間は自動で空かないが、将来的にはCSSでtext-spacingで自動でアキが入ることが期待される。

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

（2017.9.5）

タグ: CSS, JAGAT, JLREQ, W3C, Web技術を用いた日本語組版の現状, 日本語組版, 日本語組版処理の要件
カテゴリー: 未分類 | コメントはまだありません »

JLREQとCSS（3）

2017/08/04

JLREQ 3.1.4 始め括弧類，終わり括弧類，読点類，句点類及び中点類が連続する場合の配置方法

　例えば『」「』（閉じカギと開きカギが連続する場合）の間のスペースは前の文字に付くスペースなのか後ろの文字に付くスペースなのか。どちらに付くのかで例えば文字を拡大したときの挙動が変わる。

　これに対して次のような意見が出た。
　「どちらにつくものでもないので、（CSSの規格やRSの実装としては）前後の文字を二分モノと考えて、適宜スペースを挿入するという考え方もありではないか（小林さん）。」
　「適宜スペースを挿入してゆくとどこまでも字間が開いてしまうので、最大値を定めるのもありかもしれない（木枝さん）。」
　私個人の意見としては、現状「版面（というべきかどうか）のサイズを本文文字サイズの整数倍にする」というベタ組みの基本ルールが規格化されていないわけで、それを抜きにして個々の箇所のツメを厳密に決めてもほとんど意味がないと思っている。もし今後も当面ベタ組みの規格化が望めないのであれば、小林さんの案のようにスペースをある程度フレキシブルに伸縮できるものとするのがよいのではないか。その上で木枝さんの話のようにスペースによる調整量にリミットを設け、リミットを超過した場合には文字間を割って調整する形にするのがよさそう。

JLREQ 3.1.6 区切り約物及びハイフン類の配置方法

　「文末にくる区切り約物（疑問符・感嘆符）の前はベタ組とし，区切り約物の後ろは全角アキとする（図73）．ただし，区切り約物の後ろに終わり括弧類がくる場合は，この字間はベタ組とし，終わり括弧類の後ろを二分アキにする」
　！？の後のスペースが行頭に送られて字下げにならないように全角スペースのぶら下がりを許容するべきではないか、という意見が出ていた。

JLREQ 3.1.7 行頭禁則

　JLREQ本文には「終わり括弧類，ハイフン類，区切り約物，中点類，句点類，読点類，繰返し記号，長音記号，小書きの仮名及び割注終わり括弧類を行頭に配置してはならない（行頭禁則）．これは体裁がよくないからである．」とあるが、注の表記内でさまざまなバリエーションを記述してある模様。
※ベタ組みの横のラインの保持を優先し、長音記号や小書きの仮名の行頭配置を許容する考え方もあるよう。これは歴史のある出版社に多く見られるルールのようだ。

CSS：禁則
CSS Text Module Level 3　5.3. Line Breaking Rules: the line-break property
禁則に関しての規定。autoでは本来は一行文字数に応じて徐々に緩い禁則になる実装が期待されるが、実際にはあまりそういった実装はされておらず、Normalとほぼ同義になっているものと思われる。

JLREQ 3.1.9 行末に配置する終わり括弧類，句点類，読点類及び中点類の配置方法

　「行末に配置する終わり括弧類（cl-02），読点類（cl-07）及び句点類（cl-06）は，その後ろを原則として二分アキとする（図76 ）．」

　「（活字組版時代は，次の考え方が主流であった（図78 ）．として）行長に過不足が発生し，行の調整処理で詰める処理の必要がある場合（3.8 行の調整処理を参照），優先的に句点類，読点類及び終わり括弧類の後ろの二分アキをベタ組にする．これは，行末でもあり，これらの後ろの二分アキがベタ組になってもほとんど問題にならないからである．なお，この二分アキを中間的な四分アキにするという方法は採用されていなかった．二分アキ又はベタ組のいずれかを選択する，ということである．また，行の調整処理で詰める処理が必要な場合，句点類，読点類及び終わり括弧類の後ろの二分アキより優先順位は低くなるが，中点類の前後の四分アキをベタ組にする．」
※「そもそも活字の時代には全角の中黒しかなかった」とのこと。必要に応じて削っていたそう。そういった対処が必要だったことが、ツメ処理の優先順位で中点類がカギ類などより後になっていることに影響しているのではないか。
※JLREQはあくまで活版ペースでの記述なので、長体平体の記述はない。おそらく写植起源のため。

「DTPなどでは，行末に配置する句点類，読点類及び終わり括弧類のすべての後ろをベタ組とする処理法も行われている（図79 ）．」
これに対応するCSS指定がtext-spacingの「trim-end」。なお、「no-compress」という指定もあるが、これは後日JLREQ 3.8.2に関連して触れる予定なのでここでは深掘りしない。

JLREQ 3.1.10　分割禁止

「次のような文字・記号が連続する場合は，その字間で2行に分割しない（分割禁止）．これは，それらの文字・記号を一体として扱いたいためである．」
※分離禁止とは違う用語なので注意。
　JLREQでは二倍ダーシ、三点リーダ、アラビア数字の字間などの例が挙げられている。

※UnicodeでTWO-EM DASHという符合位置が規定されたのに対応して、2倍ダーシを独自グリフとして持っているフォントも出てきている（源ノ角ゴシックなど）。これは活版のグリフの再現と見ることもできそう。なお符合位置としてはTHREE-EM DASHも既にあるようだ。
※図84の123 4 のアキは位取りとのことだがほとんど見たことがない。用例はどのあたりだろうか？　また、ちょっとわかりにくく、誤植を疑ってしまったのでもう少し桁数を増やして欲しい。

CSS：分割禁止／許容
CSS Text Module Level 3　5.3. Breaking Rules for Letters: the ‘word-break’ property
・word-break:normal
一般的なルールに従って単語を分断する
・word-break:keep-all
単語の中での分断は禁止される。CJKの文字（漢字、かな、カナを含む）は分割されなくなる。
・word-break:break-all
normalでの分断可能部分に加えて、単語の中での分断も許容される。

　今回はここまで。次回はJLREQ 3.1.10のgから。

（2017.8.7）

CSS Text Module Level 3のリンク参照先を10 August 2017のワーキングドラフトに変更しました。

（2017.9.4更新）

タグ: CSS, JAGAT, JLREQ, W3C, Web技術を用いた日本語組版の現状, 日本語組版, 日本語組版処理の要件
カテゴリー: 未分類 | 2 件のコメント »