作成者別アーカイブ: AHEntry

高速なPDF表示を実現!『Antenna House PDF Viewer SDK SP版』

『Antenna House PDF Viewer SDK SP版』は高速な PDFファイルのレンダリングを実現した .NET Framework のライブラリです。

4月21日より評価版の配布を開始しました。ご興味があればぜひお試しください。

『Antenna House PDF Viewer SDK SP版』はWindows 上の .Net Framework に対応したアプリケーションへのPDF表示機能を組み込みや、PDFファイルの画像ファイルへの変換や印刷などに利用することができます。
高速なPDFレンダリングにより、スムーズな画面表示や、画像出力や印刷時間の短縮が見込めます。製品ページに速度改善の計測例がございますのでご覧ください。
また、すぐにお試しいただける簡易PDFビューアーのサンプルコードを添付しておりますので、評価版でぜひお試しください。
現在はPDFの描画機能が中心でまだ開発途中ですが、今後、検索やテキスト抽出など他の機能も充実していく予定ですので、ご期待ください。

詳しい製品情報や評価版の申し込みについて、下記のページをご覧ください。

製品ページ:
http://www.antenna.co.jp/oem/ViewerSDK/sp_edition.html
評価版のお申し込み、お問合せ:
http://www.antenna.co.jp/oem/ViewerSDK/sp_edition.html#pagelink04


Server Based Converter V6.0:PDF変換, Flash変換, イメージ変換, サムネイル作成, PDFセキュリティ, Office変換

Server Based Converter  V6.0 では Microsoft Word(.docx) 用読み込みエンジンの改定を行いました。
文書の処理部分を1から作成しなおしました。

以前の読み込みは、リッチテキストコンバータから続くOffice 文書処理技術の蓄積で作成されていました。 最初は doc(OLE) ファイルの処理から始まったプログラムは年月を重ね、プログラム、データ構造などが肥大化し新しい機能への対応も難しくなっていました。

最新の Word ファイル(.docx) の中身は XML ファイルです。
XML 文書処理においては AH Formatter という技術もあり、古い doc 形式のデータ構造から見直し、作り直すこととなりました。

Word の OOXML (Office Open XML) は文書であり、本文 (document.xml) は文字列の並びに Property が付いているだけです。文書ですから先頭からシーケンシャルに処理することが可能になります。
新しいエンジンではシーケンシャルに文書のタグをハンドリングし、処理が終わればデータのメモリは順次開放していきます。このあたりのデータ構造も新しく作り直し、使用メモリ量も抑えることができました。少ないメモリで動作するということは、大きな文書の処理でもスピードが遅くなることが少なくなります。

ページ処理は AH Formatter の Area という構造を使います(以前も使ってはいた)。文書では のパラグラフごとに BlockArea を作成し、Word の段落属性を attribute として設定します。BlockArea 内には LineArea を作成し、親の BlockArea の情報で TextArea を並べ行を作成していきます。
この Area 構造は AH Formatter と同じで、行などエリアの分割なども AH Formatter の組版エンジンプログラムを呼び出し処理します。

また、文字列以外のシェープなどの処理は、今まである Excel,PowerPoint と共通化して同じ処理を行っています。このように新しいエンジンを1から作成したといっても、AH Formatter などの既存のプログラムを使っており、安定感のあるプログラムになっています。
再現性が向上したとの評価もうけています。

興味のあるかた、以前のバージョンをお使いのかたは 評価版 をお試しください。

プログラマの疑問

Word の用紙設定 はなぜ最後にあるのだろう。
用紙設定を取得するために1度最後まで解析する必要がある。
途中にもあるので読み飛ばすわけにはいかない。

30年以上前に日本語ワープロを開発していたプログラマの疑問

[1] AH Formatter


PDFのレイヤー

PDFには、レイヤーという便利な機能があります。
レイヤーは、PDFの内容をまとめて、表示を切り替えたり印刷を切り替えたりします。 Acrobatでは次のようなダイアログでコントロールします。

layer-dialog

AH Formatter には、このレイヤーを出力する機能があります。
今回は、PDFのレイヤーでの言語指定について取り上げます。

レイヤーで指定した言語は、どのように振る舞うのでしょうか。
仕様では次のように書かれています(PDF 32000-1:2008)。

