本を読む

読書やコンピュータなどに関するメモ

cpdfがpdftk代替として高機能だけど自分の用途には使えなかった

 PDFから一部のページを抜き出したり、反対に複数のPDFを1本にまとめたりするのに、コマンドラインツールのpdftkを便利に使っています。

 ただ、pdftkがGCJ(GNU Compiler for Java)で作られていて、そのGCJがメンテナンス終了になっていたりという状況です。最近のCentOSやmacOSでは、動かなかったり、動かすのに苦労したりするようです。

 調べてみると、cpdf(Coherent PDF)というツールがpdftkのようなことができて、高機能なようです。そこで、試してみました。

 先に結論をいうと、タイトルのとおりです。

ライセンス

 「自分の用途には使えなかった」理由は、ライセンスです。cpdfは、無料で使えてソースも公開されていますが、フリーソフトウェアではありません。アカデミック目的での利用や、個人でのお試しはOKですが、仕事目的で使うのはNGとされています

 機能はよかったんですけどね。

インストール

 cpdf-binariesリポジトリに、Linux用(64bit、32bit)、macOS用、Windows用のバイナリが用意されています。ダウンロードして実行権を付け、実行パス中のディレクトリに置くだけです。

 依存ライブラリは少ないようですね。

$ ldd ~/bin/cpdf
        linux-vdso.so.1 =>  (0x00007ffe523db000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3f83be9000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3f839e5000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3f8361b000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3f83ef2000)

 そのほか、OCamlのopamでビルドしてインストールする方法もあるようです。

使い方

 PDFファイルの結合はこんな感じ。

$ cpdf a.pdf b.pdf -o out.pdf

 一部のページを抜き出すにはこんな感じ。

$ cpdf a.pdf 1-5,8 -o out.pdf

 ページ指定にendとかoddとかevenとかallとか使えるのはpdftkっぽいですね。

 ページの回転も指定できます。

$ cpdf a.pdf -rotateby 90 -o out.pdf

 PDFファイルの情報を表示する機能もあります。

$ cpdf -info a.pdf

 使われているフォントも調べられます。

$ cpdf -list-fonts a.pdf

 そのほかにも、ページサイズ操作とか暗号化とか、さまざまな機能があるようです。

日経xTECHのRSSを生成するスクリプトを作った

 IT系ニュースサイト「日経ITpro」が「日経xTECH」にリニューアルされました。それにともない、RSSフィードが廃止されたようで、どこにも見当りません。これでは自分には不便すぎるので、指定した記事一覧ページから勝手にRSS(Atom)を生成するスクリプトを作りました。

 nokogiriとRSS::Makerをつないでいるだけの、30行ぐらいのRubyスクリプトです。

 たとえば、ITカテゴリーのニュースのRSSを生成するには以下のように実行します。

$ ruby xtech2rss.rb http://tech.nikkeibp.co.jp/news/index_it.html > xtech_itnews.xml

追記2018.2.25:その後、日経xTECHで公式にRSSフィードを公開したようです。

Pocketの連続再生が便利

 以前書いたように、私はAndroid端末のPocketアプリで音声読み上げ(TTS)を愛用しています。

 ちょっと前になりますが、2017年10月のアップデートで、Pocketの音声読み上げのインターフェイスが一新されました。再生中はモーダルダイアログが表示されるものから、画面下にバーが表示されるものになり、記事表示と独立して再生されます。再生スピードや声の高さなども以前より柔軟になったようです。

 一番便利なのは、連続再生の機能が付いたことです。記事一覧の画面でツールバーのヘッドフォンのアイコンをタップすると、上の記事から順に連続で読み上げてくれます。また、記事を開いた状態で音声読み上げを呼び出すと、そこから下の記事を順に読み上げてくれます。私はたとえば台所で料理や皿洗いをしながら記事を聞くので、濡れた手で操作しなくてすむのが想像以上に便利でした。

 ただ、使っている限りでは、常に全記事での順序となるようです。私の場合、音声読み上げ向けの記事に「tts」タグを付けているので、タグの記事一覧を順に読み上げてくれる機能があればもっと便利なのにと思います。

PocketのTTSの連続再生

Ubuntu 17.10リリース記念オフラインミーティングで発表した

 「Ubuntu 17.10リリース記念&Ubuntu Weekly Recipe 500回記念オフラインミーティング17.12」に参加して、5分程度の発表をしてきました。

ibus-skkをなんとかすっぺ会議 from emasaka

 「パッチを書いても送り先がないんですよね」というだけの話です、はい。

濁点問題

 こんにちは。これは編集者アドベントカレンダーの12月4日の記事です。

 この記事では、濁点問題という極めてちっちゃい話題を取り扱います。なにせ1文字の片隅ですし。

 編集者の一般的な仕事についてのちゃんとした話題は、ほかの方々の記事にご期待ください。私も期待しています。

百聞は一見にしかず

 濁点問題を理解するために、まずはMicrosoft Wordの画面キャプチャーをご覧ください。

