月別アーカイブ: 2018年11月

『瞬簡PDF 変換 10 改訂版』のお知らせ

朝晩の冷え込みが戻ってきました。
先週は気持ち悪いくらい気温が高くて、北海道では初雪もまだ観測されていないと聞きました。
今年は異例ずくめの天候ばかりですが、これでようやく?通常の季節感になりホッとしています。

さて、弊社のPDF変換ユーティリティ『瞬簡PDF 変換 10』は現在、改訂版を製品のWebサイトで公開しております。

『瞬簡PDF 変換 10』(Ver.10.0.2)

今回の改訂版は、先週トレンドマイクロ社の「ウイルスバスター クラウド」で『瞬簡PDF 変換 10』がランサムウェアと誤認識される現象が報告されたことに対応し、急遽準備したものです。

ランサムウェアと誤認識される

ウィルスチェックプログラムでアプリケーションの動作がウィルスと誤認識されたり、インストール時にファイルが誤検知されて削除されるといった現象はこれまでもいくつか弊社サポートに報告がされています。
その都度、ウィルスチェックプログラムを一時的に止めてもらうなどでお客様に対応をお願いしてきましたが、今回はアプリケーション側でも回避可能なことが判明したため、改訂版として公開しました。

「ウイルスバスター クラウド」に関しては、弊社「Antenna House PDF Driver」が出力したPDFファイルのウイルスチェックに時間がかかり、当該PDFファイルの処理に時間がかかる現象も報告されております。

緊急のお知らせ

こちらは「ウイルスバスター クラウド」の機能不具合に起因するものと判明し、現在トレンドマイクロ社からの修正版公開を待っている状況です。該当するお客様にはご迷惑をおかけして恐縮に存じますが、今しばらくお待ちいただけますようお願いいたします。

インターネットを通じて悪意あるウィルスが蔓延する昨今の事情を見ますと、ウィルスチェックプログラムは常備せざるを得ない生命保険のようなものですが、ソフトウェアである以上100%完全ということはなく、期待されるべきアプリケーションの使い勝手を阻害してしまう場合もあるのは悩ましいところです。
ソフトウェアの利用にはメリットもデメリットもあることを理解して、うまく折り合いをつけていくしかないのでしょうね。


「瞬簡PDF 変換 10」は体験版をご用意しております。
これにより、変換精度や使い勝手を事前にご確認いただくことができます。

体験版では以下のような制限がありますので、あらかじめご了承ください。

  • インストールしてから 15日を過ぎると利用できなくなります。
  • ひとつのPDFについて、3ページまで変換可能です。
  • 評価以外の目的で日常業務に利用することはできません。

体験版に関する詳細は、『瞬簡PDF 変換 10 体験版のお申し込み』をご参照ください。


『Antenna House PDF to Office 変換ライブラリ』 改訂版のお知らせ

本日は、コンバータ製品グループからの投稿です。

Antenna House PDF to Office 変換ライブラリ』は、弊社パッケージ製品『瞬簡PDF 変換 シリーズ』の高精度変換エンジン(PDF→Word/PDF→Excel/PDF→PowerPoint)を各種アプリケーションから利用するための組み込み専用ライブラリです。
今回、新たに改訂版(1.4.0)を公開しました。

改訂の主な目玉は、OCR機能(オプション)に使用するOCRエンジンの刷新です。
まったく新しいOCRエンジンの採用により、日本語・英語を含む約40の言語で使用される文字を認識できるようになりました。
OCR処理の対象データに使用されている言語種別を指定することで、日中韓はもちろん、ラテン系文字、ギリシャ文字、キリル文字をそれぞれ識別します。
文字を正しく識別することで、表組みや段組みなどの書式もより高精度に変換できるようになります。

対応する言語やライブラリの詳細は ライブラリの概要 から確認することができます。

本ライブラリの活用をご検討いただければ幸いです。


『Antenna House PDF to Office 変換ライブラリ』は、ソフトウェアの開発会社等が開発するPDFソリューション、ISV(独立系ソフトウェア・ベンダ)が開発するPDFアプリケーションに組み込んで再配布するためのOEMライセンスのみ販売しております。

価格は、組み込み条件等により異なります。
詳しくは、oem@antenna.co.jp までお問い合わせください。