Language dictionary (Optional) A dictionary specifying the language of the content controlled by this optional content group. It may contain the following two entries:

Lang (required) A text string that specifies a language and possibly a locale (see 14.9.2, “Natural Language Specification”). For example, es-MX represents Mexican Spanish.
Preferred (optional) A name whose values shall be either ON or OFF. Default value: OFF. it shall be used by conforming readers when there is a partial match but no exact match between the system language and the language strings in all usage dictionaries. See 8.11.4.4, “Usage and Usage Application Dictionaries” for more information.

Language については、次のようにも書かれています。

Language: This category shall allow the selection of content based on the language and locale of the application. If an exact match to the language and locale is found among the Lang entries of the optional content groups in the usage application dictionary’s OCGs list, all groups that have exact matches shall receive an ON recommendation. If no exact match is found, but a partial match is found (that is, the language matches but not the locale), all partially matching groups that have Preferred entries with a value of ON shall receive an ON recommendation. All other groups shall receive an OFF recommendation.

PDFに指定されたLanguageは、アプリケーションの言語と地域に基づくと書かれています。アプリケーションとは、PDFのビューア、例えばAcrobatのことです。アプリケーションがレイヤーをサポートしていなければ、もちろん何も起こりません。Acrobatはサポートしています。

PDFに、日本語用のレイヤーと英語用のレイヤーを用意しておけば、アプリケーションの言語によって自動的に一方が表示され、他方が表示されないということができます。では、アプリケーションの言語とは何でしょう。仕様書中でそのことについて書かれている部分はありません。
そこで、どうすれば言語によるコントロールが意図どおりにできるのかを、Acrobatを用いて、試行錯誤を交えながらいろいろ探ってみました。

PDFには、Catalog辞書に言語を明示することができます。これは、文書のプロパティで確認することができます。AH Formatter では、<fo:root> に記述した言語がそこに反映されます。

<fo:root ... xml:lang="ja" ...>

property-dialog

アプリケーションの言語とは、これのことでしょうか。
いいえ、この言語はレイヤーの言語とは関係ありません。
これは、PDFの言語であってアプリケーションの言語ではありません。
アプリケーションの言語とは、Acrobatでは環境設定の言語環境にあるアプリケーションを表示する言語に対応することがわかりました。

lang-env

では、アプリケーションの言語は、具体的にはどう表記されているのでしょうか。14.9.2.2 Language Identifiers には次のような記述があります。

A language identifier shall either be the empty text string, to indicate that the language is unknown, or a Language-Tag as defined in RFC 3066, Tags for the Identification of Languages.

Although language codes are commonly represented using lowercase letters and country codes are commonly represented using uppercase letters, all tags shall be treated as case insensitive.

ざっくり言えば、PDFに書かれるLangの値は、RFC 3066 に従っていて大文字小文字は区別しない、ということです。RFC 3066 の言語コードは ISO 639、国コードは ISO 3166 によります。アプリケーションの言語も、ISO 639 と ISO 3166 で表現されているはずです。
実際にAcrobatでアプリケーションを表示する言語を変更すると、どこにどういう情報が書かれるのかはわかりませんでした。しかし、日本語なら ja とか ja-JP などが設定されると、常識的には予想するでしょう。

Preferredを指定していないと、Langに指定したものとアプリケーションの言語の間では完全一致性が判断されることになっています。そこで、日本語環境のとき、どういう指定をしたら完全一致するのかを調べました。

  • ja ⇒ NG
  • jpn ⇒ NG
  • ja-JP ⇒ NG
  • jpn-JP ⇒ NG
  • jpn-JPN ⇒ NG
  • ja_JP ⇒ NG
  • jpn_JP ⇒ NG
  • jpn_JPN ⇒ NG
  • ja-jp ⇒ OK

結果は、まったく想定外でした。仕様には大文字小文字区別しないと明記してあるし、国コードは大文字で表記するのが普通とも明記されています。これはどういうことでしょうか。Acrobatは仕様どおりに動作しているようには見えません。Acrobatの不具合なんでしょうか。仕様の見落としがあるのでしょうか。

