任意デザインのPDFを帳票に使える、デザイン不要のバリアブルPDFサーバはいかがでしょうか。

納品書、請求書、見積書や案内状等々、ビジネスシーンでは同じ様なフォーマットの書面を宛先毎に複数作成する機会が多くあります。一昔までには、こうした書面は、印刷して郵送していました。しかし、デジタル時代では書面ではなく、PDFにしてeメールで送っているのではないでしょうか。

こうしたPDFを作る方法はさまざまです。シンプルなレイアウトで、ボリュームも少なければOfficeソフトの差し込み印刷機能が便利です。ボリュームが多い場合は帳票ソフトを使うことが多いでしょう。帳票ソフトを使うときは、帳票ソフトのレイアウト機能を使って出力レイアウトをデザインし、データをどの位置に配置するかを設定することになります。

帳票専用のソフトは、すでに定番の優れたソフトがいろいろあります。しかし、レイアウトのパターンが多い場合は、帳票ソフトのレイアウト機能ではあまり効率が良くありません。さらに、凝ったデザイン・綺麗なデザインはデザイナーに依頼したくなります。デザイナーはイラストレータのようなデザインツールを使うでしょう。

そこでご紹介したいのが、このバリアブルPDFサーバです。バリアブルPDFサーバは任意のPDFページを台紙として使い、その任意の位置にテキストや画像を配置し重ね書きして、新しいPDFを作ることができます。宛先やそれに関連する情報をExcelやCSVファイルで作成しておき、PDFの上にデータを重ねて、PDF化できます。

バリアブルPDFサーバーについては、こちらのWebページもご参照ください。

バリアブルPDFサーバのご提案

・デザイン済みの台紙PDFを利用して簡単に差し込み処理を実現!!
・定形の納品書や送り状を宛先毎に一括処理!!
・画像の差し込みも可能なので、押印済みのPDFも簡単にできる!!
・指定枠内へ収まるよう自動的にフォントサイズを調整!!


[AH Formatter] MathML への取り組み

当ブログでこれまでも何度か話題として取り上げていますが、改めて『AH Formatter』の MathML への取り組みに触れたいと思います。

まず、MathML(マスエムエル)とは?
MathML は、Mathematical Markup Language の略であり、XML形式で数式などの数学的記述を表現するための言語です。
数式「x+2」であれば次のような記述で表現されます。

数式「x+2」

<mi> は変数など識別名、<mo> は +, – などの演算子、<mn> は数値を表します。

『AH Formatter』は MathML を描画するためのエンジンを独自開発、特に V6.2 では MathML描画エンジンの刷新と合わせ、W3C による「MathML 3.0」に対応し PDF中へのイメージを高い解像度で描画することが可能になりました。その後も MathML 3.0 2nd Edition に対応、最新 V6.6 では数式用の OpenTypeフォントに含まれる、MATHフィーチャへ対応するなど改良を続けています。

製品ページ、関連するブログ記事により詳細な情報を掲載しています!

・製品ページ:MathML で記述した数式を PDF に変換
[AH Formatter] MathML 3.0 2nd Edition 対応
[AH Formatter V6.6] OpenType の MATHフィーチャに対応

製品以外でも MathML を使って数式組版を行うための入門書「MathML 数式組版入門」の販売や公開、描画エンジンの性能の一端をご覧いただくため W3C の MathML仕様書を『AH Formatter』で組版、PDF出力したものを公開するなど MathML の普及のため活動を行っています。

[書籍紹介] MathML 数式組版入門
AH Formatter の CSS組版例「MathML 3.0 2nd Edition」

「MathML 数式組版入門」は、PDF版を公開しています。興味を持たれた方には是非ご覧になっていただきたい内容です。
PDF版
 
 
AH Formatter ロゴ

『AH Formatter』の評価版は以下のページよりお申し込みいただけます。是非、お試しください。
AH Formatter 評価版のお申し込み

XSL-FO の基本仕様と『AH Formatter』の拡張機能を気軽にお試しいただくため「サンプル FO 集」もご用意しています。

『AH Formatter』についてお問い合わせがございましたら sis@antenna.co.jp 宛てにご連絡ください。


[AH Formatter] line-heightプロパティ

こんにちは。
AH Formatterサポート担当です。

今回は XSL-FO の line-height プロパティのお話です。
line-heightプロパティは、行高さを指定するものですが、
その値は次のような種類があります。