濁点問題サンプル

 赤丸で囲んだ2つの文字は、同じ「が」という文字に見えます。しかしこれは、「が」と「が」という異なる文字です。スペルチェックの波線が付いているほうが「が」です。

この記事は何ではないか

 濁点問題というと、比較的詳しい方には、ファイル名の問題と思われがちです。iOS 10でのKindleアプリの不具合なども問題になりましたし。が、ここで扱うのはファイルの内容(テキスト)のほうの問題です。

 ファイルのテキストの問題も、原理としてはファイル名の問題と同根です。ただ、テキストのほうの問題は認知度が低くて見過ごされがちです。また、正規化されないという問題により、一括処理したときにトラブルを起こす可能性があります。

私が意識したころ

 私がこの問題に遭遇したのは、2015年のことでした。Macを使っている著者様から送られてきた原稿テキストの中で、濁点や半濁点が付いていた文字のうち、テキストエディタの文字列検索にヒットしない文字があるという現象があったのです。ちょっと調べてみると、微妙に違う文字になっているようです。

 それからちらほらと、Macで書かれたMicrosoft Wordファイルやテキストファイルの中で、同様の現象を目にするようになりました。

 私の主な仕事範囲は、IT系出版物です。いまIT関連の文章を商業出版物に書くような技術者の方には、Macが高い普及率を誇ります。編集者にとっては、あらかじめ注意しておきたいポイントです。

どこで起こるか

 この問題は、Unicode文字集合による現象です。そのため、Shift JISなどJIS文字集合ベースの文字コードのテキストでは起こりません。

 Microsoft OfficeのようなUnicodeベースのアプリケーションや、UTF-8などUnicodeベースの文字コードで書かれたテストファイルで起こりえます。

Unicodeの濁点や半濁点

 Unicodeには濁点や半濁点の表しかたが2種類あります。想像しやすいのは、「が」を「が」という1文字として表す方法ではないでしょうか。この形式を「合成済み文字」と呼びます。

 もう1つの方法は、「が」を「か」と「゛」(相当)の2文字の組み合わせで表現する方法です。この「゛」の部分には、単体で使う濁点ではなく、組み合わせ専用の文字を使います。この形式を「結合文字列」と呼びます。

 文書中の濁点や半濁点を合成済み文字に揃えるのを「NFC(Normalization Form Composition)」正規化と呼びます。反対に、結合文字列に揃えるのを「NFD(Normalization Form Decomposition)」正規化と呼びます。NFD正規化されたUnicodeを、通称で「UTF8-MAC」と呼ぶこともあります。

 ちなみに、細かくいうとNFCやNFDは濁点と半濁点の正規化だけではありません。が、とりあえずここでは濁点と半濁点だけに話を留めておきます。

Macと結合文字列

 Windowsを使っていると、外で作られた文書を除けば、意図していないところで結合文字列が入力されることはありません。

 しかし、Macでは意図せずに結合文字列が使われることがあります。最初にちょっと触れたファイル名などはその一つです(HFS+ファイルシステムの場合)。

 ファイル名にとどまらず、Macではテキスト中にも意図せずに結合文字列が使われることがあるようです。挙動を見て推測した限りでは、Webブラウザーなどほかのアプリケーションから、テキストエディタやワードプロセッサにテキストをコピー&ペーストすると、そこで結合文字列が使われるように見えます。実験したわけではないのであくまで推測ですが。

困ること

 テキスト中に結合文字列が混じって何より頭の痛い点は、正規化されていないことです。普通に日本語入力した文字列は合成済み文字で入力されます。そこに、コピー&ペーストで結合文字列が入ると、テキスト全体ではNFCでもNFDでもない非正規化状態となります。

 それが直接トラブルとなるケースに、検索や置換があります。テキストエディタの機能で「ユーザー」を「ユーザ」に(あるいはその逆に)置換したつもりが、結合文字列の「ザ」が入っていた部分はヒットしないと、表記不統一となってしまいます。

 また、Microsoft Wordでは、よくも悪くも合成済み文字と結合文字列が同じように表示されます。しかし、アプリケーションによっては結合文字列だと表示が違う(「か」と「濁点」がわずかに離れて表示される)という場合もあります。印刷機でどうなるかは怖いので試したことはありません。

 なにより、同じはずの文字が2通りの異なる文字として入っているのは、気持ち悪いですよね。

NFC正規化する(コマンド編)

 さて、テキストを一気にNFC正規化する方法を見てみましょう。

 私はLinuxデスクトップを主に使っています。Linuxデスクトップでは、さまざまなコマンドを使ってテキストを処理できるのが強みです。最近では、Windows 10のWSLでもまったく同じことができるでしょう。なお、ここではWSLやコマンドを使う準備については割愛します。

 Linuxのコマンドにはテキストの文字コードを変換するものがあり、そこでNFC正規化もやってくれます。Macでも同じだと思いますが、試していないので念のため。

 文字コードを変換するコマンドにnkfがあります。nkfは、変換元と変換先の文字コードを指定して実行します。この文字コードとして「utf8-mac」(NFD正規化されたUTF-8)が指定できます。