完全一致させるのにこんな試行錯誤した上、それが正しいのかどうか裏づけも取れないのでは、完全一致を使うのは現実的ではない気がします。Preferredを指定すると、かなりあいまいな指定でもマッチします。
日本語は、それを話す国は日本しかないですが、英語やポルトガル語スペイン語などはそんなことはありません。例えば、en-US(米国英語)と en-GB(英国英語)を区別したいこともあるはずです。Preferredでは、それらを区別させることはできませんでした。どちらもすべての en にマッチしてしまうようです。つまり、国コードを明示したいなら、Preferredを指定できないということになります。

次に Preferred な ja と、そうでない ja-jp の指定を混在させたらどうなるか見てみます。
日本語環境ではどちらも表示されそうなものですが、ja-jp の方だけ表示されて、ja は表示されません。完全一致するものが見つかったらそれしか表示されない、ということになっているからのようです。このことは、en-US と en-GB を用意し、両者の共通部分を en として表現したくても、できないということを意味します。

AH Formatter V6.4 では、次のようにレイヤーへの言語指定を行ないます。
実際には重なり合った領域に内容を配置するでしょうから、<fo:block-container> などを利用することになります。

<?xml version="1.0"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format"
         xmlns:axf="http://www.antennahouse.com/names/XSL/Extensions"
         axf:layer-settings="'Japanese layer' lang 'ja' preferred,
                             'English layer' lang 'en' preferred">
...
<fo:block axf:layer="'Japanese layer'">
こんにちは
</fo:block>
...
<fo:block axf:layer="'English layer'">
Hello
</fo:block>
...

AH Formatter V6.4 MR3 以降を利用してください。

 


Acrobat の不満点(その2)

前回 に引き続き、Acrobat の不満点を書いてみます。

Acrobat にて PDF を作成し、印刷も視野に入れていたため CMYK の ICC Profile を出力インテントに指定して PDF/A-2 形式で保存しました。

PDF/A-2 ではベースバージョンが PDF1.7 となったため、PDF1.4 というベースバージョンの制約があった PDF/A-1 と比べて非常に有効なバージョンになります。
以下は PDF/A-2 によって実現可能となった機能の一部です。

  • PDF 1.4 -> PDF 1.5
    JPEG2000圧縮によるイメージ
    オブジェクトストリーム、Xrefストリーム(圧縮率の向上)
    オプショナルコンテント
    XFA Form
  • PDF 1.5 -> PDF 1.6
    暗号化機能の強化(AES暗号化の追加)
    カラースペース追加(DeviceN、NChannel)
  • PDF 1.6 -> PDF 1.7(ISO 32000-1)
    3Dアートワーク
    ポータブルコレクション

PDF/A-2 の詳細につきましては、PDF資料室 過去のブログ にまとめておりますので、参照ください。

さて、PDF/A-2 で保存した結果、出力された出力インテントが RGB の ICC Profile に置き換わってしまいました。
作成した PDF にはテキスト注釈、スタンプ注釈といった注釈が含まれていたのですが、この事が原因で強制的に RGB となってしまったのでしょうか。
PDF/A-2 の仕様では CMYK が使用できない、といった制限はありませんので、不思議な結果となりました。
CMYK の ICC Profile を出力する方法はあるのでしょうか。

<< その(1)


Acrobat の不満点(その1)

日頃 PDF ファイルの編集作業で Adobe Acrobat を使用する機会が多いのですが、使用している中で不満に感じている事を書いてみます。

PDF では対話フォーム(AcroForm)と呼ばれる、使用者から対話的に情報を収集するフィールドを持つことができます。
その中にはテキストフィールド、ラジオボタン、リストボックスといった使用者が入力するフィールドや、ボタンのようにアクションを関連付けて特定のページへジャンプするようなアクションを指定することができる便利な機能です。Acrobat では「ツール」の「フォーム」にて作成可能です。

この機能は PDF1.2 以降で使用可能な機能なので、使用している方も多いのではないでしょうか。

さて、この対話フォーム(AcroForm)を使用した PDF を作成し、PDF/A(*1) へ別名保存してみます。 ところが PDF/A として保存した PDF で、表示上はボタンの画像やテキストボックス風のエリア、ラジオボタン風の円が残るのですが、マウスクリックしても全く機能しません。
Acrobat では PDF/A 保存すると、外観だけを残して対話フォーム(AcroForm)の機能自体を削除してしまうようです。

