2017/04/12(水)今どきの和文Webフォント

Webサイトを制作していて、悩みの種のひとつに文字フォントの問題があります。
従来(結構昔話になってきている)は閲覧する側で表示できる文字フォントを考慮するのが一般的であり、制作側で使用したい文字フォントをデザイン的に強制出来ないという問題 があります。

筆者が制作したサイトもこんな感じで、クオリティにやや難を感じる状態です。。
20170412_before.png

最近は CSS の普及でこうした問題も解決し、ライセンスに注意する必要がありますが、制作側で意図した文字フォント一式をWebブラウザにダウンロードさせ、強制することができます。
これは、一般的に「Webフォント」と言うものです。

しかしながら、日本語環境でこの「Webフォント」を採用するには問題があります。先ず、
・英文フォントと違い文字種が多いので、フォントファイルも数MBはザラである。フォントによっては、数10MBあり、ダウンロード → 表示に必然的に時間かかる。

という致命的ともいえる問題があり、更に、
・実際に表示させてみると、文字フォントによってはレンダリングが汚く、プロ品質の実用にやや難がある。

とりあえず、致命的な問題が何とかならないものかと色々調査していましたが、
有償のサービスもあるもののそれは弊社の環境にはオーバスペックなため、下記の手法で落ち着きました。

〔参考〕
10分で設定完了!Webフォントの使い方や軽量化・はてなブログでの設定手順、優良リソースなどまとめ【おすすめ日本語フォントも】
http://brian.hatenablog.jp/entry/how-to-set-web-fonts

先ず、
「サブセットフォントメーカ」 というソフトウェアと、
「WOFFコンバータ」 というソフトウェアをダウンロードしてインストールしておきます。
ちなみにこれら2つのソフトウェアは Win版とMac版両方あります。

両方ともいわゆるフリーソフトで、生成したフォントファイルは、元にしたフォントファイルでライセンス制限されていない限りは商用利用(有償で制作を請け負うなど)可能です。

インストール出来たら、「サブセットフォントメーカ」を起動し、以下のように入力しました。
20170412_1.png
因みに、元フォントは「モトヤLマルベリ等幅3」というApache ライセンスのものを採用しました。
フォントに格納する文字のところは、テキストファイルであれば何でもよいようです。
筆者はそのまま対象のHTMLファイルを選択しました。
但し、Windows 環境において、UTF-8 では文字化けするようなので、予め UTF-16BOM(Windowsで言うところのUnicode形式) に変換しておくとよいです。

ここで「作成開始」をクリックすると、すぐに WOFF コンバータの画面が開きます。
以下のように入力します。(変換前ファイルの欄は自動入力される)
20170412_2.png

ここで「変換開始」をクリックすると、拡張子が .eof , .woff , .woff2 の3つのファイルが生成されます。
こうすることで、使用している文字のみをピックアップし、フォントファイルのサイズを大幅に削減できます。筆者の場合は最大で 15kB 余りとなりました。

これらをサーバにバイナリモードにて(FTP の場合)アップロードし、次にCSS ファイルで、これらフォントファイルを参照するように設定します。
こんな感じです:
@font-face {
  font-family: 'motoyasub3' ;
  src: url('/css/motoyasub3.woff') format('woff'),
       url('/css/motoyasub3.eot')  format('eot') ;
  font-weight: 100 ;
}

a.sidemenu  { font-family: 'motoyasub3',"MS Gothic",Osaka,monospace,sans-serif;
      .... [中略] ....
            }
これで、こうなりました:
20170412_after.png

レンダリングも問題なさそうです。(Cyberfox,chrome,IE11,edge で確認)
woff 形式は IE 以外で、eot 形式は IE のみでサポートする Webフォントファイルのようです。

2017/01/05(木)壊れたのと同じテスタを買ってみた

早速、昨日から業務稼働しています。
20170105.JPG
12月29日、たまたま興味本位で寄った個人経営らしきリサイクルショップなのですが・・・

なんと、機械的損傷で数ヶ月前に壊れてしまった安物テスタと全く同型のものが平積みで売っていました。とりあえずというか、必要ではあるので思わず買ってしまいました。
3年くらい前にネット通販で980円で購入した記憶があるのですが、税抜き699円で売っていました。
しかしまぁ、リサイクルショップで安物新品テスタが売られているなんぞ、誰も考えないでしょうね。

本当は、もっときちんとしたプロの業務に耐えうるテスタが欲しいのです。
工事現場などで携帯目的で使うにもやや難があります。
この手のテスタは測定誤差が結構あるのですよ。。

