Webにおけるフォントとタイポグラフィー|Design Report

Webにおけるフォントとタイポグラフィ

刷物とWebデザインの違いは数あれど、その中でも特に大きな違いともいえるのがこの「文字」に対するものだろうと思います。 印刷物のデザインにおいて「文字」に関するアレコレは本当に沢山あり、多岐に渡っていますね。 しかしWebではその2割も使えない。 これを聞くとほとんどのデザイナーは「え!?」となることでしょう。 冗談などではなく、残念なことに現状のWebの仕組みとタイポグラフィはとにかく相性が悪い。 前回の項目でも述べた「使用できるフォントの制約」もそうですが、もう一つ大きな、かつ印刷物を扱うデザイナーが「愕然とする事実」をもう一つ突き付けよう。 Webのテキストには事実上「文字組」ができない。

Webにおける「文字」の在り方と扱いについて

この出だしに食いついてくれた人には素直に嬉しく思う。きっと僕と同じく文字やタイポグラフィが好きな人だと思う。 そんなみなさんにこそ今回の内容はお届けしたい。

現在のWebにおける「文字」の在り方と扱いは
「まだ、情報伝達の手段」でしかない。

それを用いた高度な表現というものには、まだシステムが追いついていないというところ。

顕著に分かるのが、Webのテキストに関しては、一文を「画一的なカーニング」を施すプロパティはあるものの、印刷物等のテキストに施すような「文字組」―各文字毎の大きさ・字間の微調整を行うのに適したプロパティが存在しない。
また、システム上欧文なので、テキストは「横書き」のみしか設定が無く、縦書きの設定は(自前で作らない限り)無い。更には「一文字単位のスタイル指定」にも向かない。
このように、文字まわりに関しては整備されていない。・・というか意識されていない印象。

文字組みをWebで表現するのは無理がある

Webのテキストに対して「文字組」を行おうとするとどのようになるか・・というところを再現してみよう。

Webにおいてはマークアップされた「要素」に対して、cssなどスタイルシートで「スタイル(形状)を指定」する、というかたちでグラフィックをHtmlへ反映させていきます。

・・というところを踏まえて
例えば、「美しい文字組」という一文を文字組してみようとする。 するとコーディングはこうなる。

[Html]
<p><span class="a">美</span><span class="b">し</span><span class="c">い</span><span class="d">文</span><span class="e">字</span><span class="f">組</span></p>
[Css]
.a{ letter-spacing:0px; font-size:1.07em; }
.b{ letter-spacing:2px; font-size:0.99em; }
.c{ letter-spacing:2px; }
.d{ letter-spacing:3px; font-size:0.98em; }
.e{ letter-spacing:2px; }
.f{ letter-spacing:1px; font-size:1.02em; }

テキストの文字間を変更するプロパティ「letter-spacing」と、
テキストのサイズを変更するプロパティ「font-size」を使って再現しています。
※値は適当です(普通こんなことはしないので・・)

はっきり言ってあり得ない記述量が必要になるばかりか、コードがぐちゃぐちゃで何が何か・・。
たった6文字ですらこんな状態です。文字量が増えるともう・・・(合掌)

また、例えこんな感じで無理矢理調整したとしても最小単位が1px。
よほど大きな文字で行わない限り「微調整」は不可。
つまり、この文章中の文字くらいの大きさでは、調整などできたものではない。 はっきりいってまったく現実的ではない。

タイポグラフィも難しい

加えて言うと「長体」と「平体」も設定できない。
css3で新しく追加された「transform」プロパティを使えば、無理矢理できなくもないが、 css3をサポートしていない古いブラウザを使っていると適用されない。(10未満のIEとかIEとかIEとか・・)

ちょっと試しにやってみよう。

長体

平体

これが tateyokohiritsu

このように見えていればご利用中のブラウザはcss3に対応しています。
「これならまぁいいじゃん?」なんて思うかもしれませんが、あくまで「無理矢理」それっぽく設定しただけです。

「transform」プロパティを使って、縦(横)に拡大しているのですが、 注意しなければならないのが純粋にテキストを拡大している訳ではないということです。

このように、ちょっとした文字での表現がなかなか面倒な設定が必要になってしまいます。

じゃあ結局のところ、美しく組まれた文字やタイポグラフィをWeb上に反映させるには結局「画像化」するしかない? という考えに至るでしょう。

極論すれば、現状は「ほぼ」そうです。

じゃあ文字を美しく見せたり、タイポグラフィをWeb上に反映させたければ全部画像化してしまえばいいじゃないか? と考えるかもしれない。しかし、それは「おすすめできない」ではなく「やめたほうがいい」。

