カテゴリー別アーカイブ: 構造化文書

AH Formatter V6.6 改訂２版の強化内容

昨日、2018年12月6日に XML/HTML 自動組版ソフトのベストセラー『AH Formatter V6.6』のメンテナンスリリースとして改訂２版を公開しました。

基本的に改訂版では機能強化は行っておりませんが、今回は海外のユーザ様からご要望のあった次の機能に対応しました。

internal-destination に PDF の Named Action が指定可能になりました。
電子署名フィールドで、署名の時点で文書をロックするかどうかが指定可能になりました。 ☞ axf:field-lock-document / CSS -ah-field-lock-document

『AH Formatter』は主にバージョンアップのたびに機能強化や新機能の追加を行っていますが、”あったら便利な機能” も既に追加されていることがございますし、いくつかの機能を組み合わせたり工夫することで実現できることもありますので、どうぞお気軽にサポートにお問い合わせください。なお、未実装の機能であれば、ご要望として承り今後の開発の参考にさせていただきます。お問い合わせをお待ちしております。

ご購入前のお客様で『AH Formatter』についてお問い合わせがございましたら、sis@antenna.co.jp 宛てにご連絡ください。

投票をお願いいたします

瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換

瞬簡PDF 統合版 2024
アンテナハウスPDFソフトの統合製品！

AH Formatter のライセンスと保守期限について

こんにちは
AH Formatter サポート担当です。

お客様からAH Formatterのライセンスや保守契約（保守期限）についてお問い合わせを受けることがありますので
今回はライセンス（保守期限）のお話をしたいと思います。

AH Formatterをご購入or保守契約更新していただくと、弊社保守サービスからAH Formatterのライセンスファイルをお客様にお送りします。
これには内部データとしてお客様情報の他、保守期限が埋め込まれています。
ライセンスファイルが正しくインストールされた状態で以下のようにすると詳細を確認することができます。
・Windows版 GUI でメニューの【ヘルプ】から【AH Formatter V6.x について】を選択
・コマンドラインインターフェース（AHFCmd）で -v オプションを付けて起動

Windows版 GUI でメニューの【ヘルプ】から【AH Formatter V6.x について】を選択

コマンドラインインターフェース（AHFCmd）で -v オプションを付けて起動

上記の保守期限：や Maintenance Limit：とある項目が保守期限です。
このサンプルのように、保守期限が 6月までだった場合
今お使いのAH Formatter V6.x は保守期限を過ぎてもそのまま製品版として動作しますのでご安心ください。

もし、AH Formatterの改訂版や新しいバージョンをインストールする場合には
お客様の保守期限を確認していただく必要があります。
次のような場合を考えてみましょう。

AH Formatter

例:
保守期限は6月某日で、V6.5 改訂1版を使用中
5月に V6.5 改訂5版リリース
7月に V6.5 改訂6版リリース
8月に V6.6 初版リリース

保守期限より前（保守契約期間中）にリリースされたV6.5 改訂5版をインストールした場合は現状のライセンスファイルのままで
製品版としてお使いになれます。
保守期限から後にリリースされたV6.5 改訂6版や V6.6 は保守期限が終了したライセンスファイルでは評価版となってしまいます。
したがって新しいAH Formatterをインストールして使いたい場合には保守契約を更新していただく必要があります。
弊社保守サービスにて保守契約更新のご契約をしていただきますと、新しい保守期限のライセンスファイルをお送りいたします。
この新しいライセンスファイルをインストールすることで V6.5 改訂6版や V6.6 も製品版として使う事ができます。

このように保守契約期間中にリリースされたAH Formatter（改訂版やマイナーバージョンアップ）はお手持ちのライセンスファイルで製品版として動作します。
メジャーバージョンアップの場合は保守期間に関わらず、新しいライセンスファイルが必要になります。
今後 AH Formatter V7.0 がリリースされた際にご使用される場合は V7.x対応のライセンスファイルをお送りいたしますので
弊社までご連絡ください。