$ nkf --ic=utf8-mac --oc=utf-8 source.txt > dest.txt

 ただし、nkfでは「utf8-mac」は変換元にのみ指定できます。つまり、NFC正規化のみです。

NFC正規化する(エディタ編)

 テキストエディタにNFC正規化やNFD正規化の機能が備わっている場合もあります。

 私が日頃使っているGNU Emacsには、リージョン(選択範囲のようなもの)をNFC正規化する「ucs-normalize-NFC-region」と、NFD正規化する「ucs-normalize-NFD-region」の2つのコマンドがあります。

 そのほかのエディタにも同様の機能があるかもしれませんが、よく知りません。

ワープロでは?

 案件によっては、Microsoft Wordなどのワープロ文書で原稿をやりとりすることがあります。Googleドキュメントで文書を共有して作業することもあるでしょう。

 ワープロ文書でも結合文字列が入っていることがあります。フォーマットを保ったまま(プレーンテキストにせずに)NFC正規化をかける機能が欲しいところですが、私の調べた限りではなさそうです。

 Microsoft WordやLibreOffice Writerなどのワープロや、Googleドキュメントでは、マクロ言語(外部DSL)を使って1文字ずつ見ていけば変換できそうな気もします。ただ、そうしたマクロ言語はいちど文書に組み込まなければ使えないのが面倒なところです。

 一つの試みとして、Microsoft Wordの.docxファイルを処理するdocx-normarize-nfcというプログラムを試作してみました。20行未満の簡単なPythonスクリプトです。これは、.docxファイルをZIPアーカイブとして開き、文書本体のXMLテキストを開いてNFC正規化し、ZIPアーカイブに書き戻すというものです。

注意

 少し触れたように、NFC正規化は濁点や半濁点だけの処理ではありません。

 たとえば「神」をNFC正規化すると「神」になります。これは変換ツールによって挙動が異なるようで、nkfで試すと「神」のままでしたが、GNU Emacsのucs-normalize-NFC-regionで試すと「神」になりました。

 私の主な仕事範囲であるIT系出版物では、文字や文字コードの本でなければ問題になるケースは少ないですし、むしろこのような正規化をかけたほうがいいかもしれません。ただ、固有名詞については注意したほうがいいでしょう。

まとめ

 Macから来た文書は、濁点や半濁点に注意しましょう。

Unicodeの濁点や半濁点のコネタ

 地域Linuxユーザーズグループ「小江戸らぐ」の2017年11月の月例会に参加して、「濁点の話」というコネタを発表しました。

濁点の話 from emasaka

 知ってる人はよく知ってる、Unicodeの濁点や半濁点の問題です。

 Unicodeの濁点半濁点とか、NFD/NFDとか、UTF8-MACとかいうと、macOSのファイル名の問題だと早合点されがちです。しかし、macOSではテキストの本文でもしばしば発生するし、むしろ正規化されていないぶん、もっと面倒だ、というのが言いたかったことです。

フルワイヤレスイヤホン「M-SOUNDS MS-TW1」を買った

 以前からノイズキャンセル付きBluetoothイヤホンを愛用している。外出のときなどに便利しているが、家事やワークアウトのときに使うにはケーブルやBluetooth受信機が少し邪魔に感じていた。

 そのため、フルワイヤレスイヤホンに興味を持っていて、最近いろいろな製品が出て値がこなれてきたので、「M-SOUNDS MS-TW1」を買った。

 自分の場合の要件は以下のとおり。

  • そこそこの値段
  • 品質などであまり冒険しない
  • 1回の充電で使える時間はそれほど気にしない
  • 量販店でその場で買える

 フルワイヤレスイヤホンは、2〜3万円クラスのハイエンドモデルから、2〜3千円クラスの廉価モデルまである。2〜3万円クラスはいろいろな機能があるけどちょっと高いなあ、かといって2〜3千円クラスは品質に不安もあるなあということで、間をとって1万円前後の製品から「M-SOUNDS MS-TW1」を選んだ。

 片方が親機となってスマートフォンと接続し、もう片方が子機となって親機とつながる。親機は最初にペアリングしたときに決まる。ペアリングしたら、充電機能のある専用ケースから外すだけで電源が入ってスマートフォンと接続される。

 ざっくりとした感想としては、フルワイヤレスは便利、接続とかの扱いは思ったより手軽、大きさや重さは気にならない、音質はとてもいいというほどではないけどそこそこ、とったところ。

 というわけで、いまのところ便利に使っている。電車に乗ったときなどはノイズキャンセル機能の付いたBluetoothイヤホンを引き続き愛用してるけど。

 なお、フルワイヤレスイヤホンがいろいろな製品が出ている中で、普通に自分で買った製品なので、ほかの機種と比較してどうかは自分にはわからない。念のため。

 | HOME |  »

Categories

Recent Entries

Recent Comments

Recent Trackbacks

Appendix

emasaka

emasaka

フリーター。
連絡先はこのへん

Monthly


FC2Ad