確かに長期保存する文書で使用者との対話は不向きなのかもしれませんが、ボタンでのページ移動等のように便利な機能もあるので削除してしまうのは惜しいと感じています。

(*1)
PDF/A(ISO 19005の同義語)は、国際標準化機構 ISO が制定した国際規格 ISO 19005 に定められる PDF の形式の1つです。このファイル形式の第一の目的は、使用するツールにかかわらず、長期間に渡ってファイルの視覚的な外観を維持できること、第二の目的は、PDF の視覚的な外観ではなく、論理構造、意味といった情報を格納できるようにすることにあります。
PDF/A につきましては、PDF資料室過去のブログ にまとめておりますので、参照ください。

その(2) >>


PDFチェックツール「Easy PDF Checker」のSEO日記紹介-上位ページを真似た結果、ペナルティを食らって? 地獄に落ちた

弊社では、以前に、某大学の資料センター向けに、学生さんが作ったPDFの内容をチェックするツールを開発したことがあります。また、最近、某イベント主催者の方から、「プリントオンデマンド(POD)するために入稿されたPDFのページサイズ設定やフォント埋め込みの有無を自動チェックしたい」という要望をいただき、PDFチェックツールを開発して提供しました。弊社が開発したPDF読み込み用ライブラリーを活用して比較的簡単にできました。イベント後、主催者の方に確認しましたところ、大変役立ったと好評をいただきました。

こうしたことで、PDFを一括またはオンラインでチェックしたいというニーズがきっとあるに違いない、と考えて製品化を目指すことにしました。早速、Webページを作り3月13日から「Easy PDF Checker」として公開しています。

●Webページ:PDFの用紙サイズ、フォント埋め込み、カラースペース、セキュリティをチェックできる

さて、Webページを公開後、1ヶ月してもなかなかページビューが伸びません。

なんとかしないと。

そこで4月21日にSEOのチェックツールを使って「PDF チェッカー」という単語でGoogle検索の順位を見ました。16位です。Google検索の結果から来訪が見込めるのは上位10位以内です。16位では検索による来訪数は絶望的です。順位を上げてトップ10に食い込まないと…

ちなみに検索上位ページはこんな順位でした。

1 PDFチェックツール (pdf-checker)
http://masao.jpn.org/software/pdf-checker/

2 デジタル校正ソフトウェア「Proof Checker PRO 」| その他のソフトウェア …
http://www.too.com/product/software/proofchecker/

3 デジタルカタログ作成サービスが個別見積もり対応となります/他 …
https://www.ddc.co.jp/tokupre/blog/20170117123343.html

4 PDFのプリフライトチェック(データチェック)について|PDF|印刷データ …
https://www.ddc.co.jp/tokupre/data-guide/pdf-data-preflight-check.html

5 PDFサイズチェッカー – 株式会社 恒河沙
http://www.gougasha.co.jp/products/software/pdfsizechecker/pdfsizechecker.html

1位のページは2011年(2010年?)に公開されたフリーのソフトです。見出しは次のようになっています。1位ページからの引用:

<h1>PDFチェックツール (pdf-checker)</h1>
<p>このツールは複数のPDFファイルの情報を一括してチェックするためのツールです。
もともと、図書館等における大量の紙資料をスキャンする必要がある場合において、納品されたPDFファイルやOCRソフトウェアが出力したPDFファイルを、(ある程度まで)自動的にチェックしたいというニーズに対応するツールとして試作したものです。
現在、以下の項目をチェックして出力する機能を有しています:</p>

そうかぁ。なかなか分かりやすい! しかし、機能的にみてもうちのページが負けるはずはないんだけどねぇ… 

と、いろいろ考えて4月24日に次のように変更しました。

1.タイトルを変更

変更前)<h1>PDFのページサイズ、フォント埋め込み、カラースペースを自動で確認できる</h1>

変更後)<h1>PDFの用紙サイズ、フォント埋め込み、カラースペース、セキュリティをチェックできる</h1>

2.本文を変更
本文書き出しに次の言葉を入れる。