投票をお願いいたします

瞬簡PDF 作成 2024
ドラッグ＆ドロップでPDF作成

瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換

text-decoration-* 指定の解釈について

とある業務で CSS の仕様を読み、気になった点が以下でした。
text-decoration-* という指定の解釈についてです。

https://www.w3.org/TR/2018/CR-css-text-decor-3-20180703/#text-decoration-color-property
によれば
親の text-decoration-color 指定時、子供の text-decoration-line の指定がない場合に子供が text-decoration-color を指定した場合、どうするか書いていないようです。

では、ブラウザはどのような実装にしているのでしょうか？
子供の単独の text-decoration-color の色指定が、親の text-decoration-line の色指定と独立という解釈を取っているブラウザは Google Chrome や Firefox がありました。
Microsoft Edge はこれらの実装されていません。
※ 2018/11/27 現在

上記ふたつでは text-decoration-line と text-decoration-color を共に指定しないと、子の下線の色はその指定から何も影響を受けないということです。
text-decoration-color で色の指定があっても、text-decoration-line の指定がない場合、親のそれらの色のスタイルを引き継ぐという実装が正しいのかはわかりませんが、現状、ブラウザ上ではそうなっている、ということが分かりました。
腑に落ちないところも多々ありますが、今後とも、CSS の仕様を勉強していこうと思います。

投票をお願いいたします

瞬簡PDF 書けまっせ 2024
PDFに文字が書ける！入力欄を自動認識

瞬簡PDF 作成 2024
ドラッグ＆ドロップでPDF作成

Windows 10 Enterprise LTSC（旧称 LTSB）動作確認について（AH Formatter、Web Interface for AH Formatter）

Windows 10 は旧来の Windows OS とは異なり継続的に機能更新が行われていきます。これとは異なりセキュリティ更新プログラムのみが Windows Update にて配信される LTSC（Long-Term Service Channel）というバージョンが存在します。

LTSC は Windows 10 Enterprise のみで提供される長期サービスチャネルのバージョンです。セキュリティ更新プログラムのみが Windows Update にて配信され、機能更新や強化の配信がされないため、これらを極力不要とされるシステム中心に利用が想定されます。

お客様から LTSC への対応について問い合わせをいただくことがあり確認を進めております。弊社システム製品の『AH Formatter V6.6』、『Web Interface V6.0 for AH Formatter』では次の LTSC 環境にて問題なく動作することを確認しております。

◆ AH Formatter V6.6
Windows 10 Enterprise 2015 LTSB x86/x64版
Windows 10 Enterprise 2016 LTSB x86/x64版
Windows 10 Enterprise 2019 LTSC x86/x64版

◆ Web Interface V6.0 for AH Formatter
Windows 10 Enterprise 2015 LTSB x86版
Windows 10 Enterprise 2019 LTSC x64版

また、先日当ブログで Java 11以降の動作確認と動作保証が話題に挙げられましたが、『AH Formatter V6.6』は Java 11 での動作も確認いたしました。

各製品について詳しくは、『AH Formatter V6.6』と『Web Interface for V6.0 AH Formatter』の各ページをご覧ください。

投票をお願いいたします

瞬簡PDF 作成 2024
ドラッグ＆ドロップでPDF作成

瞬簡PDF 編集 2024
かんたん操作でPDFを自由自在に編集

アンテナハウス製品におけるJava 11以降の動作確認と動作保証

2019年1月でJava 8のサポートが切れます。
そして、2018年9月下旬、Java 11が予定通り出荷され、お客様からの問い合わせが入っていますので、アンテナハウス製品におけるJava 11以降の動作確認、動作保証について、現段階での方針をお知らせします。

