2018-11-18

Windows 10 October 2018 Updateは古いMacにはインストールできない?

昨今、政府のサイバーセキュリティ戦略を担当している大臣がパソコンを使ったこともないという事実が問題視されている。マスコミからは「システムエラー大臣」とか散々な言われようだが、この桜田さんという方、存外、サイバーセキュリティについて造詣をお持ちなのではないだろうか。

「最も安全なコンピューターは使われないコンピューターだ」というセキュリティの格言をご存知なのだろう。電源やネットワークから切り離され、ドアのない(誰も出入りできない)部屋に置かれたコンピューターは極めて安全である。

歴史と伝統が何より大切な美しい国では、手書きの書類にハンコを押すことや、口頭によるほのめかしのほうが、より優れた情報処理手段とみなされるのも無理はない。

つまり、コンピューターや通信ネットワークを使わなければ、サイバーセキュリティに関するリスクは存在しなくなる。と、大臣はおっしゃりたいのだ。まったくもって、その通り。サマータイムも導入しやすくなるしね。日本政府の考える鉄壁のサイバーセキュリティ戦略を自ら体現している大臣は賞賛に値する。適材適所とはまさにこのことだ。

それはさておき、実際的なサイバーセキュリティの観点からはOSを最新の状態に保つことが望ましい。2018-11-13にWindows 10 October 2018 Update(バージョン1809)の配信が再開されていたので、世界最古のIntel Macである iMac (17-inch, Early 2006) にインストールできるか試してみた。のだが……

2018-04-24

プログラマのための小説・文芸原稿執筆技法

業務連絡です。

このたび、Kindle本『プログラマのための小説・文芸原稿執筆技法』を自己出版しました。 Amazon Kindleストアにて販売中です。

本書は『プログラマのための超手抜きKindle本作法』の続編です。

『プログラマのための超手抜きKindle本作法』は、横書き技術書の原稿作成方法を解説した本でしたが、今回の『プログラマのための小説・文芸原稿執筆技法』には、縦書き文芸書の原稿作成に役立つヒントを詰め込みました。

2018-03-27

Hagoromoを縦書きテキストエディターとして使う

ベストセラー作家を目指しているRさんに、業務連絡です。

アートマン21製の、macOS向け日本語リッチテキストエディタ「Hagoromo バージョン 1.14」を、小説やエッセイの原稿執筆に適した縦書きテキスト編集用に設定する方法を解説します。目障りなユーザーインターフェース要素を、できるだけ表示しないように設定することで、文章を書くことに集中できます。

見た目を次の図のようにするべく設定していきます。

ここでは、原稿1枚あたりの文字数が42文字×34行であると想定して説明します。

2018-03-23

egword Universal 2を縦書きテキストエディターとして使う

ベストセラー作家を目指しているRさんに、業務連絡です。

物書堂製の、macOS向け日本語ワープロソフト「egword Universal 2 バージョン 2.1.3」を、小説やエッセイの原稿執筆に適した縦書きテキストエディター専用に設定する方法を解説します。目障りなユーザーインターフェース要素を、できるだけ表示しないように設定することで、文章を書くことに集中できます。

見た目を次の図のようにするべく設定していきます。egword Universal 2にはプリセットされた原稿用紙のテンプレートもあるので、そちらで事足りる場合は自分で設定する必要はありません。

ここでは、原稿1枚あたりの文字数が42文字×34行であると想定して説明します。

2018-03-02

一太郎を縦書きテキストエディターとして使う

ベストセラー作家を目指しているSさんに、業務連絡です。

ジャストシステム製の、Windows向け日本語ワープロソフト「一太郎2018 バージョン 28.0.2」を、小説やエッセイの原稿執筆に適した縦書きテキストエディター専用に設定する方法を解説します。目障りなユーザーインターフェース要素を、できるだけ表示しないように設定することで、文章を書くことに集中できます。

ドラフト編集モードで縦書き表示できれば、それで済みそうなものですが、あいにくドラフト編集は横書きにしか使えないようです。イメージ編集モードを使います。

見た目を次の図のようにするべく設定していきます。

ここでは、原稿1枚あたりの文字数が42文字×34行であると想定して説明します。

2018-02-25

shift+spaceが半角スペースにならない

macOS High Sierra 10.13にアップグレード後、しばらくたって自分の入力した日本語文書の中に、空白の幅がおかしくなっている部分をたびたび目にするようになった。

半角スペースを入れたつもりが、全角スペースになっているのだ。 shift + spaceキーを押したつもりがシフトするのを忘れていたんじゃろう。 歳をとるとタイプミスが増えて困るのぉ。ヨボヨボ。

と、思っていたのだが、どうもそうではない。

しばらく観察していると気が付いた。 High Sierraの日本語入力における shift + space のコンビネーションでは、どうやら、カーソル直前の文字が全角なら半角スペースが、カーソル直前の文字が半角なら全角スペースが入力されるらしい。

空白記号を表示できるテキストエディターで、shift + spaceキーを連打した場合と、全角文字と半角文字の間にshift + spaceで空白を入力した場合にどうなるか試してみると、

2018-02-01

KDP HTML原稿の脚注

この記事は拙著『プログラマのための超手抜きKindle本作法』の補足情報です。

本書で推進するKDP向け超手抜きHTML原稿の、脚注のマークアップについて、気がついた問題点と、その後の環境変化について読者の皆さんにお知らせします。

『プログラマのための超手抜きKindle本作法』で紹介したPandocによるHTML出力では、脚注(p要素)の内容の末尾に参照元へ戻るリンク(a要素)が配置されます。

<p>脚注の内容テキスト<a href="参照元へのリンク">↩</a></p>

これに対して『Amazon Kindle パブリッシング・ガイドライン』の脚注サンプルコードでは次のようにa要素がp要素の内容の先頭に配置されています。

<p><a href="参照元へのリンク">↩</a>脚注の内容テキスト</p>

PandocのHTML出力そのままでも、Kindleアプリで閲覧するぶんには問題ありません。

ところが、Kindle端末において脚注のポップアップを正常に機能させるためには、Amazonのサンプルコード通りに記述されていなくてはならないらしいのです(a要素の位置がポイント)。

a要素がテキストの後ろにあると、ポップアップで、該当項目の他に余分な脚注も表示されてしまいます。 コンバーターではエラーも警告も出ないし、そういうもの(仕様)なのだろうと思い込んでしまいました。執筆時に参照した『Amazon Kindle パブリッシング・ガイドライン バージョン 2017.3』の、脚注のガイドラインには「双方向ハイパーリンクを設定する必要があります」としか書かれていなかったので、そんな罠があるとは思いもよらず。

さらに執筆時点とは、Pandocデフォルト設定でのマークアップ形式が変わっています。 本書出版時点の検証では、脚注のHTML出力は、

<div class="footnotes"> 〜

だったのですが、現在は、

<section class="footnotes"> 〜

となっています。このままだと本書の解説にある脚注部分のCSSが反映されません。

pandocコマンドの呼び出しにオプション -t html4 を付けることで本書出版時点と同様の出力が得られます(CSS側のセレクタを書き換えて対応する手もあります)。

また、『プログラマのための超手抜きKindle本作法』の原稿を書き上げた後、『Amazon Kindle パブリッシング・ガイドライン』の改定で、「HTML5 aside 要素と epub:type 属性を使ってマークアップすることを強く推奨」となっています。