f

2015-01-18

Auto-detecting Japanese file enconding for Python3

Python3の標準機能だけでテキストファイルの日本語文字コードを自動判別する方法を記す。結論としては,fortryにより考えられるパターンを総当りでopenして試すことがベストだといえる。

Introduction

Pythonで日本語を使っていると文字コード(エンコード)関係のエラーに悩まされる。具体的にはファイルの入出力時や演算時の以下のような2種類のエラーにでくわす。

UnicodeDecodeError
UnicodeEncodeError

これはPythonが想定している文字コードと実際のデータの文字コードが違うために起こる。Python2系では文字のデータ型として,以下の2種類を持っている。

  • str型
  • unicode型

そのため,これらのデータ型が混在するとエラーとなる。Python3系では内部の文字のデータ型が実質的にunicodeであるstr型で統一されたためこの問題に対処しやすくなった。その代わりに,以下2点を明示的に指定する必要がある。

  • テキストファイル入力時のエンコード
  • テキストファイル出力時のエンコード

具体的には以下のように,open関数でencodingの値を指定して行う。

fr = open("./input.dat", "U", encoding="utf-8") # 入力
fw = open("./output.dat", "w", encoding="utf-8", newline="\n") # 出力

なお,入力時の改行コードに関しては,ファイルモードに"U"を指定することで,LF,CR,CR+LFをLFとして認識してくれる。出力時の改行コードについてもnewline="\n"を指定することで,LFとして出力できる。そのため,Python3での入出力時の改行コードの取扱は問題にならない。

文字コードについては,ファイル入出力時にだけエンコードを指定するため,問題の発生箇所を限定できわかりやすくなった。しかし,この入出力時にエンコードを明示的に指定する方法には欠点がある。それは,ファイル入力時にファイルの文字コードが不明である場合に,標準のPythonで自動的に文字コードを判定する方法が確立されていない点だ。

例えば,chardetのような外部ライブラリを使えばおそらく簡単に解決できるだろう。しかし,ファイルを開くときのエンコードの判定だけのために外部ライブラリを使うのは大げさである。そして以下のような欠点がある。

  • ネットがつながらない環境では,外部ライブラリをインストールできないため動作しない。
  • パッケージングする際にファイルサイズの肥大化につながる。

そのため,できる限りPython3の標準機能だけでファイルの文字コードを自動判別する方法が必要だ。

Method

調査の結果,Python3の標準機能だけで文字コードを自動判別するには以下の手順が簡単かつ依存性が少なくてベストだと判断した。

  • forとtryを駆使して,
  • 考えられる文字コードを総当りで,
  • 実際にファイルを開いて,
  • UnicodeDecodeErrorが出ないか確認

具体的にはに示すgetEncode関数を定義して,引数に開こうとするファイルパスを与えて,エンコードを取得する。考えられる日本語エンコードで実際にファイルを開いてエラーが出ないかどうか確認し,エラーが出れば次のエンコードを試し,エラーがなければそのエンコードを返している。

文字コードの自動判定関数
#!/usr/bin/env python3
# (File name: getenc.py)
# Lincense: CC0

def getEncode(filepath): encs = "iso-2022-jp euc-jp sjis utf-8".split() for enc in encs: with open(filepath, encoding=enc) as fr: try: fr = fr.read() except UnicodeDecodeError: continue return enc

FR = "./data.csv"
with open(FR, "U", encoding=getEncode(FR)) as fr:
fr = fr.read()

これにより日本語のテキストファイルであれば文字コードを自動的に判別してファイルを開くことができる。

Order of trying to encode

のコードにおいてポイントは以下のエンコードリストの順番だ。

    encs = "iso-2022-jp euc-jp sjis utf-8".split()

文字コードの判定を試すエンコードの順番が重要だ。

ISO-2022-JPとEUC-JPが曲者で,以下のようにSJISやUTF-8で誤判定(誤認識)されてしまう。

  • ISO-2022-JP:EUC-JP,UTF-8,SJISで誤判定。
  • EUC-JP:SJISで誤判定。

SJISとUTF-8はこの4種類では一意に判定される。つまり,ISO-2002-JP▷EUC-JP▷SJISの順番にエンコードを試していけばいい。この順番にしたがうと以下の3通りの組み合わせとなる。

  1. ISO-2022-JP▷EUC-JP▷SJIS▷UTF-8
  2. ISO-2022-JP▷EUC-JP▷UTF-8▷SJIS
  3. ISO-2022-JP▷UTF-8▷EUC-JP▷SJIS

