2011-09-19

英語の本の脚注の付け方（データ）

英語の本の脚注の付け方を少し、といっても2冊だけ、調べてみた。

１．Econometric Analysis (New York University, Prentice Hall, 2003)

脚注のアンカー番号：　アラビア数字、上付き、
脚注分離罫線の長さ：約8.5mm
脚注分離罫線の太さ：約0.3mm
脚注番号：　アラビア数字、上付き
脚注本文配置：　字下げなし、段落位置は本文段落と揃える
脚注の行送り：約3.3mm/行　(本文約4mm強）
脚注の番号：章毎の連番
脚注間の空き量：あり
脚注文字スタイル：本文と同じ（serif）

２．Basic Econometrics　（US Military Academy,　MacGrawHill, 2003）

脚注のアンカー番号：　アラビア数字、上付き、
脚注分離罫線の長さ：約34mm
脚注分離罫線の太さ：約0.1mm
脚注番号：　アラビア数字、上付き
脚注本文配置：　先頭行字下げ約4mm、段落位置は本文段落と揃える
脚注の行送り：約3.1mm/行　(本文約4.2mm強）
脚注の番号：章毎の連番　
脚注間の空き量：なし
脚注文字スタイル：本文と同じ（serif）
　

３．「Chicago Manual of Style」（第15版）では次のようになっている。

Noteの番号
（16.25)テキスト中の番号は上付き。ノート自身は通常フルサイズ、上付きではなく、ピリオドをつける。
（16.26）注番号は、1から始まって、記事または章の中で連続して付けるべきである。テキストが内部でまったく別れていないときは別として、書籍全体で連続ではない。注の数が少ないならば、番号ではなくアスタリスクでも良い。
（16.27）脚注と後注（endnote）の両方があるときは、脚注はアスタリスク、ダガーなどで参照し、後注を番号で参照する。

2011-09-14

絶対寸法と相対寸法　ピクセルは絶対単位なのか？

CSS3の距離・長さ（Length）を表す単位には、相対単位と絶対単位があります。

CSS Values and Units Module Level 3
W3C Working Draft 6 September 2011
http://www.w3.org/TR/2011/WD-css3-values-20110906/

◎長さ
http://www.w3.org/TR/2011/WD-css3-values-20110906/#lengths

１．相対単位
‘em’ フォントの大きさに相対的
‘ex’ フォントの高さに相対的
‘ch’ フォントの"0"の幅
‘rem’ ルート要素のフォントサイズ
‘vw’ ビューポートの幅基準
‘vh’ ビューポートの高さ基準
‘vm’ ビューポートの幅または高さで小さいほう

２．絶対単位
‘cm’ センチメートル
‘mm’ ミリメートル
‘in’ インチ; 1インチは2.54センチメートル
‘px’ ピクセル; 1px は1/96インチ
‘pt’ ポイント; 1ptは1/72インチ
‘pc’ パイカ; 1pcは12pt

この中でpxは絶対単位なのかどうか大いに疑問です。上のように定義してしまえば、もちろん、絶対単位ですが、現実にはそのように実装されていないのではないかと思います。

Wikipediaには、「ピクセル (pixel、画素) とは、コンピュータで画像を扱うときの、色情報(色調や階調)を持つ最小単位．．．例えば、640×480ピクセルの画像は、横640個、縦480個の点を並べて表現されていることを示す。」（http://ja.wikipedia.org/wiki/%E3%83%94%E3%82%AF%E3%82%BB%E3%83%AB）とあります。私の理解も同じでした。

画像によっては、解像度をファイルに保持しているものがあります。たとえば、次のJPEGは、72dpiとなっています。

３．SVG

昨日、CAS-UBで作成したPDFの中に入っている図版を調べていましたら、どうも大きさが小さいのがある、ということでいろいろ比較してみました。

SVGの中に次のようなサイズの宣言があります。

- - - - -

○CAS-UB

http://www.cas-ub.com/

○電子出版サービス

http://www.antenna.co.jp/epub/

2011-09-09

CAS-UB、SVGを画像としてEPUBで使うには、文字をアウトライン化するのが一番良いようだ

昨日の話題の具体例として図版のフォント問題について検討してみます。

CAS-UBではワンソースでPDFとEPUBを同時に作り出します。

(1)PDFは画面に出すだけではなく、紙に印刷するためにも使います。印刷は画面とは比較にならないほど高精細ですので印刷用の図版は高精度であることが必要です。できればベクトル図形が望ましいと思います。

(2)EPUBは主に画面で表示するものですので表示精度については、拡大縮小に耐えられる程度の精度があれば良く、むしろ、ファイルサイズが小さいのが望まれます。

現在、ひとつのファイル形式で、(1)と(2)の二つの要請を両立させることのできるのはSVGと思います。特に、EPUB2では外部画像としてSVGを表示できることになっていますし、EPUB3ではSVGを本文に使うことができます。

こんなことからSVGに大いに期待しています。いままで長いこと鳴かず飛ばずだったSVGの出番が漸くやってきたのかもしれません。

今のうちにSVGのノウハウをためて置こうということで、現在、CAS-UBで制作している冊子の図版にもSVG形式を採用していろいろ試しています。

○オリジナルの図版

これは縦書き文章の組版例のひとつです。

１．まず、図版を単純にSVGに変換し、CAS-UBでPDFとEPUBを作り表示してみました。

(1)PDF（PCのAdobe Readerで表示）　

問題点：レイアウトは良いが、フォントが明朝系からゴシック系に入れ替わっています。オリジナルに使われているフォントが変換環境・表示環境に存在しないため途中でフォントが置き代わってしまうためです。

(2)EPUB（iBooksで表示）

問題点：文字のベースラインの位置がかなりずれています。一番右の行（縦）が欠けて見えるのは、文字がSVGの台紙からはみ出しているためと思います。さらに、特に欧文と和文のずれが大きくなっています。
また、括弧や句読点が横書き用になっています。これは、SVGは縦書きなのに、iBooksでは縦書きができないので、SVG中の文章を横書きと見なして表示しているためでしょう。

2. 次に、SVGを作成する際にフォントをアウトライン化してみました。つまり、SVGの中で文字が線画として表されていることになります。このSVGを使ってCAS-UBでPDFとEPUBを作り表示してみました。

(1)PDF（iBooksで表示）　

(2)EPUB（iBooksで表示）

これを見ますと、PDFもEPUBも両方とも、オリジナルの通りに表示されます。このことから文字、特に縦書きを含む場合、については、SVGを作る際にフォントをアウトライン化するのが良いということになります。

○CAS-UB
http://www.cas-ub.com/

○電子出版サービス
http://www.antenna.co.jp/epub/

2011-09-08

CAS-UBでPDFとEPUBを制作する際の、フォントの問題の整理と解決策

PDFの作成、あるいはEPUBを作成する場合、環境によってインストールされているフォントが異なっていることが大きな問題となります。この際、考慮に入れるべき環境を大きく分けると次の３つになるのでしょう。

１．原稿を執筆した環境
２．PDFとEPUBを制作する環境
３．PDFとEPUBを複製・閲覧する環境

出版物の制作においては１→２→３の工程で出版物のコンポーネント（文章、図版、表など）を複製していくことになります。

工程ごとに表示・編集ツールが同じ場合と異なる場合があります。ここでは問題を簡単にするために、表示・編集ツールが同じと仮定してみます。

前工程で専門的・特殊なフォントを使用していた場合、次工程にそのフォントがないことがあります。この場合、表示・編集ツールは指定されたフォントを別のフォントに置き換えます。Windowsの場合は、表示・編集ツールではなく、Windows自身がフォントを適当に置き換えて文字を表示する機能を持っています。また、たとえば、アンテナハウスのAH Formatterはフォント・エイリアス機能（あるフォントを別のフォントに見立てる）機能を備えていて、存在しないフォントを別のフォントを指定して表示できます。

こうしたことから、前の工程で利用したフォントが次の工程に存在しない場合、その見栄えを再現することができないという事態が生じます。この場合の見栄えとはレイアウトと文字の形（明朝・ゴシックなどの書体、縦書き用の字形と横書き用の字形など）です。

なぜレイアウトを再現できないかといいますと、多くの場合、フォントの中の情報（フォント・メトリック）をつかって文字の位置を決めているからで、たとえばベースラインの位置がフォントによって微妙に異なるならば、文字の表示位置が微妙にずれてしまうことがあります。また、明朝体系のフォントをゴシック体系のフォントに置き換えてしまうと、文字の字形が異なってしまうので印象が大きく違うことになってしまいます。

これを避けるためいくつかの方法があります。

一つ目は、前工程でフォントをアウトライン化することです。フォントをアウトライン化すると、フォントの字形描画情報がベクトル図形となります。

二つ目は、フォントの埋め込みです。これはフォントの中のメトリックスや字形描画情報をファイルに埋め込むことです。

三つ目は、Ｗebフォントです。インターネットを使ってフォント情報を供給することで、環境にフォントがない、という状態をなくすことに相当します。

他にも方法があるかもしれませんが、残念ながら知りません。

これらの方法が実践的にどの程度まで有効かということは、もう少し実験を重ねて知見を高めないと判りません。

○AH Formatter
http://www.antenna.co.jp/AHF/

○CAS-UB
http://www.cas-ub.com/

2011-09-06

コンテンツの構造化とは何か？Word文書のスタイル付けとマークアップ

われわれが言うときのコンテンツの構造化は、コンテンツにある種のXML文書型に従ってマークアップするのとほぼ同等である。

自由奔放に記述された文書は構造化文書とは言わない。そうではなく、予め定めた一定の型にはめて記述した文書が構造化文書である。

文書の構造をあらわす方式のひとつがXMLである。XML方式の構造化文書では、構造をXMLのマークアップで明示的にあらわす。

XML方式で文書を構造化する目的は、文書をコンピュータで加工処理できるようにのである。

印刷された文書は一般には構造化文書ではない。印刷した文書においては、見出し、段落の位置（上下・左右の余白の量など）や箇条書き、文字の修飾（強調、斜体、ゴシック体、文字の大きさ）などは文章の文脈や意味を明確にするために使う。たとえば、見出しの文字を本文よりも大きくしたり、前後に空き（行間）を広くとるのは見出しであることを分かりやすく示すためであるし、ある特定の段落の左余白を広く取った場合、それは、引用や注記など本文とは異なる段落であることを示すためなのである。

つまり、印刷においては文字列の意味的・文脈的な役割をスタイルとレイアウトで表すのである。

一方、XMLではこれらの意味的・文脈的な役割をその範囲をマークアップすることで明示的にあらわす。見出しというマークアップした場合、文字が大きいこと・文字がゴシックであることなどの見出しを視覚的に区別するスタイル指定はマークアップの方で担う。見出しの文字列は、本文と同じテキストで表す。

そこで、マークアップをすることは狭義のコンテンツである見出し文字列と見出しに指定するレイアウトという視覚要因を分離することであるといっても良い。このような意味で、コンテンツとレイアウトを分離するという言い方をすることもある。

Microsoft Wordにはスタイル機能がある。見出しというスタイルを定義しておき、ある文字列に見出しスタイルを適用すると、その適用された文字列の文字がいっせいに大きなゴシック体になる、というものである。

こうしてみるとMicrosoft Wordのスタイル機能は、XMLにおけるマークアップに近い機能であることが分かる。このようなことでスタイル機能を使って記述したMicrosoft WordはXMLで構造化した文書に比較的容易に変換することができる。

一方、同じMicrosoft Wordを使って、スタイル機能を使わずに、見出し文字列をその都度、文字修飾（フォント機能）と段落修飾（インデント、改行幅）をつかって外見を指定して作成した文書を作ることができる。このような作りかたをすると、構造化されていない文書となる。このような文書はXMLに変換しにくい。XML化するときに、すべての見出しをいっせいに特定のマークアップに変換しにくいのである。それは、ときどき、修飾を忘れるなどの例外があるからである。

★CAS-UBは構造化文書の作成とそれをEPUBやPDFに変換するサービスです。