qasefuzikoのブログ

文章の練習

asciidocで表紙をカスタマイズする

背景

WordやExcel方眼紙(笑)に代わるドキュメントツールとしてAsciidocを試している。Wordで書いていたフォーマットをなるべく踏襲できないかと試行錯誤していたが、PDF変換においてスタイルファイルだけでは表紙のカスタマイズに限度があることがわかった。デフォルトではタイトル、著者名、Revisionなど基本的な要素は触ることができるが、承認欄や付帯事項、Copyrightなど独自の要素を追加することができなかった。

調べてみると表紙は別途WordなりPowerPointなりで作成して後から合成する方法が多くを占めるが、記載する内容はadocで完結したいなぁと。

waku-take-a.github.io

もっと調べてみたら同じことを考えている人はやはりいらっしゃって、pdfのコンバータを拡張することで、かなり自由にカスタマイズできるとのこと。

omnirev.net

上記の記事内でもリンクがあるが、公式のリファレンスにも拡張する方法が記載されていた。

docs.asciidoctor.org

方法

カスタマイズの作り方

公式リファレンスにも同じことが書いてあるけど、適当なrbファイルを作成して、以下の雛形を作成する。

docs.asciidoctor.org

class ExtendedPDFConverter < (Asciidoctor::Converter.for 'pdf')
  register_for 'pdf'
  # ここに色々書いていく
end

adocファイル内に定義した要素:doctitle:は、

title = doc.doctitle

のように参照することができる。 また、独自の要素も参照することができ、例えば製品名としてproduct-nameという要素をadoc内に作った場合、

productName = doc.attr 'product-name'

とすれば、表紙に独自の要素を使用することができる。

表紙に描画する場合、ink_proseメソッドとtextメソッドのいずれかを使用する。ソースを追いかけきれていないけど、前者はasciidocの記法を解釈でき、後者は汎用的に使えるものらしい。公式ドキュメントではink_proseで記載している。

text title, align: :center
ink_prose ProductName , align: :center, margin: 0

表示位置の調整は、相対位置はmove_cursor_tomove_downが使える。位置指定にpage_heightを使用すれば、ページの絶対位置を指定することができる。

move_cursor_to page_height * 0.8
move_down 50

pdfへの変換

作成したrbファイルをasciidoctor-pdfで使用する場合は、コマンドライン-rオプションでrbファイルのパスを指定する。

asciidoctor-pdf ^
    -r ./Style/ext-pdf-convert2.rb ^
    -r ./Style/config.rb ^
    -a scripts=cjk ^
    CustomTitlepage.adoc -o output.pdf

adocファイル

// 表紙
:doctitle: 表紙タイトル
:subtitle: サブタイトル
:author: ◯◯◯◯株式会社▲▲▲▲部
:revnumber: 1
:revdate: 2025/10/12
:product-name: 〇〇システム

:pdf-themesdir: ./Style
:pdf-theme: StyleforPDF.yml
:pdf-fontsdir: ./Font;c:/Windows/Fonts;/usr/share/fonts/custom;GEM_FONTS_DIR
:doctype: book
:encoding: utf-8
:lang: ja

= {doctitle}

Rubyファイル

class PDFConverterCustomTitlePage < (Asciidoctor::Converter.for 'pdf')
    register_for 'pdf'
    def ink_title_page(doc)
        title = doc.doctitle
        subtitle = doc.attr 'subtitle'
        productName = doc.attr 'product-name'
        revdate = doc.attr 'revdate'
        author = doc.author

        move_cursor_to page_height * 0.8
        text title, align: :center, size: 40, leading: 8
        text subtitle, align: :center, size: 32, leading: 8
        ink_prose productName, align: :center,size: 32, margin: 0

        move_cursor_to page_height * 0.4

        ink_prose revdate, align: :center, size: 20, leading: 8
        ink_prose author, align: :center, size: 20, leading: 8 

        move_cursor_to page_height * 0.2
        approval_data = [["承認", "起草"], ["", ""]]
        table(approval_data, width: 100, column_widths: [50] * 3, position: :center) do
            cells.style do |c|
            c.inline_format = true
            c.align = :center
            c.borders = [:top, :bottom, :left, :right] # セルのすべてに罫線を引く
            c.border_width = 1
            end
            row(1).height = 50 # 2行目の高さを高めに設定
        end

    end
end

結果

はてなブログに移行

FC2からはてなブログに移行した.

 

