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

XMLをMarkdownに変換することについて

前回はMarkdownをDITAに変換する方法について紹介しました。
今回のテーマはXMLからMarkdownへの変換についてですが、見方を変えると、これは「なぜ情報量を落とす不可逆な変換をするのか」ということについてを考えることになります。
もちろん様々なニーズにより行われるのでしょうが、1つの文書型を扱う上でのこと、複数の文書型を扱う上でのこと、そして文書型のことを考えないときのことをみてみましょう。中間形式としての軽量マークアップについて扱っていますが、ライティング形式として扱いやすいといったメリットは今回は省きます。

XMLの欠点として挙げられることの多い点に「複雑」「冗長」といったワードを聞くことがあります。ここでいう「複雑」は構造の話であり、「冗長」は単純に統一された要素と属性のマークアップ記法によって起こる話といえるでしょう。軽量マークアップの多くはまさにこの点を克服するものですが、これは構造の表現力や記法の統一性とのトレードオフでもあります。

ある1つの文書型について考えてみます。文書型情報を持つ「XMLアプリケーション」と呼ばれるもの、XHTMLやDocBookやDITAといった文書では、「それらの文書型を背景に持ちつつ軽量な記法を使う」、今までの記事で取り上げてきたMDITAでいえば「トップレベルの見出しはtopicのtitle、最初の段落はshortdescにする」といったことが可能です。つまり、軽量の記法と変換される構造の対応を一対一に近いものにできます。文書型にもよるでしょうが、「XMLの構造を潰す」ものとしては最小限、不可逆ではあるものの復旧が行える可能性が高いものです。

複数の文書型を扱う上での軽量マークアップを経由する変換について考えてみます。ある文書型Aの文書から文書型Bの文書を変換、生成したいというときにはXMLにおいてはXSLTを使う方が大抵の需要に沿うでしょう。XSLTを逐一用意する必要こそあるものの、明確な構造の対応が取れるのであれば落とす情報、残す情報の選択も自在です。

この場合に落ちる情報には文書型Aの構造aに対応するBの構造がない、といったものもあります。ここで落ちる情報がXSLTを用意する手間を上回り、かつそれでも変換の必要があり、Aの文書もBの文書も相互にやり取りする頻度が高いといった場合には軽量マークアップを保存の形式に選択するのも考慮に入れてもよいかもしれません。変換先に該当の構造がなければその構造は潰れるしかありません。ある軽量な構造Mを、Aのときはこの構造になることにして、Bのときはこの構造を、とするのであれば、処理系の実装言語や環境の問題を除けばMからA、MからBの変換と、ABのXML+XSLT変換はそう変わらないことになります。この場合のMは、PandocやDocutilsの扱う抽象的なデータ型となるでしょうか。

アンテナハウスでは以前に『Markdown+CSS組版で冊子本（PDF）を作ってみる』[1]という書籍を作成しました。また、「Markdown + CSS/TeXで冊子本を作ってみた」[2]というセミナーを開催しました。このセミナーでは、Pandocを使用し、Markdownの拡張機能から抽象データ型にしたものをLaTeX用に変換し書籍を作成するラムダノート様による第一部と、Markdownと、HTMLタグで不足する構造を補ったものをXHTMLに変換し、CSSでスタイルを付与しAntenna House Formatter[3]で書籍を作成するアンテナハウスの第二部となり、対照的なアプローチでの発表となりました。少し話が逸れますが、Markdownそしてその他の軽量マークアップを最終的にHTMLやPDFといった閲覧用の形式にするにあたり、変換におけるどの層にカスタマイズのウエイトを置くのか。様々なバリエーションがあり、必要なスキルセットも方法によって異なります。これは、（できていたかは別として）構造と分離していた表現をどの段階で付与するかということでもあります。抽象データ型の変換で難しいことが起こるときは、（この記事筆者の体感的には）概ねこの部分の感覚の不一致です。

さて、最初のテーマ設定に戻ります。「なぜ情報量を落とす不可逆な変換をするのか」の答えとしては、「落として問題のない情報であるから」ということになるでしょうか。
当たり前の結論ではあります。
しかし「保存形式はXMLより必ずMarkdownがいいのだ」といった話ではなく、「補完可能」あるいは「変換不能」の情報があるとき、元のリッチな表現力の形式に固執すべきかということを考えてみてもよいかもしれません。

