NAKAMURA Minoru's Diary (2010年10月)

10/22 (金)

Office 2010 でしおり付きPDFが高速に安定して作れる!!

カイシャのお仕事の仕様書は MS-Word で作成するが、いつのまにか数百ページを越えているのが常。図を描いたり、 EXCEL の表を OLE オートメーションで貼り付けたりするとファイル自身も10MBを越えてしまう。しばらくすると貧弱なマシンでは開くことすらできない Word 文書ができあがる。そのため閲覧用の仕様書は Word を PDF 化して固めることになる。

仕様書は長大なので可能であれば、 Word の文書の「見出し」を PDFの「しおり」に変換したい。ところがこれが意外に難しい。

Adobe Acrobat は MS-Word のプラグインとして振る舞って、開いている Word ファイルを PDF に変換する機能がついている。この機能で PDF にすると「見出し」が「しおり」に変換される。
ただしこの変換はメモリ喰いで、大きな Word 文書を PDF 化しようとすると、何時間も待たせたあげく「メモリ不足で中止します」というメッセージを表示して諦めてしまう。 Acrboat3 あたりから Acrobat8 ぐらいまで見てきたが、動作の不安定さはバージョンアップしても一向に改善しない。
OpenOffice.org の Writer には Word 文書の読み込み機能と PDF の書き出し機能が備わっている。書き出される PDF はしおり付きだ。
しかし OpenOfifce.org は MS-Word 文書を完全に取り込めるわけではなく、手持ちの仕様書を OpenOffice.org で読み込むと、判読が困難なぐらいに変形する。
しおり付き PDF にはなるものの使えない。
DTP ソフトの中には Word 文書を取り込んでそれを PDF に書き出せる可能性もあると聞くが、いかんせん価格が高いので PDF 化のためだけに買うのが躊躇する。

しかし Office 2010 の Word には、デフォルトで PDF ファイルへの書き出し機能がついている。しかもオプションの中で「印刷対象外の情報を含める」の中に「次を使用してブックマークを作成」を選択すると、しおり付き PDF が作成できた。しかも Word の開発元自身が作っているだけあって、 Acrobat とは比較にならないぐらい短時間で作成可能だ。いろいろ試してみたが Word 2010 で開ける範囲の文書は、全部 PDF 化できるようだ。

PDF 化機能自体は Office 2007 の時にPDF/XPS保存アドインという形で配付していた。これにも見出しをしおりに変換する機能があったようだ。

ただ Office 2010 の場合は相互参照のリンク化ができないので、章・節・表・図・脚注番号を使った埋め込みはできないようだ。とはいえほとんどの人には Office 2010 だけで事足りそう。

P.S.

Antenna House PDF Driverでもしおり出力が可能なのね。しかも相互参照のリンク化も可能みたい。

コメントを書き込む

10/16 (土)

東急東横線の沿線で見かける変な建物

東急東横線の乗りながら沿線の景色をみていると、ふと

田園調布側から自由が丘駅に差し掛かるときに、北側の窓を覗いていると側面に大きなステンレスっぽい階段がついた建物が見えるはず。ずっと気になっていたのだが、これは正体は ARBOS という高級賃貸マンションだったようだ。