normal:
line-height-“norml” のように指定します。既定値です。ユーザエージェント(AH Formatter)が適切な値に設定します。
AH Formatterではline-height=”1.2″ を初期設定としています。この値はオプション設定によって変更することも可能です。
<length>:
line-height=”20pt”のように数値+単位を指定します。
<number>:
フォントサイズに対する倍数を指定します。line-height=”1.5″ のように指定します。
<percentage>:
フォントサイズに対するパーセンテージを指定します。line-height=”150%” のように指定します。

ここで、1つ疑問に思われた方がいるかもしれません。
line-height=”1.5″ と line-height=”150%” って結局同じじゃないの? と。

実際に組版してみると、このようになります。
例1:
 <fo:block line-height=”1.5″>line-height=”1.5″</fo:block>
 <fo:block line-height=”150%”>line-height=”150%”</fo:block>
line-height プロパティ

そうです、”この場合”の行高さは同じです。
例えばフォントサイズが 30pt の場合、どちらもフォントサイズ 30pt × 1.5 で行高さは 45pt になります。
では、<number>と<percentage>で何が違うのか。
XSL-FOの仕様説明をみてみましょう。

<number>
The computed value of the property is this number multiplied by the element’s font size. Negative values are illegal.
However, the number, not the computed value, is inherited.

<percentage>
The computed value of the property is this percentage multiplied by the element’s computed font size. Negative values are illegal.

どちらの説明も前半の意味は同じですが、<number> にはこの一文が追加されています。

However, the number, not the computed value, is inherited.
日本語訳:しかしながら、計算された値ではなく、数値が継承される。

line-height プロパティの値は継承されます。親block で指定された値が子(子孫)block にも適用されます。
親block に line-height=”1.5″ または 150% が指定されていて、
子(子孫)の block でフォントサイズが変更されたとき、この “the number, not the computed value, is inherited.” が関係してくるのです。
例えば、次のような場合です。

例2:
 <fo:block font-size=”30pt” line-height=”1.5″>
  <fo:block font-size=”20pt”>line-height=”1.5″</fo:block>
  <fo:block >line-height=”1.5″</fo:block>
 </fo:block>
line-height プロパティ

例3:
 <fo:block font-size=”30pt” line-height=”150%”>
  <fo:block font-size=”20pt”>line-height=”150%”</fo:block>
  <fo:block >line-height=”150%”</fo:block>
 </fo:block>
line-height プロパティ

どちらも親block で line-height を指定しています。
1つめの子block で、フォントサイズを変更しています。

<number>の場合は、指定された数値が継承されます。
line-height=”1.5″ の場合、”1.5″ の値が継承されて
フォントサイズが変更になると、その block のフォントサイズ×1.5 の行高さになります。
例2では1つめの子block は、20pt×1.5 で35pt、2つめの子block が 30pt×1.5 で 45pt の行高さになります。

<percentage>の場合は、それが指定されたときのフォントサイズから計算された値が継承されます。
例3では、親block の font-size=”30pt” line-height=”150%” から行高さは45ptと計算されます。
(line-height の指定がない)子block には、その”45pt”の値が継承されます。
1つめの子block も 2つめの子block も同じ 45pt の行高さとなります。

両者の違いに注意してお使いください。
 
 
AH Formatter ロゴ

『AH Formatter』の評価版は以下のページよりお申し込みいただけます。是非、お試しください。
AH Formatter 評価版のお申し込み

XSL-FO の基本仕様と『AH Formatter』の拡張機能をお試しいただけるよう「サンプル FO 集」もご用意しています。

『AH Formatter』についてお問い合わせがございましたら sis@antenna.co.jp 宛てにご連絡ください。


[AH Formatter] Markdown形式の原稿を CSS組版により PDF文書に変換するための事例紹介

AH Formatter の導入事例紹介ページに有限会社フェリックス・スタイル様の事例「AH Formatter を用いた Markdown-PDF 変換事例紹介」を掲載しております。

事例紹介ページにある PDF文書では、Markdown形式の原稿を『AH Formatter』の CSS組版により、表紙や目次、ノンブルなどを備えた PDF文書へと変換するフローが詳解されております。

また、この事例紹介の PDF文書も Markdown原稿から作成されており、その作成に用いたソースファイル一式も GitHub にて公開しておりますので、実際に Markdown原稿から CSS組版を利用した PDF へのビルドをご体験いただけます。是非ご覧ください。