判定のヒット率を考えると利用状況から3を使用したほうがよいかもしれない。しかし,後で見返すときに順番に意味があることをわかりやすくするために,日本語エンコード▷UTF-8の順番でやったほうがよいだろう。

このエンコードの順番は一般的にいえることのようで,例えばVimでエンコードのテキストファイルの自動判別を行うfencsの設定もこの順番にしたがわないと誤認識される。

set fileencodings=iso-2022-jp,euc-jp,sjis,cp932,utf-8

日本語エンコードの自動判別方法についてRubyでの状況も簡単に調べたが,標準ライブラリだけでやろうと思うと,に示したとおり総当りでやるしかなさそうだ。したがって,この総当りで文字コードを自動判別する方法は汎用性が高いといえる。

Appendix

今回は日本語の文字コードだけを対象としたが,全エンコードについて試してどんな言語のテキストファイルが来ても正しく判別できるようにしたいと思う人もいるだろう。

Python3が認識できるエンコードのリストは以下で示されている。

http://docs.python.jp/3/library/codecs.html#standard-encodings

利用可能なエンコードリストは/usr/lib/python3.4/encodings/aliases.pyに格納されており,以下のように標準ライブラリであるencodingモジュールのaliases属性でアクセス可能だ。

import encodings
encodings.aliases.aliases # エンコードとその名前の辞書が戻る

そのため,encs = encoding.aliases.aliases.keys()とすれば全エンコードを試せる。しかし,この方法はうまくいかない。なぜなら,encoding.aliases.aliasesには文字コード以外のエンコードも入るためだ。例えば,zipのエンコードなどバイナリファイルのエンコードも格納されており,途中でエラーが出る。また,辞書であるため誤った順番でエンコードが試され誤認識される。

したがって,全エンコードを試す場合は標準ライブラリの限定を諦めて,別の外部ライブラリに頼るべきだろう。

Reference

Python3での文字コードの自動判別にあたって参考にしたページを列挙する。数も多く玉石混交で整理するのが面倒なのでとりあえず他の人が参考にできるように掲載だけしておく。

エンコードとデコード.py - 3948番地 http://moon.my.coocan.jp/3948/wiki.cgi?page=%A5%A8%A5%F3%A5%B3%A1%BC%A5%C9%A4%C8%A5%C7%A5%B3%A1%BC%A5%C9.py

コンソール上でのみ使用されるプログラムの場合、入力文字の文字コードを推測する方法として、
import sys
decoded_string1 = unicode(input_string1, sys.getfilesystemencoding())
decoded_string2 = unicode(input_string2, sys.stdin.encoding)
というのがある。後者はコンソールから入力された文字の文字コードとしてはかなり信憑性がある。

Pythonにおける日本語のエンコーディングの検出について - 試験運用中なLinux備忘録 http://d.hatena.ne.jp/kakurasan/20100330/p1

[python3]文字コードの判定 | 「きまぐれほげほげひろば」のTOPICS http://chidipy.jpn.com/topics/?p=302

Python - テキストファイルのエンコーディングを自動判定して処理する - Qiita http://qiita.com/zarchis/items/3258562ebc9570fa05a3

pythonで丁寧な文字コード変換 - シコウサクゴ() http://d.hatena.ne.jp/yosshi71jp/20090915/1253034464

標準入出力、は
404 Blog Not Found:備忘録 - #python3 で sys.std(in|out|err) の encoding を強制する http://blog.livedoor.jp/dankogai/archives/51816624.html

  • Pythonであるディレクトリ以下のファイル全てに対して文字コードが何であるかチェックして出力 - Qiita http://qiita.com/selious/items/aa647128f54afe6a2063
    • このやり方は2系。

Python でエンコーディングを判定する | 傀儡師の館.Python - 楽天ブログ http://plaza.rakuten.co.jp/kugutsushi/diary/200805250000/

[mixi]文字コード判別 - Python | mixiコミュニティ http://mixi.jp/view_bbs.pl?comm_id=6869&id=68843693

技術志向 |Python 文字コードの判定と変換 http://speirs.blog17.fc2.com/blog-entry-4.html

[python3]文字コードの判定 | 「きまぐれほげほげひろば」のTOPICS http://chidipy.jpn.com/topics/?p=302

2015-01-17

C言語での日本語ファイル名でのファイル出力方法

C言語で日本語のファイル名でファイルを出力しようとすると,WindowsかLinuxのどちらかで文字化けする。この対処方法について説明する。結論としては,Windowsでのgccのコンパイルオプションに--exec-charset=sjisを追加すれば解決する。

