WORDとLaTeXと私

ひだるまです。

2.5mmバランス端子-RCAケーブルをどう思いますか？　使っているスピーカーのレベル的に、バランスで出したとしてどこまで出るか微妙なところですよねぇ……。

Yodonami 2.5mmバランス-2RCAオス ak120?ak240 ak380 DP-X1ハイレゾプレーヤーに対応 RCAケーブル 7N冷凍単結晶銅 (0.5m)

さて、この記事はWORDIAN Advent Calendar 2018 - Adventarの8日目の記事になります。それではそろそろ表題の話へ移りましょう。

興が乗りましたら本誌の方にも載せたいので、記憶違いの指摘や名前を伏せて欲しいなどの連絡があればお願いします。

歴史

TeXはKnuthが~といった話や、WORD編集部の創立は筑波が陸の孤島だった頃~といった話は別資料をお探しください。そろそろ編集部の歴史本は必要な気もしますが。

導入

情報科学類学生がいつからLaTeXを使っているかは定かではありませんし、編集部員の利用度なども正しいところは分かりかねますが、 私の入学した時分では編集部の記事はほぼJustSystems社の「一太郎*1」を用いて書かれていました。一太郎はMS-Wordと同じような感覚で執筆する、WYSIWYGなエディタです。私は小学校の授業で触って以来でした。 編集部ではタイトル部や執筆者欄、見出しや導入を適当に埋めたものをテンプレートと称し、「名前をつけて保存」で新しい記事を作成しておりました*2。 これらを使った経験のある方なら分かるかと思いますが、MS-Wordや一太郎はコードを載せる記事や、統一された見た目の印刷物を作りたいときに難点が幾つかあります。 どちらが良いのかはおいておいて、更にはプロプライエタリであるエディタを使わなければならない状況に不満のある編集部員がいました。

突然の

主観の上、少々記憶が曖昧になってきましたが、1年以上経った頃だったと思います。 編集部にも慣れてきたある日、yyuさんとpi8027さんが「作ったんで、使いたい人は使ってください」と作成したLaTeXのテンプレートを編集部で皆に紹介しました*3。 そのときの私の頭の中では「？？？」と疑問符が踊っていました。 「なぜ一太郎で書きたくないのだろう」と。 とりあえずテンプレートのソースとクラスファイルの説明（idxとinsから生成したPDF）に目を通してみたときの感想は

「わーむずかしそーなことがかいてあるー」

でした。

そんな私を他所に、じわじわとLaTeXで記事を書く人間は増えていきました。まあ毎号いても3、4人程度ですが。 コードを書く皆は分かっていたのです、「一太郎でコード載せるのは面倒臭い」ということが。

誕生！　一太郎大臣

部内で勢力を拡大していったLaTeXですが、人数が増えると声が大きくなるので、次第にこんな声が上がるようになりました。

「一太郎の記事と見た目が違って、冊子にしたときまとまりがなくて美しくない」

LaTeXで書かれた記事は同じテンプレート基クラスファイルを使って処理されているので、別の人が書いたものでも見た目の統一がある程度されていました。 そうなると、テンプレート基以前の履歴を使って書かれたにWYSIWYGな一太郎による記事は同じ人が書いたものですら見た目がバラバラでしたから、 これは粛清の対象です。日々増大を続けるLaTeX派に一太郎派は自己を総括する必要に迫られたのです。

LaTeXテンプレートを齎した2人はLaTeX大臣としてテンプレートの改修や組版の相談などを受けるようになっていました。

特に記事のネタを思いつくでもなく居心地の悪さを覚え始めていた私は、 ある日haroperiさんが「一太郎に詳しい人欲しいよねぇ」と言ったとき飛びつきました。立ち位置が欲しかったんですね。 これはアドバイスですが、アイデンティティは自分の持っているものから確立すべきです。 一太郎は貴方の知らないものが溢れていて、例えば今は亡きJustsystems製のメーラーと連携するマクロが存在する。 マクロと言いつつほぼ言語に必要なものが揃っているので、多分マンデルブロ集合とか書ける*4。 そうして、俺達は登り始めたんだ。この長い、一太郎坂をよ……（第一部完）。