なお、主に海外の方に向けて、ソースファイルは英語版もご用意しております。
Markdown-PDF
https://github.com/2SC1815J/md2pdf/tree/en (English Version)
 
 
AH Formatter ロゴ

『AH Formatter』の評価版は以下のページよりお申し込みいただけます。是非、お試しください。
AH Formatter 評価版のお申し込み

XSL-FO の基本仕様と『AH Formatter』の拡張機能をお試しいただけるよう「サンプル FO 集」もご用意しています。

『AH Formatter』についてお問い合わせがございましたら sis@antenna.co.jp 宛てにご連絡ください。


[AH Formatter] より良い欧文組版を目指して その2

前記事:
[AH Formatter] より良い欧文組版を目指して

欧文組版では避けるべき現象があります。
注意することは多々あり、それらは審美的なものであったり、読み辛さを誘発するものであったりします。

例えば
・「複数段落で最後の行に一単語残る」
『AH Formatter』では axf:avoid-widow-words に true を設定することで、出来る限りその現象を避けます。
ただし行の長さが短いときは、追い込む余地が少ないのであまり効果がありません。
また、一単語を追い込む余地がない場合などでは、axf:avoid-widow-words の効果は現われません。

・「ページをまたがって一行、一単語残る」
かなり見た目が悪いので、欧文組版以外でも避けるべきでしょう。
『AH Formatter』では widowsプロパティで最低何行から次ページに送るかを設定をすることができます。
規定値は 2 ですが、ページ送りなどの設定により、1ページに少数行だけあるといった現象は美しいとは言えないでしょう。

・「同じ単語で始まるまたは連続している行が多すぎる」
このような現象があると、読み手の目線がその単語の連続に移ってしまいます。
これはあまり良い組版とは言えません。手作業で直す必要があるでしょう。

欧文組版において、考える必要のあることはこれらだけではありません。
より美しく、読みやすい組版結果を目指して『AH Formatter』は改良され続けています。
 
 
AH Formatter ロゴ

『AH Formatter』の評価版は以下のページよりお申し込みいただけます。是非、お試しください。
AH Formatter 評価版のお申し込み

『AH Formatter』についてお問い合わせがございましたら sis@antenna.co.jp 宛てにご連絡ください。


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

かなり間が空きましたが、以前の 記事 で『Antenna House PDF Viewer SDK』を使えば簡単にPDFの自動印刷プログラムが開発できることをご紹介しました。

4/10 にリリースした「V4.0改訂1版」では、まさにこのような自動印刷プログラムのサンプルをご用意しておりますので、ここで少しご紹介したいと思います。
この他にも この記事 でご紹介しているサンプルプログラムも用意しておりますので、併せてご利用ください。

印刷プログラムでは、PDFファイルと印刷先のプリンター名を指定します。

 ApiPdfPrint.exe path printer [-options]
   path            PDFファイルパス
   printer         プリンター名

これ以外に印刷時のオプションとして、開始・終了ページや用紙にあわせた拡大縮小、印刷部数、両面印刷などの指定ができます。

  -pass password  PDFファイルのオープンパスワード
  -start start    開始ページ番号(1以上)
  -end end        終了ページ番号(ページ数以下)
  -scaling <none/fit/shrink> 拡大縮小
       none:   実際のサイズ
       fit:    ページサイズに合わせる
       shrink: 特大ページを縮小
  -scale scale  カスタム倍率 省略時1.0 ※-scaling none時に有効
  -selectpaper  ページサイズに合わせた用紙サイズを選択する
  -copies <n>     印刷部数(1~100) 省略時1
  -papersize size  用紙サイズ (例 8…A3 297 x 420 mm、9…A4 210 x 297 mm)
  -tray trayno     用紙トレイ (例 7…自動用紙トレイ選択)
  -duplex <simplex/vertical/horizontal> 片面両面
        simplex:    片面印刷
         vertical:   両面印刷(短辺を綴じる)
         horizontal: 両面印刷(長辺を綴じる)
  -colate      部単位で印刷する
  -grayscale   白黒(グレースケール)で印刷する

サンプルのソースコードを添付しておりますので、お客様のシステムへの組込みの参考にして頂いたり、これをベースにもう少し細かな制御を組み込んだりとご活用いただけると幸いです。

以上、PDF自動印刷サンプルプログラムのご紹介でした。 PDF印刷の自動化が必要になったら『Antenna House PDF Viewer SDK』をぜひご検討ください。

