2013/06/19

縦書きのブログをリキッドデザインにしてみる

縦書きのブログ「アポロ漫録」はもともと横幅が 1000 ピクセルくらいまでは画面の幅に合わせて伸縮する半リキッド(可変)デザインだったのですが、その設定を少し変えて、横幅がどんなに広くなっても常に 100% の横幅で表示するようにしてみました。

縦書きの場合は画面が横に広くなればなるほど読みやすくなりますからね。高解像度のワイドスクリーンで表示するようなときには縦書きのメリットが最大限に生かされると思います。
ただ、IE 以外のブラウザでは横書きで表示されるので、その場合には横幅が広すぎると読みづらくなってしまいます。

そこで、IE 以外のブラウザの場合には今まで通り 1000 ピクセルくらいまでを上限としました。

ついでに IE 以外のブラウザについては記事の高さを可変に変更しました。
(というか、本当はこちらの対応のついでに IE の横幅を可変にしてみたんですけどね。)

今まではブラウザの種類に関係なく全て高さを固定して、はみ出た部分はスクロールして読むようになっていました。

これはこれで便利だとは思っていたのですが、アンドロイドのスマートフォンのブラウザで見たときにスクロールできなくて記事の全文が表示できなかったりしたので、このような問題の対処もかねて、IE 以外のブラウザの表示を修正しました。

最新の CSS3 では縦書きの対応が進んでいて、Safari や Chrome でも縦書きができるということで話題になっていたりもしますが、現段階では実装が中途半端で使い物にならないので、アポロ漫録での採用は見送っています。

iPhone のブラウザ iOS5 の Safari でも縦書きに対応したというような記事を見かけたような気がしますが、実用レベルに達したものとなっているのでしょうか?

Chrome の縦書き対応については割といいところまで来ているのですが、長文の記事が画面からはみ出て横にスクロールしなければ読めないようなときに、IE ならマウスホイールで普通にスクロールできるのですが、Chrome の場合はスクロールバーをドラッグしたりしないとスクロールできないというのが致命的でした。

Firefox においては縦書きに手をつける気配すらありません。将来的に WebKit に切り替わる Opera は自動的に縦書き対応となることを期待してもいいのかな?

最近の EPUB などの電子書籍の流行のせいもあってか、WebKit 系のウェブブラウザで今さらになってやっと縦書きができるようになったことが注目されているようですが、IE ではもう何年も前から実用的な縦書きの実装が完了していたことの方がよっぽどすごいと思いますけどね。

縦書きに関する情報も、今のところほとんどが「縦書きにできます」という解説記事ばかりで、実際にニュースやブログで標準的なスタイルとして採用しているサイトは全く見かけません。

ちょっと前は「ウェブで縦書きなんてありえない」「縦書きは読みづらいから必要ない」などという意見が多かったと思いますが、今では「どうしても縦書きで読みたい」というような人も増えてきていると思います。

日本人は本当は縦書きが好きなんだってこともそろそろ気づいてきたと思うので、縦書きのサイトもどんどん増えてくれるといいんですけどね。

2013/06/17

PDF の文字化けを解消する

Android の PDF ビューアに SideBooks というアプリがあるのですが、たまに文字化けが発生するので困っていました。同じ PDF を開いても Adobe Reader などの他のビューアでは文字化けすることがないので SideBooks 特有の不具合のようでした。

開発元に不具合の報告をしたところ、
問題の原因を調査したところ、SideBooksに使用している他社製のモジュール(PDFレンダリングエンジン)が原因であることが判明し、弊社単独での対応が不可能なことがわかりました。

この問題は、モジュールの開発元に障害案件として報告し、対応を待つことにいたします。開発元が海外の企業であることもあり、いつ修正されるかの確約ができないこと、お詫び申し上げます。
との回答をいただきました。

とりあえず、SideBooks については当面の改善は見込めないということで、他の改善策を考えなければなりませんでした。

他に使いやすいビューアはないかと思って探してみたのですが、どれもいまいちな感じだったので、ビューア探しはあきらめて PDF ファイル自体を修正することにしました。

今まで PDF 作成には Apache OpenOffice の PDF エクスポート機能を使っていました。

