「電帳法」を優しく解説!

  • 一丁目一番地の話し
    • 青色申告法人の帳簿書類の保存義務について
  • 政府のデジタル化の取組の流れ
    • 財務省のICT施策の具体例
  • 電帳法※の制度比較について
    • 「電子帳簿等保存制度」と「スキャナ保存制度」
  • 税務署宛て申請書の簡素化(JIIMA認証・申請書サンプル)

について、優しく解説させて頂きます。

内容をギュッと22分に圧縮して、YouTubeでいつでも視聴できるミニセミ
ナーにしました。
お好みのところのみ短時間での確認も可能です!!

皆様のお役に立てれば幸いです。

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

筆者紹介
益田康夫
メールアドレス:masuda@antenna.co.jp

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

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

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

※電子帳簿保存法

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


記事リンク
前回:「日本はデジタル化後進国!」(【有料級】YouTubeミニセミナー)のご案内
次回:「帳簿・書類」7年保存は何故? YouTubeミニセミナー第3弾



瞬簡PDF 書けまっせ 2024
PDFに文字が書ける! 入力欄を自動認識


瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換

テレワークの目的を考える やはり日本では首都直下地震対策が一番重要

3月下旬から新型コロナウィルス感染症(COVID-19)対策として日本でも世界でもテレワークで働く人が急増しました。

前回(2020年5月よりテレワークを本格導入へ。中小企業のテレワーク実践例としてご参考まで。)は、主にCOVID-19対策の緊急措置をきっかけとして、弊社でテレワークを導入したこと、その問題点について報告しました。

その後、日本では5月下旬に緊急事態が解除され、また欧米でも解除の動きがあります。それに伴いテレワークについて大局的に・冷静に見直そうという話題も紹介されています。例えばFacebookは、COVID-19対策で大部分の社員が自宅からテレワークで働くようになったため、シリコンバレーの本社がゴーストタウン化していて、今後、シリコンバレー本社の価値などを含め抜本的な対策を考えていると発表しています[1]。

日本では首都圏を除くエリアが5月18日から緊急事態解除、首都圏が5月26日から緊急事態解除となりました。新型コロナウィルス(SARS-Cov-2)がいなくなったわけではなく、まだ感染リスクが残っている状況ですが、都心に働く人が徐々に戻ってきているようです。弊社でも、現在は希望者のみを対象として平常時のテレワーク規定を運用しており、社員の約3割がテレワーク、約7割が通常勤務となっています。

2カ月程度ですが、テレワークを実施する過程でいろいろな問題点が上がってきています。今後、そうした問題の一つ一つにきめ細かく対処することが必要です。一方で基本に立ち返って、なんのためにテレワークを導入するのか、一番大きな目標として、なにをすべきだろうかを最初に考えてみたいと思います。

首都圏直下巨大地震の可能性を考える

テレワークの目的を原点から考えなおすとすると、日本の大都市、特に東京が抱える、感染症とは別で、もっと大きなリスクである「首都直下巨大地震」について考えざるを得ません。

米国や欧州(イタリアやスペインを除く)の多くの先進国の国土と比べると、日本の主要部分が所在する日本列島は、世界の中でも特に火山と地震が集中している地域です。その原因はプレートテクトニクス(地殻表面が多数のプレートに分かれていて、各プレートはマントル対流に載って移動するという現象)にあります。プレートテクトニクスを少しでも学んだことがあれば、地球上の火山と地震はプレート境界線に沿って分布していることを知っていることでしょう。