以下の内容をもつアウト.datというファイルを出力するプログラムを考える。

アウト

名前をout.cとして,ソースコードを以下に示す。

// (File name: out.c)

#include <stdio.h>

int main(){
  FILE *fp;
  fp = fopen("./アウト.dat", "w");
  fprintf(fp, "アウト\n");
  fclose(fp);
  return 0;
}

このプログラムを以下のコマンドでコンパイルして実行する。

gcc -o out.exe out.c
./out.exe

Linux環境(Ubuntu 14.04)では問題なくアウト.datが出力される。しかし,Windows環境(MSYS2のMinGW-w64のgcc)でコンパイルして実行するとファイル名が文字化けする。ファイル内容は文字化けしない。

fopen関数の第1引数に日本語を渡すと環境に依存するようだ。日本語でファイル出力したい場面があるので可能ならば,環境に依存せずに日本語ファイル名を出力したい。

日本語ファイル名の出力方法

Windowsであればwindows.hに定義されている_wfopen関数を使えば日本語でも問題なく書き込める。しかし,この方法はWindows環境に依存する。マルチプラットホームでの動作を考えるならば使えない。標準のC言語のライブラリでどうにかできないか調べた。

調べた限りそのような関数はないようだ。

参考:streamのファイル名 - meryngii.neta http://meryngii.hatenablog.com/entry/20081130/1228044065

標準のC言語のソースコードの範囲では無理だとわかった。コンパイルオプションでどうにかできないか調べていると以下のサイトで記述を見つけた。

参考:猫科研究所 - gcc, windresで日本語を扱う方法 http://up-cat.net/gcc%252C%2Bwindres%25A4%25C7%25C6%25FC%25CB%25DC%25B8%25EC%25A4%25F2%25B0%25B7%25A4%25A6%25CA%25FD%25CB%25A1.html

以下のオプションにより実行ファイルの内部文字コードをShift JISに変換すればうまくいくようだ。

--exec-charset=sjis

このオプションの値はiconvコマンドが認識できるものならなんでもよいとのこと。つまり,sjisでもcp932でも同じShift JISの文字コードを指す。実際にWindowsで以下のようにこのオプションをつけてコンパイルして実行すると,ファイル名が文字化けしなかった。

gcc -o out.exe out.c --exec-charset=sjis

ただし,このオプションをつけると以下2点の問題がある。

  1. 日本語を含むファイルはファイルの文字コードもShift JISになる。
  2. Linux環境で同じオプションをつけて実行するとファイル名が文字化けする。

1について説明する。出力ファイルに日本語が含まれるとそのファイルの文字コードがShift JISになる。しかし,日本語が含まれなければUTF-8となる。この問題は以下2点の理由により解決は諦める。

  • 文字化けせずに表示されることが大事
  • きちんと出力できていればエンコードは別の方法で変換したり対応可能

2について説明する。同じout.cを--exec-charset=sjisオプションをつけてLinux環境でコンパイル・実行するとファイル名が文字化けする。元々LinuxはUTF-8がデフォルトなのでOSが想定しているエンコードと違うために起こるのだろう。

MakefileによるOSごとのオプションの自動設定

環境ごとにコンパイルオプションを考えないといけないのは面倒だ。また,実際にプログラムを作るときは複数のソースコードになるので,Makefileを書くのが一般的だ。そこで,OSごとのコンパイルオプションMakefileで吸収することにする。こうすれば,元々のソースコードを書くときやコンパイルするときにいちいち考えなくて済む。以下にMakefileを示す。

# (File name: Makefile)

## choose target compiler
FC = gfortran
CC = gcc
CXX = g++

## unset non target compiler
FC =
# CC =
CXX =

COMPILER = $(FC) $(CC) $(CXX)

## global flag (compile option) and library
LDFLAGS = -g -MMD -MP -mcmodel=large -Wall

TARGET = out.exe

ifdef FC
 SRC := $(wildcard *.f90)
 OBJ := $(SRC:%.f90=%.o)
 DEP := $(SRC:%.f90=%.d)
 MOD := $(wildcard *.mod)
 FFLAGS += -cpp
endif
ifdef CC
 SRC := $(wildcard *.c)
 OBJ := $(SRC:%.c=%.o)
 DEP := $(SRC:%.c=%.d)
 CFLAGS += -lm
endif
ifdef CXX
 SRC := $(wildcard *.cpp)
 OBJ := $(SRC:%.cpp=%.o)
 DEP := $(SRC:%.cpp=%.d)
 CXXFLAGS +=