前々から思っていたが,FC2の新エディタが死ぬほど使いづらかった.意図しない装飾を修正しようとhtmlエディタを開くのだが,まあ見づらい.というかタグがめちゃくちゃ書き込まれていて,どこをどう編集すればいいか分かりづらい.そういうこともあって移行した.

WSL+LaTeX+VScodeにおけるsynctexの利用

 Windows10から搭載されたLinuxをネイティブ実行できるWindows Subsystem for Linux(WSL)だが,専ら開発用途ではなくLaTeX用途として利用している.もともとWindows用のLaTeXを利用していたのだが,Mac版やLinux版と比べて処理速度が遅いと常々感じていた.実際,Windows上の仮想デスクトップで動かしているUbuntuLaTeXは,Windowsのそれよりもかなり高速で処理できている.マシンの性能云々よりソフトウェアの問題なのではないかと思っている小さい文字.とにかくこの処理速度の遅さはストレスを増大させるので,WSLのLaTeXを使って文書作成をしている.

 ところで,synctexはtexファイルとpdfファイルのファイルパスを認識してソースとpdfの位置を動悸できる.WSLで処理した場合,Linux用のファイルパスが書き込まれるため,Windowsのエディタでsynctexを行おうとすると,Windowsはファイルパスを認識できず,synctexを使うことができないのだ.この問題を指摘している記事は結構少ない印象である(加えてこんな問題があるのにvscodeのレシピにsynctexの項目があったりと適当である).

 このことを自分が参考にしていたqiitaの記事にコメントしたら,どうやらRemoteWSL
というものを利用するとsynctexが使えるとのこと.RemoteWSLについて日本語で書かれた記事が見つけられなかったので自分なりの解釈なのだが,exeとしてVScodeを起動するものの,ファイルの読み込み,処理はすべてLinuxとして取り扱うものらしい.イメージ的にはX Windowみたいなものだろうか(処理とかぜんぜん違うけど).リンク先より開発版VScodeを入れてRemoteWSLの拡張機能をインストールして,あとはLaTeXの設定をするだけ.VScodeは開発版と通常版はそれぞれ独立しているので,今までの環境とはまた別にVScodeを使うことができる.

リンク先より開発版VScodeを入れてRemoteWSLの拡張機能をインストールして,あとはLaTeXの設定をするだけ.VScodeは開発版と通常版はそれぞれ独立しているので,今までの環境とはまた別にVScodeを使うことができる.

 使ってみた感想だが,Windows版と同じようにsynctexがスムーズに使えた.ただ,新たに環境構築(キーボードショートカットや拡張機能)する手間があるのと,ファイルを開く際,Explorerを用いないの(VScodeの簡易ファイラを用いるの)で,ファイルを扱う点では扱いづらい印象である.ただ,WSLでsynctexを使えるようになったので,とりあえず問題は解決したかな.


最初からLinux使えよとは自分でも思っているのだが,やっぱOfficeの利用機会は減らないし,互換Officeは所詮互換なので再現性は高くないから使いたくないしでなかなかOSの一本化はできない.

onenoteを大学で1年間使ってみて

 Surface pro3とSurface penを手に入れたので,今まで手で書いてきたノートを電子ノートに置き換えてみようと思った.同じMicrosoft製で親和性が高いんだろうと思ったのと,ちょうど大学の包括ライセンスでoffice365が使えたので,onenoteを使うことにした.そんで1年間の講義,研究ノートなどなどを出来だけonenote上で済ませた.1年間使ってきて思ったことを色々書く.

キーボードか手書きか

 これについてはonenote以外でも当てはまると思うけど,講義や打ち合わせの時など,何かを聞きながらメモを取るならば圧倒的にペンのほうがいいと思った.タイプ速度が遅いというのもあるが,キーボード入力では,聞き漏らしが多くなってしまう.例えば講義中の重要な単語をハイライトさせたいとき,マウスやショートカットキーなど余計な操作が必要となってしまって煩わしい.手書きであれば適当に単語を書いておいて,丸やら下線を引いておけば,後で見直しすときもすぐにポイントを抑えられる.なのでほとんどはSurface Penで書いてた.

 もちろんキーボード入力のときのほうが良い場合もある.授業後など十分に時間が取れるときに,ノートの内容をまとめるときは,当然キーボードの方が速いし,手書きよりは見栄えがきれいになる.

デスクトップ版とUWP版の違い

 onenoteにはOffice付属版(以後デスクトップ版)とWindowsにプリインストールされているもの(UWP版)の2種類がある.両者の決定的な違いは,機能の多さである.
 