詳しい機能についてぜひ製品ページをご覧ください。
製品ページ:
https://www.antenna.co.jp/pdfviewersdk/

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


システム製品「通常保守サービス」の【自動更新契約】を開始しました

■  前回 のあらすじ

  • システム製品「通常保守サービス」約款が、2019年6月1日付けで改定になりました。
  • 「通常保守サービス」は、入って安心な「お役立ちサービス」なので、是非ご利用ください。
  • 「通常保守サービス」は年間契約のため、保守更新の手続き忘れにご注意ください。利用できなくなります。
  • 既にお申込みのお客様は、保守更新の時期までは従来の約款が有効です。保守更新の際に新約款に移行していただきます。
  • 新約款の目玉は、保守サービス自動更新契約の開始です。

ということで、今回は「通常保守サービス」を更新する際の手間が無くなります、というお話です。

『システム製品「通常保守サービス」の【自動更新契約】(以下、自動更新契約)』開始の背景は、

「通常保守サービス」のご利用がますます増えておりますが、今後、長期に渡りより良いサービスを安定的に提供するために、「通常保守サービス」を更新する際の手続きの簡略化を目的として、「通常保守サービス」の自動更新契約を開始します。

となります。(弊社ニュースリリース「システム製品「通常保守サービス」約款改定のご案内」
より)

一言でいえば、業務の効率化と顧客サービスの向上です。はい。

では、自動更新契約の内容についての説明です。

■ 何が変わる?

弊社から「通常保守サービス」の契約更新のご確認の連絡や見積書の発行が無くなります。
また、お客様から契約更新にあたって発注書等の書類の提出も不要となります。
「通常保守サービス」終了の1 カ月前になりましたら、ご請求書と併せて「ライセンス証書」等の納品物を送付致します。
送付先は、「システム製品ユーザー登録申請書」に記載いただいた「管理担当者」、もしくは「保守サポート窓口」がある場合はその「担当者」宛となります。

■ いつから始まる?

2019年6月1日の約款改定より開始します。
2019年6月1日以降に製品をご購入のお客様と保守更新のご連絡を差し上げるお客様には、順次ご案内をさせていただきます。

■ お申し込みの単位は?

自動更新契約は、「通常保守サービス」のライセンス(シリアル番号)単位でお申し込ください。
複数のライセンス(シリアル番号)をお持ちの場合は、ライセンス毎の契約となります。

■ お申込の担当者名は?

申込者は、「システム製品ユーザー登録申請書」に記載の「管理担当者」と同じになります。

■ 製品を購入する際に申込手続きは必要?

製品のご注文の際に提出いただく「システム製品ユーザー登録申請書」の「保守サービス自動更新」欄にチェックを入れてください。別途、「自動更新契約申込書」の提出は不要です。

■ 既に「通常保守サービス」を利用している場合の申し込み手続きは?

保守更新の際に「自動更新契約申込書」をご提出下さい。申込方法と申込先は以下をご覧ください。

■ 自動更新契約の解約方法は?

「通常保守サービス」の契約期間終了の1ケ月前までに、お客様から弊社「商品センター」へ「自動更新契約解 約申込書」にて解約の通知がない場合は、「通常保守サービス」は引き続き自動更新するものとします。また、更新後の途中解約、返金はできません。

申込方法と申込先

お申し込みは、記入済み「自動更新契約申込書」のPDF ファイルまたはスキャン画像化PDF ファイルをE-Mail  に添付でお送りいただくか、FAXでもお受けできます。
E-Mail:hosyu@antenna.co.jp、FAX番号:0265-76-3913
アンテナハウス株式会社商品センター

ソリューション・システムコンポーネント製品を快適にご利用いただく為に、「通常保守サービス」の継続をお願いいたします。

※必要書類については、別途ご案内しております。お問い合わせ下さい。


『システム製品「通常保守サービス」』約款の改定のご案内

弊社システム製品をご利用の皆さん、保守サービスに入られていますか?

今回は、『システム製品「通常保守サービス」』約款を6年ぶりに改定しましたので、そのご案内です。

「約款、あの字の細かいやつね。最近度が合わなくなって。」とか「条文読むと、速攻で眠くなるから。」とか、「約款」と聞いただけで拒否反応を起こす方のなんと多いこと。