・PDFチェックツール 
・複数のPDFの内容を一括してチェック
・納品された・出稿されたPDFを自動的にチェックできる

4月24日変更後の書き出しは次のようにしました。

「Easy PDF Checker」は、複数のPDFの内容を一括してチェックするツールです。PDFのページサイズ(用紙の大きさ、表示領域の大きさ)、フォント埋め込みの有無、カラースペースなどのPDFの内部に設定されている情報をチェックして、テキストファイルやXML形式のファイルに出力できます。コマンドラインから動作しますので、納品されたPDFを自動的にチェックしたり、Webプリントサービスなどの入稿PDFチェックの自動化に最適です。

あと、出力データの幾つかの項目に用語の説明を少しずつ追加しました。

さて、今日4月27日にはどうなったかと言いますと、

「PDF チェッカー」という単語でGoogle検索の順位を見ました。な! なんと圏外です! じ!地獄に落ちてしまいました

うーーむ。

競争相手の言葉をいろいろ頂戴してしまったので、Google先生に「このページはDeNAってる」とペナルティを食らってしまったのだろうか? たぶんそうだろう。やはり似すぎているよね…

16位と圏外ではクリック数には差が無いんだけどね(どうせ両方ゼロだから差は無い、と開き直りつつ)。さあ、どうしたら良い? 次の一手は? やはりオリジナリティ重視かな~~


本はWeb化するか? PDFとブック型WebページとEPUBを考える

4月25日よりCAS-UBのバナーを次のように変更しました。この背景には、最近、本(PDF)、ブック型Webページ[1]、EPUBの関係について考えたことがあります。

CAS電子出版では『XSL-FOの基礎 第二版』を2017年3月に発売しました。詳しくはこちらをご覧ください:『XSL-FO の基礎 第2版 – XML を組版するためのレイアウト仕様』

本書は、現在、アマゾンなどのプリントオンデマンドによって紙の本として販売しています。一方で、4月から全文をWebページ版として公開しています。

もともと本書の出版は、本の販売収益よりもむしろ、XSL-FOという技術を普及促進し、ひいては弊社のAH Formatterの販売に繫げようということを意図しています。初版はKindle版などを販売しましたが、第二版からKindle版を見合わせて、Webページ版として公開することにしました。

これは、CAS-UB V4のユーザーガイドの体験に基づきます。CAS-UBは、V4からユーザーガイドなどのドキュメントをPDF版とWebページ版を作って両方ともWebで公開しています:CAS-UBサポート&ガイド一覧(V4よりも前はPDF版とEPUB版を公開していましたが、EPUB版はあまり利用されないようなので廃止しました)。

こうしてPDF版とWebページ版を並べておきますと、自分ではPDF版を参照することがなくなり、Webページ版を参照するようになってしまいました。主に、CAS記法の説明ページやPDF出力のガイドを参照するのですが、情報を参照する際の利便性という点ではPDFよりもWebページが圧倒的に便利です。(今頃になって! という感もありますが、情報参照のための利用という点では、PDFはWebページに決して勝てないと思います!)

利便性では:Webページ版≫PDF版>EPUB版 という状態です。

4月にMicrosoft Windows 10の大型アップデートがあり、新しいEdgeでEPUB3を表示できるようになりました。これを体験していただく参考として、Webページ版に加えて、4月21日からEPUB3の公開も始めました(EPUB復活?)。