参考

  1. ラムダノートの技術 Advent Calendar 2019

関連資料

  1. [1]『Markdown+CSS組版で冊子本（PDF）を作ってみる』 アンテナハウス CAS-UB出版
  2. [2]Markdown + CSS/TeXで冊子本を作ってみた※終了しています
  3. [3]Antenna House Formatter V7
DITA/XML Service Antenna House

Antenna House Formatter

関連記事

  1. Markdown＋CSS組版で冊子本（PDF）を作ってみる
  2. XMLエディタで始めるリッチなMarkdown入門？
  3. MDITA（LwDITA uses Markdown）の書き方
  4. DITAとしてのMDITA
  5. Markdown DITAとMDITA
  6. MDITAをDITAに変換する
LINEで送る
このエントリーをはてなブックマークに追加

MDITAをDITAに変換する

さて、前回の記事ではMarkdown DITAとMDITAの違いについて確認しました。
Markdown DITAはMDITAと比べDITA形式へ変換するためのライティング形式の向きが強いという感想を書きましたが、MDITAをDITAへ変換することもそう難しいことではありません。

DITAパブリッシングエンジンDITA-OT[1]には、標準的な出力形式として「Normalized DITA」があります。
Normalized DITAについてはDITA-OTの出力形式についてのページ[2]や弊社の「DITA入門 パブリッシング」のページ[3]でも軽く紹介をしています。外部プロジェクトなどで使用できるように、内部パスの依存関係などを処理した状態のDITAを出力するものです。DITA-OTを使ってMarkdownファイルをDITAのXML形式にするには、この出力を用いるのが便利そうです[4]。XMLオーサリングソフト[5]などではより簡便な方法が用意されているかもしれません。

今回処理するMDITAファイルは次のsample.mdとします。DITA-OTのバージョンは3.4.1を使用しました。

---
id: sampleofmd
keyword:
- markdown
indexterm:
- md
---

# Markdownサンプル {.task}

これはMarkdownのサンプルです。

この文書は`dita --format dita`でDITA形式に変換されます。

## MDITAでセクション

これはMDITAでのセクション例。IDは自動で振られています。

後からの比較のために、MDITAでは記法として有効でないものを含んでいます。

通常のDITAファイルであればDITA-OTは単体ファイルでも変換が可能ですが、
このsample.mdを直接処理しようとすると、エラーを吐きます。

dita -i \topics\sample.md --format=dita -o .
Error: Failed to run pipeline: [DOTJ012F][FATAL] Failed to parse the input file 'file:/d:topics/sample.md'.: file:/d:topics/sample.md Line 1:Content is not allowed in prolog.

とりあえず今回はマップ経由で変換を行うことにします。

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE map PUBLIC "-//OASIS//DTD DITA Map//EN" "map.dtd">
<map id="index">
<title>map title</title>
<topicref href="topics/sample.md" format="mdita" />
</map>

結果を見ると、指定した場所にマップファイルとフォルダ構造を保った
トピックファイルがあります。フォルダへ移動すると、sample.mdファイルがありますね。
……？ md？ と思いながらファイルをエディタで開いてみると、拡張子はともかく
DITAのTopic情報タイプになっています。


<?xml version="1.0" encoding="UTF-8"?><?path2rootmap-uri ../?>
<!DOCTYPE topic
  PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd">