OpenOffice Writer で作成しているのですが、文字化けする部分だけを修正しても他の部分が文字化けするようになったりして、まるでもぐらたたきのようでした。

文書全体のフォントの指定を変えても直りません。

OpenOffice のエクスポートではだめなのかと思って、他の PDF 作成ソフトを試してみることにしました。

CubePDF というフリーソフトをインストールしてみました。

文書を印刷するときにプリンタドライバーとして CubePDF を使うことで PDF として出力することができます。

CubePDF にも多少癖があるようで、一部のフォントの埋め込みに失敗することがあるので、問題のないフォントを選ぶ必要があります。

どうにか出来上がった PDF は OpenOffice でエクスポートしたものに比べるとファイルサイズが3倍くらいに膨れ上がっていたのですが、画像の解像度指定を 600 dpi から 96 dpi に変えるとほぼ同じくらいになりました。

SideBooks で閲覧してみると文字化けは完全に解消されていたようでした。

ただ、画像の品質については OpenOffice の PDF に比べるとかなり落ちていました。ファイルサイズをとるか画質をとるかということになりますが、画質については妥協すべきところかもしれません。

一つだけ CubePDF の利点として気づいたことがありました。

今まで OpenOffice でエクスポートした縦書き文章の PDF はテキストを一文字ずつ分断して無理やり縦組みしたような構造だったようなのですが、そのせいで PDF をテキスト化したときに問題があったのです。たとえば、SlideShare にアップロードするとこんな感じになってしまうわけです。
  • 霊性の評価について(SlideShare)
    (スライド下部に文書内から解析されたテキストが表示されていますが……)
CubePDF で作成した場合には文章が一行ごとに改行されているので、テキスト化しても普通に読める文書になっていました。つまり、日本語の体裁を保っているということですね。たぶん、読み上げソフトなんかでは都合がいいんじゃないかな? ウェブ上で公開したときにはキーワードで検索されやすくなるだろうし。

OpenOffice からのエクスポートはとても使いやすかったのですが、今後は CubePDF を使っていこうかと思います。

外国製のソフトで日本語を扱うのは何かと問題が多いですね。

ニッポンの技術者さんたち、がんばってください。

この記事をサンプルとして CubePDF で作成した PDF を SlideShare にアップロードしてみました。
スライド下部に表示されているテキストもまともに読める状態になっています。

2013/06/14

HTML5 で UTF-8 を使用する場合の注意事項

今までホームページの文字コードは主に Shift_JIS を使ってきたのですが、HTML5 への切り替えに当たり、推奨されている UTF-8 にした方がいいのか迷っていました。

しかし、古いコンピューターで表示したときに文字化けの可能性があることを考慮すると、今まで通り Shift_JIS のままの方が無難ではないかと思い、とりあえず、トップページは Shift_JIS のままにしておきました。

先に HTML5 で作成した Tarot FILES #100 以降の記事は実験的な試みもあったので当初から UTF-8 を使用していました。いくつかのブラウザやスマートフォンでの表示も確認しましたが、特に問題はないようでした。

ところが、一つだけ問題があることに気づいてしまいました。

HTML5 では文字コードの指定に、ヘッダーのメタタグで以下のように指定することができます。
<meta charset="UTF-8">

この書式を認識できないブラウザが存在し、その場合にはデフォルトの文字コードで表示されることになります。たいていは Shift_JIS としてエンコードを試みることになるかと思います。その場合にはかなりの頻度で文字化けすることになるでしょう。
(サーバーの設定で対処済みの場合もあります。)

実際に、Lynx というテキストブラウザで確認してみたところ、文字化けしてしまいました。
そこで、文字コードの指定を旧来の
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
に戻してみたところ、Lynx でも文字化けせずに表示することができました。

まだまだ文字化けの可能性が残されている以上は、旧来の書式を使い続けるのが無難といえそうです。

ちなみに、旧来の書式であっても HTML5 の仕様としては問題ないはずです。

ドキュメントタイプが最新の HTML5 であっても、文字コードさえ適切に認識できればたいていのブラウザで問題なく表示は可能です。先の Lynx でも、IE4 でも Netscape Communicator 4.7 でも問題はありません。むしろ、記述が単純化された分、認識率が高まったといってもいいくらいです。