Oracleが、これまで無償で配布してきたJDKのサポートを有償化するという話が出て、いろいろと混乱した話が飛び交いましたが、OpenJDKを使えば、無償で使えます。
OpenJDKは、OracleからJDKのソースコードの提供を受けて、いろんな企業や団体がビルドして無償で配布しているもので、企業や団体によって、有償サポートがあったりなかったり、サポート料やサポート期間もマチマチです。
この辺は、Linuxに各種のディストリビューションがあるのと似ています。
詳しい話は、参考に挙げた記事やサイトをお読みください。

アンテナハウスは、OpenJDKの中でも、LTS(Long Term Support)バージョンのOpenJDKを、無償で、最低4年間は、セキュリティやバグフィックスのアップデートを提供するといっているAdoptOpenJDKによって、動作確認と動作保証を始めています。
AdoptOpenJDKのJava 11は、最低、2022年9月までアップデートが提供される予定です。

AdoptOpenJDK

AdoptOpenJDK Support

	First Availability	End of Availability [1]
Java 8 (LTS)	March 2014	At Least Sep 2023 [2]
Java 9	Sept 2017	March 2018
Java 10	March 2018	Sept 2018
Java 11 (LTS)	Sept 2018	At Least Sept 2022 [2]

AdoptOpenJDKでダウンロードできるバイナリのうち、アンテナハウスが動作確認、動作保証の対象とするJava 11は、「OpenJDK 11 Hotspot」です。
Hotspotは、元々Sun(Javaの本家)が作ったJVM(Java仮想マシン)です。Oracleがメンテナンスや機能拡張をしています。これがリファレンスと考えてよいので、このJVMのみ動作保証対象にする予定です。
理由は、JVMは多くの実装があるので、やり出したら、きりがないからです。
たとえば、上記サイトには、Java 11でも、
「OpenJDK 11 with Eclipse OpenJ9」
がありますが、OpenJ9は、IBMが開発したJVMです。これは動作保証の対象にはしない予定です。
アンテナハウス自身が、動作確認、動作保証をするJVMを限定することについては、何卒、ご了承ください。

現在、アンテナハウス製品で使われているJavaのコードは、Java 8のコンパイラでビルドして出荷していますが、動作確認を始めた製品では、いずれも、問題なくJava 11で動いています。
アンテナハウスの製品のうち、Javaを使っている製品については、いずれ、各製品のウェブページで、動作確認が取れたことをお知らせしていく予定です。
なお、Java 8のコンパイラからJava 11のコンパイラに切り替える時期は未定です。
Java 11のコンパイラでビルドすると、Java 11の実行環境が必要になり、Java 8では動かなくなることが予想されます。
2019年1月でJava 8のサポートが切れるといっても、すぐ、Java 11に乗り換えられるお客様は、そんなに多くないだろうと考えていますので、2019年早々のコンパイラの切り替えは考えていません。
Javaを使っているアンテナハウス製品のリリース時期によりますが、今後、1年から数年をかけて、コンパイラを切り替えていくことになるでしょう。

参考：
【GlassFish勉強会レポート】各JDKベンダの動向を知ってJava 11に備えよう
2018年10月5日
杉山貴章

Javaは今も無償です

Oracle Java SE サポート・ロードマップ
(2018年 9月25日更新)

Time to look beyond Oracle’s JDK
Monday, 3 September 2018

投票をお願いいたします

瞬簡PDF 書けまっせ 2024
PDFに文字が書ける！入力欄を自動認識

アウトライナー
PDFを解析してしおり・目次を自動生成

Breaking Paragraphs into Lines

Breaking Paragraphs into Lines は、Donald E. Knuth と Michael F. Plass の行分割に関する論文で、40年近く前のものです。ここで示されているアルゴリズムは、パラグラフ全体を Box/Glue/Penalty という要素（Paragraph Item）でモデル化して、行分割位置を決定するものです。処理の流れは次のようになります。