思わず登りたくなる衝動をぐっと我慢する	高架から覗き込むように見ると巨大感があるが近寄ると結構普通っぽい(^_^;

電車の中から多摩川駅の南、田園調布側を眺めていると、小高い山の中に突如として突起物を生やした建物が出現する。宗教関連施設っぽいのだがその正体をさぐるべく丘の上まで行って見る。

どりこの坂の碑
坂がキツイ

清涼飲料水の開発者の屋敷が名前の由来

その正体はやっぱり「世界真光文明教団田園調布道場」でした。


突起物が出雲大社の神殿を思わせる		時計ではなかった	裏側にも

ここは結構高い丘の上にあるが田園調布側から続く高級住宅街の中だ。周囲の民家も奇抜な建物が多いので、近場で見るぶんにはそれほど違和感がないナリ。

コメントを書き込む

10/11 (月)

[MyWeb] NMINORU.JP ドメインの維持費用をレジストラに支払う

ヒューメイアにこのドメインの年間維持費用をレジストラに支払う。

ここは維持料が高いし他に移ろうと思いつつ、後回しになっているよのね…

秋葉原で見かけた街宣カー、いや街宣バス

「学園黙示録 HIGHSCHOOL OF THE DEAD」の街宣カー。元バスのようだ。

コメントを書き込む

10/10 (日)

[Food] らーめん元山亭＠日吉

日吉に塩ラーメンの店ができたの行ってみる。塩ラーメン主体の店は日吉ではじめてかしら？

鶏つくね入り

あっさり鶏がらスープでかなり美味しい。縮れ麺がスープによく絡む。

オプションにわさびがあるけど、これを入れるとどうなるんだろう。

コメントを書き込む

10/8 (金)

[Linux] kdump の出力先を LVM にしようとしてトラブル

Fedora12 (x86-64) で kdump の出力先を LVM のボリュームにしようとして、さんざんトラブルに遭遇する。 kdump を使う場合、LVM は鬼門のようだ。

kdump 用の initrd が LVM のマウントに失敗する

kdump はクラッシュ時に vmcore を採る専用カーネルと再起動せずに内部的に立ち上げる。このために使うカーネルは initrd-version.kdump.img で、ベースシステムの設定を元に mkdumprd というシェルスクリプトが生成する。

initrd-version.kdump.img は、内部起動に必要なプログラムは ram disk 内に抱え込んでいる。ただ、それでは足らないようでなぜかブートディスクやルートディスクを見に行く。

この時 Fedora12 の mkdumprd にはバグがあり、 mkdumprd が生成する initrd-version.kdump.img の起動スクリプト init は、ルートディスクが LVM の場合には正常時でも無限ループするようなコードを挟み込んでしまう。

1662  if [ -n "$vg_list" ]; then
1663      emit "echo Scanning logical volumes"
1664      emit "lvm vgscan --ignorelockingfailure --mknodes"
1665      emit "echo Activating logical volumes"
1666      emit "lvm vgchange -a y --ignorelockingfailure"
1667      emit "DM_NUM=0"
1668      emit "lvm lvs --noheadings -o lv_name,vg_name | while read i"
1669      emit "do"
1670      emit "   LV=\`echo \$i | awk '{ print \$1 }'\`"
1671      emit "   VGRP=\`echo \$i | awk '{ print \$2 }'\`"
1672      emit "   mkdir -p /dev/\$VGRP"
1673      emit "   if [ ! -e /dev/\$VGRP/\$LV ]"
1674      emit "   then"
1675      emit "      ln -s /dev/mapper/\$VGRP-\$LV /dev/\$VGRP/\$LV"
1676      emit "      DM_NUM=\`echo \$DM_NUM 1 + p | dc\`"
1677      emit "      if [ -z \"\$noresume\" ]"
1678      emit "      then"
1679      emit "        /sbin/dmsetup resume /dev/mapper/\$VGRP-\$LV"
1680      emit "      fi"
1681      emit "   fi"
1682      emit "done"
1683  fi

RHEL5 の kdump は正しく動く mkdumprd が付いている。

1662  if [ -n "$vg_list" ]; then
1663      emit "echo Scanning logical volumes"
1664      emit "lvm vgscan --ignorelockingfailure --mknodes"
1665      emit "echo Activating logical volumes"
1666      emit "lvm vgchange -a y --ignorelockingfailure"
1667      emit "DM_NUM=0"
1668      emit "for i in \`lvm lvs --noheadings -o lv_name,vg_name | sed -e's/ \\+/:/g'\`"
1669      emit "do"
1670      emit "   LV=\`echo \$i | awk -F\":\" '{ print \$2 }'\`"
1671      emit "   VGRP=\`echo \$i | awk -F\":\" '{ print \$3 }'\`"
1672      emit "   mkdir -p /dev/\$VGRP"
1673      emit "   if [ ! -e /dev/\$VGRP/\$LV ]"
1674      emit "   then"
1675      emit "      ln -s /dev/mapper/\$VGRP-\$LV /dev/\$VGRP/\$LV"
1676      emit "      DM_NUM=\`echo \$DM_NUM 1 + p | dc\`"
1677      emit "      if [ -z \"\$noresume\" ]"
1678      emit "      then"
1679      emit "        /sbin/dmsetup.static resume /dev/mapper/\$VGRP-\$LV"
1680      emit "      fi"
1681      emit "   fi"
1682      emit "done"
1683  fi

LVM の出力先に指定すると途中で再ハング

クラッシュダンプは /proc/vmcore を出力先にディレクトリにコピーするだけなのだが、 LVM ディスクに書き出すと途中で書き出しが失敗しカーネルの再起動がかかってしまう。 /var/crash/<日付>/ 以下には vmcore-incomplete というファイルが残る。システムの物理メモリは 12GB なのだが vmcore-incomplete は 1.2GB 程度しかない。

ルートディスク以外の ext3 のディスクをマウントしてそこを書き出し先に指定すると、問題なく vmcore は書き出せる。

疑問

kdump は通常はファイルツリーの指定位置を出力先にするが、個別のパーティションしたり、RAW ディスクを指定したりすることも可能だ。しかしその場合でもルートディスクはマウントするようにできている。なぜなんだろう？
LVM に /proc/vmcore が正常にコピーできないのはなぜか？

コメントを書き込む

10/3 (日)

ハロウィーンの季節

ハロウィーンの季節になると、近所の喫茶店はビニールでできた人形を店の前に飾っている。

去年までは気づかなかったのだが、カボチャのジャックの首がグルグル回って、白いおばけが飛び出てくるというギミックがあったみたい。

道行く子供たちが足を留めて覗き込んでゆくよ。

コメントを書き込む

10/2 (土)

[Linux] sparse file の穴を検出する一般的な方法はないようだ

疎なファイル(sparse file)とかholeのあるファイル(2006年2月6日の日記) の穴の位置を検出する方法を探しているのだが､通常の POSIX システムにはそのような穴の位置を調べる方法はないようだ。

スパースファイルは lseek か mmap を使えば簡単に作成できる。

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int main(int argc, char** argv)
{
    int fd = open("sparse-file.dump", O_CREAT|O_RDWR, S_IRUSR|S_IWUSR);

    /* 1MB の位置に移動する。 */    
    lseek(fd, 1024*1024, SEEK_SET);

    /* 最後の1バイトだけ書く。 */
    char buf=0;
    write(fd, &buf, 1);

    close(fd);

    return 0;
}

一方、スパースファイルのスパースな箇所を発見するシステムコールは用意されていない。

tar コマンドは S オプションをつけるとスパースファイルを穴があいた状態でアーカイブしてくれる。ただしこれはファイルを read したブロックが全部 0 だったら圧縮するというもので、スパースファイルでない全部 0 のファイルも同じように圧縮されてしまう。
cp コマンドはファイルサイズと消費ブロックの差に注目し、コピー元がスパースファイルと判断した場合はコピー先をスパースファイルとして構成する。ただしこれもブロック単位の読み込みが全部 0 であったら穴をあけるというものなので、所どこに全部 0 のブロックがあるスパースファイルを cp すると、完全なスパースファイルになってしまう。

さてどうやれば穴の位置が分かるのか？ Linux カーネルでも address_space_operations のレベルまで降りないと穴の位置は判定できないようにみえる。 AUFS は support copyup sparse file (a file which has a 'hole' in it) とあるがはたしてどうやっているのだろう？

追記(2011/2/2)

Linux の場合でもやり方が分かった。 2011年2月2日の日記に記載。

コメントを書き込む

NAKAMURA Minoru の日記 (2010年10月)

10/22 (金)

Office 2010 でしおり付きPDFが高速に安定して作れる!!

P.S.

10/16 (土)

東急東横線の沿線で見かける変な建物

10/11 (月)

[MyWeb] NMINORU.JP ドメインの維持費用をレジストラに支払う

秋葉原で見かけた街宣カー、いや街宣バス

10/10 (日)

[Food] らーめん 元山亭＠日吉

10/8 (金)

[Linux] kdump の出力先を LVM にしようとしてトラブル

kdump 用の initrd が LVM のマウントに失敗する

LVM の出力先に指定すると途中で再ハング

疑問

10/3 (日)

ハロウィーンの季節

10/2 (土)

[Linux] sparse file の穴を検出する一般的な方法はないようだ

追記(2011/2/2)

[Food] らーめん元山亭＠日吉