にわか一太郎の大先生には意図せずともコーナーケースを突き続ける編集部員の相手はなかなかに荷が重く、 ,無季さんに

「一太郎でこれはどうやるの」

と問われても

「俺にだって、分からないことぐらい、ある……！」

としか返せないこともありました。それでもめげずに学習を続け、とりあえず暫定テンプレートになっているものを書式設定として登録したり、文字サイズなどの調整を行ってくれるマクロを 編集部の計算機に追加してみたりと少しずつ自身を深めていきました。 まあ、皆そんなものは使わず、相変わらず以前書いた記事ファイルを開き直して「名前をつけて保存」で記事を作成していましたが。

結局、誰かが書いた記事を一発で用意した書式に直してくれるマクロを書くことになりました。これも、良い経験でした*5！

そうそう、このちょっと前くらいの時期にWORDの発行に使うリソグラフがPDFを読みこめることが発覚し、データによる入稿が基本になりました。その前？　通常のプリンタで印刷したものを マスターと呼び、それら数十枚を抱えてリソグラフに1枚1枚スキャンして……。

折衝

一太郎側の書式設定がある程度落ち着いたところで、それがそのままLaTeX側と調和を生み出す訳ではありません。 かつて編集部のLaTeXテンプレートは一太郎の書式設定を参考に作られましたが、一太郎側が譲歩をする段階に来ていたのです。 組版の設定は何を基準とするかでも変わってきます。文字数の設定から文字サイズが決まったり、逆に文字サイズから1行あたりの文字数が 設定されたり。そんな訳で、主に一太郎の書式設定をLaTeXの設定に寄せました。余白や文字数、文字サイズを明文化し部内のwikiに残しました。 双方が妥協しつつも、ここにある程度書式統一されたWORDが誕生したのです。

それから数ヶ月後

そこにはLaTeXをいじる私の姿が！！　……いやだって使い易いし。

ビルドサーバ

少し触れましたが、改善されたもののLaTeXのビルド環境を整えるのは初心者には厄介なポイントが幾つかあり、環境構築の手間もないに越したことはないのです。そうすると、 ビルドサーバの概念が誕生します。

コンテンツを作成するときフォントのライセンスは厄介で、勝手に引っこ抜いて使うというのは大概アウトです。幸か不幸か一太郎2012承にヒラギノフォントがついてきたために、 この前後のWORDはヒラギノフォントを使うことで統一されていました。大学の計算機室にもMacがあったために、ヒラギノフォントを使うことへのハードルが低い状態だったのです。

ヒラギノがある計算機をそのままビルドサーバにしてしまおうという考えが生まれるまで時間はかかりませんでした。無論大学共用の計算機ではなく編集部で用意した計算機です。

記事を書いた後 make を叩けばPDFが出てくる、そんな素朴なLaTeXテンプレートが生まれました。

LuaLaTeX

それまで編集部で使われてきたのはpLaTeXでした。TeXの統合パッケージであるTeXLiveもこの頃には大分落ち着いてきて扱い易くなってきてはいましたが、pLaTeXではフォントの設定などが多少ややこしいところがあります。職人による丁寧な指導の元、個人の計算機にLaTeX環境がインストールされていく、そんな様相を呈していました。そんな折、編集部のLua派が台頭しました。そう、LuaLaTeXの登場です。 WORDのLaTeXテンプレートの元となったarticleクラスは古代から存在しているものでしたので、モダンなLuaLaTeXでは使えませんでした。でも使いたい。LuaLaTeXテンプレート（クラスファイル）が作られる運びとなりました。もっとも、この時点ではLuaLaTeX自体が安定していない状況だったことと、ビルドシステムでのpLaTeXとの切り替えが多少手間だったことも ありあまり部内には普及しませんでした。多分2人くらいが使っていました。

俺はその先にいるからよ

大学というのは普通4年も在学していれば卒業し社会へ出ていくことになります。やめろ、そんな目で俺を見るな。 編集部の人間も移ろいいきます。LaTeX大臣の任期も現役を過ぎたらあまり強要はできません。

編集部内で組版に関わっている人間には野望がありました。そう、

「ソースレベルで結合してまとめてPDFに出したい」