アプリケーションが、文書から Paragraph Items を構築する。
分割可能位置に対して、そこで行分割したときの不具合度を示すデメリット値と呼ばれる値を計算する。
もっともデメリット値の合計の少ない位置を選択し、行分割位置とする。

Paragraph Item の要素 Box/Glue/Penalty は、それぞれが幅を持っています。

Box は常に幅が確保される。伸縮性はない。
Glue も幅が確保されるが、そこで分割が起こったとき幅がなくなる。Glue には伸縮性がある。
Penalty はその逆で、通常は幅が確保されないが、そこで分割が起こったとき前の行末にその幅が確保される。Penalty に伸縮性はない。また、行分割の起こり易さを調整するペナルティ値という値を持っており、分割不可では ∞ を、分割必須では −∞ を与えることになっている。ハイフネーションは Penalty を利用して実現されている（通常の Penalty と区別するために Flagged Penalty と呼ばれる）。

次のような文書（論文に出てくるグリム童話）を例に、このアルゴリズムがどのように行分割位置を決定するのかをざっと見てみましょう。

fig-12

これから次のような Paragraph Items が構築されます。
x は要素、t は要素の種別、w は要素の幅、y は伸ばせる幅、z は縮められる幅、p はペナルティ値を示しています。

x₀	empty box for indentation	t₀	= box	w₀	= 20
x₁	box for ‘In’	t₁	= box	w₁	= 17.44
x₂	glue for space U+0020	t₂	= glue	w₂	= 4.54	y₂	= 5	z₂	= 2
x₃	box for ‘old’	t₃	= box	w₃	= 25.68
x₄	penalty for hyphenation	t₄	= flagged-penalty	w₄	= 7.12	p₄	= 100
x₅	box for ‘en’	t₅	= box	w₅	= 19.44
x₆	glue for space U+0020	t₆	= glue	w₆	= 4.54	y₆	= 5	z₆	= 2
x₇	box for ‘times’	t₇	= box	w₇	= 43.7
x₈	glue for space U+0020	t₈	= glue	w₈	= 4.54	y₈	= 5	z₈	= 2
x₉	box for ‘when’	t₉	= box	w₉	= 43.88
`......`
x₂₄	glue for space U+0020	t₂₄	= glue	w₂₄	= 4.54	y₂₄	= 5	z₂₄	= 2
x₂₅	box for ‘lived’	t₂₅	= box	w₂₅	= 38.54
x₂₆	glue for space U+0020	t₂₆	= glue	w₂₆	= 4.54	y₂₆	= 5	z₂₆	= 2
x₂₇	box for ‘a’	t₂₇	= box	w₂₇	= 8.78
x₂₈	glue for space U+0020	t₂₈	= glue	w₂₈	= 4.54	y₂₈	= 5	z₂₈	= 2
x₂₉	box for ‘king’	t₂₉	= box	w₂₉	= 35.5
x₃₀	glue for space U+0020	t₃₀	= glue	w₃₀	= 4.54	y₃₀	= 5	z₃₀	= 2
x₃₁	box for ‘whose’	t₃₁	= box	w₃₁	= 50.64
`......`
x₅₁	box for ‘young’	t₅₁	= box	w₅₁	= 49.76
x₅₂	penalty for hyphenation	t₅₂	= flagged-penalty	w₅₂	= 7.12	p₅₂	= 100
x₅₃	box for ‘est’	t₅₃	= box	w₅₃	= 21.84
x₅₄	glue for space U+0020	t₅₄	= glue	w₅₄	= 4.54	y₅₄	= 5	z₅₄	= 2
x₅₅	box for ‘was’	t₅₅	= box	w₅₅	= 29.82
x₅₆	glue for space U+0020	t₅₆	= glue	w₅₆	= 4.54	y₅₆	= 5	z₅₆	= 2
x₅₇	box for ‘so’	t₅₇	= box	w₅₇	= 17.7
x₅₈	glue for space U+0020	t₅₈	= glue	w₅₈	= 4.54	y₅₈	= 5	z₅₈	= 2
x₅₉	box for ‘beau’	t₅₉	= box	w₅₉	= 38.36
x₆₀	penalty for hyphenation	t₆₀	= flagged-penalty	w₆₀	= 7.12	p₆₀	= 100
x₆₁	box for ‘ti’	t₆₁	= box	w₆₁	= 11.56
x₆₂	penalty for hyphenation	t₆₂	= flagged-penalty	w₆₂	= 7.12	p₆₂	= 100
x₆₃	box for ‘ful’	t₆₃	= box	w₆₃	= 21.82
`......`
x₁₄₃	box for ‘old’	t₁₄₃	= box	w₁₄₃	= 25.68
x₁₄₄	glue for space U+0020	t₁₄₄	= glue	w₁₄₄	= 4.54	y₁₄₄	= 5	z₁₄₄	= 2
x₁₄₅	box for ‘lime-‘	t₁₄₅	= box	w₁₄₅	= 42.34
x₁₄₆	penalty for inter-word	t₁₄₆	= flagged-penalty	w₁₄₆	= 0	p₁₄₆	= 100
x₁₄₇	box for ‘tree’	t₁₄₇	= box	w₁₄₇	= 30.46
x₁₄₈	glue for space U+0020	t₁₄₈	= glue	w₁₄₈	= 4.54	y₁₄₈	= 5	z₁₄₈	= 2
x₁₄₉	box for ‘in’	t₁₄₉	= box	w₁₄₉	= 16.3
`......`
x₂₆₇	box for ‘her’	t₂₆₇	= box	w₂₆₇	= 26.52
x₂₆₈	glue for space U+0020	t₂₆₈	= glue	w₂₆₈	= 4.54	y₂₆₈	= 5	z₂₆₈	= 2
x₂₆₉	box for ‘fa’	t₂₆₉	= box	w₂₆₉	= 14.7
x₂₇₀	penalty for hyphenation	t₂₇₀	= flagged-penalty	w₂₇₀	= 7.12	p₂₇₀	= 100
x₂₇₁	box for ‘vor’	t₂₇₁	= box	w₂₇₁	= 26.48
x₂₇₂	penalty for hyphenation	t₂₇₂	= flagged-penalty	w₂₇₂	= 7.12	p₂₇₂	= 100
x₂₇₃	box for ‘ite’	t₂₇₃	= box	w₂₇₃	= 19.6
x₂₇₄	glue for space U+0020	t₂₇₄	= glue	w₂₇₄	= 4.54	y₂₇₄	= 5	z₂₇₄	= 2
x₂₇₅	box for ‘play’	t₂₇₅	= box	w₂₇₅	= 33.42
x₂₇₆	penalty for hyphenation	t₂₇₆	= flagged-penalty	w₂₇₆	= 7.12	p₂₇₆	= 100
x₂₇₇	box for ‘thing.’	t₂₇₇	= box	w₂₇₇	= 47.02
x₂₇₈	finishing glue	t₂₇₈	= glue	w₂₇₈	= 0	y₂₇₈	= ∞	z₂₇₈	= 0
x₂₇₉	forced break	t₂₇₉	= flagged-penalty	w₂₇₉	= 0	p₂₇₉	= −∞