ちょっと気になるのは、推奨されている UTF-8 以外の文字コードを使用した場合に何か問題がおきるかどうかということですね。Shift_JIS でも問題がないのなら、無理をして全てのページを UTF-8 に書き換える必要もないと思うのですが。

詳しい人がいたら教えてください。

2013/06/13

オンラインステータスを表示する Skype ボタン

(追記: 2015年6月12日)以下の方法は完全に使えなくなってしまったので、新たにSkype のオンラインステータスをウェブサイトに表示する方法という記事で解決方法を書きました。


Skype のオンラインステータスをウェブサイトに表示するボタンがあるのですが、現在はサポート対象外となっていて、公式サイトでの入手はできなくなっています。
ログイン状態
この Skype ボタンは現在でも使用可能で、必要ならば以下のようなタグを自分のサイトに埋め込みます。
<script type="text/javascript" src="http://download.skype.com/share/skypebuttons/js/skypeCheck.js"></script>
<a href="skype:YourSkypeName?chat"><img src="http://mystatus.skype.com/smallclassic/YourSkypeName" style="border: none;" width="114" height="20" alt="ログイン状態"></a>
使用する場合は "YourSkypeName" の部分を自分の Skype 名に書き換えてください。

最近までずっとこの方法で使ってきたのですが、呼び出す JavaScript が重かったりするのが気になっていたので、上記の JavaScript 部分は削除してしまいました。JavaScript がなくても問題なく使えるようでした。

オンラインステータスはほぼ正確に表示されていましたが、ボタンの画像はブラウザのキャッシュから呼び出されてしまうので、2 回目以降の表示では正確なオンラインステータスが表示されないという問題が残されていました。

ブラウザの更新ボタンを押せばオンラインステータスの画像も最新のものに入れ替わるのですが、それを訪問者に強制するわけにもいかないので、できればサイト側で何とか対処したいところです。

そこで、対応策をあれこれと調べてみた結果、埋め込むタグを以下のようにすることで解決できました。
<a href="skype:YourSkypeName?chat"><img src="http://mystatus.skype.com/smallclassic/YourSkypeName" style="border: none;" width="114" height="20" alt="ログイン状態" id="mystatus"></a>
<script type="text/javascript">

var nowdate = new Date();
var stamp = nowdate.getTime();
document.getElementById('mystatus').src="http://mystatus.skype.com/smallclassic/Apollo-Tarot-Divination?"+stamp;
</script>
JavaScript で後から画像を入れ替えているのですが、その際に画像の URL を変更しています。

オンラインステータスは正確に表示されるようになりましたが、この機能はすでにサポート対象外となっているので、いつかは完全に使えなくなる日が来てしまうかもしれません。

とりあえず、使えるうちは使わせてもらいます。

こんなに便利な機能なのに、何でサポートが終了しちゃったんでしょうね?

現在 Skype で公式に配布されているボタンはオンラインステータスの表示はできないシンプルなものだけとなっています。

2013/06/12

トップページも HTML5 に書き換えてみました

先日は Tarot FILES を試しに HTML5 形式にしてみた(FILES HTML5)ところ、なかなかいい感じだったので、ホームページのトップページも書き換えてみることにしました。

トップページははるか昔に Microsoft の Frontpage Express とかいう HTML エディターで作成したファイルをちょこちょことテキストエディターで修正しつつ使い続けてきたので、ソースはつぎはぎだらけでぼろぼろでした。

一応、古くは Netscape 4.x や IE4.0、テキストブラウザの Lynx、携帯(ガラケー)、ドリームキャストでの閲覧まで配慮した作りになっていて、そういった古いブラウザ向けのタグやらスタイルシートやらを取り除くことができずにいたのです。

それでもまあ、最近は IE8 以上のブラウザを想定していればほぼ問題はなさそうだったので、HTML5 対応ついでにソースの大改修を行うことにしました。

ページのデザインはほとんどがテーブルレイアウトで、文字修飾にはフォントタグを使って大きさや色を指定していた始末で、それらを排除してほぼ全てを外部スタイルシートで管理するようにしました。

今までテーブルレイアウトでデザインしていたものは DIV 要素を用いてブロックレイアウトで代用し、ほぼ完全に再現することができました。ぱっと見は、以前とどこが変わっているのかわからないくらいですが、中身は骨組みから何から全てごっそりと書き換えてあります。