という欲求です。この頃には一太郎派はかなり減り、LaTeXで「それぞれが」コンパイルしたPDFをまとめ、ページ番号を振り直し、印刷用のデータとしていました。 この部分の自動化を果たせば主に編集長がしてきた作業が減り、皆ハッピーになるはずなのです。2018年12月現在も未だ果たされてはいませんが、準備はちょこちょこ進めています。 数十年後には記事原稿もAIに書いてほしいし、排泄、睡眠、食事、種族保全もディープラーニングってやつで自動化してほしい。

その前段階として、テンプレートが複数ある状態はあまりよろしくありませんでした。 ビルドシステムでの分岐処理が複雑になること、レイアウトやその他の更新が複数回の手間になるからです。 編集部でのLaTeX作業の多くを担ってきたyyuさんが卒業するということで、テンプレートの大改修をやるならやらんとという空気もありました。 実際は卒業後に作業が活発化するのですが、まあ空気があったということで。

独自クラスファイルの更新はより切実な問題でした。専門的にクラスファイルレベルでいじれる人間がいなくなるというのは致命的です。

そんな中白羽の矢が立ったのはbxjsclassesでした。これはjsclassesでできることをpLaTeX、LuaLaTeX、XeLaTeXで共通のソースからコンパイルできるというクラスファイル群です。 このクラスファイルをロードし、WORD用の設定を加えたものを新テンプレートとするといい感じになるんじゃないだろうか。 した 。 新テンプレートではビルドシステムのpLaTeX/LuaLaTeX切り替えもmakeの引数をいじる程度で済み、更新はこのクラスファイルだけ、草木は萌え、小鳥は歌い、王国は千年の平和に包まれます。

窓に、窓に！

文章はここで途切れています。より詳細な内容やこれより後について読みたい方は「わっふるわっふる」と

*1:「フォントを買うとMacがついてくる」というジョークがありますが、プレミアム版の一太郎にも有名書体がついてきます。

*2:これ以前だとMS-Wordの盛り上がっていた時代、温かみのある手書き主流時代などに過去資料から遡れました。

*3:このテンプレートはarticleクラスを一部改変したものでした

*4:講義の課題として、何の言語でも良いから「マンデルブロ集合をかけ」というものが存在しました。

*5:学園の門の前でピースをしながら

続・明治教科書明朝購入とLuaLaTeX用セットアップ

お前のフォントはそれでいいのか

文章の本文は何で書きますか？　明朝ですかゴシックですか？　本文では明朝という方が多いのではないでしょうか。体感としては、長文ではゴシック体はここぞというときに使わないと見辛い気がします。 さて、明朝体とおおまかに言ってもその特徴は様々ですし、使い所によっても選ぶフォントは変わってきます。技術書では読み易い、誤認識しないものが重要であるとかそういう話です。

大概の文書は文字によってほとんどが構成されます。読者には、文書の内容の他にそれを受けとるインターフェースである文字も印象づけられます。厳めしい書体であれば固そうですし、 やわらかな書体であればポップとかキュートといった印象を持つでしょう。文字は言葉を伝える手段であると同時に、それ自体の持つメタ*1的な要素があります。

「馴染んでいて極力フォントの存在を意識させない」フォントによって内容で勝負というのもアリですが、思いきったフォントで書くのも同様にアリです。

ライトノベルではお馴染み「リュウミン」や、京極先生他大勢に好まれる「ヒラギノ」などで個人でも書籍が出せるのがDTPの良いところではあります。商業と同じクオリティのものを作ることが可能*2なのですから。しかし、商業出版と同じことをしたいのなら自分で組むよりもその手のノウハウのある出版社さんに協力してもらった方が総コストとしては安いかもしれません。

例えば私はオールドタイプの明朝体が好きです。何を以てオールドなのかなどの話題は不得手なので書き直すと、古めっぽい見た目の雰囲気の明朝体が好きです。大正浪漫が好きなので。 なら、小説をオールドな明朝体で組むしかないじゃない。

続・教科書明朝