デスクトップ版は歴史が長いため,多くの機能を有している.例えば用紙サイズの変更や印刷設定など,細かい設定面ではデスクトップ版のほうが豊富である.しかしタッチ操作するには使いにくい点がある.またパソコンの性能にもよると思うが,UWP版に比べて動作がやや重い.

一方でUWP版はタッチ操作用に最適化されているので,指での操作がしやすい.また気持ちデスクトップ版よりも動作が軽い(気がする).機能面は基本的なものは搭載されているものの,用紙サイズの変更はできないし,印刷機能も非常に限定的である.

そもそもonenote自体,機能が豊富ではない.例えば画像のトリミングをonenoteで行うことができない.デスクトップ版であればアドオンを導入することで解決できるが,UWP版はアドオンを導入できない.

Microsoftが言うには,ゆくゆくはUWP版に統合するとのこと.実際UWP版でも使える機能はだんだんと増えていっている.ただ,開発ペースはかなり遅い印象なので,当面は併用するつもり.

講義での利用

講義資料は基本的にPDFかPowerPointファイルが配布される.なので,それらのファイルをonenoteにインポートすれば,PDFのページをonenote上に表示させることができる.そのうえペンを使えば書き込みができる.電子ノートのアドバンテージを発揮できたと思ったのが,演習プリントの書き込みである.演習プリントに直接書き込みできるため,わざわざ印刷せずとも手書きで問題を解くことができる.Surface Penであれば書き損じた文字もすぐに消すことができるので,多少はきれいに残せる



いろいろ引っかかったこともあった.
 1つ目に,ページの印刷である.講義によっては試験中に講義資料の持ち込みが認められる場合がある.いざonenoteのページを印刷しようと思うと,なかなかうまくいかない.デフォルトでは用紙サイズは「自動」となっているので,用紙いっぱいに書いてしまうと,印刷時に見切れてしまうか,無理やり縮小されて文字が見えなくなることがある.特にPDFやPowerPointをインポートしたページを印刷すると,PDFの内容が見切れてしまうことがある.
 
これを回避するには,用紙サイズを予め設定しておくことである.デスクトップ版であれば「表示」タブの「用紙サイズ」から任意のサイズに変更することができる.印刷を想定するならばとりあえずA4にしておくと良いかもしれない.

ファイルをインポートする際に,1ページに纏めて貼り付けるか,(PDFファイルの)ページ毎に新ページを作成する,の2種類の方法がある.ページ数が多いファイルならば,個人的に後者の設定方法を推奨する.ページ数が多いファイルを1ページにまとめると,印刷問題に加えて,ページが長い故に閲覧しにくいためだ.

万が一ページサイズをデフォルトのまま書いてしまった場合,デスクトップ版で印刷設定を弄ることである程度きれいに仕上がる.ただしUWP版では細かい設定ができない.もともと,onenote(というか電子ノート)自体,印刷を想定していないと思われる.現実問題,紙を一切使わないってことはできないので,印刷を想定するならば注意したほうが良い.

 2つ目に,ファイルをインポートしたときに,ページの内容がいつまで経っても表示されない時があることだ.これはデスクトップ版を使っていたときに頻発した問題である.添付したファイルが比較的重かったり,ページ数が40ページと多いときにこの症状が起こる.再起動しても治らないことが多く,キャッシュを消すことである程度マシになる.だけどマシになるだけで,再発してしまう.UWP版であれば比較的発生しない.
 苦労したのが印刷するときである.PC上ではしっかり表示できているのに,印刷結果を見ると何故か表示されてないときがある.こういうときは,一度PDFにエクスポートして,そのPDFを印刷すると,幾分マシになる.あくまでマシになるだけで,PDFエクスポートの場合でも画像が表示されないことはある.非常に厄介.

chromeIPassの代替拡張機能の「ChromeKeepass」

パスワード管理にkeepassを使っており,それとchromeを連携させるために,「chromeIPass」を使っていた.しかし,公開を停止してしまったのか,chrome webストアから消えてしまい,それと同時にchromeからも削除されてしまった.いくつかの代替機能を探していったところ,chromeIPassとほとんど機能が同じの「ChromeKeepass」という拡張機能を見つけた.


なお,keepassのプラグインとしてkeepasshttpが必須である.
これでchromeIPassと同様に,自動的にフォームを埋めてくれるようになった.

zaimの金融機関連携機能を使ってみた

