CAS-UB 昨日の定期メンテナンスでプリントオンデマンド(POD)用PDF出力機能を拡張しました

出版における、最近のはやり言葉はプリントオンデマンド(POD)なのですが、POD用のPDFと言っても実は結構いろいろあります。これは、印刷会社毎にPOD用の機械が違うためですが、PDFを作成する立場からはちょっと厄介です。

CAS-UBでは、いままでアマゾンのPODサービス仕様に準拠するPDFを出力していました。しかし、お客さんからhontoでPODをしたいという要望があり、今回hontoのPOD仕様を調べて機能追加しました。

○CAS-UBのPDF生成

POD版設定のボタンをクリックすると、現在のPDF設定(判型など)を基準にして、POD版設定を作ります。次の図で値は現在のPDF設定で、推奨値がPODにするときの推奨設定です。

○POD版設定

設定とPDFの見本は次のようになります。
・通常のPDF設定
裁ち切り:なし裁ち切り
トンボ :トンボを出力しない

①アマゾンのPOD
裁ち切り:天地と小口に裁ち切り
トンボ :トンボを出力しない

②hontoのPOD
裁ち切り:四辺に裁ち切り
トンボ :両方のトンボを出力する

○CASブロクPOD関係記事
CAS-UBのデモ動画 新ファイル : POD用PDFを用意して出版する
アマゾンPODの便利な利用法
オンデマンドブックストアでのPOD本の販売のこと
『XSL-FOの基礎 – XML を組版するためのレイアウト仕様』POD出版顛末記
PODで『XSL-FOの基礎』の出版を準備中です。
『PDFインフラストラクチャ解説』POD版とKDP版が揃い踏みとなりました
『Adventures of Huckleberry Finn』英語版POD本をつくりました
デジタル時代の本の再定義。 EPUBはPOD書籍普及のブレーク・スルーになるだろうか?
EPUBをアマゾンPOD用PDFに変換するツール、EPUB vs PDFの相違点など

一回使ったら止められない CAS-UBの超便利機能 UBテキストのご紹介

今年発売の『PDF CookBook』シリーズの制作では、UBテキストが大活躍です。2冊とも、アウトライン(章見出し、節見出し、項見出し)の作成はWordで行いました。アウトラインをCAS-UBにインポートして見出しを作った後のテキスト本文編集作業は、USテキスト形式で、ほとんど行なってしまいました。

さらに、Javaのサンプルプログラムを書いた担当者に、UBテキストを渡してプログラム部分を編集(重複している部分を最初に出現した箇所への参照に)してもらいました。UBテキストはwikiを拡張したものですので、プログラマであれば一目で内容が理解できるようです。

ご参考のために、下記に『PDF CookBook第2巻』の先頭部分のUBテキストをご紹介します。ちょっと長いですが、最初に簡単な解説をまとめます。