しかし、普段慣れている明朝の形ではないので、当然読み辛い。旧字体で構成された文書を現代字と同じスピードで読み進められる人は、そうでない人より少ないのではと思います。 Oradano明朝の雰囲気は好きなのですが、本文でいきなり使うには正直ハードルが作者、読者双方に高すぎると感じていました。

そんな或る日、適当にインターネットを漂っていると出会いがありました。

fg-tokyo.com

話は少し逸れますが、教科書体というものがあります。印象としてはゴシックと明朝の間という感じでしょうか。高校くらいまでの教科書を思い出してもらえれば、多分その感じです。 教科書はその内容のせいで「読み辛い」と感じていた方もいるかもしれませんが、フォントとしては相当に読み易いつくりです。Win10の最近のバージョンには「UD教科書体」がバンドルされていますが、 あれもとても良いと思います。

（続・）明治教科書明朝は当然明朝体ですが、教科書に使われていたものを元にしていますから、オールドスタイル明朝としてはかなり読み易いと感じました。意識を失って、気がついたら買っていました。 旧字体も当然ありますが、雰囲気を合わせた現代字も普通に使えるので、「古いっぽい雰囲気の書体で組みたい」という私のニーズに見事合致したのですね。

JustsystemsのECサイト「JustmyShop」にて特別価格7000円弱で売っていたので、在庫がなくなる前の購入をオススメします。「明治教科書明朝」の方は複数の販路があるようですが、「続・明治教科書明朝」は ほぼJustmyShopだけになってるのはどうしてでしょうね。

Ubuntu18.04へのインストール

WindowsとMacでの方法しか載っていませんが、インストーラ形式ではなくフォントがポンとCD-ROMの中に入っているだけなので考えることはあまりないです。

nautilusなどでCD-ROMを開いて中のフォントをコピーしてフォントを置く場所に置いて((私は/usr/share/fonts/opentype/にfgpzokumeijiディレクトリを作り、その中に置きました。))

$ sudo fc-cache -fv
$ sudo luaotfload-tool --update

をかければ終了です。 後は.texファイル中で

（略）
\usepackage{luatexja-fontspec}

\setmainjfont{FGPZokuMeijiKyoukasyoM}

のようにしてビルドすれば良し。pLaTeXの場合は一緒に収録されてえいるttf版を使った方が確実かもしれません。

宣伝

技術書典5 に「い08」にサークル「Virtual Ones」として参加します。間に合えばこれで組んだ小説を持っていきたいなあ。

*1:ここではメタデータのことではないです。

*2:可能、ではあるはず……。

技術書典5配置い08です

出す本用のページは9月頭に用意できればいいかなあ。

技術書典5

techbookfest.org

配置決定

配置決定は本来15日だったんですが、延期し17日に発表されました。某アパレル会社社長もイベント規模が倍になると厄介事は二乗で増えるって言ってたし、規模前回比3倍らしいからね、仕方無いね。配置場所はい08となりました。

Virtual Ones

弊サークル名です、はい。 技術書典4では @rizaudo 君のサークルに寄させてもらってたんですが、やっぱり自分のサークルで出してみたいな、と。 音楽性の違い*1がなくもなかったんですが、特に喧嘩事とかは無いです。Dragon Universityもよろしくね！

同人誌に限らず、サークルというのは基本的に「何らかの目的を共有するグループ」であります。では、Virtual Onesの目的はというと、「コンテンツプラットフォームに関連する全て」です。そして、研究室のボスと僕の共通見解では「プラットフォーム」とは「任意」を指します*2。

上の条件に当て嵌る人材をVirtual Onesでは常に募集しています。連絡は @hid_alma1026 まで。

頒布予定本

現在、完全に個人サークルの様相を呈してきたVirtual Ones。

今回は的を「文書編集またはその周辺」に絞って臨む予定です。初参加だからタイトルなどの方針もまだ定まっていません。9月の中旬までには脱稿していないとまずいですね。Virtual Onesの明日はどっちだ。

*1:例えば、彼は「必要や関連がなければ可愛い女の子の表紙であるべきではない」という方針なんですが、僕は「特に必要が無い限りは可愛い子が表紙であるべきだ」という方針なんですねー

*2:まあ、ボスは訊くタイミングによってこれと異なる見解を述べることもありますが