PDF Tool API (C#の場合)

いろんな機能がいろいろ紹介されてるPDF Tool APIですが

参考
たったこれだけで 9行目で指定した入力PDFをロードして10行目で指定した出力PDFとして保存できます。

あとはロードと保存の間でPDFの処理をするだけ。

PDF CookBook 第1巻
PDF CookBook 第2巻
PDF CookBook 第3巻
各処理の詳細な説明も取りそろっております。


アンテナハウス製品における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


Breaking Paragraphs into Lines

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

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

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

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

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

fig-12

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

x0 empty box for indentation t0 = box w0 = 20
x1 box for ‘In’ t1 = box w1 = 17.44
x2 glue for space U+0020 t2 = glue w2 = 4.54 y2 = 5 z2 = 2
x3 box for ‘old’ t3 = box w3 = 25.68
x4 penalty for hyphenation t4 = flagged-penalty w4 = 7.12 p4 = 100
x5 box for ‘en’ t5 = box w5 = 19.44
x6 glue for space U+0020 t6 = glue w6 = 4.54 y6 = 5 z6 = 2
x7 box for ‘times’ t7 = box w7 = 43.7
x8 glue for space U+0020 t8 = glue w8 = 4.54 y8 = 5 z8 = 2
x9 box for ‘when’ t9 = box w9 = 43.88
......
x24 glue for space U+0020 t24 = glue w24 = 4.54 y24 = 5 z24 = 2
x25 box for ‘lived’ t25 = box w25 = 38.54
x26 glue for space U+0020 t26 = glue w26 = 4.54 y26 = 5 z26 = 2
x27 box for ‘a’ t27 = box w27 = 8.78
x28 glue for space U+0020 t28 = glue w28 = 4.54 y28 = 5 z28 = 2
x29 box for ‘king’ t29 = box w29 = 35.5
x30 glue for space U+0020 t30 = glue w30 = 4.54 y30 = 5 z30 = 2
x31 box for ‘whose’ t31 = box w31 = 50.64
......
x51 box for ‘young’ t51 = box w51 = 49.76
x52 penalty for hyphenation t52 = flagged-penalty w52 = 7.12 p52 = 100
x53 box for ‘est’ t53 = box w53 = 21.84
x54 glue for space U+0020 t54 = glue w54 = 4.54 y54 = 5 z54 = 2
x55 box for ‘was’ t55 = box w55 = 29.82
x56 glue for space U+0020 t56 = glue w56 = 4.54 y56 = 5 z56 = 2
x57 box for ‘so’ t57 = box w57 = 17.7
x58 glue for space U+0020 t58 = glue w58 = 4.54 y58 = 5 z58 = 2
x59 box for ‘beau’ t59 = box w59 = 38.36
x60 penalty for hyphenation t60 = flagged-penalty w60 = 7.12 p60 = 100
x61 box for ‘ti’ t61 = box w61 = 11.56
x62 penalty for hyphenation t62 = flagged-penalty w62 = 7.12 p62 = 100
x63 box for ‘ful’ t63 = box w63 = 21.82
......
x143 box for ‘old’ t143 = box w143 = 25.68
x144 glue for space U+0020 t144 = glue w144 = 4.54 y144 = 5 z144 = 2
x145 box for ‘lime-‘ t145 = box w145 = 42.34
x146 penalty for inter-word t146 = flagged-penalty w146 = 0 p146 = 100
x147 box for ‘tree’ t147 = box w147 = 30.46
x148 glue for space U+0020 t148 = glue w148 = 4.54 y148 = 5 z148 = 2
x149 box for ‘in’ t149 = box w149 = 16.3
......
x267 box for ‘her’ t267 = box w267 = 26.52
x268 glue for space U+0020 t268 = glue w268 = 4.54 y268 = 5 z268 = 2
x269 box for ‘fa’ t269 = box w269 = 14.7
x270 penalty for hyphenation t270 = flagged-penalty w270 = 7.12 p270 = 100
x271 box for ‘vor’ t271 = box w271 = 26.48
x272 penalty for hyphenation t272 = flagged-penalty w272 = 7.12 p272 = 100
x273 box for ‘ite’ t273 = box w273 = 19.6
x274 glue for space U+0020 t274 = glue w274 = 4.54 y274 = 5 z274 = 2
x275 box for ‘play’ t275 = box w275 = 33.42
x276 penalty for hyphenation t276 = flagged-penalty w276 = 7.12 p276 = 100
x277 box for ‘thing.’ t277 = box w277 = 47.02
x278 finishing glue t278 = glue w278 = 0 y278 = ∞ z278 = 0
x279 forced break t279 = flagged-penalty w279 = 0 p279 = −∞

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

  1. xb が Penalty であり pb < ∞ である xb
  2. xb が Glue であり xb-1 が Box である xb

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

上の例では、x2 や x4 のデメリット値は非常に大きく、候補から除外されます。最初(1行目)の分割位置候補となるのは x26 と x28 で、デメリット値を d とすると、d26 = 975.065、d28 = 23.5004 となっています。
x26 で行分割したとき、次の行(2行目)の分割位置候補は、x52 と x54 で、d52 = 29412.2、d54 = 1288.3 です。
x28 で行分割したときは、x56 と x58 が次の候補となり、d56 = 24.6185、d58 = 6446.52 です。
パラグラフ全体にこれを繰り返すと、次のようなネットワークができ上がります(パスのいくつかは省略されています)。数値は、下に示された語の後で分割したときのデメリット値を示しています。この例では、太い枠の語で分割するのが最良となっています。

fig-12-network

 

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

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

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

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

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

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

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

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

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

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

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

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

 


『Antenna House PDF Tool API』(PDF Tool API)でページ単位に分割してみる(2)

『Antenna House PDF Tool API』(PDF Tool API)は、PDFファイルの情報取得やPDFファイルの加工・編集を行うライブラリです。
PDFに関するさまざまな処理機能を搭載しています。
文書情報やページ数などの情報取得、ページの挿入や削除、透かしの挿入、セキュリティ設定などのファイル加工、ページコンテンツのテキストや画像の削除、画像の最適化(ダウンサンプリング)といったページ編集処理が可能です。

今回は『Antenna House PDF Tool API』(PDF Tool API)を使用して、複数ページのPDFを、1ページ単位に分割しながら、リンク注釈を設定します。
設定されたリンク注釈をクリックすると、前後のページのPDFを呼び出します。

Javaサンプルコード

Javaサンプルコード(ExtractPageAndLink)のダウンロード(ZIP)

入力元PDFから1ページ単位で取り出し、出力先PDFを生成します。
この時、入力PDFの文書情報を、出力先PDFに設定しています。
更に、前後ページのPDFファイルへリンク注釈を設定しています。

入力サンプルPDF(総ページ数3)

pdftool.6.0.sample

出力サンプルPDF(1ページ目)

次ページのPDFファイル(output_page_2.pdf)へのリンク注釈です。

pdftool.6.0.page1

出力サンプルPDF(2ページ目)

前ページのPDFファイル(output_page_1.pdf)へのリンク注釈です。

次ページのPDFファイル(output_page_3.pdf)へのリンク注釈です。

pdftool.6.0.page2

出力サンプルPDF(3ページ目)

前ページのPDFファイル(output_page_2.pdf)へのリンク注釈です。

pdftool.6.0.page3

索引用のPDFファイルを作成して、分割したPDFファイルへリンク注釈を設定するなども可能です。


『Antenna House PDF Tool API』(PDF Tool API)でページ単位に分割してみる(1)

『Antenna House PDF Tool API』(PDF Tool API)は、PDFファイルの情報取得やPDFファイルの加工・編集を行うライブラリです。
PDFに関するさまざまな処理機能を搭載しています。
文書情報やページ数などの情報取得、ページの挿入や削除、透かしの挿入、セキュリティ設定などのファイル加工、ページコンテンツのテキストや画像の削除、画像の最適化(ダウンサンプリング)といったページ編集処理が可能です。

今回は『Antenna House PDF Tool API』(PDF Tool API)を使用して、複数ページのPDFを、1ページ単位に分割してみたいと思います。

Javaサンプルコード

Javaサンプルコード(ExtractPage)のダウンロード(ZIP)

入力元PDFから1ページ単位で取り出し、出力先PDFを生成します。
この時、入力PDFの文書情報を、出力先PDFに設定しています。

入力サンプルPDF(総ページ数3)

pdftool.6.0

出力サンプルPDF(1ページ目)

pdftool.6.0.page1

出力サンプルPDF(2ページ目)

pdftool.6.0.page2

出力サンプルPDF(3ページ目)

pdftool.6.0.page3

入力元PDFが1000ページであれば、出力先PDFは1000ファイルになります。
分割条件を変更すれば10ページ単位や、特定の文字列をキーに、そのページで分割なども可能です。

製品に関するご質問は
sis@antenna.co.jp(SYSTEM担当)
または
oem@antenna.co.jp(OEM担当)
まで、お気軽にお問い合わせください。

評価版のお申込
評価版のお申込ページ

Webページ
https://www.antenna.co.jp/ptl/


電子図書館について徒然

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

今回は、出版関係の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年前は普及するだろう、とか言われていたような気がしますが、現実は世知辛いですね。

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

<参照記事・引用サイト>