バイトを始めてからzaimを使って家計簿をつけている.レシート読み取り機能や簡単なグラフ描画機能など,まあまあ便利な機能がついている.
自分はズボラな性格が故に,家計簿の入力を滞る時がある.なのでかなり溜まったときに一気に処理するのだが,何故か金額が合わない.考えられる原因として,自販機や電車バスなどレシートがその場で発行されないもの,電子マネーにチャージしたときの入力を忘れているなどなど・・・.その度に各種電子マネーの利用履歴を出力して手作業で確認している.それでも合わないときは使途不明金で処理.まあ面倒だし正確に入力できなければ家計簿の意味はない.というわけで入出金を自動で記録してくれる「金融機関連携」を使ってみた.

金融機関連携機能は,銀行をはじめクレジットカード,電子マネー,ポイントサービスなどの入出金記録を自動で行ってくれるものである.これなら金額が狂うことがないだろうと思っていたが,調べてみるとちょっと雲行きが怪しい.例えば,zaimは別に金融機関などと公式に連携をとっているわけではないらしい.そもそも殆どの金融機関で残高を返してくれるapiなどは準備されていない.zaim側にはネットバンキングのログイン情報を入力しろって書いてあるから,zaimが定期的にログインして明細ページをスクレイピングしてるのではないかと予想してる.一応,zaimに保管される情報は暗号化されているらしいけど,それでも銀行のログイン情報を第三者に渡すのはリスクが高いかな.

そういうわけで,万が一情報が漏れても問題ないような銀行口座,電子マネー(モバイルsuica,edy,nanaco,waon)を対象に連携機能を使ってみた.使ってみた感じ↓

  • 金額が変動する取引においては有用である
携帯代や海外のパトロンサイトは月によって金額が変動するので,「繰り返し入力機能」ではzaimと実際の預金残高とで誤差が生じてしまう.連携機能であれば明細ページをそのまま持ってくる(はず)なので,金額の変動に対応できる.

  • 入出金の反映が遅い
金額が変動したら即反映されるのではなく,一日ぐらい経たないと自動的に反映されない.これはzaim側の仕様で,金融機関へのログインは日に一回程度しか行っていないためである.また,金融機関もすぐに反映しないこともあるので即時反映は厳しい.

  • 支出項目は手動で入力する必要がある.
連携機能による記録をみると,項目名が「シュッキン ○○ △円」という感じになっていた.銀行のweb明細と同じ内容だったので,やっぱりスクレイピングしてるんじゃないかなと思う.しかしモバイルSuicaの場合,電車に乗ると電車賃としてzaimに記録されるものの,飲食物品購入の場合は「物販」となってしまう.詳細に記録したい場合は自分で手打ちするしかない.

以上のことから,電子マネー系は連携を解除し,銀行口座はそのまま継続することにした.特に電子マネーは頻繁に使用するので,「反映が遅い」,「項目の手動修正が必要」という問題は無視できない.というかそれなら今までどおり手動で入力したほうがまだ正確である.
今後,各金融期間が入出金記録を出力してくれるapiを提供してくれたり,電子レシートがもっと浸透すれば,家計簿入力も格段に楽になるんじゃないかな.

MusicBee移行作戦 その後

iPodからAndroidスマホに移行してからも楽曲の管理はiTunesで行い,転送する際にMusicBeeへライブラリ情報をコピーしてから転送を行っていた.流石に面倒になってきたので管理ソフトを一本化すべくMusicBeeの移行を行ったのが先月ぐらい.今回はその結果を書く.

・移行方法
MusicBee側でライブラリを新規作成して,MusicフォルダにiTunesのMusicフォルダの内容をそのままコピーした.MusicBeeにiTunesのライブラリをインポートできる機能は付いているが,どんな挙動を起こすかいまいちわからなかったことと,最新のバックアップを取っていなかったのでやり直しが効かないと厄介だと思ったから.結果的に全曲コピーできたようだ.

・タグの問題
移行作戦で最も不安だったのがタグ情報の消失だった.特に「よみがな」である.MusicBeeデフォルトの設定では表示されなかったが,カスタムタグを設定することで表示させることができる.
移行してみたところ,何故か認識されなかった.しかし一度プロパティを開くことで読み仮名を認識させることができた.これ以外で認識させる方法が見つからなかったので,プロパティの「→」を連打することで全曲認識させた.非常にアホらしい方法と思う.その他のタグ情報はほぼiTunesのものを引き継げた.

目立った問題はよみがなの認識方法ぐらいで,他は殆ど問題なかった.