分散SNSポエム

この記事は WORDIAN Advent Calendar 2017 - Adventar の20日目の記事になります。 今日もポエムです。この書き方だといつもはポエムじゃないみたいだ。

前書き

Twitterの自動凍結やUserStreams廃止などでまた揺れてますね。絵師のMastodon（Powoo）移行なんかもよく聞く話になってきました。僕も息子の要請によりPowoo垢を作ってみたりしました。そのコミュニティの感覚がまだ上手く掴めていないのでメイン所在地の移動というのはまだ無さそうですが。

所属している研究室では「分散SNS」の研究もあります。もっと早くこっちに変えておけばと思わなくもないです。

中央サーバ型のSNSの利点は運用ポリシーの管理が比較的容易であることが挙げられるかと思います。アカウントのBANとか。

連邦型のSNSはインスタンス毎にポリシー、追加機能が分かれているので合うものを自分で選べる、気に入らなければ自分で立てられるといった感じでふわっと理解しています。

この何れもが、弱点として「ユーザーが増えると運営が大変」というのを持っています。あと、連邦型では分散されているとはいえ、「運営がいなくなる」可能性もありますね。「運営が信用できない」なども中にはありますが。

分散SNSは主にPeer-to-Peerネットワークを利用したSNSのことです。後でもまた書きますが、これに関して一番難しいのは「P2P」に関する偏見かなとは思います。WebRTCだと皆飛びつくのにな。

今回はTwitter-Alternativeのこととか。各技術についてふわっとしてしか理解していない*1ので、ツッコミ待ちなところはあります。

既存プロジェクトなど

github.com

BitTorrentのイメージってファイル共有（特に、文脈が違法ファイル共有）で認識している人が多くて、 Bleepとかはそこで損している部分もありそうですよね。

プラットフォーム系は巨大すぎて全く把握できていない......。

Tomo’s HotLine: P2P

結構以前からP2PによるSNSについて書かれています。

ランデブーポイント

ほとんどのプロトコルやプロジェクトで、「最初に繋がるための情報を得る特定の場所」というものが存在しています。DHT（分散ハッシュテーブル）とかを使っていても最初にアクセスする場所は決まっていたりして、種別は違えども似たようなものが必要であったりします。

Gossip-Protocol

nullkal君に「Scuttlebutt」を教えてもらいました。

staltz.com

現状のSNSについての欠点などの紹介から、開発したアプリケーションの紹介まで↑のリンクで載っています。

限界脳状態だったのでプロトコルなどはちゃんと読めていないのですが、ランデブーポイントの問題も解決できているはず？

ぼくのかんがえたさいきょうの

まあ、子供の考える最強の設定ってオリジナリティに溢れていることって実は少ないですよね。

要求機能

Twitterがチャットシステムでは無く、マイクロブログであることが大切だと僕は思っていて、望む情報は手に入る必要があるが、望まない情報が絶対に目に入らないというのは閉塞感に繋がって良くないんじゃないかな、と。 勿論ゾーニングの必要性はありますが、完全にドメイン特化した情報しか手に入らないならクローズドなチャットシステムであってマイクロブログでは無い気がする。

アカウント

公開状態と鍵垢状態は必要そうだなと。 アイコン（プロフィール画像）は要りそうだけれど、背景画像まで用意すると割とコストになりそう。 プロフィール文章は必要として、所属組織とかのフィールドを設けると硬くなってしまうのではという不安があります。

本文投稿

まあ基本機能ですよね。字数制限はシステムの軽量さのためにもある程度必要な気がします。長文投稿用には自レスで運用する今のTwitteシステムで皆馴染んでいそうですし。あまり長い文はやはりパッと読むには向かないというのもあります。

返信

マイクロブログとしてはむしろ「コメント」と定義するべき部分かもしれませんが。

リブログ（RT）、引用（QT）

連投や流れを無視した「切り取り」に思うところが無い訳ではありませんが、機能としては必要、といったところ。

公開でない投稿を引っぱる際の仕組みには気をつけないといけないかも。

DM

直接応答。Slackみたいに複数人対象をサポートしてもいいのかも。

削除