次の位置が分割可能位置となります。上の例では、x₂、x₄ などです。

x_b が Penalty であり p_b < ∞ である x_b
x_b が Glue であり x_b-1 が Box である x_b

デメリット値は、そこで行分割するとどの程度よろしくないのかを示す値であり、この値が小さいほどよい分割位置と判断されます。あまりに大きなデメリット値のときは分割位置の候補から除外されます。デメリット値の算出方法の詳細はここでは触れませんが、外部から与えるいくつかのパラメタによって、デメリット値を調整できるようになっています。

上の例では、x₂ や x₄ のデメリット値は非常に大きく、候補から除外されます。最初（1行目）の分割位置候補となるのは x₂₆ と x₂₈ で、デメリット値を d とすると、d₂₆ = 975.065、d₂₈ = 23.5004 となっています。
x₂₆ で行分割したとき、次の行（2行目）の分割位置候補は、x₅₂ と x₅₄ で、d₅₂ = 29412.2、d₅₄ = 1288.3 です。
x₂₈ で行分割したときは、x₅₆ と x₅₈ が次の候補となり、d₅₆ = 24.6185、d₅₈ = 6446.52 です。
パラグラフ全体にこれを繰り返すと、次のようなネットワークができ上がります（パスのいくつかは省略されています）。数値は、下に示された語の後で分割したときのデメリット値を示しています。この例では、太い枠の語で分割するのが最良となっています。