何となく保険のためにとか、断る理由もなかったからとか、初年度はタダだったからそのまま惰性でとおっしゃる方、この機会に是非ご一読ください。
保守サービス、なかなか使えるやつですので。

それでは、「保守サービス」とはなにかについて説明をさせていただきます。
正式には、『システム製品「通常保守サービス」(以下、通常保守サービス)』と言います。

ソリューション・システムコンポーネント製品の保守サービスには、次の3種類があります。

  • 通常保守サービス
  • 特別保守サービス
  • 有償技術サービス

皆さんがシステム製品を購入された際に、1年分は漏れなく付いてくるのが「通常保守サービス」です。漏れなく付いてくるからと言って「無償」ではありません。製品の価格に含まれているだけです。(第6条1項)
特をした気分になっていた皆さん、ぬか喜びをさせて申し訳ございません。

では、何をしてくれるのかといいますと、以下の5つになります。

  • お問い合わせ対応(第1条)
  • お客様の不具合報告に対する対応(第2条)
  • バージョンアップ版の提供(第3条)
  • 改訂版の提供(第3条)
  • OSを移行した際の製品提供(第4条)

特にバージョンアップ版、改訂版の提供とOSの移行は「無償」ですから、利用しまくってください。(第3条)(第4条)
とはいえ、くれぐれも利用環境での動作確認は怠らないようにお願いします。

と、便利な「通常保守サービス」ですが年間契約のため、更新し忘れるとご利用できなくなります。(第6条4項)
弊社からは更新時期の2ヶ月前にご連絡を差し上げていますが、忙しいやら面倒やら大人の事情やらで、気が付いたら更新時期が過ぎているお客様も多いとか。

「OSDCv7.0新元号対応版、5/14リリース。早速入れ替えないと!」
「お客様にご利用いただきました保守サービスは、現在期限切れで使われておりません。通常保守サービス期間が終了してからの再契約はできません。もう一度製品をご購入下さい。ピーー!」
「なんじゃあ、こりゃあ!」

こんなうっかりさんにならないために、「通常保守サービスの自動更新契約」を開始しました。(第6条4項)

この保守サービスを更新する際の手間が無くなりますよ、というのが「通常保守サービスの自動更新契約」でして、これが今回の約款改定の大きな目玉になります。

約款ではわずか一言しか記載されていないその全貌については、次回ご説明をさせていただきます。

最後に、約款改定に伴い、「通常保守サービス」に既にお申込みのお客様にお願いがあります。
保守更新の時期までは従来の約款が有効となりますが、次回保守更新のお申し込み時に新約款に移行していただきます。
特別な手続きはありません。保守更新の際に記載いただく「年間保守契約申込書」に、新約款の改訂内容に同意する旨のチェックを入れていただくだけです。
少々お手間を取らせますが、ご了承いただきますようお願い致します。

システム製品「通常保守サービス」約款改定のご案内 を覧ください。

また、ソリューション・システムコンポーネント製品保守サービス仕様 もリニューアルしましたので、細かい文字が苦手な方、こちらをご覧ください。


少子高齢化社会は、人工知能が救う?

昨今はAI(人工知能)やIoTに関する話題をメディアで見ない日がないほど、これらの技術に対する関心が高まっているように思います。
ただ普段生活している分には、これらの技術が具体的にどう役立っているのかあまり分からないというのが実感です。(単にボーッと生きているから、なのかも知れませんが…)

そこで本日は、身近にAIを取り入れ活用しようとする自治体の例を紹介してみたいと思います。

■ AIを使ったタクシーの自動配車システム

弊社の伊那支店は長野県の南部にありますが、所在地に隣接する伊那市というところではAIを利用した住民サービスの実現に取り組んでいます。

具体的には「ドアツードア乗合タクシー」といい、複数のタクシー客の予約状況に応じてAIが最適な配車やルートを示すシステムを導入することで、中山間地の住民のアシを確保する仕組みを構築しようとするものです。

少子高齢化社会の弊害は地方にいくほど深刻で、特に山間地に住む高齢者は生活のための交通手段確保が困難です。
山間地と市街地を結ぶ交通手段には路線バスがあるものの、本数も停留所も限定され利便性に欠けることから利用客は減少し、運営する自治体は赤字の補填に苦しんでいます。
また、タクシーはドアツードアの利便性はあるものの、料金が高額で気軽には利用できないというデメリットがあります。