設計からすると難しい気がしますが、「消した」という意思表明ができればいいかなという感じ。

タグ（ハッシュタグ）

或いは「カテゴリー」。 本文フィールドとは別にくっつけた方が処理としては楽そうだなと思うんですけど。 ゾーニングの手段として、例えば「R-18」タグを予約語として用意して、見るには鍵が（アカウントとは別に）要るようにすれば良いんじゃないかと考えたり。他に予約語の候補としては「spoiler（ネタバレ）」を「Anime」タグと組み合わせたときに許可しないと見られなくするとかがあります。

フォロー、ブロック

あんまりアイデアが無いです。

リスト

フォロワーリスト、ユーザ作成リストなど。

URL

短縮URLも実装して、本文領域で済ますのも良いけれど、フィールドを分けたい気持ちもある。 移動先のサムネイルがあると嬉しいけれど、オプショナルな話になりそうです。

メディア

URLと埋め込みの2つの手段があるけれど、どっちもよしなにしたいですね。中央のサーバで捌かない以上、P2Pネットワークに載せたメディアというのは扱いが難しいところです。

Reaction

Twitterでは「ふぁぼ」もとい「いいね」一択ですが、SlackみたいにEmojiリアクションぐらいのバリエーションがあると嬉しいですね。「Unlike」が付く可能性も勿論ありますが。 LINEのように「スタンプ」までいくと難しそうです。

検索

タグ検索、ユーザー検索、本文検索などをね。

アーカイブ取得

分散システムだからこそ必要な機能だと考えています。

後書き

ポエムでした。 特に書くことは無いです。

*1:つまり、理解していない。

最近ergのこと書いてなかったなあって

この記事は

WORDIAN Advent Calendar 2017 - Adventar の19日目の記事です。

今日はポエムでお送りします。

前置き

美少女ゲームが好きです。 進路決めたときも理由の半分くらいに美少女ゲームのことが頭にあったと思います。情報系は美少女ゲームのプラットフォームであるPCを扱う職業だからです。

「性的搾取」とか「表現の自由」とか昨今は（以前からですが）ありますね。

ところで僕、「装甲悪鬼村正」が好きでですね。どのルートも好きなんですが、英雄篇は最初にやったこともあって特に印象的です。

正義を為すことは罪悪である これは避けられぬ理。 潔白にて正義を達する道は無い 邪悪の討滅は、正義がその正義を捨て去ることによってのみ成される 善悪相殺 善と悪は刺し違えて、共に滅ぶもの

まあ、引用してみただけです。ここだけ、今、取り出すとどう解釈されるのか。言葉の応酬というものは所詮ゲームですから、コンテキスト無く語ることはナンセンスで、また元のコンテキストから離れてその言葉を用いるのもまたアレです。

自分のコンテキストすら把握するのは困難であるのに、況んや他者の、他国の、他文化の、他世界のコンテキストをや。碇ゲンドウ君も人と人は分かり合えないと言っていた気もします。

それでも世界は自分だけではないのですから、相互理解の努力を欠かす訳にはいかないのです。

嘘を吐きました。世界はあなた一人、僕一人ではありませんが、世界は自分だけです。自分以外をどう世界に取り込むかは恐らく自由ですが、世界はどこまでも自分の色に染まっています。この辺りの取り扱いを間違えると、悲惨ですね。「相互理解」という名の押し付け合いには気を付けましょう。

本題

最近はようやくというべきか、Android対応のえっちげーなどが出始めました。コンシューマー版タイトルも含めて。 AUGUSTの「千の刃濤、桃花染の皇姫」や、OVERDRIVEの「キラ☆キラ」「DEARDROPS」などが出ていることを考えると、BURIKOエンジンがコンバートしやすい環境があるんでしょうか。いや、各社の根性な気もします。 吉里吉里Android版の開発の話*1もありましたし、「PCでプレイするゲーム」というハードルを取り払う話みたいなのはありますね。

非Windowsという話では、ブラウザを利用した、ティラノスクリプトやアルマイトJSといった手段も出ていますが、爆発的に流行ったりは今のところしていないので、制約がどこかにあるのでしょう。ちゃんと調べなきゃいけないかもですね。でも、ブラウザ環境（もしくは疑似ブラウザ環境）で動くという方向性は希望が結構あるんじゃないかと思います。