最近の研究では、日本列島の中央から北部はオホーツクプレートに属していて、その南端である中部地方と関東地方の下にはフィリピン海プレートが沈み込んでいるそうです。その境界が相模トラフです。フィリピン海プレートの下にはさらに太平洋プレートが沈み込むという複雑な構造になっています[2]。プレートの移動速度は、例えばフィリピン海プレートは年間3cm程度で、この移動がプレート間の境界面にひずみ(すべり欠損)として蓄積されます。1923年9月に発生した大正関東地震(M7.9)はフィリピン海プレートの上部境界で発生しています。その前のM8クラスの地震は、1703年五代将軍徳川綱吉の時代の元禄関東地震(M8.1)とされています。これもフィリピン海プレートの上部境界で発生しています。この間200年ですが、大正関東地震では200年分の移動に相当する6~7mのプレート境界のすべり欠損が解消されたとのことです。200年に1回であれば次の関東大震災は2100年過ぎになりそうですが、関東地方の地下は複雑で様々なタイプの大地震の巣があります。そして、M7クラスの地震は過去100年間に5回発生しています。こうした地震は周期的でないため地震本部では確率予測をしており、それによると「30年以内にM7クラスの地震が発生する確率は70%」とされています[3]。前回のM7クラスの地震は1987年の千葉県東方沖地震(M6.8)です[4]。確率予測のため、いつ起きるか分からないが、いつ起きても不思議ではないということになります。

会社としてどのように首都直下地震に備えるか

大地震対策の基本としては、事務所の建物や内部の耐震対策があります。しかし、耐震性の強化で仮に、震災時の事故を回避したとしても、首都圏ではインフラの破壊、それによる水や食料不足など様々な問題が見込まれます。弊社では経営理念に「社員が仕事を通じて物心両面の幸福を得られるようにする」ということをあげていますが、それを平たく言えば、会社とはそこに集まった社員の生活の糧を得るための場ということになります。地震で経済的に飢えてしまっては会社の役目を果たせません。

そこで、仮に首都直下大地震に遭遇してしまっても、会社がなくなることがなく、ずっと継続していけるようにしなければなりません。こうしたことに備えるには、やはり働く場所を首都圏に過度に集中させず、地方に分散化していくことが重要だと思います。そのためにテレワークを活用することが重要だろうと考えます。それにしても日本という国は災害が多いですね。

[1] Facebookが社員半数をリモートワークに、シリコンバレー外に複数の拠点開設へ
[2] 『日本列島の下では何が起きているのか』(中島淳一著、講談社ブルーバックス、2018年10月発行)第10章 関東地方の地下で何が起こっているか?
[3]  関東地方の地震活動の特徴 (地震本部)
[4] 『首都直下地震』(平田 直著、岩波新書、2016年2月)




アウトライナー
PDFを解析して しおり・目次を自動生成


HTML on Word
WebページをWordで作る!

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に変換することについて



アウトライナー
PDFを解析して しおり・目次を自動生成


瞬簡PDF 編集 2024
かんたん操作でPDFを自由自在に編集

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

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

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

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

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


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

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

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

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

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

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

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


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



HTML on Word
WebページをWordで作る!


瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換

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) とは? 概要、メリットと活用アプリケーション




アウトライナー
PDFを解析して しおり・目次を自動生成


瞬簡PDF 編集 2024
かんたん操作でPDFを自由自在に編集

「日本はデジタル化後進国!」(【有料級】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/ をご覧ください。


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



瞬簡PDF 編集 2024
かんたん操作でPDFを自由自在に編集


瞬簡PDF 作成 2024
ドラッグ&ドロップでPDF作成

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



瞬簡PDF 書けまっせ 2024
PDFに文字が書ける! 入力欄を自動認識


瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換

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

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

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

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

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

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

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

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

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

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



瞬簡PDF 書けまっせ 2024
PDFに文字が書ける! 入力欄を自動認識


HTML on Word
WebページをWordで作る!

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ベースカラースペース格納形式と使用のされ方の概略



瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換


瞬簡PDF 統合版 2024
アンテナハウスPDFソフトの統合製品!

.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




瞬簡PDF 変換 2024
PDFをOffice文書へ高精度変換


瞬簡PDF 統合版 2024
アンテナハウスPDFソフトの統合製品!
Pages: Prev 1 2 3 ... 29 30 31 32 33 34 35 ... 227 228 229 Next