endif

ifeq (${OS}, Windows_NT) # for Windows
 CFLAGS += --exec-charset=sjis
endif

all: ${TARGET}

${TARGET}: ${OBJ}
 ${COMPILER} -o $@ ${LDFLAGS} $^

%.o: %.f90
 ${FC} ${LDFLAGS} ${FFLAGS} -c $<
%.o: %.c
 ${CC} ${LDFLAGS} ${CFLAGS} -c $<
%.o: %.cpp
 ${CXX} ${LDFLAGS} ${CXXFLAGS} -c $<

clean:
 ${RM} ${TARGET} ${OBJ} ${DEP} ${MOD}

-include $(DEP)
.PHONY: all clean

上記のMakefileで重要なのは以下の3行だ。

ifeq (${OS}, Windows_NT) # for Windows
 CFLAGS += --exec-charset=sjis
endif

ここで,OSがWindowsであるときだけ--exec-charset=sjisのコンパイルオプションを追加している。これにより,OSがなんであっても日本語ファイル名でファイル出力するときに文字化けで悩まされずに済んだ。

2014-12:読了本

2014-12に読んだ本を示す。

12月はCSSに関する本を多めに読んだ。CSS組版をやっていく上で,最新のHTMLとCSSの知識が必要だったからだ。とりあえず,それらにどういうタグやプロパティがあって,どう活用すればいいのかを把握しておく必要がある。その中でもCSSのリファレンスとして最良と思われる「CSS辞典 第5版」と「CSS3 スタンダード・デザインガイド」に目を通して,結局「CSS3 スタンダード・デザインガイド」の電子書籍を購入した。

その他にもExcelのグラフの本とか,リーダブルコードとか有益な書籍に出会うことが多い月だった。

bkskの本棚 - 2014年12月 (6作品)
powered by booklog

2014-11:読了本

2014-11に読んだ本を示す。

資格試験がひとまず終わったので前から気になっていた本などを読んでみた。夏頃にまとめて借りたが読みきれなかった,パオロ・マッツァリーの本を借りて読んでみた。これでこの人の本が出版しているほとんど(90 %)以上の本を読んだことになる。この人はいい加減に見えるけど,かなりちゃんと調べた内容を本に書いている。参考文献もしっかりしている。自分にとっては役に立たない内容が多かったが,その中でも「反社会学講座」は有益な知見が得られて読んでよかったと思った。

リーナスの本は個人的にはいまいちだった。あんまり役に立たなかった。リーナスはただのオタクだったんだと思った。リーナスのライセンスに関する考え方がしれてよかった。リーナスはGPLをよしとしていない。自由を強いるのはよくなく,本人の自由意志を尊重すべきだという考えのようだ。

その他HTMLとかBlueGriffonに関する本を読んだ。BlueGriffonの本は全くの期待はずれだった。特に新しい知見はなく使っていればわかることだった。貴重な本だったからわざわざ購入して読んだけど,お金の無駄だった。

bkskの本棚 - 2014年11月 (9作品)
powered by booklog

2014-10:読了本

2014-10に読んだ本をメモする。

10月は資格試験やカンファレンスがいくつかありあんまりちゃんとした本を読んでいない。 主に野菜の料理に関する本を読んだ。ただし,この中から実際に購入した本はなかった

bkskの本棚 - 2014年10月 (6作品)
作りおきそうざい
読了日:10月20日
評価2

powered by booklog

2015-01-12

Vim language configuration for Fortran

Fortranコードを編集するための標準のVimの設定をまとめた。この設定をしておけばどのバージョンのFortranコードを編集するときでもVimで適切にハイライトやインデントされる。

作業においてFortranコードをVimで編集するときがある。しかもFORTRAN(Fortran77)の形式のファイルだ。コメントアウトされているものなど,きちんとハイライトするようにしたい。FORTRANだけでなく最新のFortran2008の形式でも通用するように柔軟に対応したい。そこで,Vimの言語設定とFortranの設定についてまとめた。

Vimでの言語設定

Vimの言語設定については以下を参考にする。

Vim: Filetype pluginを極める - while (“im automaton”); http://whileimautomaton.net/2008/09/07213145

上記の情報から最小限必要な情報を以下にまとめた。

  • Vimの標準の言語設定ファイルは<filetype>.vim。<filetype>にはFortranならfortranが入る。
  • 該当のfiletypeのファイルを開くと自動で<filetype>.vimが読み込まれる。
  • 自分で設定を上書きするには~/.vim/after/ftplugin/に<filetype>.vimを配置すればよい。
  • <filetype>.vimに設定するときは必ずローカルにする。
    • 変数はb:でバッファローカルにする。
    • オプションはsetlocalでバッファローカル設定にする。
  • after/ftpluginに<filetype>.vimを配置するときはインクルードガードを書く。
    if exists("b:did_ftplugin_<filetype>") | finish | endif
    let b:did_ftplugin_<filetype> = 1

VimでのFortranの設定

Vimで言語設定を行うときは,に示した3種類を設定する。

Vimでの言語設定項目
項目 意味 ヘルプのURL
syntax 構文ハイライト http://vim-jp.org/vimdoc-ja/syntax.html#fortran.vim
indent 字下げ http://vim-jp.org/vimdoc-ja/indent.html#ft-fortran-indent
folding 折りたたみ http://vim-jp.org/vimdoc-ja/syntax.html#fortran.vim

sytaxは構文ハイライト,シンタックスハイライト,構文強調,シンタックス強調などと呼ばれている。Vimのsyntaxのヘルプによると厳密には単語(レキシカル)ハイライトと呼ぶらしい。

Vimの標準のハイライトはFortran 2008だ。これは古いバージョンのほぼ上位互換なので変える必要はない。

ハイライトするときのソースコードの形式に固定形式(Fortran77以前)と自由形式(Fortran90以降)がある。標準だと固定形式となっている。どちらを選択するかでハイライトが変わってくる。拡張子によってこれを判断する。.fか.forの拡張子なら,固定形式としてそれ以外は自由形式とみなしてそれぞれ,fortran_free_sourcefortran_fixed_sourceの変数によりハイライトの設定をする。

その他,折りたたみやインデントの設定をヘルプを見ながら行う。

設定

ヘルプを見ながら適切だと思われるVimでのFortranの言語設定を行ったfortran.vimを以下に示した。以下のコマンドを入力することで~/.vim/after/ftplugin/fortran.vimが作成される。

mkdir -p ~/.vim/after/ftplugin
echo '
" \file fortran.vim
if exists("b:did_ftplugin_fortran") | finish | endif
let b:did_ftplugin_fortran = 1

"" 新規作成時の構文ハイライトに固定形式か自由形式のどちらを使うかの判定
let s:ext = expand("%:e")
if s:ext !=? "f" && s:ext !=? "for"
  let b:fortran_free_source=1
  let b:fortran_fixed_source=0
endif

" let fortran_more_precise=1 " より高精度な構文ハイライト。時間がかかる
" let b:fortran_have_tabs=1 " プログラム内でタブ文字を使う

"" 折りたたみ設定
let b:fortran_fold=1 " プログラム、サブルーチン、関数などで折りたたみを定義
let b:fortran_fold_conditionals=1 " doループ、ifブロックなどで折りたたみを定義
let b:fortran_fold_multilinecomments=1 " 3行以上のコメントに折りたたみを定義

"" インデント設定
let b:fortran_do_enddo=1 " do-endoブロックをインデント
" let b:fortran_indent_less=1 " プログラム単位でのインデントを無効化
' > ~/.vim/after/ftplugin/fortran.vim

これにより標準のVimにおけるFortranでの最良と思われる設定ができた。

2015-01-11

2015-01-07のVivliostyle新年会の参加・発表の感想

#vivliosytle #CSS組版 Vivliostyle新年会に参加して,「CSS組版の文献紹介と作業報告」という題で発表した。感想などを記す。イベントの概要をに示した。

イベント概要
項目 内容
イベント名 Vivliostyle新年会
開催日時 2015-01-07T20:00
URL https://www.facebook.com/events/391498301016858/

発表資料

僕の発表資料は以下に示した。

今回の発表資料はライセンスに注意した。というのも,Vivliostyleの会社のロゴや,中で書籍の表紙画像を含んでいるからである。厳密にいうと,これらのロゴや画像には著作権があり無断での利用は禁止される。そのため,発表資料にCC BYのライセンス(出典明記)を適用できない。一般的には,著作権者の黙認により問題が起きていない。ただ,他の人が使えるようにするにはCC BYのライセンス明記が必要だ。

そこで表紙のCC BYのライセンスに対して,以下を追記した。

except for images and figures

これにより画像以外はCC BYのライセンスにした。自由に使っていい画像もあるんだけど,個別に判定するのは面倒くさいので一律で決めた。今後は迷ったら画像はCC BYから除外し,自信のあるときだけ全部CC BYにする。

発表内容について