Ren'pyは僕のウォッチしてた頃はPython2環境が必要みたいな状況でした。

で

現行のゲームってエンジンとUIとスクリプトが不可分で配布（販売）されている感じがありますよね。中身が1つにパッキングされているという訳ではなく、販売形態として。 WindowsPCが今まではスーファミとかPS本体みたいな扱いだったわけですが、ロスが大きいのではという素人考えがあります。JVMとかみたいに1つレイヤを敷いて、その上で動くようにしたいのです。DirectX9.0cがそれという説もありますが、もっとプラットフォームを拡大した際の話として。

その際にUnityやブラウザ環境というのが現行では良さそうという感じがあります。各種スクリプトエンジン毎の特徴や書き易さもありますから、例えば「ERGフリーク」のような状態のものがあれば最高やという気持ちです。 各社そうなろうと努力しているんだろうなとぼんやり思う訳ですが。

ブラウザ環境で単純に動くというだけだと、ラノゲツクールとかになってしまいそうですが*2、提供したいのは「基盤」なんですよね。JS以外の何らかの改造を加えた「ブラウザ環境を基にした何か」。

「ERGフリーク」、他にも利点は多分あって。「DMMブックス」というアプリがあります。DMM（R）.comの電子書籍を読むのに使えます。これはGooglePlayで配布ができるんですね。で、R18のコンテンツもDMMのアカウントと紐付いたこのアプリで読めるんですよ。AppleStoreやGooglePlayといった、えっちげーとポリシーの相性が悪い場所でもこれは配布できる。中身に興味を持ってもらうための最初の一歩として、これは大きいのではないかと思います。一般ゲーにも利用できるでしょうし、これを規制するのであれば「包丁は殺人に使えるから禁止」みたいな論法がまかり通るような状態なので世界は末期です。「生殖器はレイプに使えるので禁止」とかいう世界観、1本いずれ書いてみたいですね。

後書き

↑の、できるなら自分で作ってみたいし、誰が作ってもそれはそれでOKという気持ちなので、忘れずにいたいですね。

以上、ポエムでした。

*1:非公式コンバートのkirikiroidなどもありました。

*2:JS+IDEらしい。でも規約でエロゲダメらしいですね。

SmartPhoneにToughnessを求める

この記事は

WORDIAN Advent Calendar 2017 - Adventar の16日目の記事です。

はじめに

人は、自分に無いものを他に求めるのだそうです。ならば、儚い僕達が圧倒的なToughnessを求めるのは、何も不思議ではない訳です。

僕のスマートフォンデビューは京セラのTORQUE SKT01です。周りがスマートフォンだらけになっても僕がヒューチャーフォンから変更していなかったのはそう、頑丈さが足りなかったからです。ですからTORQUEがSIMフリーで登場したときは迷わず注文しました。頑丈さを除いたスペックは当時としても他のスマートフォンと比べ劣り気味でしたが、頑丈さはそれを補って余りある魅力を放っていました。

今回ついにスマートフォンを買い換えたので、軽く書きます。

CAT S60

Caterpillar CAT S60 32GB Dual-SIM Factory Unlocked Thermal Imaging Rugged Smartphone - International Version SIMフリー (Black) [並行輸入品]

2017/12/18追記：僕は↑ではなくオンキョーストアにて購入しています。

「Rugged Phone」というのがジャンル的には良いようですが、頑丈なスマートフォンには実はそこそこの市場があります。ボクダケジャナインダ。

頑丈さは当然として、サーモカメラを搭載し、水深のあるところ用に音量の段階を上げる機能も付いています。

手に入った嬉しさから、地面に叩きつけてしまう pic.twitter.com/oiimbwxqYI

— SillySpeaker (@hid_alma1026) 2017年12月15日

喜びの声です。買ったばかりでうっかり地面に叩き落としても、画面が割れたりしない*1！

Toughnessのメリット

壊れない。これに尽きる気もしますが。