But! 全部「画像化」はバッド

少し凝りたい部分をピックアップして、ならまだアリですが、ページ全部なり大半の文字を画像化してしまうのはかなり問題があります。

それはテキストデータと画像データが根本的に違うものであるためです。

  • Htmlは原則としてあくまで文章
  • 画像のデータサイズはテキストデータの比ではない
  • 読み込むデータ数が多ければ、ページ表示も比例して遅くなる

『Htmlは原則としてあくまでも「文章」』です

Webページを読むのは人間だけではありません。コンピュータも読んでいることを忘れてはいけません。

画像は僕達から見てどれだけ違うものであっても、コンピュータからすれば「画像というカテゴリーのデータ」つまり「同じ情報」として扱われます。 その内容は情報として正確に認識されません。
画像は文章としては認識されまないのです。

※「検索」に影響します。 ページが画像主体になっている場合 ページの中身は「画像」という同一の情報が並んでいるという認識になるということです。 内容を情報として評価する際、情報がどれだけ充実しているかという観点から考えれば評価は低くなりますね? (同じテキストを繰り返し書いているのと同じこと、と判断されるのですから)

分かりやすく例を上げると

音声読み上げなどをすれば、代替テキスト(alt属性)が設定されていない画像はすべて「そこに何があるか」を認識されない+設定された代替テキストの内容としか判断されない。
しかも、通常のテキストと代替テキストは必ずしも等価値と判断される訳ではありません。

また、<h2><h3>…などといった「見出し要素」に画像を使ったりすると分かるのですが、
例えそこに代替テキストを設定していてもデバッグでは「No title」として結果が返ってきます。

※現在では画像のalt属性の値(文字列)をほぼ正確に認識するようになっている模様です。

「テキスト要素」でなくては情報として正確に認識されないのです。

実は「flash」も「画像」と同じ扱い。
フルflashでつくられたサイトはそこにどれだけの内容が凝縮されていても、コンピュータには「ここに一つのflashというデータがある」としか認識されません。 何ページあろうと、どれだけの情報量でも「たった一つのデータ」の扱いです。 こういうところからも「脱flash」の動きの意味が分かるでしょう。
※一部、flashの内容情報まで読み取れる高性能なクローラーもある。
テキストまで画像化したページというのはこのフルflashサイトをつくるのと同じようなものです。「旧時代的」「時代に逆行している」ようなものではないかと考えます。

余談になりますが、テキストばかりのWebサイトは読むに堪えないが、Blogならテキストベースであっても感覚的に大丈夫、という人も結構多い。その為、Blogはテキストの比重が非常に高いものも多く見られ、コンピュータからすればBlogのほうが「情報価値が高い」と判定されたりもします。 (Blogの検索結果が高くなる一因と言えます)

画像のデータサイズはテキストのデータの数十倍~数千倍にもなります

テキストデータは大量に書き込んであったとしてもせいぜい数キロバイト程度です。 しかし、画像は数百キロバイト~メガバイトになることもザラにあります。
ネット回線の速度にもよりますが、データ総容量が多くなりすぎるとページが表示されるまでに異様に時間がかかったり、画像そのものが表示されなかったりなど不具合を引き起こすため、必要最小限にしておくべきです。

読み込むデータ数が多ければ、ページ表示も比例して遅くなる

Webサイトやページには多数のデータを読み込ませて一つのページとして表示させます。
その際、デバイスの性能や種類によって、一度に読み込めるデータ数が限られています。場合によっては20個ほどのデータまでしか一度に読み込めない(=その20個が読み込み終わるまで次のデータが読み込まれない、が全データ読み込み完了まで繰り返される)ことになり、ページ表示が非常に遅くなる原因になります。

みなさんもページにアクセスしてから表示されるまでが非常に遅いページを見かけたことがあると思いますが、そのうちのいくつかはこの「データ数」が多すぎるものであるケースです。

ちなみに、モバイルデバイスでは基本的にPCに比べて一度に読み込めるデータ数は少なくなるため、画像が多いとなかなかページを表示してくれなかったりするので注意が必要です。

画像化する際の「お作法」

だからといって「画像化」しないほうがいい、と言う訳ではありません。
あくまでも、「何でもかんでも画像化すればいい、ではない」ということです。

前述の注意点を頭に入れて、ここならば画像を使うべき/使わないべきを判断できるようにしたうえで 表現の方法として「画像」が適切であればおおいに活用すべきと考えます。

詳しくは次回に!

Comments

Add a Comment

メールアドレスが公開されることはありません。

認証コード * Time limit is exhausted. Please reload CAPTCHA.

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください