年別アーカイブ: 2020年

MDITA(LwDITA uses Markdown)の書き方

「『Markdown文書』は一意ではない」ということを以前の記事で少し触れました。
Lightweight DITA(LwDITA)[1]のMarkdown形式「MDITA」について、もう少しみていきます。
まだ固まった仕様ではありませんので、記事で触れた挙動が変更される可能性があります。
内容に誤りがあった場合はおしらせください。

DITAについての説明は弊社サイトの情報ページ[2]やOASISのDITA Committe[3]、DITAコンソーシアムジャパン[4]といったサイトをご覧ください。

さて、LwDITAの目的ですが、ざっくりとは「複雑でとっつきにくい仕様だから、簡単な所だけ抜き出して簡単に書けるようにして、今までと違う層にも使ってもらおう」というものです。

LwDITA導入のためのOASISのページ[5]がDraftながら存在します。
説明が「DITAのこの機能をこう表現できる、この機能はない」といった方向によっていて、目的のひとつである「XMLで巨大なDITAを使っていない層へのアプローチ手法」としては難しいところです。このページのドキュメントのソースはGitHubリポジトリにあり、最終更新が2018年なので少し不安になりますが、SubCommitteのページには2020年5月のやり取りのログが公開されていたりするので動いているはずです。
Work In Progressな状態ではありますが、DITAをサポートするエディタのMarkdown対応が始まり、DITA Open Toolkit[6]でLwDITAのPreviewサポートが入った状況を考えれば、すぐに破棄される状況ではなさそうです。何より、そのような場合でも通常のXMLや他形式への変換がそう難しくないようにLwDITAは設計されています。

LwDITA以前にあった軽量記法への取り組みなどの歴史もあり、「現在使える仕組み」についての資料はWeb上から探すには
少し労力が要ります。正道としてはLwDITA導入のページ[5]からReferenceを辿っていくことになりますが、前知識のない状態でリーチするには難しい情報がそこそこあります。LwDITAについての書籍は1冊刊行されていて[7]、LwDITA SubCommitteeの現在のco-chairであるCarlos Evia氏によるものですから、ある程度信頼して良いでしょう。オンデマンド印刷版は4千円で手に入ります。

GitHubでホスティングされているリポジトリでLwDITA、というよりMDITAによるドキュメントのソースも幾つか見つかりますが、
基本的にセクション、リスト、リンク、コードブロックといった、GitBookなどでも登場するような要素のみ登場していました。
LwDITAの機能を使い倒すよりは、XML経由のMarkdownビルドに使用しているという印象です。
勿論それも付き合い方の1つではあるのですが、もう少しアピールできそうなポイントもありそうです。

今回はMDITAで使う記法について紹介します。次回はMDITAで使える(HTMLタグを書くことになりますが)DITAの機能を紹介する予定です。

DITAの、というよりLwDITAのファイルは基本的に、ひとつの事柄について扱うトピックを単位としてファイルを分割します。
トピックファイルを構成する要素は次の4つです。

  • トピックタイトル
  • Prolog(メタデータ)
  • トピックのShort Description
  • トピックの本文(Body)

MDITAの記法はCore Profileと呼ばれる基本の部分と、Extended Profileと呼ばれる部分で構成されます。
Extended ProfileはMarkdown方言(派生)の記法で有名、有用なものを採用して、Core ProfileではHTMLタグを書かなかければいけなかったところを補うようになっています。とはいえ、どれがCoreでどれがExtendedなのか、LwDITA導入のページ[5]でも表記にばらつきがあるようです。

まずCore Profileの部分を紹介します。

MDITAのトピックタイトルは次のように、<h1>レベルに変換されるような見出し記法で記述します。
行頭に「#」を置いて見出し内容とは半角スペースを挟む、ATX形式と呼ばれる見出しの記法です。
見出し内容の後に半角スペースを置き、「#」を重ねて見出し行、区切りを強調もできます。


# トピックタイトル

もうひとつ、Setext形式と呼ばれる記法もあります。<h1>:相当の見出し内容の行の下に「=」を並べる記法です。


トピックタイトル
===============

MDITAで段落の区切りは空行を挟みます(つまり、2連続で改行を入れます)。
基本的に要素同士の区切りは空白行です。

Short Descriptionはある意味簡単である意味難しいものといえるでしょう。トピックタイトルの行から1行空け、
最初の段落がそうなります。記法としてはそれだけですが、トピック全体を簡潔に記述した内容とする必要があります。
DITAのShort Descriptionの書き方として、
「Short Descriptionを重視し、そこで完結するなら本文は空でもよい」と薦められることを考えれば、簡易記法としては合理的です。
SubCommitteeのログを見ると、そのうちに記法のバリエーションが増えるかもしれません。

残りの部分は本文となります。

見出し項目はトピックタイトルの紹介で登場した、ATX形式とSetext形式の記法があります。


## ATXの見出し項目 ##

Setextの見出し項目
-----------------

仕様的な強制はありませんが、同じ文書内で同じ見出しレベルの記法を、
ATX形式とSetext形式で混在させるのは避けるべきでしょう。個人的には、後述するYAML Frontmatterの区切りに「---」を使うので、見出し項目にSetext形式を使うことは避けています。

一般的なMarkdownでのATX形式の見出し記法は、「#」を追加し<h3>から<h6>に相当する見出しが可能ですが、MDITAで使用可能なのは<h2>相当までです。この制限はトピック指向で文書を記述する際の目安になります。
つまり、これより低い見出しレベルが必要ならばトピックを分割すべきかもしれないということです。

箇条書きは行頭に「*」または「-」または「+」、半角スペースを空けて箇条書き内容を記述します。行区切りで次の箇条書き項目を記述します。
文書中で箇条書き記号の混在はしないようにしてください。入れ子の場合、行頭から親のラベルと半角スペース分の空白を空けて同じように記述します。番号付き箇条書きはCoreなのかExtendedなのか微妙な書き方をされていますが、「1」から「9」の数字始まりの半角アラビア数字と「.」または「)」、半角スペースを空けて箇条書き内容で同様に記述します。


* 箇条書き1
* 箇条書き2
* 2-1

1. 番号付き
2. 番号付き

表は単純な表を記述できます。見出し列、寄せ方向の指定ができますが、複雑な表は書けません。
縦の区切りを「|」、見出しと内容の区切りを「-」で記述します。「-」の個数はひとつでも構いません。行末の「|」は省略する場合もあります。内容の途中で表示を改行したい場合<br>が使えます。
寄せは区切りを「:---:」のように「:」で囲むと中央寄せ、「---:」なら右寄せというように表記します。


|見出し項目1|見出し項目2|
|----------|-----------|
|   内容1  |  内容2     |

整形済みテキストは、「“`」のに挟まれた箇所になります。コードブロックを意図している場合はExtended ProfileのHTMLタグでブロックを記述した方が確実かもしれません。


package main
...

インラインの記法として、次があります。LwDITA導入のページ[5]からはCore ProfileなのかExtended Profileなのか判然としないところですが、Markdownの基本的な記法であるはずです。

  • *」または「_」で囲んだ<em>。ただしXDITAだと<i>
  • **」または「__」で囲んだ<strong>。ただしXDITAだと<b>
  • [表示する文字](URL)」でリンクテキスト。
  • ![代替表示文字列](URL)」で画像

インラインの整形済みテキスト記法の「`」囲いについては記述が見つけられませんが、
DITA-OTの処理を見ると有効のようです。

さて、Extended Profileについてです。

メタデータはYAML Frontmatterと呼ばれる記法で記述できます。ファイルの先頭、つまりトピックタイトルよりも先に、「---」と書かれた行に挟まれた部分に、設定記述用言語のYAML[8]を用いてトピックのメタデータを記述します。

メタデータに記述できる内容についてMDITAのイントロダクションページにはあまり記述がなく、例も次しかありません。

  • id
  • author

MDITA(のExtended Profile)と同じ表現力のXDITAにはDTDがあるので見てみると、
厳密には設定されていないようです。また、『Creating Intelligent Content with Lightweight DITA』[7]には次のようにあります。

Those attributes can provide information like the language of a topic, critical dates for a topic (creation, last revision, expiration, etc.), and much more.

DITA-OTのMarkdown Contentのシンタックスページは厳密にはMDITAのページではありませんが[9]、keyword, category, sourceといった項目をメタデータに設定している例があります。DITA的な文書の記述を行うなら、こういった情報を記載することはファイルの取り回しに有用でしょう。


---
id: topic-id
author: antenna
category:
- "markup"
keyword:
- "mdita"
- "markdown"
---

HTMLタグでの記述もExtended Profileの分類です。この部分の書き方の詳細はHDITAについての記述を読むことになります。
注意点として、HTMLタグで始めて閉じるまでの箇所の内部はMarkdownの記法は使えません。
先ほどのメタデータもHTMLタグで記述が可能です。

Creating LwDITAのサポートページと見なしてよいであろう、Carlos Evia氏のlwdita-bookのリポジトリ[10]に、MDITAの追加サポート記法として
定義リストと脚注の記法が記されています。



DT
: DD

空白行の後に行頭からタイトル<dt>、次行の行頭に「:」、半角スペースから<dd>、内容の記述を行います。空白行で終了、
行頭に「:」と半角スペース始まりで次の<dd>です。PHP Markdown Extra記法から、とあります。

脚注は、アンカーに「[^アンカーID]」、脚注内容を「[^アンカーID]: 内容」で記述します。


XML[^xml]は、…

[^xml]: Extensible Markup Languageは、…

他に、noteを記述する記法として「<div data-class="note">」がありましたが、MDITAでは非推奨となったということです。

次週にLwDITAで使えるDITAの機能について紹介する予定です。

参考資料

  1. [1] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita-lightweight-dita
  2. [2] アンテナハウス XML/DITAサービス
  3. [3] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita
  4. [4] DITAコンソーシアムジャパン
  5. [5] Lightweight DITA: An Introduction Version 1.0
  6. [6] DITA Open Toolkit
  7. [7] Creating Intelligent Content with Lightweight DITA
  8. [8] https://yaml.org/
  9. [9] https://www.dita-ot.org/dev/topics/markdown-dita-syntax-reference.html
  10. [10] https://github.com/carlosevia/lwdita-book

DITA/XML Service Antenna House

関連記事

  1. XMLエディタで始めるリッチなMarkdown入門?
  2. DITAとしてのMDITA
  3. Markdown DITAとMDITA
  4. XMLをMarkdownに変換することについて

e-na伊那谷 旅便り 第23回 萱野高原

ご無沙汰しております! ライター小姫(ちめ)より お送りいたします。

本日は伊那ブログのバナーにもなっている箕輪町の萱野高原をご紹介します!