今回の発表は比較的急遽作った。12月中旬に今回の新年会の開催の連絡が来て,12月末に「プロジェクターが使えるので発表したい人は準備してね。」と知らされたからだ。ちょうど業務が立て込んでいて,年始は家でも仕事に打ち込んでいた。

あんまりネタはなかったんだけど,もう少し自分をアピールして,この先協力してくれる人や助けてくれる人が必要なので,頑張って発表することにした。

発表内容は以下のとおりだ。

  • 新年会の参加の経緯
  • CSS組版に関する文献紹介
  • CSS組版の試行例
    • 表組み
    • 相互参照

11/7のTeXユーザーの集いの後からほそぼそとやっていた,文献収集と「CSSによるプリントデザイン」を参考にやってみたCSS組版の例を紹介した。

資料の作成にはだいたい4-5時間はかかった。もともと5分程度の発表を予定していたが,当日の発表は10分くらいだった。もう少し資料の作成時間を短縮したいのだけど,なかなかうまい方法が見つからない。ただの箇条書きを羅列するだけなら楽に作れるが,そういうスライドはあんまり魅力的で なく悪いので作りたくない。当日の発表ではレイアウトや色などいまいちだったので,帰宅後修正してスライドシェアに公開した。

新年会参加の経緯では,以下のTeXユーザーの集いでの発表の感想記事に書いた内容をベースにしてスライドにまとめた。

My Future Sight for Past: TeXユーザーの集い2014で「TeXはオワコンなのか?」という題で発表した http://myfuturesightforpast.blogspot.jp/2014/11/tex2014tex.html

CSS組版関連の文献は,過去の村上さんが紹介していたものをまとめただけで特に独自性はない。この中で大事なのはアンテナハウスが公開している「CSSによるプリントデザイン」だ。これに書いているとおりにやればそれなりのことができる。

HTML+CSS+JavaScriptの参考書籍は,僕が1-2か月ほどかけて調査して購入した書籍の紹介だ。この辺の技術は僕も夏頃から勉強始めただけでまだまだ初心者だ。もっとよい書籍があればぜひ教えてほしい。ある程度知識がないとどの本がよいかどうかというのは判断できない。

最後にCSS組版の試行について。

僕のCSS組版の当分の目標はTeXでやっていたことをできるようにすることだ。そのためにひとまず表組と相互参照に手を付けた。ここに載せた内容は自分で調べたり考えてやったことがメインだ。「CSSによるプリントデザイン」も参考にしたが,id値の命名規則などは自分で考えたものだ。

TeXではpretyrefとかrefstyleというパッケージで,label名のプレフィクスから自動で判別して相互参照時に番号の前の「表」とか「図」とかのキャプションラベル部分も挿入してくれる。これをつかわないといちいち表\ref{tab:hoge}というように自分で入力しないといけない。これが面倒なのでやりたくなかった。

感想

僕は出版関係の人間ではなくただのLaTeXが好きだった一般人なので,はっきりいって部外者に近い。組版関係のイベントで見たことのある人は何人かいたけど,挨拶はしていないし話題もないので自分から話しかける勇気もなく始まるまで居心地は悪かった。

僕はもともと今回の新年会はもう少し少人数で椅子に座ってやるのかなと思っていた。そして具体的な作業のロードマップ的なのが示されるのかなと思った。しかし,違った。多数の参加者を募ったり自由に会話するには立食のほうがいいけど,込み入った話は会議室みたいなとこでやるのがいいかなと思っていた。

宴会の最中にVivliostyleの紹介とか希望者による発表という形式だった。しかし,この形式は僕には合わなかった。理由は以下に挙げる。

  • 発表が始まるまでお互い知らない者同士で,部外者かつコミュ力のない人は困る
  • 発表内容に集中できず,質疑などの大事な議論が全員で共有できない

もくもく会もそうだけど,何か話題やコンテンツがあるから人は話をしたり,集まるんだから,以下に示すように先に発表をやって質疑もして宴会で発表やその他の雑談などでよい。

  • ☓:宴会▷発表▷宴会(個人での質疑)
  • ○:発表▷質疑▷宴会

このスタイルを踏襲しているので,やはり僕はオープンCAE勉強会@関東のスタイルが気に入っている。

Vivliostyleの村上さんの発表では,正社員や協力開発者などの紹介,会社のロゴの秘話,会社設立の経緯について説明があった。おそらく初公開の情報だったので非常に興味深かった。やはり出版の世界でも自由の流れはあり,それが大事なんだと再確認できた。BookJSの開発者が協力してくれるみたいで,これはすごいと思った。既に国際的に協力者がいてさすがだなと思った。

僕の発表の後に何人か僕に声をかけてくれた。11/7のTeXユーザーの集い2014での僕の発表「TeXはオワコンなのか?」を見てくれていたようだ。組版記法とかMarkdownがダメなこととか話せて楽しかった。こういう場でもなければ組版の話とかすることはないのでね…

個人的に重要な問題である,JavaScriptの勉強するモチベーションについても質問してみた。が,しっくりする答えはなかった。業務で使わない以上,Atomエディタとかブラウザの拡張機能とか無理やり自分の利益に結びつけるのが大事だと思った。

それと組版に関して自分が日頃思うことを適当に以下で書く。

軽量マークアップはAsciiDocがベスト?

軽量マークアップでは調査中だけど,個人的にはAsciiDocが最も優れていると思う。Markdownは普及しているだけで以下のような問題がある。

  • 貧弱な仕様
  • 独自拡張の乱立

Markdownでがんばって書籍書こうとしている人がいるらしいけど,そもそもMarkdownは書籍執筆に向いていないんだから無理だ。無理にスクリプトでTeXにつなげようとしているみたいだけど,書籍執筆にMarkdownを使うこと自体がそもそも間違い。

SphinxとかRe:VIEWも不満はある。

Sphinxはいちいちプレビュー確認するためだけにプロジェクト作らないといけない。そして見出しの書き方が気に入らない。以下のように見出しの下に記号を5個とか並べるというもの。

見出し1
======

見出し2
-----

複数のレベルは記号を変更してやらないといけない。この書き方は個人的に嫌だ。Markdownのように行頭記号の個数で判別すべき。また,Python特有のインデントが重要な意味を持つというのも危なっかしい。

Re:VIEWは一部で実績はあるがそもそもあまり普及していない。公式サイトにもまともなマニュアルがないし,使い方がいまいちよくわからない。なんか同人誌でRe:VIEWの使い方の本が出ているらしいけど,Sphinxみたいにちゃんとpdfのリファレンスマニュアルを公式サイトで出すべきだ。

AsciiDocはDocBookという技術書のマークアップの簡易記法となっている。記法がよく考えられている。DockBookを経由することでTeXを使わずにpdfを出力できる。これが大きい。けっきょく既存の軽量マークアップでは自由ソフトだけで高品質なpdfをつくろうと思ったらTeXを使うしかない。Re:VIEWはInDesignに対応しているだけで,自由な組版ソフトは結局TeX依存。PandocでDocBookに変換したらいいのかもしれないが,Pandocは万能ではないし完全に再現できるとは思えない。

ただ,DocBookとかAsciiDocの情報があんまりなく,日本語の出力に工夫がいる。僕もまだうまくてきていないので今後も調査が必要だ。

このあたりの話は他の人にも意見を聞いてみたいので,まとめてどこかで発表したいなと思っている。

EPUBの存在意義とは?

電子書籍・EPUB関係の人がけっこういたような印象だった。個人的にはEPUBは利便性・必要性が理解できない。なぜこんなに話題になっているのかわからない。今回の発表で紹介した「パーフェクトJavaScript」はもともとEPUBしかなかったのでしかたなくEPUBで読んでいたのだけど,悪かった。理由は主に以下だ。

  • 表は汚い画像で検索できない
  • 1ページあたりの情報量が少ないのでページをたくさんめくらないといけない
  • 注釈など書き込みはできない

あまりにも使いにくいので自分でEPUBをpdfに変換した。12月にpdf版もでてこれはまともだったのでよかった。

リフローすることにそんなに利点があるとは思えない。それよりかは仕様がしっかり決まって十分に普及しているpdfでいいと思っている。EPUBの利点についてはまたどこかで質問してみたい。

まとめ

あんまりまとまりがないけど,まとめる。Vivliostyle新年会で発表して,何人かの人と議論を交わした。EPUBについては懐疑的なので,またどこかで質問してみたい。

とりあえず今後は,「CSSによるプリントデザイン」を参考に現状でできる範囲でCSS組版についてやってみるつもりだ。どこかでまた何か発表できたらいいと思う。

2015-01-10

京都市「動物による迷惑の防止に関する条例」へのパブリックコメントのお願い

動物愛護の人からメールが来た。京都市が1/14水締め切りで動物愛護関係条例のパブリックコメントを募集しているらしい。