(EPUBは、こちらからダウンロードできます:CAS電子出版出版物一覧のページ

Edgeの紹介ブログはこちら:Microsoft EdgeのEPUB表示機能はなかなか良い。これからはEdgeだと言いたいところですが、しかし、残念な点もあります。 EdgeでEPUBが復活として、ブック型情報をPDFとWebページ版とEPUB版の3つのかたちで提供できるようになりました。それが今後どうなるかです。

CAS-UBの場合は、ブック型Webページの作り方をさらに改善する必要があると考えています。CAS-UB V4のWebページ版は、短期間で作ったもので完成形とは言えない面があります。またPC版とモバイル版のWebページを統合できていないのも問題です。ということで、CAS-UBの次の課題は、Webページ版のテーマ化、レスポンシブWebページ版の選択を追加することです。

[1] 本やマニュアルのような冊子として提供されるものをWebページにしたものをブック型Webページと(勝手に)呼びます。ブック型Webページは、限定された読者を対象にします。大勢にPRすることを主目的にしませんので、横串検索あるいはSEOの観点よりも、ドリルダウンで情報を探す内部検索や、主にコンテンツ内部をナビゲーションしていく仕組みが重要と考えます。マニュアルの世界ではWebHelpと呼ぶことがあります。oXygenとか、RoboHelpなどの製品にはWebHelpという言葉が使われています。但し、WebHelpという言葉自体には厳密な定義はないようです。
[2] AH Formatter
[3] 補足ですが、今日は、ブック型Webページのデザインの考え方について書かれた本を探して、神田の三省堂本店に並んでいるWebデザインの本を端から見てみました。Webページのデザインについての解説書はたくさんありますが、大抵の解説書は魅せるデザインをどう作るかというテーマを中心に取リ上げているようです。しかも、トップページのレイアウトパターンと、1つのHTMLファイルの作り方の解説が主体です。ひと塊りのWebページをどのように構成するかという良い解説は見つかりません。テクニカルドキュメンテーションの業界ではどうなんでしょう?

続きを書きました本はWeb化するか? (続き)Webアプリケーション化したオンライン版の本 vs シンプルなHTML+CSSの本

■関連記事
「ワンソースマルチユースで拓く、ブック型Webページの未来」(本ブログと続きの2回分をまとめて整理し直しました)


oXygen 19.0がリリースされました

oXygen 19.0 がリリースされました。

待望のメジャーバージョンアップです。
新機能ですが、DITA 関連については以下のようなものがあります。

その他にもいろいろあるようなので、ご興味のある方は oXygen の WEB ページでチェックしてみてください。
https://www.oxygenxml.com/xml_editor/whats_new.html


XMetaL12.0(英語版)がリリースされました

XMetaL12.0(英語版)がリリースされました。

待望のメジャーバージョンアップです。
新機能ですが、以下のようなものがあります。

  • DITA Subject scheme の適用
    DITA map で参照している Scheme map を自動的に認識します。
  • カスタムテーブルモデルのテーブル編集機能の強化
    組み込みソートと塗りつぶし操作
    セル操作の分割とマージ
    マルチセル選択
  • DITA-OpenToolkit 2.4.3 搭載
    最新の DITA パブリッシングツール 2.4.3(XMetaL12.0リリーズ時点)がご利用いただけます。必要に応じて、2.2.4 および 2.0 もご利用いただけます。

その他の機能については下記をご参照ください。
http://www.antenna.co.jp/xmetal/#xmetal_12e

それからこれは非公式情報なのですが、10月くらいに日本語版のリリースを計画しているみたいです。乞うご期待を。


現在、桜前線北上中。SBCは海外拡販に向けて準備中。

伊那支店 海外営業グループです。

Server Based Converter』(近日中に新名称でバージョンアップ&リニューアル予定)の海外市場への販売を主なミッションとして着任したばかりの新入社員(若くはありませんが)が担当する事になりました。

ですので、そちらの紹介は後日(詳細が発表できる段階になれば改めて紹介させて頂きます)に取っておいて、今回は少しやわらかめのトピックを Up させて頂きます。

日本列島を桜前線が北上するなか、伊那支店のある長野県はちょうど桜の見ごろとなっています。

4月第一週、東京出張の際に見た千鳥ヶ淵の桜も見事でしたが、松本城や日本三大桜の名所に数えられる高遠{たかとお}(あとの二つはどこでしょう?)も地元のみならず多くの観光客の目を楽しませてくれます。

ちなみに花は英語で flower と言いますが、木に咲く花(桜など)に関しては blossom と表現する事が多いです。
So I hope you come to Nagano, and enjoy cherry blossoms with a caste or beautiful mountains!

(下の写真は先週末の松本城です)

SBC

桜と松本城

全国でお花見が終わるころには精度向上とスピードアップを実現した Server Based Converter の最新情報をお届けできそうです。
Keep your eyes on Antenna House!!


Pages: Prev 1 2 3 4 5 6 7 8 9 10 ... 136 137 138 Next