高原って、、いいですよね~。景色が綺麗で、空気がおいしくて、いるだけで癒されて、時間がゆっくり流れるような・・ハァ・・(遠い目
とまぁ、高原好きな私です。
萱野高原は山荘などレジャー施設がある割には穴場的な高原になっていて、人が多くなく過ごしやすいのがポイントです!

山荘からは近辺の伊那谷が一望できます。( これは秋口の写真なので季節はずれ (-_-;)


遊歩道があって散歩しながら風景や木々、鳥のせせらぎを楽しむことができます。
ゆっくり堪能しながらだと1時間くらい歩ける距離があります。

遊歩道の途中にある国見の岩。
何だか日本武尊(やまとたけるのみこと)が、ここから伊那谷を見下ろしていたみたい?

萱野高原の公式ページはこちらです。
高原の綺麗な写真や、山荘のレジャー案内が記載されています。
https://www.town.minowa.lg.jp/sangyo/sangyo036.html

この萱野高原ですが、某TV番組の一軒家のようなところにあります。

しかし安心してください、車で行けちゃいます。
車で伊那インターから30分と、ドライブついでにいけるような距離感です。
※ 途中道が狭いところがあるので運転にはご注意を・・

同じ伊那谷だと、よく中央アルプス駒ケ岳ロープウェイが TV で紹介されていますが、こうした穴場的な高原もいいですよ♪
是非、高原好きの方はお立ち寄りください!

※ 箕輪町(みのわまち)は長野県南部の上伊那郡の町です。wiki によると長野県において最も人口の多い町のようです( 知らなかった (^-^;
※ 中央アルプス駒ケ岳ロープウェイの人気の理由は、千畳敷駅の標高は2611.5m で日本最高の位置、高低差950mは日本最高、この高低差からロープウェイの景色は圧巻の一言なのです


e-na伊那谷 旅便り
前回:第22回 大芝高原
次回:第24回 家庭で作る天ぷらそば

Wordに埋め込まれたイメージ画像の解像度はどうなるか? Word2019の場合

2017年に、CASブログで、「Wordに埋め込まれたイメージ画像の解像度はどうなるか?」という記事を書きました[1]。OSDCのページの記事[2]は、この結果をもとにしています。それらの記事で書いたことを簡単にまとめると次の3点になります。

1.Word2013の内部では、イメージ画像の保存方法に旧形式(VMLのシェープ形式)と新形式(OOXMLのシェープ形式)がある。

2.イメージ画像をWord2013の編集画面にドラッグ&ドロップすると旧形式で保存され、コピー&ペーストまたは挿入―画像で埋め込むと新形式で保存される。

3.Wordの編集画面でイメージ画像のレイアウト上の大きさ(表示サイズ)を変更したとき、Word文書ファイルの内部に保存されているイメージ画像の大きさ(縦と横のピクセル数で表す解像度)がWordによって変更されることがある。その扱いが旧形式と新形式で異なっており、イメージ画像の解像度をWordが変更してしまうことを避けるには、それなりの設定をしておく必要がある。

最近、イメージ画像を含む原稿をWord2019で作成していて次のことに気が付きました:
Word2019の編集画面で、ドラッグ&ドロップでイメージ画像を配置して文書を作成し、その文書ファイルの内部をみると、イメージ画像が新形式で保存されています。つまり、Word2019で新しく文書を作るとき、イメージ画像の埋め込みには旧形式は使わないようになっています。

いつまでも昔の形式を使い続けるはずはないので考えてみれば当たり前のことですが。では、Word2019の文書ファイル内部では旧形式が廃止になったかというとそんなことはないようです。Word2013でドラッグ&ドロップで埋め込んだイメージ画像を持つWord2013の文書を、Word2019で読んでも、そのイメージ画像は依然として旧形式のまま扱われるようです。つまり、Word2019は、旧形式で保存された画像の編集機能も持っています。

実際に試してみました。次の画面はWord2019 の編集画面のリボン「図ツール」の書式タブです。上がWord2013で作成した文書を、Word2019で開いて(旧形式の)イメージ画像をダブルクリックしたときに表示されるリボンのタブ、下がWord2019で作成した新形式のイメージ画像をダブルクリックしたときに表示されるリボンのタブです。

両方ともWord2019のリボンのタブですが、これをみると、Word2019の編集画面では、同じように見えるイメージ画像でも、内部での画像の持ち方によって表示されるコマンドが異なっていることがわかります。

イメージ画像のWord2019中でのサイズ

Word2019では、ドラッグ&ドロップ、コピー&ペースト、リボンの「挿入」―「画像」のいずれの方法でもイメージ画像は同じ扱いとなります。デフォルト設定で、イメージ画像のサイズは既定の解像度を適用して圧縮[3]されます。次はリボン「図ツール・書式」タブの「図の圧縮」コマンドのデフォルト設定です。

既定の解像度は、「オプション」の「詳細設定」タブの「イメージのサイズと画質」で設定されます(次の図)。デフォルト設定では、既定の解像度は220ppiとなっています。

実際に試してみました。

まず、横2448×縦3264ピクセルのJPEG画像を用意して、Word2019の画面にドラッグ&ドロップします。画面上の幅は、図のように150mmとなっています。

画像の横ピクセル数を計算すると次のようになるはずです。

横150mm×220ppi/25.4(mm/inch)=1299pixcel

Word2019のファイルの内部を見ると、次のようにJPEG画像ファイルは、横ピクセル数が1298となっていました。1ピクセルの誤差がありますが、ほぼ計算通りです。この図は対象Word2019文書の内部を表示したものです。

関連記事

[1] Wordに埋め込まれたイメージ画像の解像度はどうなるか?

[2] Office Server Document Converter Word文書(docx文書)に埋め込まれたイメージ画像はどのように扱われているか

[3] 圧縮という用語にはいろいろな意味があるので、正確にはダウンサンプリングというべきでしょう。

[4] 用紙A4(幅210mm)で左右余白各30mm。

[5] Word文書構造については次をご参照ください:
Office Server Document Converter Office Open XML (OOXML) とは? 概要、メリットと活用アプリケーション


「日本はデジタル化後進国!」(【有料級】YouTubeミニセミナー)のご案内

だからテレワークで判子騒ぎになる!
ここで、海外と比較して、見ませんか?
日本の周りと比較しても、駄目ですぞ!
日本人の悪い癖です!
同業他社は?
あそこの会社は?
社会全体は・・・?

などと言っている間に、日本は今どういう状態なのかを、本セミナーで学習してみてください。

=セミナー概要=

  • OECD加盟国中で「労働生産性」日本に順位は?
  • 主要先進7か国で「労働生産性」の日本の順位は?
  • 主要先進7か国の国民一人当たりのGDPの日本の順位は?
  • 欧米でPDF契約が進み、日本ではあまり進んでいなかったのか?
  • エストニアでは「公認会計士」「税理士」が死滅した?
  • 日本政府の打ち手!と要件緩和の状況!
  • 日本CFO協会の4月15日コロナレポートの分析!
  • テレワークの推進のために等にも「書類」のデジタル化は有効か?

以上の内容をギュッと14分に圧縮して、YouTubeでいつでも視聴できるセミナーにしました。

https://youtu.be/aKctKhLRjOY

皆様のお役に立てれば幸いです。
また、要望を頂ければ、その要望にマッチした、セミナーの制作を検討させていただきます。

筆者紹介

益田康夫
関西大学商学部卒業

メールアドレス
masuda@antenna.co.jp

1984年に社会人になり、IT業界一筋ながら3回の転職を経て現在に至っています。
特に2008年のリーマンショック後の不況の影響を受けて、2010年6月末にリストラ退社して現本業のアンテナハウス株式会社 https://www.antenna.co.jp/ に入社しました。

Sun MicrosystemsやOracleを中心にしたITインフラから、IAサーバとしてのCompaqやIBMなどや、文書管理システムやポータルシステムを販売していた前職と、現在のアンテナハウスでのPDF技術や電子ファイルの変換技術などを中心にした、e-ドキュメントソリューションを探求してノウハウを習得してきました。

特に、2011年以降、個人で学習時間をひねり出して、文書情報管理士資格2級、1級、上級と最短記録でレベルアップさせ、更に国家資格の行政書士※、日商簿記3級を2015年までに取得しました。

※行政書士とは https://www.gyosei.or.jp/information/ をご覧ください。


記事リンク
次回:「電帳法」を優しく解説!

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に変換する

e-na伊那谷 旅便り 第22回 大芝高原

アンテナハウス伊那支店から車で5分ほどのところに、南箕輪村唯一(多分)の観光名所、大芝高原があります。(最近、道の駅になりました。)

地元民の憩いの場として知られており、筆者も小さいころはここでよく遊んでおりました。
大芝高原内には温泉やキャンプ場、プールやテニスコートにマレットゴルフ場など数々の施設が備わっており、GWに経ヶ岳バーティカルリミット(トレイルラン)、夏には大芝高原祭り、秋にはイルミネーションフェスティバルが開催されます。
(残念ながら今年は新型コロナの影響で全て中止となってしまいました。)
今回は施設など幾つかご紹介させていただきます。

元大芝高原のマスコットのまっくんです。今は南箕輪村のマスコットにまで昇格していたのですね。第一回ゆるキャラグランプリで最下位だったというのも納得のビジュアルです。松かさがモチーフなのですが、「とうもろこしじゃないの!?」と知らない人にはよく言われます。

子供に大人気のアスレチック場です。筆者も小さいころは大好きでした。
今は全部で13のアスレチックが森の中に点在していますが、昔あった大きくて危ないやつはありませんでした。
老朽化か、それとも危険で撤去されたのか分かりませんが、少し残念です。
大人でも難しい「バランスロープ」は健在でした。(クリアできませんでした。)

ストレス解消の森林セラピーなセラピーロードです。ウォーキングやジョギング、バードウォッチングが楽しめます。
今の時期のジョギングはとても気持ちいいです。歩道にはウッドチップが敷き詰められているので脚にも優しいです。
運が良ければリスに、悪ければクマに遭遇できます。おススメです。
いい汗を掻いたら、同高原内の温泉「大芝の湯」でリフレッシュしましよう。

今回紹介できなかったものも沢山あります。

興味を持った方は下記URLより詳しい内容をどうそ。
新型コロナが落ち着きましたら是非遊びにきてください。

道の駅 大芝高原
https://oshiba-michinoeki.net
宿泊施設 大芝荘
http://oshiba.jp

e-na伊那谷 旅便り
前回:第21回 こんな学校給食はいかが?
次回:第23回 萱野高原

PDFの色指定(4) ICCプロファイル

前回、CIE1931、CIELAB、CIELUVについて触れました。
これらを活用し、様々なデバイスで色について統一的にマネジメントするための仕組みがICCプロファイルです。

International Color Consortium(ICC)[1]は、コンピュータやデジタルカメラ、スキャナ、プリンタなどのデバイス上で統一して色の管理を行うための標準化団体です。ベンダー8社を中心に1993年に設立されました。

ICCプロファイルは基準となるカラースペースの定義と、それに基づく設定の記述によって構成されています。基準となるカラースペースはプロファイル接続空間(PCS)と呼ばれます。これは、CIEXYZやCIELABによるカラースペースに制限を加え、プロファイルに使用しやすいようにしたものです。PCSという共通のカラースペースがあることで、あるデバイスでの色の記述を、そのデバイスのプロファイルを使いPCSの色表現に変換し、それを別のデバイスプロファイルを使って別のデバイス上での色の記述に変換できます。またICCプロファイルには、色の記述をPCSでの色表現に変換するための共通のインターフェースという役割があります。
このインターフェースは、先に挙げたPCSとPCSに色の記述を変換する設定の書式を厳密に定めたもので、構造としては、ヘッダ部、タグのテーブル、タグに紐付いたデータで構成されます。変換アルゴリズムなどの実装については定めていません。

PCSからデバイスの色に変換する際に、そのままではデバイスで対応できない色が含まれる場合があります。そのときに対応していない色をどの色にマッピングするかを定める「レンダリングインテント」と呼ばれるものをICCプロファイルに用意できます。

caption: PCS

ICCプロファイルは、デバイスによって幾つかの種類に分けられます。主に次の3つです。

  • スキャナ、デジタルカメラなどのための入力プロファイル
  •  ディスプレイなどでの表示のためのディスプレイプロファイル
  •  プリンタなどのための出力プロファイル

他の種類もあります。

  • 画像形式での流通のためのカラースペースコンバージョンプロファイル
  • 特定の色のための命名色プロファイル
  • 追加の補正情報を埋め込むためのアブストラクトプロファイル

さらに、プロファイルを組み合わせて1つにした、デバイスリンクプロファイルがあります。

相互に色を変換するための共通の書式であるICCプロファイルについて概要を説明しました。
次回はようやく、PDFのCIEベースカラースペースについての回になる予定です。

[1] http://www.color.org/abouticc.xalter

PDFの色指定について
PDFの色指定の概要・デバイスカラースペース
PDFの色指定について(2)
色とは何か
PDFの色指定 (3)CIE1931 CIELuv CIELAB
CIEカラースペース
PDEの色指定(5)CIEベースカラースペース
PDFのCIEベースカラースペース格納形式と使用のされ方の概略

.NET Framework アプリケーションからPDF印刷

以前の記事でご紹介しましたが、「PDF Viewer SDK」を使うとPDFファイルを印刷するプログラムを開発することができます。

PDF Viewer SDKでPDF自動印刷
PDF Viewer SDKでPDF自動印刷(その2)

PDF Viewer SDK」ではC/C++言語APIの動的ライブラリ(DLL)をご用意しております。

しかしながら.NET Frameworkで開発されるお客様も多いようで、.NETからPDFファイルを印刷したい、という声もよく伺います。幸い.NET Framework にはDLLのネイティブコードを呼び出すプラットフォーム呼び出しP/Invoke)の機能があります。P/Invokeを利用すれば.NET Framework からPDFを印刷することができます。「PDF Viewer SDK」には、このようなサンプルコード “ApiPInvokeCSharp” を添付しておりますのでご活用ください。

ここで一点注意があります。このサンプルではWindowsフォームアプリケーションで標準的に利用されるSystem.Drawing.Printing名前空間を使用します。System.Drawing.PrintingWindowsフォームアプリケーション向けの印刷関連のサービスをまとめたもので、印刷ダイアログを表示したり、印刷先のデバイスを取得したりするのに利用します。

通常のデスクトップアプリケーションではこの方法で問題ないのですが、残念ながらSystem.Drawing.Printing 名前空間はサービスやASP.NETでの動作がサポートされていません。

 System.Drawing.Printing 名前空間

リンク先には、サービスやASP.NETから利用した場合動作が不安定になったりパフォーマンスの低下や実行時例外が発生するかもしれない、と書いてあります。これはWPFで利用される System.Printing名前空間も同様です。

サービスからサイレント印刷を行うようなプログラムを開発する場合は、この方法では問題があります。この場合にはちょっとしたコマンドラインをC/C++ APIで開発して.NETから呼び出す、もしくは、COMコンポーネントとして印刷機能を用意して呼び出すなどの工夫が必要になります。「PDF Viewer SDK」にも印刷コマンドラインのサンプルコード“ApiPdfPrint” を添付しています。こちらも併せてご活用ください。

以上、.NET FrameworkからPDF印刷する方法と注意点のご紹介でした。

詳しい機能についてぜひ製品ページをご覧ください。

製品ページ:
https://www.antenna.co.jp/pdfviewersdk/
評価版ダウンロードページ:
https://www.antenna.co.jp/pdfviewersdk/trial.html


PDF Viewer SDK


e-na伊那谷 旅便り 第21回 こんな学校給食はいかが?

学校給食って懐かしくないですか?
今回は長野県ならではの学校給食を紹介します。

1.キムタク御飯

テレビ等でも紹介されたことがあるのでご存知の方もいるかと思いますが、キムチとたくあんの混ぜ御飯です。
組み合わせが秀逸で、子供から大人まで多くの年齢層に人気があります。

2.塩丸イカのサラダ

長野県人にはおなじみの「柔らかさの中にある歯ごたえ」と「絶妙な塩気」で人気の塩丸イカを使ったサラダです。
塩丸イカ自体は塩気が強すぎるため、一度塩抜きしてから調理します。

3.ニジマスの円揚げ(つぶらあげ)

冷たい水を好むニジマスは渓流の多い長野県で古くより食されてきた魚です。
油で揚げるとクルっと丸くなるので「円揚げ」。
骨まで丸ごと食べられるので子供にも大人気です。

実際に給食で出される料理の写真は撮れないので家で作ってしまいました。

キャベツの味噌汁も付けて。。。。いただきます!

長野県は「緊急事態宣言」が解除され学校も再開されつつありますが、授業をフルに受けられない短縮授業となっている学校がまだ多くあります。
美味しい給食が食べらる日常へ1日でも早く戻ると良いですね。


e-na伊那谷 旅便り
前回:第20回 古代米「白毛餅」
次回:第22回 大芝高原

暗号化されていてもPDFを開くときはご用心

暗号化されているPDFが送られてきてそのパスワードを知っていたら、作成者を信用して PDFを開いた後についつい不用心にPDFViewerの警告を無視していろいろと危ない操作をしてしまうかもしれません。しかし、2019年に、PDFのパスワードを知らないでもパスワードを変えずにPDFを色々と改変できてしまう脆弱性が発見されました(https://pdf-insecurity.org/index.html)

まだ脆弱性に対応していないPDFViewerもあるかもしれないので、外部からもらったファイルには細心の注意を払いましょう。


Pages: Prev 1 2 3 4 5 6 7 8 9 10 11 12 13 Next