携帯電話というのは、精密機器でありながらラフな取り回しが求められます。うっかりインシデントは防げないなら、起こっても問題無いものを選ぶというのは当然の帰結ですね。 また、大概この手のは防水なので雨の日や風呂の中でもあまり気にせず使えます。

副次的な要素として、あまり周りに使用する人間のいない形状、機種は知人が多く利用するスペースなどで混同を避けられます。

長く使うものには愛着も湧くというもの。頑丈は信頼へ。

機体にかかる代金は初期費用こそ割高に感じますが、数年使用し、物理的故障も可能性が低いことを鑑みれば大したデメリットにはならないのです。

弊害

長持ちするということは使用期間が長くなるということで。頑丈なスマートフォンは特にソフトウェア面で遅れがちです。堅牢さが確保されている状態からアップデートもあまりかからないので。TORQUEも最後の方はアプリがOSバージョン的に非対応はザラでしたね。

形状が特殊になりがちで、汎用のケースがあまり使えないという点もあります。

余談

今までがAndroid4.2だったので色々できないことが多かったんですが、一気に6ですよ6。いや今や最新は8ですが。

レスポンスはまあ機体由来の性能だとして、UIが明るい感じになったのが大きいですね。あとフォントがNotoSansに。不満はそんなに無いですが、幾つかから選べるようになるとエンドユーザとしては嬉しいですね。

6に上がったので、Pionner製のDAP操作アプリ「Remote Duo App」が動くようになりました。電車なんかでスマートフォンいじりながら作業していると嬉しい機能です。

あと、実家に導入したGoogle Home mini用のアプリも入れました。ChromeCastも持っていないので、当面はBluetoothスピーカーになりそうです。

おわりに

https://adventar.org/calendars/2573

明日の担当は未定です......。

*1:限度はあります

tomboが無ければ作ればいいじゃない

この記事は

WORDIAN Advent Calendar 2017 - Adventar

の14日目の記事です。

トンボ

pLaTeXのパッケージの標準のやつにはtombo、 tombowオプションがついているものがあります。 これは何をしてくれるかというと、印刷所などで入稿する際に必要になったりする「断ち切り線」を追加してくれるんねすね。

さてこのオプション、僕の大好きなbxjsclassesにはついていません。処理系依存の機能を使っているから一部できない処理系があるからだそうで。

でも入稿時に困りますよね。僕の周りでもこのトンボとフォント群のためにAdobe社に頭を垂れた人間を最近見ました。

tombobase.cls

ところで、LaTeXってpdfを埋め込めるんですよ。勿論元のpdfの情報は壊れたり壊れなかったりする訳ですが、まあ表示上は問題無い。つまり、

「一度完成したpdfを取りこんでトンボを加えたＬａＴｅＸを再度コンパイルする」

ということができるのではないか、と考えた訳です。

で、基本文書クラスのtombo, tombowに関する部分だけひっぱってくればいいかなと思ったんですけど、いざやってみたら「normalfontの設定がありません」など、tomboにはあまり関係が無い（日時を出力する程度）ところで詰まる。全体をひっぱるなら別にクラスファイルを作る必要は無い訳で。......うん？

結果

A4の文書の場合、

\documentclass[tombo,a4paper]{ltjsarticle}
\usepackage{bxpapersize}
\usepackage{pdfpages}
\begin{document}
\includepdf[pages=-, offset= 1in -1in ]{main}
\end{document}

tomboの実装があるltjsclassesを呼んで、pdfpagesパッケージを利用、保険としてbxpapersizeを入れれば完成です（main.pdfはA4とします）。 最初は取りこんだ文書が左寄りになってしまいましたが、左の余白を見ると元のpdfの余白と同じ程度。そこでltjsclassesの中身を見ると、tomboは各端+1inchの所になっていたので、offsetオプションで調整しました。

これで対処できなくなるのはA6とかB6サイズを使い始めたときかと思います。 ありがとうpdfpages。

問題点

写真とか絵などはみ出すやつをこの方法だと作れないんですね。

参考

• TeXでDTP ― 断ち切りの写真を入れる

• http://mirror.hmc.edu/ctan/macros/luatex/generic/luatexja/src/patches/lltjcore.sty

• https://texwiki.texjp.org/?BXjscls

Next day

明日はwakarin111君です。