そこで、問題の解決手段として伊那市が着目したのがオンデマンドの乗り合いタクシーです。
これは、スマホなどで住民が配車を希望すると複数の要望を受けたAIが最適な配車とルートを決定し、指示を受けたタクシーがそれぞれの目的地に向かいたい複数の客を乗り合いで送迎するという仕組みです。

=
「ドアツードア乗合タクシー」のイメージ 出典:伊那市

注)SAVS:Smart Access Vehicle Service

伊那市では既に今年の3月12日~16日に現地で実証実験を実施済みで、今後数年をかけて実用化を模索していくようです。

自治体がAIをどう運用していくのか、そのコストはどれくらいで、コストに見合った効果は期待できるのかなど今後の課題は多いだろうと思いますが、AIという技術によって少子高齢化に直面している地方でも持続可能な生活の仕組みが実現できれば、とても素晴らしいことだと思います。

関連記事:
長野県伊那市、AI活用しタクシーの配車実験(日本経済新聞)

AI自動配車タクシー 実証実験開始 2019年3月12日(火)


新元号「令和」はシフトJISで表示できない?

本年5月1日に日本の元号が改元され、新元号「令和」が制定されました。
改元の前後にはメディアでこの話題が洪水のように流され、日本中が歓迎ムード一色という感じであったのは記憶に新しいところです。

ただ、新元号の発表が1ヶ月前であったことから、和暦を使うシステムに携わる人たちはこの対応に追われて大変だったのではないでしょうか?
日頃使うWindowsにおいても、マイクロソフトが「令和」対応の更新プログラムを提供開始したのは連休直前の4月26日でした。

さて、パソコン上で元号を表す場合、「昭和」「平成」のように2文字で表す場合と「㍼」「㍻」のように1文字で表す場合があります。
後者を「合字」といいます。
更新プログラムが適用されたWindowsでは、「令和」についても「㋿」という合字が入力可能になります。

以下は、Wordを使って元号の合字を入力しPDFにしたものです。

元号とその合字

このPDFを「瞬簡PDF 変換 10」によりWordに変換してみます。

合字をWordに変換

「令和」の合字は無事変換されます。
同様に、Excelへ変換した場合もみてみます。

合字をExcelに変換

こちらも問題なく変換できます。

「令和」の合字はUnicodeの文字ポイントで U+32FF という場所に割り当てられました。
「瞬簡PDF 変換 10」はPDFの文字をUnicodeベースで扱うため、Unicodeで表現された文字は問題なく変換できます。

ところが、「瞬簡PDF 変換 10」のテキスト抽出機能を使ってこのPDFから文字を抽出し、結果をメモ帳で開くと違った結果になります。

合字を既定値テキスト抽出

「令和」の合字に対応しているはずが、テキスト抽出すると合字部分が変換されません。

実は、「瞬簡PDF 変換 10」のテキスト抽出処理は、変換条件で既定の文字コードを[Windows31J]としています。

Windows31Jは、マイクロソフト社がシフトJISをベースに規定した文字コードで、Windowsの標準日本語コードとなっています。
Windows31Jは、CP932またはMS932とも呼びます。

今回、新元号が制定されるにあたり「令和」の合字はUnicodeに追加されましたが、マイクロソフト社はこれをWindows31Jには追加しないと明言しています。
Windows 用の日本の新元号対応更新プログラムについて – KB4469068
の注に、以下の記載があります。


 Microsoft Windows コード ページ 932 (MS932)、すなわちシフト JIS エンコーディングは、新元号の合字をサポートしません。
Unicode の日本の新元号の合字 (漢字 1 文字) の文字をマルチ バイト文字に変換中に文字が正しく表示されないことがあります。MS932 エンコーディングでその逆を行う変換の場合も同様です。


これにより、「令和」の合字はWindows31Jでは表現できないことになります。

ちなみに、「瞬簡PDF 変換 10」のテキスト抽出処理で文字コードを[UTF-8]または[UTF-16]に指定し実行した場合は、以下のように変換が可能です。

合字をUnicodeでテキスト抽出

Windows上で使われることが多い標準文字コードに新元号の合字を追加しないというこの措置が、元号を扱うアプリに影響を与えないものか心配ではあります。
普段使われているアプリで「令和」の合字が表示されなかったり”?”になったりする場合は、そのアプリがUnicodeに対応したものであるかを確認してみるのがよいかも知れません。


Pages: Prev 1 2 3 4 5 6 7 8 9 10 ... 182 183 184 Next