« 2019年9月 | トップページ | 2019年11月 »

2019年10月31日 (木)

Ghostscript-9.50

Unix向けのPostscriptインタープリタ、Ghostscript が9.47→9.50にupしておりました。

早速、HighSierra(macOS)でbuildしてみましょう。

LDFLAGS="-L/usr/local/lib" ./configure --disable-compile-inits --with-libiconv=gnu
$ LDFLAGS="-L/usr/local/lib" make
$ sudo make install

 

私はgnuの最新iconvを自分で/usr/local/ に別に入れていますので、それを参照してもらうように指定します。これがないと、

Undefined symbols for architecture x86_64:
"_iconv", referenced from:
_opvp_to_utf8 in gdevopvp.o
"_iconv_close", referenced from:
_opvp_to_utf8 in gdevopvp.o
"_iconv_open", referenced from:
_opvp_to_utf8 in gdevopvp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

 

というエラーを吐いて止まりますので。macOS側のiconvと自分で入れたgnuのiconvがうまく判別できないようなのですね。

 

Gs950

で、Build&install完了です。 golfer、tiger、all_aj1 の表示もOKですね。うむ!

| | コメント (0)

2019年10月27日 (日)

pango-1.44.7を

pango-1.44.7を入れてみます。macOS HighSierraです。

meson build/
ninja -C build
sudo ninja -C build install

ん?

Undefined symbols for architecture x86_64:
  "_hb_coretext_font_create", referenced from:
      _pango_core_text_font_create_hb_font in pangocoretext.c.o
ld: symbol(s) not found for architecture x86_64

で止まってしまった。 はて?
harfbuzz-2.6.2 を入れ直したらOKになった。

$ ./autogen.sh
$ ./configure --with-coretext=yes
とやることで、coretextを扱ってくれる部分はharfbuzzを呼んでるから、なんですかね?

うーん、、こりゃーわからんよ。(^^;

 

| | コメント (0)

LinuxとUSBメモリ

会社で機器制御用のLinuxのrpmやtar.gz、さらに自前で作ったCのソースなんかをUSBメモリに入れてやりとりしたり、Fileサーバ(samba)に保存したりしていたんだよね。 (会社の事務マシンはWindowsなのだ。)

 

USBメモリにXFSのCentOS/Linuxからソースやバイナリをそのまま入れてサーバに保存したり他のLinuxマシンに持って行ったりすると、まぁ、当然inode情報が欠落します。(笑) それをWindowsでZIPにして送ったり・・・してる人までいた。で。

「実行Fileが実行できなくなった」

「ソースの作成日付がCopyした日に変わってしまう」

「ZIPを解凍したらFile名が文字化けしてた」

「Cのソース、閲覧できないんだけど?」

 

とかの小さな事件が起きるわけです。(笑) Windowsしか知らない人には原因がさっぱりわからないらしい。まぁ、、私はMacユーザでunix使いなのでそんなことは当然のことなのですけどね。 ちなみにMacはUSBメモリのFAT32にFileをCOPYするとinode情報や拡張属性を不可視Fileで別保存してくれる。Linuxにはそういう(余分な)機能はない。

 

LinuxのFileSystem、ext3/4、XFS、そしてAppleのAPFSやHFS+は FAT32やNTFSとは扱えるFile属性情報が違うという認識を持って欲しいな。また、CのソースはUS-ASCII/utf8の改行コードはLFであり、Shift-JISでCR+LFのWindowsとは違う、ということ。BOMなんかも付けちゃいけない。 また、File名もutf8で扱うのが普通なので、Shift-JISの日本語Windowsとは同じZIPでもFile名が化けてしまう事になるのだ。

 

| | コメント (0)

2019年10月20日 (日)

秋の昆虫

今日は庭で昆虫たちの手入れ。

お! いた!

Kamakiri_20191020223201

カマキリ君がユーラユーラ・・・ 大きいですね。

Youki

まずはノコギリクワガタの飼育していた容器。成虫がいなくなって3ヶ月経過してます。

 

Nokogiri

いました。 ざっと3匹の幼虫。材の中にまだいるかも? なので、まだそのまま保存しておきます。

3匹は個別飼育の容器に移ってもらいました。 クヌギマット買ってこなきゃ。(冬になると入手難になるのですよ)

 

クワガタは夏を過ぎて「今年は幼虫いないか」とあきらめても、環境を大切に保存しておくのがよいのです。(保湿を忘れずにね)

 

| | コメント (0)

2019年10月14日 (月)

ナナフシの幼生

台風も去り、なんとか庭の木々も無事でした。(塀は先の15号で壊れたまま・・・)

 

今日はミカンの収穫をしました。 たくさんなってるな。 収穫してる娘が・・・

「変なクモ?がいる!?」 どれどれ。。

 

ん?

 

7fusi

糸出してぶら下がってるけど、クモじゃないね。なんだこれ??

 

7fusib

指でちょん、とやってみたら、、お、これは! ナナフシの幼生ではないですか!

ナナフシモドキ?かもしれませんが。 ウチの庭で何回かナナフシは見かけたことがありますが、

こんな小さいのは初めてみましたよ。

 

かわいいですね。

 

| | コメント (0)

2019年10月12日 (土)

tiffのヘッダ

画像を変換して、RGB/8bitで並ぶ画像データをtiffで保存しようとしてます。
固定の最低限のtiffヘッダを作って、RGB画像の先頭に入れてやろうというわけ。

先頭の8byteは簡単だ。
4D4D 002A 00000008   ←  Big-Endianで0x00000008からtiffのtagが入ってる、の意。
画像データの最後にtagをつける場合は、00000008 ではなくなるわけね。

次にtagが続く。

000A   ← 10個のtagが続くよ
00FE 0004 00000001 00000000   ← FileType(標準)
0100 0003 00000001 ****0000   ← 画像の横幅
0101 0003 00000001 ****0000   ← 画像の縦幅(高さ)
0102 0003 00000003 ********   ← 色の深度(RGB:3つ分)
0103 0003 00000001 ****0000   ← 画像の深度(ここでは1)
0106 0003 00000001 ****0000   ← 圧縮(1:非圧縮)
0111 0004 00000001 ********   ← 画像データの先頭ポインタ
0115 0003 00000001 ****0000   ← コンポーネント数(RGB:3)
0117 0004 00000001 ********   ← 画像データ総数
011C 0003 00000001 ****0000   ← 画像の並び順(RGB:1)

0000 0000   ← tagの終了
0008   ← 色の深度(R)    ここを0102のポインタで指す
0008   ← 色の深度(G)
0008   ← 色の深度(B)

こんな感じです。DataTypeが3の場合はuint16なので後半4byteは使われない。
逆に色深度のように8byteを超えるdataを示す場合はポインタで場所を指す。
ふむ、非圧縮のストリップ(分割)なしならそんなに難しくはないですね。
 

| | コメント (0)

« 2019年9月 | トップページ | 2019年11月 »