2016/12/31(土)FreeBSD11 で OpenLDAP・Courier-Authlib・postfix3.1.x インストール時の注意

今年最後の更新です。

年明けから、FreeBSD11 を使用したARM系ボードの試作の仕事が入りそうなこともあり、弊社管轄の幾つかのサーバを FreeBSD 11.0 にしてみました。
FreeBSD 9系 のサポートは本日で終了です。
FreeBSD10.3 は、少なくとも 2018年4月末までのサポート、
FreeBSD11系 は、少なくとも 2021年9月末までのサポートになっています。
FreeBSD10系 は微妙ですが、FreeBSD11系は、サポート期間が延びる可能性ありです。

FreeBSD 11 にすると、コンソール(画面表示)ドライバが変更されており、こんな表示になります。↓
20161231.JPG

フォントさえ設定できれば、日本語表示できるのですが、11.0 の時点ではまだデフォルトでは出来ないようです。
また、スクリーンセーバーは機能しません。今後の課題でしょうか。。

本題ですが、FreeBSD11にするにあたり、注意すべき気づいた点をメモ書きしておきます。
1)OpenLDAP 2.4.44 のインストール
 FreeBSD10 まで普通に使い回しが出来たのですが、
 どうやら、BDB 形式でデータベースクラスタを構築している場合、
 FreeBSD11 上で OpenLDAP自体を構築し、FreeBSD10 で使っていた BDB を使用しようとすると、slapd 自体が起動しなくなるようなのです。
 これをしなければ大丈夫ぽいですが、問題の先送りをするだけです。

 このため、
 ○ FreeBSD 11 移行前に slapcat コマンドで LDIF をエクスポート
 ○ FreeBSD 11 移行後に openLDAPを再構築したら、slapadd コマンドで LDIF インポート

 という手順で解決しました。

2)Courier-Authlib のインストール
 ソースコードからインストール作業する場合、以下のメッセージが出て configure に失敗することがあります。
 Shared object "libssl.so.7" not found, required by "courierauthconfig"
これは、 /usr/local/bin/courierauthconfig 、/usr/local/courier/bin/courierauthconfig をバッサリと削除し、 configure をやり直せば大丈夫です。
過去に Courier IMAP 等を使用したことがあって、FreeBSD を更新インストール継続しているとこうなると思います。

3)postfix 3.1.x のインストール
 現時点での最新バージョンは 3.1.3 ですが、これは FreeBSD11 には対応しておらず、ソースコードからの構築はそのままではできません。
 ですが、機能的には問題ないと思われますので、以下の修正を行ってから構築を行います。
・ makedef 260行目付近 ~ (行頭が + の行を挿入)
   FreeBSD.10*)  SYSTYPE=FREEBSD10
                 : ${CC=cc}
                 : ${SHLIB_SUFFIX=.so}
                 : ${SHLIB_CFLAGS=-fPIC}
                 : ${SHLIB_LD="${CC} -shared"' -Wl,-soname,${LIB}'}
                 : ${SHLIB_RPATH='-Wl,-rpath,${SHLIB_DIR}'}
                 : ${SHLIB_ENV="LD_LIBRARY_PATH=`pwd`/lib"}
                 : ${PLUGIN_LD="${CC} -shared"}
                 ;;
+  FreeBSD.11*)  SYSTYPE=FREEBSD11
+                : ${CC=cc}
+                : ${SHLIB_SUFFIX=.so}
+                : ${SHLIB_CFLAGS=-fPIC}
+                : ${SHLIB_LD="${CC} -shared"' -Wl,-soname,${LIB}'}
+                : ${SHLIB_RPATH='-Wl,-rpath,${SHLIB_DIR}'}
+                : ${SHLIB_ENV="LD_LIBRARY_PATH=`pwd`/lib"}
+                : ${PLUGIN_LD="${CC} -shared"}
+                ;;
  DragonFly.*)   SYSTYPE=DRAGONFLY
                 ;;
   OpenBSD.2*)   SYSTYPE=OPENBSD2
・ src/util/sys_defs.h 25行目付近~ (行頭が + の行を挿入)
 #if defined(FREEBSD2) || defined(FREEBSD3) || defined(FREEBSD4) \
     || defined(FREEBSD5) || defined(FREEBSD6) || defined(FREEBSD7) \
     || defined(FREEBSD8) || defined(FREEBSD9) || defined(FREEBSD10) \