<topic id="sampleofmd"><title>Markdownサンプル {.task}</title><shortdesc>これはMarkdownのサンプルです。</shortdesc><prolog><metadata><keywords><keyword>markdown</keyword></keywords></metadata><data name="indexterm" value="md"/></prolog><body><p>この文書は<codeph>dita --format dita</codeph>でDITA形式に変換されます。</p><section id="mditaでセクション-secid"><title>MDITAでセクション {#secid}</title><p>これはMDITAでのセクション例。IDは自動で振られています。</p></section></body></topic>

topic のidはYAML Frontmatterで指定した通りになっています。
「{」「}」囲みで要素の追加マークアップを行う記法は処理されず、
そのままタイトルに残っていますね。

本文の最初の段落はshortdescに格納されています。

YAML Frontmatterと変換後のPrologを見ると、
keywords、keywordは想定通り処理されています。
一方でindextermは汎用のdata要素
にnameとvalueとして格納されてしまいました。
YAML FrontmatterのKeyValueはLwDITAの対応範囲内で処理されていることが分かります。

セクションを切った箇所では、Markdown記法の見出しが、
sectionのidの値として自動で振られています。ここも記法が対応していないので、
「{」「}」で囲われたマークアップは処理されていません。id内では記載できる文字の関係か、
微妙に表記が変わっています。

本文段落、
「`」「`」で囲われた箇所が<codeph>に変換されているのが確認できます。
もし<pre>になることを意図していた場合はExtended Profileでタグを直接書きます。

それでは、md.ditamapのtopicrefのformatを書き換え、
これをMarkdown DITAと認識させてDITAに変換してみましょう。

<topicref href="topics/sample.md" format="markdown" />

先程と同様にマップをDITA-OTの入力に指定します。

<?xml version="1.0" encoding="UTF-8"?><?path2rootmap-uri ../?>
<!DOCTYPE task
PUBLIC "-//OASIS//DTD DITA Task//EN" "task.dtd">
<task id="markdownサンプル"><title>Markdownサンプル </title>
<prolog><metadata><keywords><keyword>markdown</keyword></keywords></metadata>
<data name="id" value="sampleofmd"/>
<data name="indexterm" value="md"/></prolog>
<taskbody><context>
<p>これはMarkdownのサンプルです。</p>
<p>この文書は<codeph>dita --format dita</codeph>でDITA形式に変換されます。</p>
</context>
</taskbody>
<task id="secid"><title>MDITAでセクション </title>
<taskbody>
<context><p>これはMDITAでのセクション例。IDは自動で振られています。</p></context>
</taskbody></task></task>

トピックタイトル行で設定したtaskが反映されています。一方で、YAML Frontmatterに記述したidは先程のindextermのように扱われ、topicのidにはなってくれていません。さらに、構造が色々壊れたものが出力されていますね。変換のコード実装を読まないとなんとも言えませんが、Strict Taskを想定しているのであればsectionは出現しませんから、Markdown DITAを書く場合には、より取り得る要素に注意しながら記述する必要があるということでしょうか。

MDITAをDITAに変換しました。Markdown DITAとの違いに注意する必要はありますが、
ドキュメントの段階的なDITAへのステップとして、
あまりピーキーではない制約のMarkdown文書をDITAの形式へ変換できることは
確かに悪くないと感じました。

DITAやDITA以外のXMLをMarkdownに変換する方向の試みも存在します。
次週はこのアプローチについて述べる予定です。

  1. [1] DITA-OT
  2. [2] Normalized DITA – DITA-OT
  3. [3] DITA-OTの対応する出力形式
  4. [4] Markdown content – DITA-OT
  5. [5] XML/DITA関連製品 – アンテナハウス

DITA/XML - Antenna House

関連記事
XMLエディタで始めるリッチなMarkdown入門？
MDITA（LwDITA uses Markdown）の書き方
DITAとしてのMDITA
Markdown DITAとMDITA
XMLをMarkdownに変換することについて
LINEで送る
このエントリーをはてなブックマークに追加

XMLエディタで始めるリッチなMarkdown入門？

Markdown記法とその派生は様々にあり、使用される場面もブログポストの原稿であったり、
Wiki記法（この記事ではHTMLへ変換される簡易記法、と考えてください）の1つであったりするので、「Markdownドキュメント」といっただけではどんな文書なのかはよくわかりません。「Markdown記法を使用して書かれている箇所があるドキュメント」くらいにはいえるのかもしれませんが。とはいえ、基本的な記法については共通しています。なので一度基本を覚えてしまえばその部分は他の派生へも通じ、その学習コストを下げることができます。

さて本題です。
「Markdownは分からないが手元にリッチなXMLエディタがある」そんなことはないでしょうか。

XML技術を駆使するDITAというドキュメントのアーキテクチャがあります。
いきなり導入するにはなかなか重量級な仕様と哲学があるので、
OASISのDITA CommitteeのSub Committeで、DITAやXMLを未だ使っていない層に向けたLightweight DITA（LwDITA）というものが考案されています[1]。
LwDITAはDITAの複雑な仕様から基本的なものを抽出し、XML、HTML5、Markdown（派生）の3つの形式でほぼ同じ表現力の記述を可能にしたものです。
特にHTML5、Markdownの形式（HDITA、MDITA）は、XML離れが激しい層へのアプローチ手法として考案された側面があり、XMLに触れなくともある程度のDITA体験が可能になっています。MDITAは単体ではGitHub Flavored Markdown（GFM）のサブセットのように扱えるので、GFMに対応したアプリケーションである程度執筆・編集のサポートが受けられます。

一方Oxygen[2]やXMetaL[3]といった、DITAをサポートするXMLエディタも
LwDITAもサポートし始めています。既にDITAのパワーをXMLエディタでフル活用されている方にはLwDITAの表現力は物足りないかもしれません。とはいえ、せっかくサポートされている機能です。もし手元に既にMarkdown対応のXMLエディタがあれば、試しに使ってみてはどうでしょうか。

参考資料

  1. [1] OASIS Lightweight DITA SubCommitteeのページ https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita-lightweight-dita
  2. [2] アンテナハウスの Oxygen情報ページ https://www.antenna.co.jp/oxygen/
  3. [3] アンテナハウスの XMetaL情報ページ https://www.antenna.co.jp/xmetal/

DITA/XML Service Antenna House

関連記事

  1. MDITA（LwDITA uses Markdown）の書き方
  2. DITAとしてのMDITA
  3. Markdown DITAとMDITA
  4. MDITAをDITAに変換する
LINEで送る
このエントリーをはてなブックマークに追加

【SODEC2020春】第29回ソフトウェア＆アプリ開発展　に出展【2020/03/23追記　開催延期のお知らせ】


2020年4月8日（水）〜10日（金）に東京ビッグサイトにて開催予定でした「第29回 Japan IT Week春」は、開催延期となりました。

「第29回Japan IT Week春」開催延期のご連絡 – Japan IT Week 事務局
以上2020/03/23追記

2020年4月8日から開催される「第29回 ソフトウェア＆アプリ開発展【SODEC2020春】」にアンテナハウス株式会社は出展致します。

例年は5月開催のところですが、オリンピックの関係で開催時期が1か月早まりました。
今年は春の訪れも早いようなので、いつもより少しだけ厚着でと出展の準備をしてきましたが、ご存じのような事態となっています。
「自粛」「辞退」と気持ちは揺れるところですが、ひと月先は誰にも予測できない状況であれば、
予定通りの開催を前提に粛々と準備を進めるだけと決め、出展のご案内をいたします。

今年も目玉は「PDF技術」。
PDFの作成から閲覧や加工・編集、そしてPDFの再利用を目的としたツールをご紹介いたします。
PDFは様々なドキュメントから変換して閲覧できることで普及してきましたが、それだけではありません。
くっつけたり離したり、書き込んだり取り出したりとお望み通りの加工・編集が可能です。
こんなことが出来ないかなとか、出来たらいいなといったご要望があればご相談に乗ります。
また、もうひとつの目玉として、ドキュメント作成の「省力化による働き方改革」を目的とした「自動組版」の提案です。
XMLなどの構造化文書の作成や大量の文書変換などのお手伝いをいたします。
ぜひともアンテナハウスブースへお立ち寄りください。

■ ご紹介製品

  • PDF Tool API
    ページ結合・分割、しおり・注釈編集などのPDF 加工機能を行うAPIです。
    ブラウザからの呼び出しで利用できるデモを会場で実施します。
  • AH Formatter
    今年20周年を迎え、2月に新バージョンを発売したXML自動組版エンジンのパイオニアです。
    日本語組版など多くの拡張機能により商品レベルの書籍組版ができます。
    また、多言語のドキュメントを大量に高速処理することで、組版の省力化を実現します。
  • Office Server Document Converter
    Microsoft Officeがインストールされていない環境でも、Word/Excel/PowerPoint等の文書をPDFや各種画像ファイルへダイレクト変換するライブラリです。
    パブリッククラウドでオフィス文書の変換を検討している皆さん、ライセンス問題はこれで解決です。
  • PDF Driver
    GDI 型の仮想プリンタドライバと、これを制御する付属APIのセット製品です。
  • PDF Server
    サーバ上で画像データやMSOffice文書からPDFを生成し、イントラネットで配信したり、各種グループウェアへ自動登録を行う開発不要のサーバソリューションです。
  • PDF Viewer SDK
    PDFの表示と編集の専用アプリケーション開発用ライブラリです。

■ 展示会詳細とアンテナハウスブース

会期： 2020年4月8日（水）～4月10日（金）
10：00～18：00（10日のみ17:00終了）
場所： 東京ビッグサイト 西展示棟
★アンテナハウスブース： 西 9-31

さて、新型コロナウイルス関連肺炎について、主催事務局ではWHO（世界保健機関）および厚生労働省のガイドラインに沿って対策を実施します。

3月3日現在予定している会期中の対策は、以下の通りとなります。

  • 出展社及び来場者に対してマスク着用のお願い
  • 全入口ゲートに手指消毒液を設置
  • 全入口ゲートでサーモグラフィーによる体温測定を実施
    37.5度以上の場合、問診票への記入を実施し、医師または看護師との面談の上、入場をお断りする場合がございます。
  • 咳エチケットと頻繁な手洗いを奨励する看板の設置
  • セミナー会場の入口を常時開放し、換気を実施
  • 医師・看護師の常駐および救護室の設置

予断を許さない状況ですが、皆様のご来場をお待ちいたします。

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

ドロップキャップ

ドロップキャップとは段落先頭の文字を大きく組むことで、書籍の組版ではよく行われています。しかし、AH Formatter V6 にはドロップキャップの機能はありません。XSL-FOやCSSに勧告された仕様はありませんが、CSSにはドラフト仕様があります。

4. Initial Letters

そこには次のようなサンプルが最初に示されています。

sample-1
これをFOで強引に組むには、いろいろやり方がありますが、例えば次のようにしなければなりません。

<fo:block>
<fo:float axf:float-x="start" axf:float-wrap="wrap">
<fo:block-container height="5em" margin-top="-1.67em">
<fo:block font-size="5.53095em">É</fo:block>
</fo:block-container>
</fo:float>tudiant (au féminin étudiante) est un mot dérivé du latin ...

ここでは、font-size と margin-top などを手計算で設定して大きさと位置を合わせています。これらは、ドロップキャップが次のように配置されるように計算されています。cap-height や baseline の位置は、使用しているフォントによって決まります。

initial-letters-cap-height
AH Formatter でドロップキャップを自動組版するためには、これらの値を自動的に計算することが必要になります。そして、CSSのドラフトに合わせると次のように指定できればよいでしょう。

<fo:block axf:initial-letters="3">Étudiant (au féminin étudiante) est un mot dérivé du latin ...

これはもっとも単純な例で、実際のドロップキャップはこんな単純ではありません。<fo:float>を利用する実装では、本当の<fo:float>が絡んできたときの制御はとても複雑になります。CSSのドラフトは、行の高さが一定であるという暗黙の前提があります。行の高さが途中で変化するようなケースでは、結果を利用者が予測できず実装も極めて複雑になるでしょう。

ドロップキャップは、次期 AH Formatter で対応される予定です。

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

『Antenna House AHPDFXML 変換ライブラリ』のコマンドライン

『Antenna House AHPDFXML 変換ライブラリ』は、PDFファイルの内部データを、
XML（Extensible Markup Language：拡張可能なマークアップ言語）形式に変換するプログラムです。
このライブラリが出力するXML形式を「AHPDFXML形式」と呼びます。
PDF解析技術により文書構造を生成して、再利用に適したXMLデータを出力します。

『Antenna House AHPDFXML 変換ライブラリ』には、コマンドライン版アプリケーションが付属しています。
今回は”AHPDFXMLCmd.exe”について書いてみたいと思います。

標準の引数は次の通りです。

  • -i PDFファイル
    入力PDFファイルのパスを指定します。(必須)
  • -password パスワード
    入力PDFにパスワードが設定されている場合、この引数で指定します。
  • -o 出力先フォルダ
    AHPDFXML形式を出力するフォルダのパスを指定します。(必須)
    保存するしおり外部ファイルの形式を指定します。

      このフォルダには、カタログXML, ドキュメントXML, スタイルXML, アウトラインXML, 画像ファイルなどが出力されます。
  • -p 接頭子
    AHPDFXML形式ファイルの接頭子を指定します。(必須)
  • -start 開始ページ
    変換対象とする、開始ページを指定します。
    省略された場合や 0以下の場合は、先頭ページからとみなされます。
  • -end 終了ページ
    変換対象とする、終了ページを指定します。
    省略された場合や実際のページ数より大きい場合は最終ページまでとみなされます。

変換オプションの引数(一部)は次の通りです。

  • -piece
    文字情報(ahp:run)を、１文字単位で出力します。
    文字単位でレイアウト座標を得たい場合などで使用します。
  • -cid
    文字情報(ahp:run)の要素に、PDFのキャラクタIDを出力します。
  • -notable
    表の解析を行いません。表情報(ahp:table)も出力されません。
  • -emf
    線画をEMFに変換します。
    複数の線画をまとめられる場合は、まとめてPNGに変換します。
    PDFのページ中に表が存在する場合などは、まとめてPNGに変換することはしません。
    この条件が設定されていない場合は、線画はSVG形式に変換されます。

呼び出し例は次の通りです。

  • AHPDFXMLCmd.exe -i input.pdf -o output -p pdfxml -piece
    • -i input.pdf : input.pdf を読み込みます。
    • -o output : AHPDFXML形式を output フォルダ下へ書き出します。
    • -p hoge : 書き出されるファイルの接頭子です。
    • -piece : 文字情報を１文字単位で出力します。

AHPDFXML形式の利用例として『サンプルXSLTスタイルシート』をご用意しております。
XMLで表現することによって、データの扱いが容易になります。
XMLのメリットを最大限に活かしてPDFデータを活用できます。
弊社ウエブサイトより評価版の申し込みが可能です。是非ご評価ください。

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

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

Webページ
http://www.antenna.co.jp/pdfxml/

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

『Antenna House AHPDFXML 変換ライブラリ』のご紹介

『Antenna House AHPDFXML 変換ライブラリ』は、PDFファイルの内部データを、
XML（Extensible Markup Language：拡張可能なマークアップ言語）形式に変換するプログラムです。
このライブラリが出力するXML形式を「AHPDFXML形式」と呼びます。
PDF解析技術により文書構造を生成して、再利用に適したXMLデータを出力します。

今回は”AHPDFXML形式”として出力される文書構造について書いてみたいと思います。

  • セクション要素
    セクション要素の属性は、矩形情報、段組み情報、縦書き/横書き情報です。
    セクション要素は、フレーム要素を含みます。
    段組み数は、テキストフレーム要素の配置から判断します。
  • フレーム要素
    フレーム要素の属性は、フレーム種別、矩形範囲、ファイルIDです。
    フレーム種別には、テキスト、表、画像、テキストボックスがあります。
    テキストフレームは段落要素を含みます。
    画像フレームには、カタログファイルに定義されたファイルのIDが指定されています。
  • 段落要素
    段落要素の属性は矩形範囲、段落スタイルIDです。
    段落スタイルには、先頭行インデント、左インデント、右インデントの情報があります。
    段落要素は、行要素を含みます。
    包含する行要素の開始位置、終了位置から、段落要素を生成しています。
  • 行要素
    行要素の属性は矩形範囲です。
    行要素はテキスト要素を含みます。
    包含するテキスト要素からベースラインを判断して、テキスト行を生成しています。
  • テキスト要素
    テキスト要素の属性は、矩形範囲と文字スタイルIDです。
    文字スタイルには、文字の大きさ、文字の色、文字のフォント、文字修飾（bold/italic、網かけ）の情報があります。
  • 表要素
    表要素の属性は、矩形情報です。
    表要素は、表の行要素を含みます。
  • 表の行要素
    表の行要素の属性は、矩形情報です。
    表の行要素は、セル要素を含みます。
  • セル要素
    セル要素の属性は、矩形情報とスタイルIDです。
    セル要素は、段落要素を含みます。
    PDF中の線画情報から、水平/垂直の線分を抜き出して、セルを生成しています。

AHPDFXML形式の利用例として『サンプルXSLTスタイルシート』をご用意しております。
XMLで表現することによって、データの扱いが容易になります。
XMLのメリットを最大限に活かしてPDFデータを活用できます。
弊社ウエブサイトより評価版の申し込みが可能です。是非ご評価ください。

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

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

Webページ
http://www.antenna.co.jp/pdfxml/

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

第二回技術書同人誌博覧会に出店します。

毎日お疲れ様です。
本日は電子出版サービスグループが担当します。

アンテナハウスが「アンテナハウスCAS電子出版」でプリントオンデマンド出版している技術書は、10冊以上あります。製品マニュアルを含めると倍くらいでしょうか。

「技術書」に関する少部数（同人誌）即売会が定期的に開催されるようになって、はや数年。

かの「技術書典」が初めて開催されてから、もう7回目を迎え、開催するごとに規模を増しているのを見て、実は技術者開発者って、自分の知識や技術を外に出したい、新知識や新技術を取り込みたい、意見交換したいんだなと思いました。

わたしですか？
わたしはPCでテレビが見られてネットサーフィンできればオールオッケー！ストレスなく使えていればよい、根っからのコンシューマ（一般消費者）です。

それはさておき、技術書に絞った同人誌即売会に新しい会が生まれ、12月14日、第2回目が開催されることになりました。

第二回技術書同人誌博覧会

技術書典（抽選）とは違い、早い者勝ちなので、我がアンテナハウスは申し込み開始日に電光石火の勢いで応募しました！
今月の半ばから入場チケットの申し込みが出来るようになるそうなので、そろそろサイトページができるころかもしれません。

売り子の社長が面白いことを言っていました。

技術書典は最近、時間を区切り、概ね午前中（～13時まで）は有料チケット購入者だけが入れるようにし、午後の時間帯は無料開場するという方針を取っています。
（技術書同人誌博覧会も同じ様式ですが、無料チケットになります。）

さて、売り上げ結果はというと、チケットを購入した人が会場を回っている時間帯のほうが大きく、逆に午後の無料開放時間帯、来場者数は多いですが、驚くほど売り上げが少なかったということでした。
売り子から見る「客」の質は、チケットを購入した来場者のほうが圧倒的に高かったことがわかります。よく考えればわかることですが、面白いですよね。。

今回の会も、同じ現象が起きそうです。
第二回技術書同人誌博覧会、12月14日（土）、プラザマーム（アンテナハウスブース：3階-た04）で開催です。
お見逃しなく！そしてご来場・ご来店をお待ちしております！

技術書同人誌博覧会公式サイト：https://gishohaku.dev/
一般参加のご案内：https://blog.gishohaku.dev/entry/gishohaku2-attend
＠技術書同人誌博覧会 運営事務局

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

oXygen 21.1 がリリースされています

oXygen のカレントバージョンは21.1です。古いバージョンをお使いの方はバージョンアップをご検討ください。

主な機能強化点は次のとおりです。

■ DITA 関連

  • 生成される WebHelp（日本語）の検索処理の改善
  • DITA マップやトピックから参照されるリソースの階層/依存関係の表示
  • 関連リンクとして追加できるトピックを素早く見つけられるように
  • 画像の挿入前にプレビュー確認

■ HTML 関連

  • 現在の編集場所で有効な要素、属性、および値の提案、多くの提案の注釈、およびHTML5仕様へのリンク

■ JSON 関連

  • JSON インスタンスを生成するためのさまざまなオプションを設定できるダイアログボックスを新設

その他多数の強化が行われています。詳しくは ここ をご参照ください。

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

「DITA Festa 2019 Tokyo」開催です

恒例の DITA Festa がやって来ます。
2019年11月27日（水）、28日（木）の二日間、場所は市ヶ谷駅のすぐ目の前です。

今回は、オムロン殿、日本電気殿、ローランド ディー.ジー.殿から DITA の導入事例発表があります。すでに受講受付が始まっていますので、興味のある方はお早めに。参加費は無料です。

詳しくは こちら をご参照ください。

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

Pages: 1 2 3 4 5 6 7 8 9 10 ... 14 15 16 Next