ページ内の構造そのものが以前とはまったく異なるものとなっています。

一応、記念に修正直前の HTML ファイルも保存しておきました。修正が完了したファイルも一緒に保存しておいたので、興味のある方は以下の場所からダウンロードしてソースを覗いてみたりしてください。

以前のページの一部を撮影したスナップショットはこんな感じ

2013/06/06

FILES HTML5

 久々に占いの実例として Tarot FILES #100 をアップしたのですが、このファイルの作成に関してはいろいろと問題があってかなり手間取ってしまいました。占いの内容には何も問題はないのですが、文書管理上のちょっとしたことです。

 まず、番号の件。もともと二桁以内のファイル数を想定して番号付けをしてきたのですが、100を超えて三桁になると何かと面倒なことになってきます。ファイル名でソートしたりするときにうまく並んでくれなかったり、見た目がいまいちだったりするので気持ち的にすっきりしません。ファイル管理の利便性の問題もありますが、一つのディレクトリにあまりにもたくさんのファイルを詰め込みすぎるのも良くないかもしれません。

 そこで、100番に到達したのを機に、新たにディレクトリを作ることにしました。100番台は「1」とし、さらにその中に下二桁の数字のディレクトリを作ります。100番なら /FILES/1/00/ となります。一つのファイル(記事)に一つずつのディレクトリを作ることになります。200番台ならディレクトリは「2」となり、想定では900番台まで対応可となります。1000番以上のことは考えてません。

 ファイル単位でディレクトリでまとめたのは、今回のファイルが複数の文書で構成されているのもありますが、一つの事例を一つのフォルダで管理するという考え方は本来の文書管理のあり方でもあると思うので、合理的になったといってもいいかもしれません。

 次に、文書形式の件。これまでは HTML 4.01 Transitional でした。結論から言うと、今回から HTML5 に切り替えることにしました。

 最近はスマートフォン向けにサイトを少しずつ修正しているのですが、その過程で文書形式が HTML 4.01 Transitional だと少し面倒なことがありました。実のところ、問題はスマートフォン対応にあるというよりも、パソコン用の Internet Explorer での表示の問題です。パソコンでもスマートフォンでも問題なく閲覧できるようなページを作ってみても、IE での表示に違和感がでてしまったりするのです。これは、IE が互換モードで表示しているためで、いろんな部分で寸法のずれなどが生じてしまうのです。

 そこで、IE でも標準モードで表示できるように、XHTML 1.0 Transitional に切り替えることも考えてみたのですが、どうせなら最新の HTML5 にしてみようということになったわけです。

 HTML5 はまだ正式に勧告されているわけではないようですが、ほぼ規格も定まり、多くのブラウザで対応が進んでいるようです。すでに大手サイトでも HTML5 を採用しているところは増えているようです。これからの主流となるのは間違いなさそうです。旧バージョンの IE でどの程度対応できるのかは不明です。

 書き方は HTML 4.01 とほとんど変わっていないので移行は簡単です。ただ、ちょっとしたルールの違いがあったりするので、その辺をきちんと調べているうちに時間がかかってしまいました。

 正式勧告前の規格なので、本来なら「アポラボ」で検証を重ねてから本サイトでの採用とすべきところなのですが、今回は少し時代を先取りして対応を早めました。

 Tarot FILES のように文章がメインのサイトでは HTML5 にするメリットはほとんどないと思いますが、時代の流れにあわせて文書形式を変化させてゆくのも悪くないのではないでしょうか。

 思えば十数年前、このコンテンツを公開した当初は Microsoft Word 95 で文書を作成し、そのまま HTML 書き出し機能か何かで出力したファイルをウェブサイトにアップロードしていたのでした。その当時は文書形式が何かなんてことは考えもしませんでしたが、その後は時代の流れにあわせて何度も修正を重ねつつ、100回目の投稿を迎えるにあたって HTML5 という新規格の採用に至ったわけです。

 昔のファイルはほとんど修正してしまったので、今はその面影はまったく残っていませんが、時代を反映する FILES というコンテンツでもあるので、今後は後から手を加えることなく、公開当初の形式のまま残しておくのも面白いかもしれませんね。