+    || defined(FREEBSD11) \
     || defined(BSDI2) || defined(BSDI3) || defined(BSDI4) \
     || defined(OPENBSD2) || defined(OPENBSD3) || defined(OPENBSD4) \

2016/12/22(木)[Windows] ネットワークドライブのフォントファイルは何をしてもエラー

以前はこんなことは無かったような。。。Windows10 Ver 1601[2016/08/02 提供開始] になってからでしょうか。(Ver 1507 だった頃は未確認)

該当のフォントファイルを右クリック → プレビュー(R) と操作すると、フォントの参照が出来るのですが、ネットワークドライブ上ではこうなります:
20161222_1.png

これをPCローカルのハードディスク上にコピーして操作すると、こんな感じ:
20161222_2.png

しばし、嵌まること5分。。バグなのか、仕様なのか、、不明です・・・

2016/12/10(土)perl 5.24 にしたら ports の XPDFJ は動作しない

提起の通りです。
サーバのエラーログに
Can't use 'defined(%hash)' (Maybe you should just omit the defined()?) at /usr/local/lib/perl5/site_perl/XPDFJ.pm line 757.
と文句を垂れますので、XPDFJ.pm の 757行目を以下の要領で直接修正します。

《変更前》
    if( defined %{$tab->{$name}} && $name !~ /::$/ ) {
《変更後》
    if ((%{$tab->{$name}})  && ($name !~ /::$/ )) {
こうすると、perl 5.24 でも動作するようです。
筆者がメンテナンスを請け負っている企業のサーバでは動作確認できました。

原因は、perl 5.24 にて defined(%hash) の構文を致命的エラーとするように変更されたためです。何故こうするのかはよく判りませんが。。。

2016/11/27(日)HTMLエディタは、現場では使い物にならない。

ここで言う「HTML エディタ」というのは、ワープロソフトのようなオフラインで使うものを指し、ブログを書くためのエディタは除いています。

具体的なソフトウェア名を出すのは避けますが、
当方の周囲でWebデザイナーと呼ばれる方々で、この類のソフトウェアを多用している人は「皆無」です。

理由は聞かなくても判ります。
「余計なものが沢山入り、痒い所に手が届かない」
といったところでしょう。これ以外にも多くの理由がありますが。

素人が案件のサンプルで持ち込んだHTMLファイルが、こういったHTMLエディタで作成したもので、そのままでは全く使えない状態だったりするので、全面的に作り直しすることもありますね。

先月、サイト構築を手伝う案件があって、担当者は、HTMLエディタソフトで作業を始めようとしていたのですが、当方はそれを止めさせました。
そのまま黙認していたら、担当者本人が大変なことになっていたからです。

有無を問わず、テキストエディタで一から作成するのがいいのです。
HTML は全く複雑な代物ではありませんし、そのほうが肝心要の基礎を習得できますのでね。

2016/11/26(土)jQuery は有害なのか・・・ 有害というより老害です。

やっと H8/3069F 関係のシステム開発が一段落したので、うんちく記事などを。。
何気に jQuery の評価なんぞ調べていたら、こんな記事に出くわしました。
jQueryは有害なのか

8割~9割同意できる内容ですね。

jQuery って何? 的な人に一言で言及するならば、
「JavaScript を使いやすく(することを目指す)したもの」
といったところでしょうか。やや専門的に言えば「フレームワーク」といった感じ。
あぁ、筆者を困らせる存在だ。。何故かというと「却って判りずらい」から。
jQuery も記述方法にクセがあり、判りにくさは一般のフレームワーク並み。

昨今では、何も考えずにこの jQuery を使ったWebアプリケーションが広く出回っているのです。近未来を考えればあまり良くない傾向。

昨今では JavaScript 自体の機能や性能が向上・ブラウザ間で統一されてきている(IE を除く) ので、使う必要性そのものが無くなってきている訳です。

Web開発技術者ならば、jQuery のようなものは使うべきではありません。
将来の自分が要らぬ苦労を強いられるだけ。

こんなものに頼ると、技術の基礎が身につかなくなります。
そもそも、スキル的にそこそこ低くても高機能なものを実現するのが目的ですから、当然の帰結です。

当方では、端からこんなものは使わないようにしています。
ひとたびトラブルに見舞われると、肝心な部分がブラックボックス化されているため、トラブル内容にもよるが何が問題なのか解らなくなる。
そんなエセ職人が大量生産されても現場にしわ寄せ行くだけなんですよね。。
そういうことまで考えてプロジェクトを組ませないような中途半端なスキルが担っている上流工程や業界自体の認識も大きな問題ですけどね。

例えば、IE を使わせないようにして、まともな機能のあるWebブラウザを使うように顧客を指導していく。こっちのほうがメンテナンスのコストダウンが出来て、技術職人的には楽です。

jQuery が自然淘汰できれば何も言うことは無いですがね。

2016/09/09(金)H8/3069F ROMライタの制作

2016/08/10 の記事 で紹介した道具を、特注で製作しなければならないことになり(というか当初の作業工程策定で漏れていた)、急遽現在のファームウェア制作を数日中断して作ることにしました。

その部品たちの一部が以下:
20160910.JPG

来週半ば目途に完成させないとならないという、半ば突貫工程です。。
と言っても、プリント基板さえ作ってしまえば、1~2日程度で出来そうな規模ですが。。

2016/08/16(火)BCD ⇔ 符号なしバイナリ変換

システム制御系、特にファームウェア制作ではよく出てくるにも関わらず、
毎回調べ直すという非効率なアホ作業をしでかしているので、自分メモ的にまとめてみようと・・orz

BCD コードというのは Binary Coded Decimal の頭文字で、日本語の古い文献などには「二進化十進数」とも表記されます。
数字を表示する機器などには未だ広く使われているようです。
BCDコードとバイナリコードの相違が理解できない方は、まずそれを他所で理解してください。理解できていないと、以下の記事の内容は全く理解できないでしょう。

今般の制作ボードの中にBCDコードを要求するLSIがあり、BCDコードとバイナリコードの相互変換が必要です。必要なのは 0~99の値なので、それに特化しています。

難しいのは、バイナリ → BCD変換のほうで、実に力ずくのアルゴリズムから、難解なものまでいろいろな方法があるのですが、応用が利くのは以下の、
『BCD部分の各桁について、「値が5以上ならば3を加算する」』
を基本にする手法。
以下を参考にしています:
http://www.geocities.jp/leitz_house/electronics/pic/bcd_01.htm
http://minkara.carview.co.jp/userid/526128/blog/24236882/
〔覚え書き:2進数 ⇒ BCD変換について…〕

オリジナルは、どうやらキャッシュしか残っていないようで、いつ消えるか判りません。
こんな方法で本当に出来るのか? という疑問を持たれる方が大半と察しますが、数学的見地でも本当に出来るのですから、科学の基礎というのは奥が深いです。
実際にC言語にて作ったものが以下(ビックエンディアン環境にて動作確認済):
/**  cnv_byte_to_bcd 1バイトバイナリデータを1バイトBCDに変換 */
unsigned char cnv_byte_to_bcd(unsigned char bval) {
  union {
    struct {
      unsigned char bcd ;          // 変換後の値
      unsigned char hex ;          // 変換対象バイナリ
    } conv ;
    unsigned short  buf ;
  } convbcd ;

  unsigned char bitcnt ;

  if (bval >= 100) return (bval) ; // バイナリ値 100 以上は BCD に変換不可のため、そのままリターン。
  convbcd.buf = 0 ;                // 使用領域は予めゼロクリアしておく。
  convbcd.conv.hex = bval ;        // 変換対象のバイナリ値を置数。

  for (bitcnt = 0 ; bitcnt < 8 ; bitcnt++) {
    if (((convbcd.conv.bcd & 0x0f) + 0x03) >= 0x08) convbcd.conv.bcd += 0x03 ;
    if (((convbcd.conv.bcd & 0xf0) + 0x30) >= 0x80) convbcd.conv.bcd += 0x30 ;
    convbcd.buf <<= 1 ;
  }
  return convbcd.conv.bcd ;
}
肝になる部分は、union 共用体の部分で、メンバ bcd と メンバ hex の順番は重要です。
対象ターゲットCPUは、ビックエンディアンで、その環境で動作確認しています。
インテルやAMDのCPUだと、殆どがリトルエンディアンなので、メンバ bcd と メンバ hex の定義を逆にしないと駄目かもしれません。

一方で、BCD → バイナリ変換は簡単です。4ビットごとに区切り、上位4ビットの値を×10し、下位4ビットをそのまま加算すると変換完了です。
/**  cnv_bcd_to_byte 1バイトBCDデータを1バイトバイナリに変換 */
unsigned char cnv_bcd_to_byte(unsigned char bval) {

  unsigned char convbin ;

  convbin = ((bval & 0xf0) >> 4) * 10 + (bval & 0x0f) ;
  return convbin ;
}
OK キャンセル 確認 その他