簡単な解説
(1) +で始まる一連の行ブロックは、UBテキスト全体、および各記事のヘッダラベルです。これはCAS-UBからUBテキストをダウンロードするときに自動的に付加される部分です。記事の階層構造(章⇒節⇒項)を表します。
(2) 各記事の本文にはCAS記法でマークアップしています。ここで使っている主なマークアップを紹介しますと:
・[[www.antenna.co.jp/ptl/]] :[[~]] URLリンクになります。
・[[[:index:key=あんごうかのアルゴリズム 暗号化のアルゴリズム]]] :単純な索引です。
・((:footnote [[https://ja.wikipedia.org/wiki/RC4]])) :脚注です。
・[[[:tbl =ISO 32000規定によるPDFバージョンと暗号アルゴリズム・暗号キー長の関係 ~ ]]] :表のブロック(表のキャプション)
・|=PDFバージョン|=使用できる暗号アルゴリズム|=暗号キー長| :表のヘッダ(セル)
・|PDF 1.3|RC4|40| :表の本体(セル)
・=狙い・効果 :見出し
・{{:width=50% GetCryptInfo-top.png}} :画像(width=50%は画像の幅指定)
・*ユーザーパスワードのみ設定されていると、… :箇条書きの1項目
・*[[[:mindex [[[:nodisp:prim API]]][[[:second setPassword() :暗号化されたPDF文書を読み込む際のパスワードを設定]]]]]] :親子の索引
・{{{ ~~~ }}} :整形済みブロック

CAS記法でマークアップの一覧表はこちらです

テキストエディタは使い易いものがいろいろあります。しかも、無料のものまであります。テキストエディタによる編集は、Webブラウザから操作するよりも、実に素早く便利です。

ここからUBテキストの例

+ updated: 2018-06-02T06:33:47+0900
+ ahax$kind: article
+ author: AuthoringOne
+ title: PDF CookBook 第2巻
+ name: publ

++++++++
+ updated: 2018-06-03T08:46:40+0900
+ ahax$kind: article
+ author: AuthoringOne
+ title: はじめに
+ name: i01-0001
+ ahax$parent: publ
+ ahax$entryClass: preface

『PDF CookBook』は、電子の紙PDFを企業向けのシステムで編集したり、加工したりする方法を紹介する本です。いわば、PDFをメイン素材とする料理本です。

(省略)

PDF Tool APIには無料でお使いいただける評価版を用意しています。次のページをご参照ください。

[[www.antenna.co.jp/ptl/]]

本書のプログラム例はJava で作成しています。本書で紹介しているプログラム例は次のページよりダウンロードしていただけます。

[[www.antenna.co.jp/ptl/cookbook/source/]]

(省略)

本書はシリーズ2巻目にあたります。第2巻では、PDF Tool APIの機能のうち第1章セキュリティ、第2章透かし、第3章しおりをテーマに取り上げています。シリーズ初巻には巻番号が付いていませんが、本書の本文中では『PDF CookBook』第1巻として参照しています。

++++++++
+ updated: 2018-06-03T08:46:40+0900
+ ahax$kind: article
+ author: AuthoringOne
+ title: セキュリティ
+ name: i02-0001
+ ahax$parent: publ
+ ahax$entryClass: chapter

ISO 32000-1:2008(以下、ISO 32000-1)は権限をもたないユーザーによるPDF文書へのアクセスを防止するための暗号化機能として、共通鍵(パスワード)による暗号化と公開鍵による暗号化の2種類を規定しています。本章の第1節ではパスワードによる暗号化の機能と使い方を説明します。PDF Tool APIは公開鍵による暗号化の機能はありません。

さらに、PDF Tool APIは、ISO 32000-1には規定されていない、独自の閲覧制限機能があります。第3節では独自の閲覧制限の使い方について説明します。

++++++++
+ updated: 2018-06-03T08:46:40+0900
+ ahax$kind: article
+ author: AuthoringOne
+ title: パスワードセキュリティ
+ name: i02-0002
+ ahax$parent: i02-0001
+ ahax$entryClass: section

PDF文書の内容はパスワードによって暗号化することで、権限をもたないユーザーによるアクセスを防止できます。ISO 32000-1の用語ではパスワードによる暗号化機能を標準セキュリティハンドラと呼びます。PDFは上位バージョンほど標準セキュリティハンドラの機能が強化されています。

標準セキュリティハンドラは[[[:index:key=あんごうかのアルゴリズム 暗号化のアルゴリズム]]]として[[[:index RC4]]]と[[[:index AES]]]のどちらかを選択します。当初から使われてきたのはRC4ですが、RC4には、既に脆弱性の点で問題が指摘されています((:footnote [[https://ja.wikipedia.org/wiki/RC4]]))。ASE 128の脆弱性は現時点では問題とされていないようです((:footnote [[ http://www.cryptrec.go.jp/topics/cryptrec_20110912_aes_cryptanalysis.html|128ビットブロック暗号AESの安全性について\\ http://www.cryptrec.go.jp/topics/cryptrec_20110912_aes_cryptanalysis.html]]))。

PDFのバージョンによって暗号化に使うキーの長さに制限があります。[[[:index:key=あんごうかのキーちょう 暗号化のキー長]]]はパスワードの文字数(パスワードの長さ)ではなく、標準セキュリティハンドラが内部的に計算して作成する値です。キーの作成方法はISO 32000-1で規定されています。

[[[:tbl =ISO 32000規定によるPDFバージョンと暗号アルゴリズム・暗号キー長の関係
|=PDFバージョン|=使用できる暗号アルゴリズム|=暗号キー長|
|PDF 1.3|RC4|40|
|PDF 1.4|RC4|40/128|

(省略)

|PDF 1.7アドビ拡張|AES|256|
|PDF 2.0|AES|256|

ISO 32000-1の仕様上は、PDF 1.4以降では暗号化のキー長は40ビット超128ビット以下の範囲で8の倍数単位で設定できます。しかし、PDFアプリケーションの多くは128ビットに固定しています。

]]]

PDF Tool APIでは暗号アルゴリズムの種類と暗号キーの長さを指定できます。

PDF Tool APIでは暗号化するときのキー長は40ビット、128ビット(256ビット)のどちらかを指定できます。一方、暗号を解読するときは8の倍数で可変のキー長の指定を受け付けます。

PDF Tool API V5では、AES 40ビットは設定できません((:footnote AESの仕様では暗号のキー長は128ビット以上とされています。ISO 32000-1でAES 40ビットを規定しているのは誤りの可能性があります。いずれにせよ新しく作成するPDF文書に40ビット暗号は使わないことを推奨します。)

(省略)

PDF Tool APIでは、入力PDF文書のバージョンと指定した暗号アルゴリズムと暗号キーの長さの組みによって、出力されるPDF文書のバージョンは、次表のようになります。

[[[:tbl =PDF Tool APIで出力されるPDF文書のバージョン
|=入力PDF文書のバージョン|=RC4 40|=RC4 128|=AES 128|=AES 256
|PDF 1.3|1.3|1.5|1.6|1.7
(省略)
|PDF 1.7|1.7|1.7|1.7|1.7
]]]

PDF文書には、[[[:index ユーザーパスワード]]]と[[[:index オーナーパスワード]]]のどちらか一方または両方を設定できます。ユーザーパスワードはPDF文書を開くためのパスワードです(詳細は[[##e.i02-0004.ユーザーパスワードによるセキュリティの設定]]を参照)。オーナーパスワードはPDF文書の利用権限を設定するパスワードです(詳細は[[##e.201805301211.オーナーパスワード]]を参照)。

ユーザーパスワードとオーナーパスワードは異なっている必要があります。

*ユーザーパスワードのみ設定されていると、ユーザーパスワードを入力してセキュリティの変更や解除ができます。
*オーナーパスワードのみ設定されていると、オーナーパスワードを入力してセキュリティの変更や解除ができます。
*ユーザーパスワードとオーナーパスワードの両方が設定されていると、(省略)

++++++++
+ updated: 2018-06-03T08:46:40+0900
+ ahax$kind: article
+ author: AuthoringOne
+ title: セキュリティ情報の取得
+ name: i02-0003
+ ahax$parent: i02-0002
+ ahax$entryClass: subsection

{{:width=50% GetCryptInfo-top.png}}

=狙い・効果

PDF文書のパスワードによる[[[:index:key=セキュリティのじょうほうをしゅとく セキュリティの情報を取得]]]します。

=処理の概要

PDF文書のセキュリティ設定は、PDF文書のトレイラーにある暗号辞書に記録されています。暗号辞書からユーザーパスワードの設定状況とオーナーパスワードの権限設定内容を取得して画面に表示します。入力PDF文書にユーザーパスワードが設定されているとき、PDF文書を開くには正しいパスワードの入力が必要です。

=PDF Tool APIの主な機能

*[[[:mindex [[[:nodisp:prim API]]][[[:second setPassword() :暗号化されたPDF文書を読み込む際のパスワードを設定]]]]]]

(省略)

*[[[:mindex [[[:nodisp:prim API]]][[[:second getType() :権限設定タイプ取得]]]]]]

=プログラム例

{{{
package cookbook;
import jp.co.antenna.ptl.*;
public class GetEncryptInfo {

(省略)

}
}
}}}

=プログラムファイル名

GetEncryptInfo.java

=入出力操作の例

{{:width=80% GetEncryptInfo.png}}

次は暗号化キー長256ビットのAESでオーナーパスワード設定したPDF文書の例です。

{{:width=80% GetEncryptInfo1.png}}

次は暗号化キー長256ビットのAESで添付ファイルのみ暗号化したPDF文書の例です。

{{:width=80% GetEncryptInfo-2.png}}

UBテキストによるフローは次のようになります。特に難しく考えることはなくテキストファイル(UBテキスト)のダウンロードとアップロードが追加になるだけです。

参考資料
[1] UBテキストの使用例 ― 記事の構成を変更する
[2] CAS-UBで編集中の出版物をダウンロードし、テキストエディタで編集し、元に戻す
[3] CAS-UBで編集中の出版物をダウンロードし、テキストエディタで編集し、元に戻す(2)UBテキスト
[4] CAS-UB V5にアップグレードしました。レスポンシブなWebページ生成や、UBテキスト機能の公開などが目玉です。
[5] CAS-UBで編集中の出版物をダウンロードし、テキストエディタで編集し、元に戻す

EPUB3電子出版におけるインターオペラビリティを考える

先日、CAS-UBのあるユーザーである出版社(版元)から、「これまで長いこと、CAS-UBで制作したEPUB3をBookLive!に配信してきたのですが、今度、これができなくなったのでCAS-UBで対応して欲しい。」という連絡をいただきました。

事情を確認しましたところ、「BookLive!に出すには、横書きではpackage.opfのspineにpage-progression-direction=”ltr”の設定が必要であり、設定しないとBookLive!側では入稿エラーになってしまう。今までは、取次がその版元のEPUB3データを修正してからBookLive!に配信していたが、大変なので版元の方で設定して欲しい」ということになったとのことです。

この根拠は、電書協ガイドver1.1.3のP.8に以下のような記載がある[1]こと、

パッケージ文書(Package Document / OPF ファイル)
ページ進行方向の遵守:コンテンツ文書やスタイルシートに記された「-epub-writing-mode」の指定にかかわらず、書籍データの「ページ進行方向」は、パッケージ文書の spine 要素に記された「page-progression-direction」の方向に従う。

さらに、取次から次のような連絡があったとのことです。

「電書協ガイドver1.1.3のP.29にある[sample code]にも「page-progression-direction」の記述があり、同梱されているサンプルファイル内のopfファイルにも「page-progression-direction」の記述がございますので、電書協ガイドver1.1.3に「page-progression-directionは必須」とは明記されておりませんが、電書協ガイドVer1.1.3では「page-progression-direction」の記述を入れることを推奨していると思われます。

「page-progression-direction」を記述していないと、ビューア側で独自に綴じ方向を判断することになりますので、「右綴じ」になるか「左綴じ」になるかはビューア側に任せる、ということになってしまいます。

そうなると、ビューアによっては御社の意図とは反対の綴じ方向になってしまうこともありますので、「綴じ方向が逆になっている」というユーザークレームに発展する恐れもございます。

なお、上記の文章は、電書協ガイドver1.1.3の引用だけでは趣旨が理解しにくいため、一部誤りを訂正のうえ無断転載させていただきました。取次さんも大変ですね。

ちなみにEPUB3.0.1の仕様では、この部分は次のようになっています[2]

page-progression-direction [optional]
The global direction in which the content flows.

Allowed values are ltr (left-to-right), rtl (right-to-left) and default.

When the default value is specified, the Author is expressing no preference and the Reading System may chose the rendering direction. This value must be assumed when the attribute is not specified.

これを見ますと、EPUB3仕様ではpage-progression-directionはオプション(省略可)となっており、しかも、省略されたらデフォルトと解釈しなければならないということです。従って、BookLive!がこうしたEPUB3を入稿エラーにするのは、EPUB3仕様違反となります。

また、電書協ガイドでも、page-progression-directionの該当箇所は、リーディングシステムに期待する動作の項ですから、EPUB3制作者への要求とはされていません。こうしたことから、BookLive!や取次の理解が間違っていると考えます。『「綴じ方向が逆になっている」というユーザークレームに発展する恐れ』って一体誰の発想なんでしょう? ブラックなジョークとしか思えませんが、もしかすると、BookLive!ってアラビア語とかヘブライ語のEPUB3も大量に配信されている世界? それともBookLive!はデフォルトを右開きにするかもしれない異次元空間?

さて、CAS-UBとしてはどうしたら良いでしょうか? 

考えてみますと、この件は「インターオペラビリティ」問題そのものです。

その典型的な例は、WebページとWebブラウザの関係、あるいは、PDF制作者とPDFリーダーの関係に見られます。Webの場合はWebページの文法が少々間違っていてもWebブラウザがなんとか表示できるようにする、という方法で普及してきた、といえます。PDFの場合も同じように少々間違ったPDFであってもAdobeリーダーができるだけ正しく表示しています。それはそれで困ることもありますが。

こうした例を見ますと、少々間違っていても読み手が対応するというのが、概ね利便性が高くなりますし、一般に広く成功を収める秘けつかもしれません。しかし、これは言うのは易しいのですが、リーダーを作る側に相当な体力が要求されます。ビジネスの成功は技術ではなく体力と気力によってもたらされるのが真実かもしれません。BookLive!のような正しいものを拒絶するというのは商売がへたなのでしょう。

(今回の場合、CAS-UBが作るEPUB3は仕様上は正しいですので、上の論点とは若干ズレがあります。念のため。)あまり仕様論・原則論にこだわらない解決策を考えようかと思案しております。

2018/6/22追記
2018年6月21日の定期保守更新にて、下記の仕様変更を行いました。
EPUB生成で、横書の出版物の.opf ファイルの に page-progression-direction=”ltr” を常に入れるように仕様を変更します。EPUBの仕様では、横書のとき page-progression-direction=”ltr” は省略可能ですが、省略を許していない販社があることへの対応です。

この問題は、CAS-UBで当面アラビア語やヘブライ語のような右から左に書く言語のEPUBを作れなくなるという制限が生まれることです。しかし、実際に問題になることはないでしょう。
定期保守更新の全体

[1] 『電書協 EPUB 3 制作ガイド ver.1.1.3』(2014/11/01(2015/01/01 更新、日本電子書籍出版社協会)「リーディングシステムに期待する動作」の一部の記述内容
[2] “EPUB Publications 3.0.1 Recommended Specification 26 June 2014”(International Digital Publishing Forum)3.4.12 The spine Element

『PDF CookBook 第2巻』を6月中旬発売します。第2巻はセキュリティと透かしがメインテーマです。

CAS電子出版は『PDF CookBook 第2巻』を6月中旬に発売します。本書は、『PDF CookBook』は、電子の紙PDFを企業向けのシステムで編集したり、加工したりする方法を紹介するPDFの料理本シリーズの2冊目です。

2018年08月24日 第2巻全文(Web版)をウエブサイトにて公開しました:『PDF CookBook 第2巻』(HTML)

『PDF CookBook 第2巻』PDF Tool API V5の使用を前提して作成しました。PDF Tool API V6では下記の仕様が変更となっています。

仕様変更点
2巻 セキュリティ
PtlEncryptPermissionType1クラス
・PERM_MODIFY_ASSENBLEANDFORM -> PERM_MODIFY_ASSEMBLEANDFORM

2巻 セキュリティ
PtlEncryptPermissionType2クラス 
・PERM_MODIFY_ASSENBLEDOC -> PERM_MODIFY_ASSEMBLEDOC
・getAccesibility -> getAccessibility
・setAccesibility -> setAccessibility

2巻 透かし
PtlParamWaterMarkクラス(本文中には掲載ありません)
setDipslayWaterMark -> setDisplayWaterMark
PtlPDFDocumentクラス
SAVE_OPTIONE -> SAVE_OPTION

第2巻では、PDFのセキュリティ設定や解除、PDFの透かしの設定や応用、しおりの追加や削除などのテーマを取り上げています。各機能の役割や目的、見込まれる効果の紹介と、利用例のサンプルプログラムとその結果例を項目ごとに載せています。

プログラミングがわからなくとも、PDFの機能についてなぜその機能があるのか理解を深めることができますし、開発者はサンプルプログラムを自分の環境で試すことができます。

PDFは米国のアドビ社が開発したものですが、PDFの仕様書はアドビ社からISO-International Organization for Standardizationに移管され、2008年にISO 32000-1:2008という国際標準となりました。こうして、PDF文書を作成したり、利用したりするアプリケーションは誰でも開発・提供できるようになっています。現在、さまざまなアプリケーションから大量にPDF文書が生み出されて流通しています。例えば、Microsoft Officeには10年ほど前からPDF形式保存機能があり、また、Windows 10にはPDF出力ドライバーが標準で付いています。主要なブラウザはPDFを表示する機能を内蔵しています。このように、この10年でPDFを作成・表示する環境は著しく進化・充実しています。これからはPDFを紙のように手軽に簡単に加工したいという需要がますます大きくなるでしょう。

本書では企業向けシステムの企画・営業担当者から開発者まで幅広い層にPDFの活用法をご理解いただけるよう、最初にできるだけ図版で料理のイメージを表すようにしました。包丁としては、アンテナハウスのPDF編集・加工ライブラリ「PDF Tool API」を前提としています。なお、本書ではISO 32000-1:2008で作成できるPDFの機能のうち、PDF Tool API V5がサポートしている範囲に限って説明しています。PDFの仕様で定められていることのすべてを網羅している訳ではありません。あらかじめご了承ください。

PDF Tool APIには無料でお使いいただける評価版を用意しています。また、本書のプログラム例はJavaで作成しています。本書で紹介しているプログラム例はダウンロードサイトより提供しています。

目次
はじめに
第1章 セキュリティ
1.1 パスワードセキュリティ
1.1.1 セキュリティ情報の取得
1.1.2 ユーザーパスワードによるセキュリティの設定
1.1.3 暗号化の対象
1.1.4 セキュリティの解除
1.2 オーナーパスワード
1.2.1 オーナーパスワードの設定
1.2.2 印刷不可セキュリティの設定
1.2.3 変更不可セキュリティの設定
1.2.4 内容のコピーの制限
1.2.5 アクセシビリティのための内容の抽出の制限
1.3 閲覧制限
1.3.1 閲覧期間の制限設定
1.3.2 閲覧場所の制限設定
1.3.3 閲覧制限設定をするページ範囲
第2章透かし
2.1 透かし(共通)
2.1.1 透かしの配置の設定―その1
2.1.2 透かしの配置の設定―その2
2.1.3 透かしを配置するページの範囲
2.1.4 透かしのZオーダーの指定
2.1.5 タイリング設定
2.1.6 透かしの不透明度
2.1.7 透かし表示条件:画面表示
2.1.8 透かし表示条件:印刷
2.1.9 透かしの名前
2.1.10 透かしの削除
2.2 テキスト透かし
2.2.1 テキスト透かしの挿入
2.2.2 透かしの改行
2.2.3 フッターにページ番号追加
2.2.4 透かしの挿入角度
2.2.5 フォントの設定
2.2.6 フォントの埋め込み設定
2.2.7 透かしの文字色
2.2.8 透かしの輪郭線
2.3 画像・PDF透かし
2.3.1 画像透かしの挿入
2.3.2 PDF透かしの挿入
2.3.3 透かしの枠線
2.3.4 倍率の設定
2.4 色透かし
2.4.1 色透かしの挿入
第3章しおり
3.1 しおりの情報取得・作成・編集・削除
3.1.1 しおり情報の取得
3.1.2 しおりの追加
3.1.3 しおりの削除
索引

紙版(プリントオンデマンド)
出版社: アンテナハウスCAS電子出版
発売日:2018年6月中旬
著者:アンテナハウス株式会社
販売形式:プリントオンデマンド版
サイズ:B5判 横組み
ページ数:126ページ
価格(税込):1,728円 6月18日アマゾンで発売になりました。
ISBN:978-4-900552-61-6
販売店:アマゾン(POD版)その他Web書店で発売予定

デジタル版(PDF)
販売形式:PDF版(DRMなし)
ページ数:126ページ
価格(税込み):864円 6月8日発売
販売店:アンテナハウス・オンラインショップ(PDFのダウンロード)※PDF版のダウンロードは自社ストアのみです。

Web版
全文公開中

シリーズ
[1]『PDF CookBook』(第1巻)
[2]『PDF CookBook 第3巻』

PDF Tool API
PDF Tool API Webページ

PDF文書の永続性、Web文書の揮発性

PDF文書とWeb文書にはいくつかの点で本質的な違いがあります。一番大きな違いは前者の永続性に対して、後者の揮発性ではないかと思います。

PDF文書の永続性とは
PDF文書のモデルは、紙にインクで印刷したのと同じ状態を再現することです。紙に書かれた情報は1つの物体としての形を備えています。そして、それは、消去されるまで永続的に、人間の目に見える状態は同じものとして保存されます。

Web文書の揮発性とは
それに対してWeb文書は、分散した情報を瞬時に探して端末に表示するモデルです。情報が分散配置されていることに特徴があります。リンクによって探し出される毎に、端末を経由して人間の目に触れるわけですが、その都度、人間の目に見える状態が変わります。Web文書は、次に可視化されるとき、今表示されている状態と同じである保証がありません。

現在、出版などでは紙からデジタル媒体への転換が進んでいます。しかし、デジタル媒体としてみたときには、PDF文書とWeb文書には上のような本質的な相違があります。こうしてデジタル媒体としては、WebとPDFが今後かなり長い間両立するだろうと予想します。

2018/06/21
PDF資料室に論点を整理した次の記事を掲載しました:
「PDFとWebにはどんな違いがありますか? インターネットやWebがますます普及するとしてPDFは使い続けられますか?」

ウイドウとオーファンって、なかなか深い 3大英文スタイルガイドの定義を比較する

欧文組版にウイドウ(widows)とオーファン(orphans)という言葉があります。しかし、有名な欧文組版に関するテキストブックで、ウイドウとオーファンについて調べて見ても意味がなかなか分かりません。

まず、そもそも定義がはっきりしていません。本によって違います。また、回避すべきかどうかの要求度も必ずしも一致していません。

例えば、Chicago Manual of Style (15th edition)では:

A page should not begin with the last line of a paragraph unless it is full measure, and should not end with the first line of a new paragraph. … (A very short line at the top of a page is known as a “widow”, a single word or part of a word at the end of a paragraph is an “orphan. “) (3.11 p, 94)

このChicago Manual 15版のOrphanの定義は間違いのような気がします。

Chicago Manual of Style (17th Edition)では次のように変わりました。(2018/6/23 17版について追加しました。)

A page should not end with a subhead. Nor should a page begin with the last line of a paragraph unless it is full measure; a short line in this position is sometimes called a widow. A page can, however, end with the first line of a new paragraph, or what is sometimes referred to as an orphan. (2.116)

Chicago Manual 17版ではOrphan の定義は変更になりました。あと、Orphanは明示的に許容に変更されました。これでOrphanについては3つのスタイルガイドは全部許容ということになります。

New Oxford Style Manual (2012)では:

The last line of a paragraph should not fall at the top of a new page or column: this is known as a widow. An orhpan―the first line of a paragraph that falls at the bottom of a page or culumn―is undesireble, though it is now tolerated in most bookwork.(2.5.2 p.46)

New HART’S Rules (Oxford press 2005)は、New Oxford Style Manualとほとんど同じ内容(2012)です[1] 。これらは比較的明確な定義です。但し、行の長さについては特に説明がありません。あとページだけではなく段も対象です。

The elements of typographic style (Robert Bringhursh, V4.2)では:

2.4.8 Never begin a page with the last line of a multi-line paragraph.

Isolated lines created when paragraphs begin on the last line of a page are known as orphans. … they need not trouble the typographer. The stub-ends left when paragraphs end on the first line of a page are called widows. It is the custom to give them one additional line for company. (pp. 43-44)

そもそもstub-endってなんだろう? stub-endなどというおそらくwidowよりも意味不明な言葉を定義文の中に持ち込むのは間違っていませんかねえ。

まず、widowはページ区切りで発生するものをいうか、段の区切りで発生するものを含めるかの相違があります。さらに、本によっては段落の区切りでwidowが発生するという文章もあります。

A widow (the term used for a single word ending a paragraph, that is, on a line of its own) …(Finer points in the spacing and arrangement of type, Geoffrey Dowding, Revised Edition Hartley & Marks, 1995 ISBN: 0-88179-119-9)

New HART’S Rulesによれば、出版社は段落の区切りのwidowを許容する方向に向かってきたということです。

欧文組版ではwidowについては、日本語組版よりもかなり嫌われる存在のようですが、そもそも定義があまりはっきりしていないのは困りますね。

関連
デジタル時代のレイアウトは、ユーザーの目に見えない神プロセス
組版の価値。組版と画面表示(レンダリング)の相違を考える。
「日本語組版における行配置の課題」(第1版)を配布開始

[1] New Oxford Style Manual (Oxford press 2012) は、前半がほとんどNew HART’S Rules (Oxford press 2005)であり、後半が辞書になっています。New HART’S Rulesから極一部の記述が変更されています。

※組版ではMeasureとはブロックまたはテキストのカラム幅のこと。

デジタル時代のレイアウトは、ユーザーの目に見えない神プロセス

『印刷用語ハンドブック』(帆風出版プロジェクト編、印刷学会出版部発行、2007年5月第2版)の3-3-5 レイアウトには、つぎのようにあります。

整理した原稿をまとめ組み立てる設計図で,文字,図,表,写真などの配置,大きさ,色など次工程への指示書となるものを指定することをレイアウト,または割付(わりつけ)といい,主にデザイナーの仕事である。(p. 72)

最近、ある案件で営業担当者からの相談がありました。お客さんはPDFにテキストボックス注釈をつけたいらしいのです。元のデータはデータベース(DB)に入っているらしいのにどうやってPDFがつくられるのか、営業担当者からお客さんに問い合わせしてもピンとくる返答が得られない、とのことです。

DBから新規にPDFを作り、その際に同時にテキストボックス注釈をつけるのであれば、弊社の製品では「AH Formatter」が最適です。AH Formatterでは、PDFへテキストボックス注釈を付けることができます。

AH Formatter
PDF出力における注釈

また、PDFが既にできているのであれば、弊社の製品では「PDF Tool API」で、PDFにテキストボックス注釈をつけられます。

PDF Tool API

ですので、PDFにテキスト注釈を付けるとして、それが:
①新しく作るPDFに対してなのか
②既存PDFに対してなのか
で弊社から提案するべき製品が異なります。

PDFにテキスト注釈をつける、という要件だけでなく、もう少し詳しい情報が必要です。

お客さんに面談させていただき、そのあたりを確認しました。そうしましたところ、どうやら、ご担当の方は、DBに入力すればPDFができると想定していたようです。

私たちのような組版ソフトのベンダーの担当者は、DBからPDFを作るにはレイアウト指定が必要、ということを常識として知っているわけです。しかし、普段、できあがったDBやWebを使っている立場から見ますと、フォームでデータを入力すれば自動的にPDFがでてくるように見えるわけです。

最初に紹介したアナログ印刷では、デザイナーという職種が担うレイアウト工程という役割分担があります。レイアウトが目に見える工程です。

それに対して、DBに入っているようなデジタルのデータからPDFを作るというデジタルな出版処理では、レイアウトという工程が利用者の目に見えなくなっています。

現代のデジタルパブリッシングにおいては、レイアウトはXSL-FOやCSSというレイアウト指定言語を使う開発者と自動組版ソフトが水面下で担うわけです。

ユーザーから見ますと、レイアウトは神プロセスです。

今週末 いよいよ技術書典4開催!

今週の日曜日(4月20日)はいよいよ技術書典4です。さあ! 技術書典の準備をしよう。

技術書典4
サークル詳細 | アンテナハウスCAS電子出版

初回の技術書典は好天でしたが、第2回・第3回は大雨で、技術書典といえば雨という記憶が残っています。天気予報では日曜日は晴れのようです。

主な出品書籍

PDF CookBook 『PDF CookBook』は、PDFを企業向けのシステムで編集したり、加工したりする方法を紹介する、いわば、PDFをメイン素材とする料理本です。
タグ付きPDF 仕組と制作方法解説 タグ付きPDFとは、内部に文書構造を埋め込んだPDFのことです。PDFをコンピュータで読み上げたり、PDF内のデータをオフィスアプリやWebページなどに再利用したりするときに有効です。
PDFインフラストラクチャ解説 第1.1版 PDFについての解説と最新情報を網羅。PDFの基本的な知識から専門的な情報まで一通り述べています。
MathML数式組版入門Ver1.1 数式記述言語MathMLを使って数式組版を行うためのガイドです。これからMathMLを学習する方も、Web上のサンプルをコピー&ペーストしてなんとなく使っていた方も、この一冊でMathMLの基本がよく分かる構成になっています。
XSL-FOの基礎【第2版】 XSL-FO(Extensible Stylesheet Language)は、XML を印刷するためのレイアウト指定用標準言語の一つです。本書では主として XSL-FOプロセサを利用する人を想定し、XSL-FO 仕様の要点を図やサンプルを使って解説しました。

アンテナハウス PDF/XML関連技術書POD版直販
アンテナハウス書籍・総合目録 プリントオンデマンド出版と電子出版

41項目のPDF料理を紹介する『PDF CookBook』4月発行! 技術書典4 でも販売します

CAS電子出版より『PDF CookBook』を4月発売します。

2018年08月24日 第1巻全文(Web版)をウエブサイトにて公開しました:『PDF CookBook』(HTML)

『PDF CookBook』第1巻はPDF Tool API V5の使用を前提して作成しましたが、説明文とソースプログラムはPDF Tool API V6でも変更ありません。そのままお使いいただけます。

PDFは、紙に印刷する情報を表現する電子ファイルで、デジタル時代の紙にあたります。現在、企業で使う文書を中心に紙からPDFへの転換が進んでおり、これからはPDFを紙のように手軽に簡単に編集・加工したいというニーズがますます大きくなるでしょう。『PDF CookBook』はPDFを編集・加工する方法を紹介する、いわば、PDFをメイン素材とする料理本です。

現在、さまざまなアプリケーションから大量にPDFが生み出されて流通しています。例えば、Microsoft Office には10年ほど前からPDF形式保存機能があり、また、Windows10 にはPDF出力ドライバーが標準で付くようになりました。本書の著者であるアンテナハウスからもマニュアルの原稿などを高度なレイアウトで自動組版してPDFにするソフト[1]や、廉価なPDF作成ソフト[2]も提供しています。また、主要なブラウザはPDFを表示する機能を内蔵しています。このように、この10年でPDFを作成・表示する環境は著しく進化・充実しています。PDFはWebと並んで身近になっているといえます。

本書では企業向けシステムの企画・営業担当者から開発者まで幅広い層を想定読者としています。初心者にもPDFの活用法をご理解いただけるよう、最初に図版でPDF料理のイメージを表すようにしました。PDFを調理する包丁としては、アンテナハウスのPDF編集・加工ライブラリ「PDF Tool API V5」[3]を前提としています。それぞれの課題に対して、実際にPDFをさまざまに調理するJavaプログラムのサンプルを紹介しています。また、プログラムを実際に使ってPDFを加工する実例も示しました。本書で紹介しているプログラムは、別途、Webページから配布しています。

なお、本書ではISO 32000-1:2008で作成できるPDFの機能のうち、「PDF Tool API V5」で使用できる範囲に限って説明しています。PDFの仕様で定められている機能のすべてを網羅している訳ではありません。あらかじめご了承ください。

目次
はじめに
第1章 PDF 文書のページ
1.1 ページ編集
1.1.1 総ページ数の取得
1.1.2 PDF 文書の結合
1.1.3 ページの抽出
1.1.4 ページの削除
1.1.5 PDF 文書の分割
1.1.6 白紙ページの挿入
1.1.7 ページの移動
1.2 ページサイズ、方向および余白
1.2.1 ページ境界値の取得
1.2.2 ページ境界値の設定
1.2.3 ページ周囲の余白を断裁
1.2.4 ページ周囲に余白を追加
1.2.5 ページを上下左右に分割
1.2.6 ページの拡大・縮小
1.2.7 用紙の向きを揃える
第2章 PDF 文書の本文描画
2.1 テキスト描画
2.1.1 本文テキストの追加
2.1.2 フォントの設定
2.1.3 文字の色指定
2.1.4 文字の輪郭線の色
2.1.5 描画テキストの不透明度
2.1.6 文字列の回転出力
2.1.7 縦書き文字列描画
2.1.8 帳票へ文字記入
2.2 画像描画
2.2.1 ページ上に画像を描画
2.2.2 画像の拡大・縮小描画
2.2.3 解像度(dpi)の設定
2.2.4 印鑑画像を捺印
2.2.5 QR コードを配置
2.2.6 透明度の設定
2.2.7 マスク処理:ステンシルマスク
2.2.8 マスク処理:カラーキーマスク
2.2.9 マスク処理:明示マスク
2.2.10 マスク処理:ソフトマスク
2.3 PDF ページを描画
2.3.1 PDF のページを貼り付け
2.3.2 ページ割り付け
2.3.3 PDF 文書として用意した印鑑を捺印
2.3.4 QR コード(PDF)を配置
2.4 図形描画
2.4.1 パスで直線の描画
2.4.2 パスで矩形の描画
2.4.3 パスで角丸矩形の描画
2.4.4 パスで楕円/円の描画
2.4.5 本文描画の重なり
索引

各項でPDFの料理法を取り挙げて、そのプログラム例、使用例を示しています。例えば、1.2.3 ページ周囲の余白を断裁の項は次のようになっています。


紙版:Web書店
出版社: アンテナハウスCAS電子出版
発売日:2018年4月
著者:アンテナハウス株式会社
販売形式:プリントオンデマンド版
サイズ:B5判 横組み
ページ数:124ページ
価格(税込):1,728円
ISBN:978-4-900552-60-9
販売店:アマゾン(POD版)(4月6日発売)、その他Web書店で発売予定

※紙版(弊社にて直販)
アンテナハウスにご来社いただいた方に超格安で販売しております:ご案内ページ

デジタル版
販売形式:PDF版(DRMなし)
ページ数:122ページ
価格(税込み):864円
販売店:アンテナハウス・オンラインショップ(PDFのダウンロード)

Web版
Webで全文を公開中

PDF CookBookシリーズ
[1]『PDF CookBook第2巻』は6月中旬発売です。

[2]『PDF CookBook 第3巻』

関連製品Webページ
[1]マニュアルの原稿などを高度なレイアウトで自動組版してPDFにするソフト「AH Formatter」
[2]廉価なPDF作成ソフト
[3]PDF Tool API

次は終了
本書は、4月22日開催の技術書典4でも販売いたします。
技術書典4サークル情報☞アンテナハウスCAS電子出版

PDFのページの境界の意味、境界の再設定で余白を増やす

以前に、PDFの余白について次のような質問をいただいていました。

「基幹系システムが自動生成するPDFの帳票の左余白が不足しているため、生成されたPDF内の文書を自動的にたとえば右にシフトするなど、余白変更をバッチ処理的に行うことができる製品はありますか」

アンテナハウス・システム製品ナビゲータ 3. PDFデータ利用・PDFの編集

この質問に対する回答は、「いまの製品ではできません。開発課題とさせていただきます。」となっています(2018/3/23現在)。

しかし、現在作成している『PDFクックブック』(仮称)という本のサンプルをいろいろ作っていながら、「あ!できるじゃん」と思い当たりました。

PDF Tool API V5には、PDFの境界を設定する機能があります。

・setMediaBox メディアボックスを設定する
・setCropBox クロップボックスを設定する

メディアボックスとはPDF を印刷する媒体の物理的な境界です。最も外側の領域であり、内側にできあがりの判型の周囲にとられる裁ち落とし領域やトンボなども含みます。PDFの仕様としてメディアボックスの外側にあるオブジェクトは無視されます。

クロップボックスとは、出力媒体の上でPDF の内容を表示するユーザー空間の矩形領域を定義します。物理的な媒体とは対応付けられていません。デフォルト値はMediaBoxです。

PDFの座標系はx軸、y軸とも無限の長さを持っていて、原点 (0,0)の位置をどこに置いても構いません。回転していないPDFでは、メディアボックスやクロップボックスは左下角(x0,y0)と右上角(x1,y1)の座標により[x0 y0 x1 y1]と表現します。

メディアボックス・クロップボックスを左(x軸)にaだけシフトするには、次のように座標値を変更します。
[x0-a y0 x1-a y1]

『PDFクックブック』に掲載予定のサンプルプログラムで実際に試して見ます。
次のように設定します。


※このサンプルプログラムは一度に1つの境界値しか変更できません。サンプルなので不便ですが。

そうしますと変更前のPDFの本分領域:

が、変更後のPDFの本分領域:

となります。PDF Tool API V5でできてしまうんですね。

『PDFクックブック』初版は、4月22日開催の技術書典4にて販売する予定です。しばらくお待ちください。

本書はもちろんCAS-UBで制作しています。

ご参考:PDF Tool API V5