この条例がそのまま施行されると,個人の動物愛護活動(餌の給餌・後片付け)が違法になり罰則が課せられてしまう。3世帯で活動団体を作るのはめちゃくちゃ難しい。自分のことしか考えられない人に動物愛護の協力は要請できない。こちらから協力を要請するのは本当に難しい。

僕の家では猫を8匹飼っていて,お母さんが近所の人に責められているのを見てきた。
野良猫は助けてあげないと餓死するしかない。だけど,助けた人は周りから責められる。なにか間違っている。動物を見殺しにした人が楽をして,助けた人が責められている。

数多くの意見が必要です。意見を書くのが難しければ,最後の参考意見のコピペや一部改変しても構わないので送付をお願いします。
動物愛護の人の中には動物愛護に詳しい弁護士さんもいるので,この参考意見はたぶんまともなものだと思う。

僕は参考意見をまるまるコピペして送付した。匿名なので誰が送っても大丈夫です。
こういうのは数が大事。意見がなければ無視されて現行で通ってしまう。
ご協力をお願いします…。

以下はメールの転載です。以下のメールの内容は転載・拡散大歓迎です。

****
京都市「動物による迷惑の防止に関する条例」の施行に向けて
今 パブリックコメントを募集しています。
「野良猫に餌をやろうとする人は自ら飼養するか、または 「まちねこ支援活動事業」
に沿って、適切な管理の下に実施すること」  と記載されており、

「身近にいる動物に対し、無責任な給餌(餌やり)をしたり、残飯ごみを
放置したりしてはならない」
これに違反すれば 勧告・命令・過料  にしようとしています。

問題は、

*無責任な給餌= 自ら飼養しない、「まちねこ」以外への給餌*
とみなされ、これ以外の給餌はたとえ避妊・去勢手術をして餌の後片付け
している(可能な場合は排泄物の処理努力をされている)場合も違反となり、
過料の対象となりえることです。

「まちねこ」にするには、
・町内で2~3名の活動団体をつくる
・町内会の同意を得る
・猫の管理方法を決める(猫用のトイレの設置など)

で、現時点ではまだまだハードルが高く、実施が容易ではありません。

意見提出は↓のフォームより
概要は↓


参考意見**ココから**

(意見)可能な限り猫を自ら飼養頂くか、又は出来る限りまちねこ活動支援事業に沿う
(背景)諸事情により自宅に連れ帰れない場合も多いことから「可能な限り」を挿入。又、町内会の同意を得ることが難しい場合も多いため「できる限り」を挿入。

(意見)無責任な給餌及び残飯ごみの放置について定義の設定
(背景)無責任な給餌及び残飯ごみの放置についても定義を設定することで、まちねこ活動及び適正な地域猫活動に取り組みやすくなる。定義は以下の通り。
a.残飯ごみを3時間以上放置している。
b.年齢や健康面で問題が無い猫に避妊・去勢を行っていない、又は行う努力をしていない。
c.トイレ設置や排泄物の掃除を行うなどの糞尿処理の努力を怠っている。

(補足)
1. 糞尿被害については、生物の排泄の回数や場所を100%コントロールするのは不可能で、糞尿への苦情だけで給餌中止を条例化するのは人道的な見地から問題があるため努力義務が適当である。この問題については、繁殖制限+適正な飼育により野良猫の数を減らすことしか平和裏な解決策はない。そこで、以下のような行政の取組みを加えて提案する。

a.避妊・去勢を行わずに給餌をしている人へ、施術するように説得する。
b.まちねこ活動支援事業の拡大に積極的に介入する。具体的には、野良猫の苦情が出た地域で、まちねこ活動が行われるように行政側が話し合いの場を設けたり、会合に出席して活動の意義を伝えたりなど。
c.糞尿被害の苦情のあった地域で、トイレを設置することを地域住民に働きかける。

2.条例を制定することで、現在進行している市民活動自体が阻害されることを危惧する。
まちねこ活動支援事業は画期的な取り組みで評価に値する。一方事業開始前から多くの個人が自己負担で避妊・去勢を行い適正な給餌(地域猫活動)を続けており、こういった市民活動が引取り数、ひいては猫の糞尿被害苦情件数の減少に貢献していることもゆるぎない事実である。野良猫を全て「まちねこ」にすることが理想だがまだ時間がかかるため、条例が「まちねこ」以外の給餌を全面的に中止するような内容であれば非常に取組みにくいものになる。また、給餌中止により餓死したりゴミをあさる猫が増え、大変不衛生な状態が起こることが考えられる。これでは京都動物愛護憲章で冒頭に謳われている「動物を思いやりましょう。」スローガンとは大きく乖離する。

ココまで***