作成者別アーカイブ: AHEntry

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

LINEで送る
このエントリーをはてなブックマークに追加

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 にこのアルゴリズムを導入することが検討されています。

 

LINEで送る
このエントリーをはてなブックマークに追加

『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を、１ページ単位に分割しながら、リンク注釈を設定します。
設定されたリンク注釈をクリックすると、前後のページのPDFを呼び出します。

Javaサンプルコード

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

入力元PDFから１ページ単位で取り出し、出力先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ファイルへリンク注釈を設定するなども可能です。

LINEで送る
このエントリーをはてなブックマークに追加

『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を、１ページ単位に分割してみたいと思います。

Javaサンプルコード

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

入力元PDFから１ページ単位で取り出し、出力先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/

LINEで送る
このエントリーをはてなブックマークに追加

電子図書館について徒然

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

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

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

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

LINEで送る
このエントリーをはてなブックマークに追加

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

LINEで送る
このエントリーをはてなブックマークに追加

FormatterでA3横サイズのPDFをA4縦サイズ2ページに分割してみる

昨日に引き続き、Formatterの普段とはちょっと違った使い方第三弾です。

すでにA3横サイズで作ってしまったPDFをA4縦サイズ2ページに分割したいことってありませんか？
だいぶ前にお客様からそういうご要望をいただいたことがあります。次のような新旧比較表でした。

これを次のようにA4見開きにしたいわけです。

いろいろと考えた挙句、次のようにすることにしました。

1. A3横サイズの左側だけをトリミングしてA4縦のページに乗っける絵にすると次のようなイメージです。

2. A3横サイズの右側だけをトリミングしてA4縦の次のページに乗っける絵にすると次のようなイメージです。

スタイルシート的にはこんな感じ

分かりにくい説明で申し訳ありません。
ご興味のある方は是非ご一報を！　詳しく説明させていただきます。

LINEで送る
このエントリーをはてなブックマークに追加

Formatterで画像やテキストを重ね書きしてみる

以前このブログの「FormatterでMathMLをPDFにしてみる」という記事でFormatterの普段とはちょっと違った使い方の紹介をしましたが、今日はその第二弾です。

たとえば次のようなXMLがあったとします。

そうすると

こんな感じにいつもとは違ったちょっとポップなPDFができちゃいます（もちろん別途XSLTスタイルシートは必要ですが）。

自動組版というよりはDTPソフトっぽい使い方ですね。テキストの部分にはFormatterの機能でドロップシャドーを付けてみました。

工夫すれば頻繁に更新するチラシや優待券みたいなものも作れるかもしれません。

LINEで送る
このエントリーをはてなブックマークに追加

海外出展情報　その２

近年では、自己出版、電子書籍、ウェブ制作に重点が置かれています。 それでもまだ、イベントでは紙の本が中心的な存在でした。

Digital Book World 2018

今年のDigital Book World（10月2－4日開催）は、いつもの展示会とは少し異なって、オーナーが替わり、出展会場が替わり、また焦点となるテーマにも変化がありました。 以前は、Digital Book Worldカンファレンスは、電子書籍、その関連技術、および既存のコンテンツを電子形式に移行するための最良の方法を理解する目的でユーザーが参加できる数少ない会議の1つでした。 しかし、長年にわたって人々の関心は減少方向にありました。 その結果、F&W Media publishingは、2017年にScore Publishingにこの展示会を売却しました。Score Publishingは、他にiBooks Author Conferenceもプロデュースしています。

今まで開催してきたニューヨーク市に替わって、Digital Book Worldはナッシュビル・テネシー・ミュージックシティ・コンベンションセンターに移転しました。 コンベンションセンターは巨大で、約1,000人の参加者には大きすぎました。 ジョイントセッション、ブレークアウトセッション、朝食/昼食、展示エリアは、それぞれ建物が異なるフロアとエリアにありました。

Digital Book Worldは6つのトラックで構成されていました。 マーケティング、教育、法律、データ、制作、および新メディアを提供していました。 ケーススタディーセッションもありました。 注目された分野は音声技術（アレクサ、シリなど）、オーディオブック、デジタルブックでした。 出展者の大部分は、オーディオへの移行、書籍の販売、配布を手がけているサービスプロバイダーでした。

Score Publishingのビジネスは、オーディオブック、Kindle、インタラクティブなibooksと印刷の分野を中心に扱っています。 それが会議に反映されたのは驚くことでははありませんでした。 これらの分野に関心のある著者や出版社は、会議で生産性を見い出したでしょう。しかし、企業の自動化ソリューションに興味を持ち、書籍の背後にあるテクノロジーに関する議論を期待していた出席者としては、それは少し残念であると感じました。

アンテナハウス（海外サイト）
http://www.antennahouse.com/

http://rainbowpdf.com/

LINEで送る
このエントリーをはてなブックマークに追加

海外出展情報　その１

アンテナハウスは最近、ドイツで開催のFrankfurt Bookfairとテネシー州ナッシュビルで開催のDigital Book Worldに出展しました。 これらのイベントに参加することの趣旨は、出版業界の方向性、出版社、ベンダー、消費者が興味を持って探しているものへの理解をより深めることです。

Frankfurter Book Fair（10月10－14日開催）は、500年以上の伝統を持ち、出版社の数と訪問者数の両方においても世界最大の書籍見本市です。世界中の出版社や訪問者が集う国際的なイベントです。 今年は109カ国から7503社の出展者と285,000人の来場者がありました。 5日間のフェアは、大規模な複数階建ての建物内にあるおびただしい数のパビリオンで開催されます。 アンテナハウスが関連しまた関心を持った分野は第４ビルに集中していました。第４ビルには、主に出版業界、学術出版の展示がありました。 ブックフェアにはアンテナハウスのパートナーがいつものように出展、ヨーロッパの長年のお客様とも会える大変貴重な機会でもありました。

アンテナハウス（海外サイト）
http://www.antennahouse.com/

http://rainbowpdf.com/

LINEで送る
このエントリーをはてなブックマークに追加

Pages: Prev 1 2 3 ... 51 52 53 54 55 56 57 ... 210 211 212 Next