fig-12-network

現在の AH Formatter はこのアルゴリズムを利用していません。そこで、このアルゴリズムを利用すると、どのように行分割位置が変化するのかを見てみます。

AH Formatter の結果 — ハイフネーションなし

Knuth-Plass アルゴリズムの結果 — ハイフネーションなし

これは、行あたりの単語数の少ない文書です。つまり、分割可能位置が少ない。行末のアキの幅がより均等に近いのは、Knuth-Plass アルゴリズムの方であるのが見て取れます。

ハイフネーションをしたときは次のようになります。

AH Formatter の結果 — ハイフネーションあり

Knuth-Plass アルゴリズムの結果 — ハイフネーションあり

AH Formatter はハイフネーションが多く発生しています。
Knuth-Plass アルゴリズムは、ハイフネーションの発生を少なく抑えるように作られていますが、パラメタを調整して、もう少しハイフネーションが起こり易くすると、次のようにもなります。

Knuth-Plass アルゴリズムの結果 — ハイフネーション多め

行あたりの単語数が多いときは分割可能位置も多いので、結果に差はなくなってきます。

AH Formatter の結果 — ハイフネーションなし

Knuth-Plass アルゴリズムの結果 — ハイフネーションなし

Knuth-Plass アルゴリズムには、いろいろ制約があることがわかっています。例えば以下のようなものです。

空白によって分かち書きされる英語などの文書を想定しているので、日本語のように分かち書きせず、ほとんどの文字間で分割可能な言語のことは考慮されていない。
非矩形の領域を扱えるが、そのとき行の高さが一定であることが仮定されている。つまり、途中で大きな文字が入っていたりすると処理できない。
ドロップキャップ、letter-spacing、カーニング、リガチャ、綴りの変化するハイフネーション、ルビなどは考慮されていない。
ページ分割は処理しないので、widows/orphans は処理できない。

AH Formatter にこのアルゴリズムを導入することが検討されています。

投票をお願いいたします

瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換

アウトライナー
PDFを解析してしおり・目次を自動生成

電子図書館について徒然

本記事を御覧いただき、ありがとうございます。今日は電子出版サービスグループの一員としてあまり仕事に関係なく書きました。文中の感想は個人の意見と感想です。お許しください。

今回は、出版関係のWebニュースサイト「HON.jp News Blog-出版の未来を拓く非営利のニュースメディア Since 2004」からです。昨日の国内ニュースで、電子図書館について電書協が11月に『電子図書館・電子書籍貸出サービス調査報告2018』を出すとありました。そこで気になった箇所を引用。

電子図書館サービスを導入している公共図書館は昨年の調査から17館増え、78館81自治体。図書館を持つ自治体比の導入率は5.9％となった。

ずいぶん少ないんですね。

自治体の大小問わず、全国の公共図書館総数は、『日本の図書館　統計と名簿』（日本図書館協会刊行）によると、2017年度は3,292だそうです。

更に気になったので、電子図書館の歴史をさらっとWeb検索してみると、国立国会図書館では、なんと1994（平成6）にはプロジェクトが立ち上がっていたそうです。もっとも、本格的にデジタル資料を公開し始めたのは2011（平成23）とのこと。資料の収集や法令整備など、20年近い年月を要しています。以降、ユーザーの要望やIT技術の進化と普及に伴い、新しいサービスを展開していますが、そのための予算もすごそうです。

国立国会図書館でこういう状況なのだから、普及率が低いのも当然だろうなぁと思います。古本屋街で「ここからここまで全部買う」という方法（←我が出身大学の創始者は図書館の蔵書集めのため、こういう買い方をしたらしいです。今、○○（伏せ字）文庫になってます）で一気に集められるものでもないですし、公開するための手続きやその後の管理等は、実体がないぶん余計に大変そうです。

さて、同ニュースの関連記事として「電流協、電子図書館を導入している公共図書館78館の一覧を発表」というのがあり、我が家のある神奈川県はどうかなー？と、一覧表（Excel）をダウンロードして見てみると、なんと2館！じゃあ、会社の在る東京都はとソートすると…、6館でした。ちなみに一番多いのは兵庫県で、9館です。中にはサービスを終了したものも…。予算でしょうか。4～5年前は普及するだろう、とか言われていたような気がしますが、現実は世知辛いですね。

みなさんは、電子図書館、利用したことはありますか？（私はないです。社会人になってから図書館自体使わなくなった…）機会があったら一度利用してみたいですが、所属自治体じゃないとやっぱり利用できないんだろうなぁ。

＜参照記事・引用サイト＞

投票をお願いいたします

瞬簡PDF 書けまっせ 2024
PDFに文字が書ける！入力欄を自動認識

瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換

EPUBtoPDF変換ツールを使ってみる（Formatter最新バージョン対応）

ご無沙汰しております。
本日と明日のブログは、電子出版サービスグループからお送りいたします。

Formatter 最新バージョンに対応

「EPUBtoPDF変換ツール」は、ときどき、地味に引き合いがあります。EPUBをPDFにするという需要自体が、まだまだ少ないので引き合いが少ないのはやむを得ないところです。製品の方も少しずつですが、バージョンアップしています。

今回、AH Formatterのバージョンアップ（V6.6MR1）に合わせて同バージョンに対応しました。劇的な変化はありませんが、昨今の縦組み横組み混じりのEPUBも、そのとおりにPDF変換できますし、CSSからのページ組版上、行間のアキ処理で不自然に1,2行ほどページの最後の行が空いてしまう問題も、軽減しました。

縦組みの中に横組みのページがある場合のパラメータ設定：mixed-writing-mode=”true”
ページ最後の空白軽減のパラメータ設定：baseline-grid=”true”

ただし、ページ最後の空白軽減については、行数（lines）が指定されているものに限ります。行数が設定されていない場合は無効ですのでご注意ください。

EPUBの本文と奥付

PDF変換してみる

上図は、EPUBの本文が縦書き、奥付を横組みに設定した例です。その下の図は、EPUBtoPDF変換ツールを使い、PDF変換してみた例です。
（出典：青空文庫-幸福のうわおい靴）

※余白等デザインがよろしくないのは、このためだけに作った見本EPUB/PDFなので、単純にCSSやツール側のパラメータ設定をしていないだけです。

これで、小洒落た（？）デザインのEPUBも、まずまずの出来具合でPDF変換が可能になりました。

「EPUBtoPDF変換ツール」はライセンスの販売のみではなく、これを使った変換サービスも承ります。EPUBの校正のためにPDFにしている版元さんもいらっしゃいます。EPUBから紙書籍の出版を考えている版元様、制作会社様、このままPDF入稿もできればイメージを掴むための校正用としてもご利用いただけますので、ぜひお問い合わせください。

「EPUBtoPDF変換ツール」のご紹介ページ

<お問い合わせ先>
電子出版サービスグループ：cas-info@antenna.co.jp

投票をお願いいたします