20131101.html rend

/ 最近 .rdf 追記 編集 設定 本棚
grep
翌⽇へ 前⽇へ
脳log[2013-11-01] Firefoxが句点を⾏頭に送って
しまうのがあまりに⽬障りでもう耐えられないので〜
正規表現(Rubyに劣るECMAScript仕様)〜禁則処理
(IE完璧。Firefox/Safariに指導)〜両端揃え(IE完
璧。Firefox満⾜。Safariを補完)〜画像とCSSのDPI
〜字詰め
2013年11⽉01⽇ (⾦)
「Kindleストアから⼤⼿アダルトコミックが⼤量削除 - 電パ
ブログ」■ちんちんかもかもって辞書に載ってる単語だったり
する。知らねー。■紙の本でも独善によって⼀部をなき物にす
るアマゾンだけど Kindleではそれよりさらに厳しい基準での
ぞんでいると。TSUTAYA と⼀緒。消えろ(※強勢はなし。付
けると願い事みたいになってしまう。平板に、興味のないゴミ
カスに退場を許可するみたいに発⾳する)。■ところで、
Reader Storeで も Kinoppy で も 最 初 か ら 取 り 扱 い が な か っ
たりするわけですね。終わってるやん。(直販してる)フランス
書院が正解。ISBNのついた本を100% カバーすることを⽬標
に掲げた電書書店はないのか？■こんなんのまま紙が廃れたら
悲劇だなあ。分を弁えへん私企業に所有させていいもんやない
で。こんなところに利益をくれてやるのは同時に⼈質を差し出
す よ う な も の 。 あ と で 後 悔 す る こ と に な る 。 ■ ■ ■ @201311-18 「 あ と で 後 悔 」 が ⼆ 重 表 現 の 例 と し て 挙 げ ら れ て い
て、そうかと思って書き直そうとしたがどうもしっくりしな
い。これは、未来のある時点において後悔することを動詞(の
付属部)だけでなく副詞も使って⽰しているのであって、つま
り、後悔の対象が必ずその時点における過去の事象であること
と、後悔するのがいつであるかは別物なので⼆重表現にはなら
ないのではないだろうか。■「今後悔してる」に対する「あと
で後悔する(ことになる)」は不⾃然じゃないと思う。
最終更新: 2015-03-22T12:56+0900✍
♪
[tDiary][Firefox][正規表現][javascript] Firefoxが
句点を⾏頭に送ってしまうのがあまりに⽬障りでもう耐え
られないので〜正規表現(Rubyに劣るECMAScript仕様)
〜禁則処理(IE完璧。Firefox/Safariに指導)〜両端揃え
(IE完璧。Firefox満⾜* 。Safariを補完)〜画像とCSSの
DPI〜字詰め
tDiaryのプラグインとして今回追加したのは auto_nobrの
部分だけ。
add_title_proc {|date, title|
auto_nobr = lambda{|src|
return
src.gsub(/[^{}\[\]()*#"!'`=:|]
[、。」』!?！？)]+|[「『(]+[^{}\[\]()*#"!'`=:|]/u){
%{{{'<nobr>'}}#{$&}{{'</nobr>'}}} }
}
inline_or_nil = lambda{|src|
lines = src.split(/\r?\n/)
return nil if 1 < lines.length
html = WikiSection.new(auto_nobr.call lines.f
irst).body_to_html
return html.gsub!(/\A\s*<p>/, '') && html.gsu
b!(/<\/p>\s*\z/, '')
}
if title.index('<')
title.sub(/<span class="title">([^<>]+)<\/spa
n>/){|_0|
html = inline_or_nil.call(CGI.unescapeHTML
$1)
html ? %/<span class="title">#{html}<\/spa
n>/ : _0
}
else
inline_or_nil.call(CGI.unescapeHTML title) or
title
end rescue title
}
⼀応。Firefoxの挙動は word-break: break-allが指定さ
れた結果である。であるが、だからといって⾏頭の句点、句点
だけの⾏(ぽつーん)はありえないだろうと思うのです。
やっつけ仕様
1.標準に存在しない<nobr>タグの使⽤
か と い っ て 空 ⽩ が 関 係 す る わ け で は な い か ら whitespace:nowrap とか使えないし、使えたとして FONTタグを
<span style="font:〜"></span>に置き換えるようなことに
意味を⾒いだせたのはそれが 2000年頃のことだったからだ
し、段落全体を⼀⾏で表⽰したいわけでもないので Pタグに対
してルールを追加することもできず、代替案が⾒つからない。
2.テキトーなテキスト置換
HikiDocで意味を持ってそうな記号を避けつつ句点＋１⽂字
を<nobr>で囲ってる。整形式でないというエラーが出るパタ
ーンがまだ残ってるかもしれない。footnoteプラグインとかわ
りと⽂章を渡すから危険だ。
3.対象がタイトル欄だけ
全体を対象にするなら JavaScriptでやる。でもテキストを
対象にしつつタグをインジェクトする⽅法がわからなかった。
マッチしたテキストノードをドキュメントフラグメント(テ
キスト+NOBRエレメント+テキスト)と置き換えればよかった
のか？具体的⽅法が⾒えたところだが、レイアウトが変わって
しまう変更を読み込み完了間際にスクリプトで⾏うというのは
やっぱりよくないかも。フラグメント付きの URLでアクセス
したときターゲットが画⾯外に逃げてしまいかねない。
4.表⽰を確認したのは Firefox(23.0.1)と IE9だけ
Opera は 独 ⾃ の レ ン ダ リ ン グ エ ン ジ ン を 放 棄 し た し 、
Windows 版 Safari は ア ッ プ デ ー ト が ⽌ ま っ た し 、 Google
Chromeはインストール場所がキモいから(今でもそうかは知
らない。当然やめるだろうと予想するほどに、そして⼀瞬でア
ンインストールしてしまうほどにキモかったということだ)。
「CSS 3 におけるテキストの⾃動改⾏と禁則処理の定義 builder by ZDNet Japan」
break-all
任意の位置で⾃動改⾏を⾏うが、⽇本語のテキストでは
「line-break:normal」と指定したときと同じようにゆるい
禁則処理を⾏う。
これを期待して待ってたんだけど。
「アポラボログ: Firefox 15 の禁則処理を修正」
この「word-break」というスタイルシートは⽂の改⾏の
仕⽅を指定するもので、もともと Internet Explorer 独⾃
の物だったようなのですが、最近になって Firefox もこれ
を採⽤したらしいのです。そのため、以前の Firefox では
無効化されることを想定してこのスタイルシートが指定さ
れていたと考えられます。
サイト制作者の想定としては IE のみにこのスタイルシー
トを指定したつもりが、意図せず Firefox でも有効化され
てしまい、禁則処理のされない読みづらい記事が発⽣して
しまったということだと思います。おそらく、IE の場合は
このスタイルシートが指定されていても禁則処理には影響
がなかったのではないでしょうか。
先⾏する IEはまとも。後追いの Firefoxはバカ。⽇本⼈の貢
献が⾜りないのか？
「Gecko と Webkit の word-break:break-all; ってこれで
いいの？ « やおよろグッ！」
良くないと思います。
「word-break: break-all; がW3CでOKになってるし｜ぼく
んちのバックステージ」
余談:Googleの検索仕様変更について
1ヶ⽉ほど前から、Google検索の左メニューが無くなっ
ちゃいましたねえ。
スクリプトを無効にしてると今でも出てくるんですよ。畳ま
れたメニューをクリックしなくても⼤体の選択肢が羅列されて
るんですよ。フォールバックが機能してるのをほめる前に、ス
クリプトを使って使いにくくしてることにあきれる。
@2013-11-02 正規表現パターンについて
auto_nobr処理の中の
/[^{}\[\]()*#"!'`=:|][、 。 」 』 !?！ ？ )]+|[「 『 (]+
[^{}\[\]()*#"!'`=:|]/u
というパターンは要するに
HikiDocで特別な意味を持たない１⽂字＋⾏頭禁則⽂字、ま
たは、⾏末禁則⽂字＋HikiDocで特別な意味を持たない１⽂
字
ちょうふく
という意味なんだけど、HikiDocで〜という部分が 重 複 し
てる。パターンの中にパターンを展開する⽅法を持たない
JavaScriptで？この重複をどう取り除けるか？
⽂字列を組み合わせて RegExpのコンストラクタに渡すの
は、⽂字列を Functionコンストラクタに渡すこと(evalと同
じ)や、⽂字列から SQLを組み⽴てるのに似て好きではない。
⼀⾯でわかりにくくなるのを承知で書き直すとこうなる。
/(?=([
「
『
(]+)?([^{}\[\]()*#"!'`=:|])
([、。」』!?！？)]+)?)(?:\1\2|\2\3)/u
前半の先読み部分は次のような意味の１〜３個のキャプチャ
を含む。
(⾏末禁則⽂字)?(HikiDocで〜)(⾏頭禁則⽂字)?
後半の、対象⽂字列と実際にマッチする部分はキャプチャを
参照するだけの単純な⼆択。
(?:\1\2|\2\3)
かっこによるグループ化がないと先読みが最初の選択肢にし
かかからないことに注意。| の結合は⼀番弱い。
キャプチャや分岐が増えてるがパターンの繰り返しはない
し、トリッキーに⾒えてもひとたび構造がわかると簡単だと思
うがどうだろう。
最終的にこの⽇記で使⽤するパターンは \3? を付け加えて
こうなった。
/(?=([
「
『
(]+)?([^{}\[\]()*#"!'`=:|])
([、。」』!?！？)]+)?)(?:\1\2\3?|\2\3)/u
これで、かっこで１⽂字だけを囲った 『⽬』みたいなテキ
ストがひとかたまりとして扱われて折り返されることがなくな
る。
ひとつ⼼配なのは、?によって存在しないことにされたキャ
プチャを参照することが必ずマッチの失敗を意味するのかどう
か。参照が空の⽂字列に展開されるなら必ず成功すると判断さ
れてもしかたがない。たとえそれが NULLと空⽂字列の混同だ
としてもありそうな話ではある。
「禁則処理がおかしい - Ronten」
ここまで書いてから⾒つけたのがこれ。
word-break: break-all;
から、
word-break: normal;
word-wrap: break-word;
に変更。元々、英数だけの⽂字がdivをはみ出す現象の防
⽌の為にword-break: break-all; を指定していたが、それ
だと⽇本語の句読点が⾏頭に来てしまうっぽい。
word-break: normal;だけだと、英数だけの⽂字がはみ
出すが、上のように⼆つ指定すると、⽇本語も英語も両⽅
うまくいった。
ええええええ。くやしいから本⽂の⽅だけ CSSで対応す
る。
/* chiffon_leafgreen.css 183⾏⽬ */
div.day {
word-break: break-all;
word-wrap : break-word;
}
/* に追加して */
div.section {
word-break: normal;
}
⽅針は変更せず、タイトルではきっちり右端での折り返しを
優先し、本⽂では禁則処理を優先しよう。そもそもは wordbreak:break-allで禁則処理が⾏われるのが本当で、それこそ
が望みの結果なのに。
@2013-11-04 朝令暮改
「 2.テキトーなテキスト置換」が予想以上にプロブレマティ
ックだった。⼆重ブラケットで囲った URLの中の ? を NOBR
タグで囲おうとして URLを破壊し XHTMLを破壊していた。既
に書いたように footnoteプラグインに引数として渡す⽂章に
NOBRタグを挿⼊する問題もある。タイトル欄で footnoteプ
ラグインは使わない(セクション末尾に脚注を挿⼊しようとし
ても無理だから)が、同じような問題が続出するということ
だ。
というわけで、⽬途をつけておいた JavaScriptでの実装に
切り替えた。
// Firefox(ver.15-23現在まで)が word-break:break-a
llで禁則処理を
// してくれないので NOBRタグで強制的に特定の折り返しを
禁⽌する。
function auto_nobr(textNode)
{
var create_nobr = function(text){
var d = textNode.ownerDocument;
var nobr = d.createElement("nob
r");
if (text) {
nobr.appendChild(d.create
TextNode(text));
}
return nobr;
};
var
m,
re
=
/[ 「
『
（
(]+.
[)）』」、。!！?？]*|.[)）』」、。!！?？]+/;
while (m = re.exec(textNode.nodeValue)) {
/* assert 0 < match.length in cas
e of infinite loop. */
nobrText = textNode.splitText(m.i
ndex);
textNode = nobrText.splitTex
t(m[0].length);
nobrText.parentNode.replaceChil
d(create_nobr(m[0]), nobrText);
}
return textNode; // the last Node of spli
tted textNodes.
}
function apply_auto_nobr_recursively(node)
{
var except_tags = {
"textarea":"タグの包含が許可されてい
ないのか<nobr>で囲ったテキストが消えてしまう。",
"nobr"
};
:"⼆重適⽤防⽌"
for (var child = node.firstChild; child;
child = child.nextSibling){
if ((child.tagName||"").toLowerCa
se() in except_tags) {
// skip blacklist-ed elem
ents.
} else if (child.nodeType == Nod
e.TEXT_NODE) {
child = auto_nobr(child);
} else if (child.firstChild) {
apply_auto_nobr_recursive
ly(child);
}
}
}
var h2 = document.getElementsByTagName("h2");
for (var i = 0; i < h2.length; ++i) {
var root = h2[i].parentElement;
if (! root || root.tagName.toLowerCase()
!= "div" || -1 == (" "+root.className+" ").indexO
f(" day ")) {
continue;
}
// now root is a div.day.
apply_auto_nobr_recursively(root);
}
それから、
ひとつ⼼配なのは、?によって存在しないことにされたキ
ャプチャを参照することが必ずマッチの失敗を意味するの
かどうか。参照が空の⽂字列に展開されるなら必ず成功す
ると判断されてもしかたがない。たとえそれが NULLと空
⽂字列の混同だとしてもありそうな話ではある。
と書いておいた懸念は現実のものだった。Firefox(23.0.1)
でも IE9でも次のスクリプトは true(マッチした)を表⽰する。
(ちなみに ruby1.8は nil(マッチ無し)を返す)
alert(/(?=(A)?)\1/.test("B"));
これと区別できた⽅が応⽤が広がるのに。
alert(/(?=(A?))\1/.test("B"));
@2013-11-05 Safari(5.1.7)の微妙に異なる振る舞いとや
り残し。
Safariでは <nobr>で囲った直前の⽂字までがひとかたまり
になるのか、句点＋２⽂字が次⾏に送られている。読みやすく
はあるがなんでこうなる？ Safariのユーザー・エージェント・
スタイルシートに nobr{white-space:nowrap}がある。これ
を normalで上書きすると NOBRタグによる禁則が無効にな
る。空⽩による分かち書きを⾏わない⽇本語⽂章において
white-space指定は空⽩だけを対象にしたものではなかった
か。そういえば全⾓⽂字だけの⽂章と全半⾓混在の⽂章で
Safariの処理が異なるという報告もあった。ま、<NOBR>で
も white-space:nowrapでも、Safariが対象要素の外側にある
１⽂字を余分に巻き込む理由にはならないとおもうけど。パタ
ーンから⾏頭禁則⽂字⼿前の１⽂字にマッチするドットを取り
除くと Safariの挙動に対応した禁則処理が⾏えるが、そうする
と Firefoxで⾏頭禁則が効かなくなる。おかしな Safariに合わ
せたりはしない。
既にタグで囲まれているテキストと交差するように
<nobr>で囲うことはできない。ということは、「<a>テキス
ト</a>」とか <a>テキスト</a>。みたいなよくあるマークア
ップ済みテキストに禁則処理を適⽤できないということだ(む
しろこれに対処したくて Safariは直前の⽂字(要素)を巻き込ん
でるのか？という疑いもわいてきたが、直前の⽂字ならぬ直前
の要素にくっついたりはしなかった。残念Safari残念)。これ
は後付けスクリプトでなんとかできるとは思えない。Firefox
の word-break:break-all完全対応待ち。
@2013-11-06 両端揃え
1.箱の端から端まで⽂字を満たしたい。
を徹底するためにスタイル指定を⾜して完成。
.day .section, .day .title > * {
text-align: justify;
/* 両端揃え */
text-justify: inter-ideograph; /* ⽇ 本 語 両 端 揃
え(IE向けに字間の調整⽅法を指定する。CSS3?) */
}
Firefox(23.0.1)と IE9は期待通り。Safari(5.1.7)は英字⼿
前のスペースだけを使って両端揃えをしようとして英字混じり
⽂が不⾃然に分断される。これは
3.やりすぎた字間調整(text-justify)は⾒苦しいからやら
ない。
に反するけど、Safariだけの問題なので知らない。時間が解
決するでしょう。
<追記@2013-11-11>WebKit向けに⾯⽩いことをしてる
⼈ が い ま す ね 。 「 【 ⽬ 指 せ ePub 出 版 】 Webkit で textalign:justifyに挑戦する | ⾼橋⽂樹.com」俺だったら表⽰さ
れない空⽩SPAN要素を挿⼊するんでなく Unicodeの幅０スペ
ースのどれかを挿⼊するかな。結果が期待通りになるかは確か
める必要があるし、いずれにしろコピペがひどいことになりそ
うでコンテンツを改変しない⽅策が望まれるが。</追記>
< 追 記 @2013-11-12> こ う い う 指 摘 「 iOS5 の Mobile
Safariでは、⽇本語でも両端揃えができるようになりました |
BALLOG」もあるが、提⽰された例から判断する限り、iOS4
で⾏われていた「ィ」「ー」の禁則処理が iOS5で⾏われなく
なった結果⾏末が揃っただけに⾒える。字間調整が⾏われた結
果ではなく、むしろ退化してないか？それから、全⾓⽂字だけ
で⽂章を書くならスペースに頼らない字間調整が⾏われるとの
報告もある>「webkit系ブラウザ（Chrome/Safari）で両端揃
えはできないの？jQueryで検証 | 株式会社LIG」。</追記>
@2013-11-07 「 CSS
Text
Module
Level
3
(www.w3.org)」
text-justify
W3C Last Call Working Draft 10 October 2013
The following features are at risk and may be cut
from the spec during its CR period if there are no
(correct) implementations:
the ʻtext-justifyʼ property
Value: auto | none | inter-word | distribute
先⽉出た⽂書。text-justify(とその他いくつか)が名指しで消
滅の危機。後がない。inter-ideographに代えて distributeを
指定しといた⽅が先々有効かも(属性⾃体が消えてなければ)。
word-break, line-break
word-breakに line-breakを統合するのはなくなったんだろ
うか。line-breakの項⽬がある。うまくないとは思ってたので
歓迎。でも句読点の禁則が line-breakの３つのレベル：strictnormal-looseのどこかわからない。
句点は U+3002;CL # IDEOGRAPHIC FULL STOP 。かぎ
か っ こ ( 開 ) は
U+300C;OP
#
LEFT
CORNER
BRACKET。UAX #14 (www.unicode.org)では CLも OPも
⾔及されてるけど、CSSの 5.1. Line Breaking Detailsではそ
れらを含まないクラスに限定して UAX #14を参照してるから
CLも OPも位置づけが明確にならない。要は、line-break属性
で具体的に挙げられてるのは最低限の要件であって、その他の
線引きは User-Agentまかせということだった。書いてありま
した。
CSS distinguishes between three levels of strictness
in the rules for text wrapping. The precise set of rules
in effect for each level is up to the UA and should
follow
language
conventions.
However,
this
specification does require that:
将来組み版向けに細かい制御が必要だろうとも(別の場所で)
⾔ってるが、当⾯満⾜できないということは、line-breakを緩
くしておいて必要な部分に<nobr>というアプローチもなくは
ないのか、な？
KADOKAWAが EPUBの取り扱いに関する⽂書を公開してい
た な 、 と ダ ウ ン ロ ー ド し て み た 。 → 「 KADOKAWA-EPUB
PORTAL」
■３点リーダや２倍ダーシがつづく際の禁則の抑制につい
て
３点リーダや２倍ダーシ、ナカグロなどは、前後の⽂字
と分離禁⽌禁則が⾏われるため、あまり⻑いと直前の⽂字
から改⾏されて、意図せぬ表⽰になることがある。そのよ
うなときは、４⽂字以上連続する場合を⽬安に、以下のよ
うに「word-break-break-all」を該当箇所にのみ指定する
こと。未対応の RS もあるが、指定があって表⽰が崩れる
ことはないので挿⼊しておく。
【参考】分離禁⽌される可能性の⾼い⽂字について
CSS3 の「line-break」の項には、⾏頭・⾏末で前後の⽂
字との分離が禁⽌になる⽂字についての記載がある。詳細
は
「
http://www.w3.org/TR/2012/WD-css3-text-
20121113/」の「line-break」の項を参照。
実際には、まだ禁則処理については RS 次第であり、
line-break の指定が反映されることも期待できないので、
これらに依存するような記述は避ける。
引⽤元: 制作仕様ver.1.0.1 http://kadokawaepub.bookwalker.co.jp/download/KADOKAWAEPUB_producing_guidelines_ver.1.0.1.zip?
attredirects=0&d=1
基本は word-break:normalで、必要に応じて⼀部を wordくるむ
break:break-allで包 むと。どっかで⾒たような⽂書(だがちょ
っと古い)へのリンクもあるぞ。
この PDFでも⾒たし、数⽇前に「⾃炊ePubのためのあれこ
れ覚え書き - 道具眼⽇誌：古⽥-私的記録」でも⾒たのだけ
ど、tcyというクラス名を。やっぱりアレをタテチュウヨコと
読むんだってことだよね。検索したら例によって Wikipediaが
⼀番。「読みは「たてちゅうよこ」であり、「たてなかよこ」
ではない（JIS X 4051で規定）」。腹腔といい縦中横とい
い、ローカルルールでもこうと決めたからには正解！みたいな
のってどうなん？
@2013-11-09 ECMAScript(3rd&5th ed.)の、Rubyとは
異なる、残念正規表現仕様
20131101p01.08の最後の⽅に書いてたこと。Firefoxでも
IEでも Safariでも同じ挙動――?をキャプチャの中に付けても
外に付けても trueを返すこと――を⽰すので ECMAScriptと
して規定されてるんだろうと探してみた。以下該当部引⽤。太
字強調は失われたり付け⾜したりしてます。
The form (?! Disjunction ) specifies a zero-width
negative lookahead. In order for it to succeed, the
pattern inside Disjunction must fail to match at the
current position. The current position is not advanced
before matching the sequel. Disjunction can contain
capturing parentheses, but backreferences to them
only
make
sense
from within
Disjunction
itself.
Backreferences to these capturing parentheses from
elsewhere in the pattern always return undefined
because the negative lookahead must fail for the
pattern to succeed. For example,
/(.*?)a(?!(a+)b\2c)\2(.*)/.exec("baaabaac")
looks for an a not immediately followed by some
positive number n of a's, a b, another n a's (specified
by the first \2) and a c. The second \2 is outside the
negative
lookahead,
so
it
matches
against
undefined and therefore always succeeds. The
whole expression returns the array:
["baaabaac", "ba", undefined, "abaac"]
引⽤元: Microsoft Word - Ecma-262.doc / Standard
ECMA-262 3rd Edition - December 1999 / 15.10.2.8
Atom / 139ページ
こちらでも "always succeeds"と書いてある。
Informative comments: An escape sequence of the
form \ followed by a nonzero decimal number n
matches the result of the nth set of capturing
parentheses (see 15.10.2.11). It is an error if the
regularexpression
has
fewer
than
n
capturing
parentheses. If the regular expression has n or more
capturing parentheses but the nth one is undefined
because
it
hasn't
captured
anything,
then
the
backreference always succeeds.
引⽤元: 15.10.2.9 AtomEscape / 140ページ
残念だ。thereforeとかあっさり書いちまいやがって。それ
はまったく⾃明ではないぞ。
空パターン(※JavaScriptは Perlと違ってダブルスラッシュ
がコメントになってしまうので作るのに⼩細⼯が必要)が必ず
成功するのはわかる。でもそれに対応するのはキャプチャが空
⽂字列を保存していてそれを後から(その⽂字列そのものにマ
ッチする)パターンとして参照した場合であって、参照すべき
キャプチャ・参照すべきパターンが存在しない(=undefinedで
ある。空⽂字列ではない)ときは必ず失敗して欲しかった。理
由はすでに書いたように、この⼆つを区別できなくなるのが困
るからだ。
/(?=(A)?)\1/.test("B"))
/(?=(A?))\1/.test("B"))
もっと実際的な不利益は 20131101p01.06に書いた書き換
えが通⽤しないことだ。これって C++11にも影響する(して
る)んでしょ？ *SIGH*
@2013-11-12 Safari(Win版5.1.7)で満遍なく字間調整
Safari で は 全 半 ⾓ 混 在 ⽂ 章 に 対 し て は ⾃ 動 的 に textjustify:inter-wordに相当する字間調整が選択されるらしく、
⽇本語⽂章にわずかに含まれる空⽩が過剰に引き延ばされた⾒
苦 し い 表 ⽰ に な っ て し ま う こ と を も う 書 い た
>20131101p01.10。
実は word-break:break-allを指定しているとほとんど任意
の場所で折り返しができるので(Safariの場合禁則処理も⾏わ
ないので)わずかなスペースに調整のしわ寄せがいっても問題
にならない(といっても切り落としたような右端のラインは得
られないが)。でも禁則処理を施した場合 Safariはなぜか３⽂
字を次⾏に送ってしまうので(20131101p01.09)、全⾓１⽂
字分以上の空⽩が⽂章を分断してしまうのが問題になる。
ど う す る か 。 こ れ に 対 処 し て 「 <span style="width:0;
font-size:0; overflow:hidden"> </span>」を挿⼊した⼈が
唯⼀⾒つけられる。visibility:hiddenを指定した空⽩なら挿⼊
してもコピペに影響しないのを Safariと IEと Firefoxで確認し
た(※)ので⾃分はこうした。※.textContentには影響するか
も。.innerTextには影響しないかも。
// Windows版Safari(5.1.7)の字間調整は全半⾓混在⽂章
でスペースに対してしか働かず⽂が不⾃然に分断されてしま
う。
// 不可視の空⽩を挿⼊することでさらなる字間調整ポイント
を Safariに対して教える。
// 相当うざい結果になる(なにせほぼ任意の２⽂字の間に S
PAN要素が挿⼊される)ので、Safariでだけ実⾏するように。
function textfunc2_safari_whitespace_distributio
n_inter_ideograph(textNode)
{
var _xp, new_xp = function() { // XP = ex
pansion point
if (! _xp) {
var d = textNode.ownerDoc
ument;
_xp = d.createElement("sp
an");
_xp.style.fontSize
=
_xp.style.letterSpacing =
"0px";
_xp.style.visibility
=
"hidden";
_xp.appendChild(d.createT
extNode(" "));
}
return _xp.cloneNode(true);
};
var p = textNode.parentNode;
var m, re = /\S(?=\S)/;
while (m = re.exec(textNode.nodeValue)) {
/* assert 0 < match.length in cas
e of infinite loop. */
textNode = textNode.splitText(m.i
ndex + m[0].length);
p.insertBefore(new_xp(), textNod
e);
}
// ついでに、Safariが <nobr>の直前直後の２⽂
字を接着して字間調整も折り返しも⾏わないのを矯正する。
try { if (textNode.nextSibling.tagName.to
LowerCase() == "nobr") {
p.insertBefore(new_xp(), textNod
e.nextSibling);
} } catch(e) {}
return textNode; // the last Node of spli
tted textNodes.
}
スクリプトの全体はページのソースを参照のこと。結構重い
処理なのでページの表⽰後しばらくして⽂字が移動するのが⾒
えてしまうかも。でも Safariだけの問題なので(略)。
Safariで表⽰したこのページでテキストを選択してみると、
⽂字と⽂字の間に⽩い縦線が⼊ってるのが⾒えるんじゃないだ
ろうか。それが visibility:hiddenなスペースだと思われる。⾏
末から⾏頭に向かって１⽂字１⽂字の間に１ピクセルの字間を
配ってるかんじ。⾏頭に着いても分配する字間が余ってる場合
は２ピクセル⽬をまた⾏末から配る、と。たまに２⽂字くっつ
いたままになってるのは禁則処理のために挿⼊した NOBR(開
き)タグの直前と直後の⽂字。Safariはなんでこの２⽂字を接
着してしまって字間調整も折り返しも⾏わないんだろう。
<NOBR>の直前に字間調整⽤の SPANを挿⼊するとめでたく
接着が解けたが、SPAN挿⼊の⼆重適⽤を避けつつ NOBRに限
ったアドホックな処理を追加せずに済む⽅法は……。<追記
@2013-11-14>上のスクリプトは Safariを特定したものな
のだし、NOBR要素狙い打ちで字間調整⽤の SPANを注⼊する
ことにした。 </追記>
<追記@2013-11-21>⾒えない、クリップボードにコピー
されないとはいえ、スペースを挿⼊してるのは間違いないの
で、スタイルシートを切ると空⽩⼊りのテキストが表⽰される
し、ページ内検索も空⽩を⼊れないとヒットしない。タグの意
味的にもこれらの副作⽤を避ける⽬的でも WBRタグを使いた
いんだけど、字間を挿⼊する効果がないんよね。</追記>
<追記@2013-11-25>分離禁⽌と分割禁⽌の２つの概念。
分離禁⽌は分割禁⽌を含む、より強い拘束。―と―の間に改⾏
(折り返し)はもちろん空⽩も挿⼊してはいけないというのが分
離禁⽌の例。WBRは分割(改⾏(折り返し)の挿⼊)を許可する要
素だから⾃動的に字間の挿⼊も許可しているはず。期待して待
っていていいかな？</追記>
「W3C⽇本語組版ノートとCSS3 - JAGAT」
WebKit以外は禁則に対応している。CSSには禁則ルール
を「通常」から「厳しくする」と3段階の設定がある。両端
揃えについては実装依存、「どういう実装をしてもいい。
ただ⽇本語ではJLREQを参照するといい」としている。
EPUB仕様も同様である。
Firefoxで word-break:break-allを指定すると禁則処理が⾏
われなくなるのが問題。(対応してるが適⽤外)
Safariが全半⾓混在⽂章に対して⽇本語向けの両端揃えを選
ばないのが問題。(xml:lang="ja-JP"なのに JLREQを参照すべ
き場⾯だと思われていない)
「[email protected] Mail Archives」
@2013-11-14 PS3・泥ケー・Opera
PS3のインターネットブラウザも今では WebKitベースだと
か(実際そう名乗っていた。診断くん)。なかなかきれいなフォ
ントレンダリングで(でもズームするともやっとする)、禁則処
理、字間調整の⽅法まで含めて Safariによく似た結果。スクリ
プトを有効にすることでこのページも期待通りの表⽰になっ
た。
もうひとつブラウザ。ドロケー(URBANO L01)で表⽰する
と中⼼線近くでせせこましく折り返したり折り返さなかったり
する現象(※)が⾒られたんだけど、google/京セラのせいにし
て放置していいのか、DPIの⾼さにこのページが対応できてい
なかったりするのか。
※スクリプト実⾏中は画⾯に⾒えてる３⽇分のタイトルがせ
せこましく折り返してた。実⾏後は先頭の１⽇だけがせせこま
しく折り返したままだった。
また、ナビゲーションリンクをクリックすると再現性なく
HTTPステータスコード 505 HTTP Version not supportedが
返ってくることがわずかな時間に何度もあった。やっぱりブラ
ウザ(GCかどうか知らないが)が信⽤ならんのかな。LTE経由や
ったから auがいらん茶々⼊れてたんかな。
Opera17も試してみたんだけど、フォントの設定がないの
んな。開発者プレビューにはあったみたいだけどその場所にも
なかった。閲覧者が読みやすいと感じるフォントは閲覧者が知
っている(そして設定している)だろうと思って HTML/CSSで
はフォントファミリを指定してないんだけど、その結果がＭＳ
Ｐゴシックのビットマップフォント。３段階ほど⽂字を⼤きく
するとベクタデータに切り替わるのか⾒られる表⽰になるけ
ど、ＭＳ Ｐゴシックをあえて指定してすら⽂字が美しい
Safariとは雲泥の差。⾒るに堪えない。
@2013-11-15 テーマ画像。DPI
URBANOのブラウザは Google Chromeではなかった。バ
ージョンが４.XXXだということがかろうじてわかったがまっ
たく素性が知れない。これは不⾃由ゆえか不慣れゆえか。
スマホの Google Chromeで表⽰してみると PCで⾒るより
⼀⾏の⽂字数が少ない。固定サイズの背景画像を基準にして横
幅をピクセルで指定しているために、ひと⽂字ひと⽂字をより
多くのピクセルを使って精細に描画する(⾼DPIってこと)スマ
ホでは⽂字数が減るんだろう。こういうのってベクタ画像をス
ケーリングしたり、左上⾓+辺の繰り返し+右上⾓の画像３枚
構成で横幅を可変にしたりするのだろうか。そういうことがで
きるのかどうかも知らないけど。それかこういうときにこそ画
像の DPI値(JPEGにそういう値がなかった？)が役⽬を果たし
てブラウザが勝⼿にリサイズしてくれたりするんじゃないんだ
ろうか。DPIとピクセル数で現実世界の⻑さがわかるわけで、
それを共通の尺度にしてブラウザが再度スマホにおいて画像を
表⽰するのに使うべきピクセル数を求められるはずでは？でも
現実世界の⻑さを共通の尺度にするとスマホの画⾯サイズは
PCのモニタと⽐べて⼩さすぎるのか。でもそれはスマホが
DPI設定をそれなりの⾼さに抑えておいてズームを駆使すれば
いいだけのことじゃないか。Windowsの DPI設定がモニタの
ピクセル密度を全然反映していないのだから何を考えても机上
の空論か。そもそも、⽇記のテーマ(chiffon_leafgreen)で使
ジフ
われてる画像が DPI値をセットできない GIFだった。画像にだ
け DPIが指定してあっても、というのもある。画像のピクセル
数を基準にして div.day要素の横幅が 510pxと指定してある
から、こちらも、画像が何ピクセルを使って表⽰されるのかに
合わせて変換されないとつじつまが合わない。そのへんはまた
CSSの px単位が論理的/相対的な単位であるとかが関係してき
て……。これかな？「ʻpxʼ pixels; 1px is equal to 1/96th of
1in」DPIを固定して定義されてるから pxと現実世界の⻑さが
いつでも１：１対応する、その結果 CSSの 1pxとモニタの画
素とは１：１対応しない、と。テーマ(※ライセンスはGPL)で
pingと同じピンではないの？
使われてる画像を 96×96DPI指定した
PNG
に
変換するだけで解決するといいなあ(儚い希望)。
PCでなんちゃってRetina。Firefoxと Safariにつく差。(@201311-22)
Windowsの DPI設定を２倍(192dpi)にするとなんちゃって
Retina(300overにはまだまだ届かない)を体験できる。贅沢な
ピクセルの使い⽅の代償は画⾯の仮想的な広がりが⾯積⽐４分
の１に狭くなること。24.1インチ・WUXGA(1920×1200)モ
ニタは今となってはでかいばっかりで粗いもんだ。4Kなんか
より QUXGA Wide(3840×2400)が 27インチまでで出ないか
なー。
Firefoxは⾼DPI設定に応じて滑らかな、質感すら感じさせる
⽂字を表⽰する。Safariは、⾃分の管理外なのであろうウィン
ドウのタイトルバーの⽂字だけがきれいで、メニューから⽂字
から他の全てが滲んでぼやけている(もちろんズームはしてい
ない)。Safariの普段の美しさは最適化(切り捨て)の結果なのだ
った。
仮 想 的 に DPI を 上 げ た か ら と い っ て ス マ ホ の Google
Chromeで⾒たようにこの⽇記の１⾏が１６⽂字になったりは
しないんだよね。ズームでなく⽂字サイズだけを拡⼤すると⾏
あたりの⽂字数が減っていくから、これかな？ 対策は、画⾯
が⼩さくて⽂字が読めないときは⽂字サイズそのままでズーム
しろ、と。<<改めてスマホのGCで確認した。既に述べた状態
は⽂字サイズ100%でのもの。60%で PCより少し１⾏の⽂字
が多いくらいになる。それでタップしてズームすると左右の余
⽩がほぼゼロになって精細で美しい⽂字の⽂章が難なく読め
る。物理的には PCモニタより⼩さいんだろうけど、カンマと
ピリオドを⾒分けるのにも苦労しない。⽂字サイズ100%で
PCと同じレイアウトになって欲しいんだけど……。
追記@2014-02-16 ドロケーのブラウザで「60%で PCより少し１
⾏の⽂字が多いくらいになる」ことに関係するかもしれない話。
Androidの密度⾮依存ピクセル「dp」
Density-independent Pixel / dipともいう
このdpという単位は、Androidアプリを作る際に使われ
る単位で、Androidの開発者向けウェブサイトではDeviceindependent Pixel（密度⾮依存ピクセル)という単位を定
義しています。これは160dpiのピクセル密度を持つディス
プレイで表⽰される1pxを1dpとしたもので、たとえば、
320dpiの場合1dp = 2pxに、480dpiの場合1dp = 3pxに
なります。
引⽤元: いまさら聞けないRetina対応のための「ピクセル」
の話 – Rriver
http://parashuto.com/rriver/development/pixelrelated-info-for-coping-with-retina-displays
Android では Windowsや CSS3に準拠した 96dpiではな
く、160dpiに固定して論理ピクセル「dp」を定義したと。
160:96 = 1:0.6 だ か ら 、 ⽂ 字 の 描 画 に 使 ⽤ す る 画 素 数 を
60%(縦)×60%(横)に減らしたときに PCとレイアウトが同じ
になることに納得できる。
訂正@2014-03-17 CSS3の 1pxが１対１対応するのは CSS3の
1inであった。
そして、1inが現実の 1インチに対応するパターンの他に、
1pxが "reference pixel"に結びつけられるパターンが認められ
ている。Androidの Google Chromeでは reference pixelを
媒介にして CSS3 px と dpが⼀致してるってことなのかも。
@2013-11-19「HTMLで⽂字詰めするタイポグラフィー⽤
JS | fladdict」
これは字詰め。禁則とも字間調整(広げる⽅)ともかち合うの
で、これを適⽤しようとするとタグの交差に対処する⽅法を真
剣に考えないといけない。でもやりたいなあ。読点とかぎ括
弧、中⿊は全⾓だと間延びしすぎだし、だからって半⾓⽂字を
使うのも違う気がするし。ああでも、フォントを知らないと
めくらうち
盲 撃 ちになってしまうのか……。Webフォントが救世主なん
だろうけど、⽂字サイズを決めないのと同様にフォントもこち
らで決めたくはないのだな。といいつつ……「リニューアルし
た(www.hsbt.org) 」 www.ruby-lang.org/en/ の ⽂ 字 が ⾒
な れ な い き れ い さ だ な と 思 っ て イ ン ス ペ ク ト す る と Noto
Sunsという Googleが提供する(?)フォントが使われていたり
して結局は受けとり⼿が満⾜できるかどうかが問題なのだっ
た。
<link href='https://fonts.googleapis.com/css?fami
ly=Noto+Sans:400,700,400italic,700italic&amp;subs
et=latin,cyrillic,greek,vietnamese' rel='styleshe
et' type='text/css'>
@2013-11-20 字詰め。
やった。ほとんど昨⽇貼ったリンク先のスクリプト
(FLAutoKerning.js)の移植。⾏頭の約物の処理だけ省いた。
折り返しでの天付きをせずにそれだけするのもどうかと思っ
て。いい加減⻑いので詳細はソースの textfunc4_jizumeへ。
問題点
さらに重くなった。重たい字間処理と重なる WebKit系が悲
惨。
ＭＳ Ｐゴシックだと詰まりすぎる。つまり、ユーザーがフ
ォントを指定できない Opera17で詰まりすぎる。今⽇のこ
の⽇記を⻑々と書き継いでいるうちにリリースされた
Opera18ではフォントの指定ができました。めでたいOpera
すばらしい。(もちろん⽪⾁)
Safariでは⼀部の記号の⼀部(※)が元々詰まっていて、そこ
に字詰め処理が⼊ると詰まりすぎる。※CODEタグによって
プロポーショナルと等幅が切り替わる所だった。これは特殊
だし難しいケースだ。(ある程度はタグを乗り越えて)隣の⽂
字を⾒て詰める量を決めるけど、隣の⽂字からフォントが変
わってるとは思わないもんなあ。タグを乗り越える理由は禁
則のための NOBRタグを無視したいからなので、要素の終
端で打ち切る選択肢はない。
適⽤先の要素に 0以外の letter-spacingが指定されていた場
合は、それに加算した letter-spacingを設定すべきではない
か？
まとめると、フォントにメイリオを指定した
Firefox(25.0)、Internet Explorer(9)以外お断り仕様になっ
てしまいました。
Firefox25 で の 表 ⽰ ( ベ ン チ マ ー ク )>
20131101p01.pdf(610KiB)
スクリーンショット追加@2013-12-05
Firefox19 on Mountain Lion の ス ク リ ー ン シ ョ ッ ト
(5.2MiB)>macml_firefox_19.0.png
Fx23 on Vistaとの違い。
1. text-align:justifyにも関わらず右端が揃っていない(そ
の割に⽂字間が調整されたような疎密の波がある)。
2. PRE 内 の ⽂ 字 が font-size:100% 指 定 に も 関 わ ら ず
90%ほどになってる(IEとか他のブラウザでなら⾒たこ
とあるけど)。
iPhone5 で の ス ク リ ー ン シ ョ ッ ト (5.0MiB)>ios_iPhone5_6.0_landscape.jpg
Fx23 on Vistaとの違い。
1. PRE 内 の ⽂ 字 が font-size:100% 指 定 に も 関 わ ら ず
90%ほどになってる。
2. 他は完璧、というか、感覚的な読みやすさで凌駕してる
のでは？
プロポーショナルフォントにはもともと余分な空⽩はないし
(※)、等幅フォントが指定してあるなら等幅であることを尊重
すべきだし、実質、ほとんど等幅のプロポーショナルフォント
であるメイリオでしか⾒るべき効果がない。
※参考にすること(メトリクスカーニングとオプティカルカ
ーニング)@2013-12-05「デザイナーは⽂字詰めに命をかけ
よう 〜和⽂と欧⽂のフォーマットの違いから考える〜 | 企業
ソーシャルメディア運⽤・ソーシャルデータ分析・YouTube
チャンネル運⽤の株式会社アクトゼロ」
SVGの⽅に measureTextとか text-renderingがあるらしい
(DOMインスペクタを覗いていたら⾒つかった)。CSS Fonts
Module Level 3 に も font-kerning と か font-variant-eastasian:proportional-width(胡散臭い……)とかあった。追い追
いどうにかなるでしょう。
といいつつ、せっかく書いたコードを捨てきれないのだな
あ。簡易に等幅とプロポーショナルフォントを⾒分けて、プロ
ポーショナルの場合は字詰めの対象を絞ることにした。メイリ
オ、ＭＳ Ｐゴシック、ＳＨ Ｇ30-M、ＳＨ Ｇ30-Pでまあま
あ破綻せずに表⽰できてると思う。テストするときは、フォン
トを切り替えた後にリロードしないとフォントにあった処理が
⾏われないことに注意。
⻑いけど貼りますよ。バージョン管理されてませんからログ
を残さないとね。
// 全⾓の約物・句読点などの連続すると過剰になる余⽩を詰
める。プロポーショナルフォントはもともと
// 余⽩が調整されているから、主にメイリオと等幅フォント
が対象になる。
// textfunc2/textfunc3で字間調整のための⾒えないスペ
ースを挿⼊した後だと全く
// 効果がないのでその前に実⾏すること。
//
// アイディアと実装とカーニングペアの定義の下敷きはこち
ら。
//
http://fladdict.net/blog/2011/02/auto-kernin
g.html
function textfunc4_jizume(textNode)
{
var is_proportional = function() {// ¿等幅
フォントもしくはほぼ等幅のメイリオではない? フォントご
とにカーニングペアのひとつひとつについてテストするのも
いいかもね。
try {
var canvas = textNode.own
erDocument.createElement("canvas");
textNode.parentNode.appen
dChild(canvas);
var ctx = canvas.getConte
xt("2d");
ctx.font = "100% "+getCom
putedStyle(textNode.parentElement||textNode.paren
tNode).getPropertyValue("font-family"); // If ret
urned value is the used value, appendChild may be
removed.
//console.log(""+ctx.meas
ureText(" 」
「
").width+"
"+ctx.measureTex
t("＠＠").width);
return ctx.measureTex
t("」「").width < ctx.measureText("＠＠").width;
} catch(e) {
return true; /* 字詰めをや
りすぎないように無難な⽅を返す。*/
} finally {
if (canvas) {
textNode.parentNo
de.removeChild(canvas);
}
}
};
var ki = is_proportional() ? textfunc4_ji
zume.kerning_info_for_all : textfunc4_jizume.kern
ing_info_for_monospace;
var enclose_in_letterspacing_span = funct
ion(textNode, em) {
var span = textNode.ownerDocumen
t.createElement("span");
span.style.letterSpacing = ""+e
m+"em";
span.appendChild(textNode.parentN
ode.replaceChild(span, textNode));
};
var next_element_char_or_empty = functio
n(textNode) {
var skip_blankTextNode = functio
n(node) {
for (;node && node.nodeTy
pe == Node.TEXT_NODE && /^\s*$/.test(node.nodeVal
ue); node = node.nextSibling) {
// empty loop-bod
y;
}
return node;
};
var nextNode = skip_blankTextNod
e(textNode.nextSibling) || skip_blankTextNode(tex
tNode.parentNode.nextSibling);
for (; nextNode && nextNode.nodeT
ype != Node.TEXT_NODE; nextNode = skip_blankTextN
ode(nextNode.firstChild)) {
// empty loop-body.
}
return (nextNode && nextNode.node
Type == Node.TEXT_NODE) ? nextNode.nodeValue.char
At(0) : "";
// あんまり先の⽅の⽂字を読んで lett
er-spacingを設定しても意味ないかもね。
// 何もしないか、むしろ先の⽂字に負の
marginなりを設定したほうが意味があるかも。
};
for (var i = 0; i < textNode.nodeValue.le
ngth;) {
var
char = textNode.nodeValu
e.charAt(i);
var nextChar = textNode.nodeValu
e.charAt(i+1) || next_element_char_or_empty(textN
ode) || "*";
var space = (ki[char+nextChar] ||
(ki[char+"*"]||0)+(ki["*"+nextChar]||0));
if (space) {
var charNode = textNode.s
plitText(i);
textNode = charNode.s
plitText(1);
enclose_in_letterspacin
g_span(charNode, space);
i = 0;
} else {
i += 1;
}
}
return textNode; // the last Node of spli
tted textNodes.
}
/*
カーニングペアの定義
単 位 は em。 -0.5(em) で ボ ッ ク ス 0.5個 分 詰 ま
る。
"*く " と 定 義 し た 場 合 、 "あ く "、 "い く "、 "う
く"、というように、全ての"○く"の組み合わせにカーニング
が設定される。
"あく" と定義をした場合、 "あく"という⽂字のペ
アのみにカーニングが設定される。
ワイルドカードペアと直接指定のペアが衝突する場
合、直接指定のペアが優先される。
*/
textfunc4_jizume.kerning_info_for_all = { // プ ロ
ポーショナルフォントでも削られていない(であろう)余⽩に
関して設定する。
// 直接指定のカーニングペア
"か。":-0.05,
"が。":-0.10,
"け。":-0.10,
"げ。":-0.15,
"す。":-0.15,
"ず。":-0.15,
"み。":-0.05,
"。」":-0.25
};
textfunc4_jizume.kerning_info_for_monospace = {
// プロポーショナルフォントでは削られている(ことが多
い)余⽩に関して設定する。
// 前後の⽂字をワイルドカード指定した汎⽤のカーニングペ
ア
"*ト":-0.10,
"*ド":-0.10,
"*「":-0.25,
"」*":-0.25,
"*（":-0.25,
"）*":-0.25,
"、*":-0.25,
"。*":-0.25,
"・*":-0.25,
"*・":-0.25,
"*：":-0.25,
"：*":-0.25,
// 直接指定のカーニングペア
"」「":-0.75,
"」。":-0.50,
"」、":-0.25,
"、「":-0.75,
"。「":-0.75,
"、『":-0.75,
"。『":-0.75,
"、（":-0.75,
"。（":-0.75
};
for (var k in textfunc4_jizume.kerning_info_for_a
ll) {
textfunc4_jizume.kerning_info_for_monospa
ce[k] = textfunc4_jizume.kerning_info_for_all[k];
}
getComputedStyle(textNode.parentElement||textNode.pa
rentNode)に関して。
IE9がテキストノードに parentElementを定義していないら
しい。まさにこれですよ。
⼀部のブラウザーでは、parentElement プロパティは
Element ノードでのみ定義されており、特にテキストノー
ドに対して定義されていない場合がある点に注意して下さ
い。
引⽤元: Node.parentElement - Web API リファレンス |
MDN
https://developer.mozilla.org/ja/docs/Web/API/Node.p
arentElement
で 、 parentNode で な く parentElement を 呼 ん で る の は
getComputedStyleの第⼀引数が Elementでないといけない
と書いてあるからで
The first argument must be an Element, not a Node
(as in a #text Node).
引⽤元: window.getComputedStyle - MDN
http://mdn.beonex.com/en/DOM/window.getCompute
dStyle.html
IEの場合だけ parentNodeで誤魔化します。parentである
Nodeはいつでも Elementであるという仮定は、確かめてない
けど、ほぼ正しいでしょう。
@2013-11-25 「 Mozilla, Opera で も ⽇ 本 語 を 均 等 割 付
(deztec.jp)」
知ってるドメインだけど 11年前の記事とあって読んだこと
はなかった。２番⽬に⾒つかった、空⽩挿⼊で均等割り付けを
やった⼈。ただし対象は WebKitでなく Operaと Mozilla。今
の Firefox(1.5から？)は⽇本語⽂字間に調整⽤の字間を挿⼊し
てくれる。英字間にまったく配分しないのが⾏内の疎密の偏り
となって時々⽬⽴つというのが現在の問題。
スピードアップ
is_proportionalが全体の50数%の時間を使っていたので結
果をメモすることにした。読み込み完了直前に⼀回だけ実⾏す
る処理だから、スタイルやフォントの変更について⾏けなくて
も構わないよね。関数の消費時間の40%が削減できたので全
体では２割の削減。
@2013-11-27 defer, async. ねえ waitは？
スピードアップの⼀環。SCRIPTタグに deferやら asyncを
付けようと思うたびに未定義の関数を呼び出すエラーに悩まさ
れて結局諦める。こういう⾮同期・遅延属性を付けたいのは完
全⾃動の後付けスクリプトか共有ライブラリのどちらかだ。完
全⾃動タイプは問題ない。deferと asnycを両⽅付けて⾮同
期・最速で実⾏してもらえればいい。完全⾃動だけどイベント
ドリブンではないなら、対象要素の登場後に配置するなり
deferだけを付けるなりすればいい(※あれもこれも deferにす
ると⼀部の⾮常に遅い外部スクリプトが以降の deferスクリプ
トの実⾏をブロックしかねない？)。ライブラリの場合は、ラ
イブラリ関数を呼び出すコードがどこかにある。それが独⽴し
た .jsファイルであればライブラリ共々 defer属性だけを付け
る と 順 番 に 実 ⾏ さ れ る こ と が 期 待 さ れ る (HTML5 に 限 っ
て？)。でもページやその内容に依存して呼び出しコードが変
化する場合は？ページの⼀部として HTML内に埋め込まれてい
る場合は？ src属性がない SCRIPTタグには deferも asyncも
付けてはいけないという。
ライブラリは⾮同期・最速で読み込んでほしい。それを待っ
て実⾏したい HTML埋め込みスクリプトはどうやって待つ？
DOMContentLoadedイベントの発⽕は Blink Opera(18)で
⾮同期スクリプトの読み込み・実⾏より早いことがある。仕様
がどうあれ、画像やスタイルシートの読み込みがまだかもしれ
ないのと同様、スクリプトの読み込みが完了しているとは期待
できないのが現状。
答 え は jQuery の ソ ー ス と か こ の へ ん に ( 丸 投 げ
た ！ )> 「 <script> タ グ の async 属 性 を 使 わ ず に ⾮ 同 期 で
JavaScript を 読 み 込 む ⽅ 法 | さ く ら た ん ど っ と び ー ず 」
「script.onloadを使ってJavaScriptがロードされた時の処理
を記述する | さくらたんどっとびーず」。
やってらんない。⾮常に保守的で asyncや deferを付けすぎ
ても全然問題を起こさない(でも読み込みは並列でやってる)
Firefox
に
限
っ
て
script.onload
だ
と
か
document.currentScript 、 document.onafterscriptexecute
といったお役⽴ち⼿段が充実しているという。やってらんな
い。
<追記@2013-12-02>Promiseという名前/概念を仕⼊れ
た 。 async な SCRIPT 要 素 が Promise を 返 し て く れ れ ば 、
Promise.every( こ れ と 、 こ れ と 、 こ の ス ク リ プ
ト).then(function(scripts){ 指定したスクリプトに依存した
処理 })とか書けそう。scriptsが何の配列なのかという疑問は
残るが。</追記>
⼀番遅いのはスクリプトによるブロック(HTML解釈DOM構
築中断。スタイルシート読み込み完了待ち(ただし Operaはイ
ンチキしてたらしい))ではなく、tDiaryのレスポンスなんだけ
どね。静的ファイル書き出しには抗いがたい魅⼒があ
る。.htaccessにはこういう記述があるんだけど
# Rewrite rule1
# shows static html, if exists.
RewriteCond /home/vvvvvv/www/cgi_file/ds14050/dia
ry/snap/$1.html -f
#RewriteCond %{REQUEST_METHOD} =GET [OR]
RewriteCond %{REQUEST_METHOD} =HEAD
RewriteCond %{HTTP:Cache-Control} !=no-cache [noc
ase]
RewriteRule ^([0-9]{8})\.html$ /cgi_file/ds1405
0/diary/snap/$1.html [L]
なんでやめた(GETの場合を除外した)んだっけか。<テーマ
がまだら模様になるからだ。コメントやらなにやらで更新のあ
った⽇は、隣の書きっぱなしの⽇とは異なる更新⽇時点のテー
マをまとって新たに書き出される。常に現在のテーマで表⽰さ
れるも良し、12⽉に書いた⽇記がいつまでも12⽉のテーマで
表⽰されるも良し。でもモザイクはいただけない。SSIででも
対処したらいいんだけど１⾏コメントアウトする⽅が簡単だっ
たとか、単体で完結しない .htmlファイルを書き出すことへの
抵抗だとか(※SSIがサーバーを選ぶことは気にしない)。
Latestモードや Monthモードでレスポンスを⼀⽇⼀⽇順番
に出⼒していくとかでもブラウザの助けになるんではないかと
思うけど、どうだろうか。思い⽴ったが吉⽇でちょっとやって
みよう。<<ETagとか Content-Lengthヘッダをどうするんだ
って。
ETagは必ずしもレスポンスボディから⽣成する必要はなか
った>「ETagをどう⽣成するか - 岩本隆史の⽇記帳」
Content-Lengthはどうか。
転送コーディングが施されている場合、Content-Length
ヘッダは送られてはならないし、仮に送られてもこれを
無視しなければならない
転 送 コ ー デ ィ ン グ が 施 さ れ て い な い 場 合 、 ContentLength ヘッダは送られなければならないが、これはメッ
セージボディ中のオクテット数と正確に⼀致しなければ
ならない
Content-Length ヘッダが送られない場合は、接続の終
了を持ってエンティティボディの終末を判断する事がで
きるが、リクエストボディにおいてこの⼿法は推奨され
ないし、サーバは 411 レスポンスを持って明⽰的に拒否
する事ができる
引⽤元: [Studying HTTP] HTTP Header Fields
http://www.studyinghttp.net/header#Content-Length
レスポンスの場合は接続を閉じることで内容・転送の終了を
告げることができるので必ずしも Content-Lengthが必要では
ない、のかな？
body = tdiary.eval_rhtml
を
tdiary.write_to($stdout)
みたいな形にする⽅向でやってみる。
いろいろのバッファの他に HTTPDが間に⼊って、実際のと
ころどうなってるんでしょ。
@2013-12-06 字間調整・改。そして、独⽴分離している⽂
字列処理を実⾏時に効率的に融合する⽅法。
WBRタグでは効果を得られない。不可視の空⽩を挿⼊する
⽅法ではスタイルシートを切ったときに空⽩が⾒える。またペ
ージ内検索でも、単語の⽂字と⽂字の間に空⽩を挿⼊しないと
⾒つけられなくなる。第３の⽅法は CSS content属性を使う
こと。スタイルシートを切ると空⽩ごと消えるし、ページ内検
索でも挿⼊された空⽩は無視される。また、どのブラウザでも
字間挿⼊効果があることは確認済み。
実装の問題は、要素の挿⼊ではなく要素で⽂字を包むことに
なるのを、他の⽂字列処理(禁則, 字詰め)が知って対処する必
要があること。実際のところそれはもう済んでいて、さらに以
前は禁則と字詰めと字間調整がバッティングする場⾯(「A」
「B」など)で字詰めが効いていなかったのだが、これも解決し
た。解決していないのは、各々の⽂字列処理がテキストをぶっ
た切るのだが、２番⽬３番⽬の処理は細切れのテキストノード
を相⼿にしなければならないがために、メソッドの呼び出しと
メソッドの固定された初期処理とタグを乗り越えて⽂字を先読
みすることの回数が増え、効率が著しく低下すること。２段３
段の⽂字列処理を加えるなら切断は⼀度で済ませたい。
対象が共通。操作も若⼲のバリエーションはあるものの⼤枠
は同じ。対象と操作を選び組み合わせるところが固有。固有部
分を分けながら実⾏時に効率的に融合させる⽅法。マニピュレ
ータ付きのコンテクストを引き回す。操作を⼀旦ため込んで、
マージしてから実⾏に移す。
style_to_range(begin, end, style) // letter-spacingなど
unbreakable_style_to_range(begin,
end,
style)
//
white-space:nowrapなど
unbreakable_tag_to_range(begin, end, tag) //NOBR で
囲むのを white-space:nowrapに替えるなら今のところ不
要。
要 素 挿 ⼊ メ ソ ッ ド 。 幅 の な い range に 対 す る
unbreakable_xxxとして扱えるはず。でも字間調整のため
にはもう不要。
あとで。
@2013-12-08 アップロードした>textfunc.ver2.js@201503-04
いいかげん HTMLに埋め込むには⻑々しいので独⽴した .js
ファイルに。textfuncX_*はより簡素になったが、それを⾛ら
せる基礎を新しく書いた。過去の記録>textfunc.ver1.js。オ
ーバーヘッドは ver2の⽅が⼤きい。が、多段のテキスト処理
を前提にするなら組み合わせによる所要時間の増⼤は ver2の
⽅ が 抑 え ら れ て い る 、 と 思 う 。 誤 算 が ひ と つ 。 IE9 は
visibility:hiddenな content属性値をクリップボードにコピー
してしまう。それでも、スタイルシートOFFで挿⼊した空⽩が
⾒えてしまうことやページ内検索がほとんど不可能になってし
まうことに⽐べればずっとマシではある。
TODO: ⾼速なフォント判別。ブラウザ判別によらないテキス
トレイアウトの妥当性検証。混植？
フォント判別(is_proportional)が⼀番コスト⾼なのは変わ
らず。テキストレイアウト(禁則・字間・字詰め)が満⾜できる
ものかどうかをブラウザ判別に頼らず機能検出によって判断す
る ( ※ jQuery.browser が な く な り 代 わ り に 現 れ た
jQuery.support の 使 ⽤ が 推 奨 さ れ る ら し い が
「jQuery.supportでのブラウザ判別」という⾯⽩記事の登場
は避けられない世の流れ(惰性)か。ブラウザを判別したいその
理由、ブラウザ間の差異を検出するロジックを
jQuery.supportに追加するのが本道だろうに)⽅法は、(より
軽量な)フォント判別にもつながっているように思
う 。 .offsetWidth と か ね 。 結 局 の と こ ろ 初 め て ⾒ つ け た
.measureText を 使 っ て み た か っ た と い う の が
is_proportionalを構成する理由の８割だから、中⾝を置き換
えると存在理由までが消えてしまいかねないのだが。
<追記@2013-12-22>is_proportionalが遅いのは先送り
されていたブラウザの処理が getComputedStyleをきっかけ
に し て 実 ⾏ に 移 さ れ る か ら 。 is_proportional か ら
getComputedStyle を 取 り 除 く と 処 理 時 間 の ほ ぼ す べ て が
is_inline_element(これも getComputedStyleを呼んでいる)
へと移る。DOM操作のコストが getComputedStyleをきっか
けにして噴出してるとみるのが正しい。例えば関連するスタイ
ル(wbrクラス)の定義をスクリプト実⾏の後ろに移すことでわ
ずかに改善する。</追記>
混植だって。「「Webデザイナーのためのタイポグラフィ
と⽂字組版（Reloaded）」鷹野 雅弘（スイッチ）」やろうと
思えば正規表現で⽂字を拾い出して最⼩限の SPAN要素でフォ
ント指定ができますよ。他の処理を有効にしたままで。……と
思ったらここに衝突の種が。
フォントを変更する処理とフォントに依存する字詰めを並⾏
して⾏うことはできない。⼀段⽬としてフォントを変更する処
理を単独で(テキストノードの分割を最⼩限に抑えながら)⾏
い、⼆段⽬にその他の処理をまとめて⾏うワークアラウンドが
必要になるだろう。
上の⽅でリンクした MLで名前を⾒た⼈達がいたので。おも
しろい。
Web標準化の関係者たちが語る、標準化の現実と前進の
た め の 処 ⽅ 箋 （ 前 編 ） 。 HTML5 Conference 2013 －
Publickey
Web標準化の関係者たちが語る、Web標準化の現実と前
進のための処⽅箋（後編）。HTML5 Conference 2013
－ Publickey
@2013-12-11 .offsetWidth に よ る ボ ト ル ネ ッ ク
(is_proportional)の解消＆テキストレイアウトの検証……
のはずだったけど
.offsetWidth を 使 っ た is_proportional は Firefox23 で
.measureText の 倍 の
1.4 秒 か か っ た 。 Opera で も
.measureTextの消費時間が２桁ミリ秒のところ .offsetWidth
は ４ 桁 ミ リ 秒 を 消 費 す る 。 意 外 に も canvas を 作 っ て
.measureTextする⽅が早かった。
is_proportional の テ ス ト 過 程 で 気 が 付 い た ん だ け ど 、
Opera18と Safari5.1.7で等幅フォントとして欧⽂フォント
Consolas を 指 定 す る と 、 ⽇ 本 語 ⽤ の フ ォ ー ル バ ッ ク が 、
FontLinkではメイリオを指定してるにも関わらず ＭＳ Ｐゴ
シックになる。font-family:monospaceを指定してるのに台
無しだよ！
.offsetWidth/.offsetHeightを使ったテキストレイアウトの
検 証 は
function
TextLayoutInfo() と し て
textfunc.ver2.js@2015-03-04に追加した。
結果が出てから調べる奴。
Text measurement: element vs. canvas · jsPerf
Firefox23での実⾏結果
- Measure text in span is 78% slower than Canvas
measureText().
Internet Explorer9での実⾏結果
- Measure text in span is 95% slower than Canvas
measureText().
Opera18での実⾏結果
- Measure text in span is 93% slower than Canvas
measureText().
Safari5.1.7での実⾏結果
- Measure text in span is 91% slower than Canvas
measureText().
圧倒的じゃあないか。
まだ⾼速化をあきらめない。is_proportionalの結果を要素
にメモするのでなく font-familyの値をキーにしたメモをどこ
かに作ればいい気がした。でもそれには computed valueの定
義の新旧を乗り越えないといけない(関連:used value)。
Fx23で１割しか改善しない。getComputedStyleで時間を
⾷ってるのかも(Operaだと組み込み関数のプロファイルもと
れるんだけど、Fxでは？)。
これね(またしても後⼿)。
測りごとの罠 - EfficientJavaScript - Dev.Opera
前に読んでたけど「offsetWidth のようなプロパティを使っ
たり getComputedStyle のようなメソッドを呼ぶと」なんて
そのものズバリの具体例が頭に残ってなかった。
そろそろおしまい
経緯をふり返ってみる。
1. URLが折り返されなくてはみ出したり、⻑い単語がごっそり
次 の ⾏ へ 送 ら れ て 右 端 が 余 っ た り す る の が 嫌 で wordbreak:break-allを指定する(横幅に制限のあるテーマだった
から word-wrap:break-wordとともに最初から指定してあ
った)。
2. Firefox(と Safari)で禁則処理が⾏われないのがありえな
い。(word-break:break-allが原因)
3. NOBRタグを使って全てとはいわないが⼤部分の禁則処理を
補完する。
4. 右端が揃ってないのが気になってきた。(禁則処理が悪化さ
せた)
5. text-align:justify,
text-justify:distribute(inter-
ideograph)で⾏末を揃える。
6. Firefoxと Safariで⽣じる字間の偏りが気になる。(IEと違い
text-justifyで⾏末揃えの具体的⽅法を指定できないのが原
因)
7. 不可視の空⽩を分離許可・分割許可の⽬印として挿⼊するこ
とで是正する。
8. 字詰め(カーニング)も同じ仕組みで実現できそうなのでやっ
てみた。
9. あれ？分離許可・分割許可の空⽩を挿⼊してるなら wordbreak:break-allする必要なくね？
10. word-break:normalにしてブラウザの禁則処理を利⽤する
と、タグをまたいだ禁則も有効になって嬉しい。<<imkk
11. (これから) IE以外で英単語がぶった切られる結果になるの
は問題があると思ってる。word-break:break-allや wordwrap:break-wordや無差別な分離許可・分割許可の挿⼊に
か え て 、 text-justify:distribute,
line-break:loose,
hyphens:autoが使える⽇を待ってる。⽇本語か英語しか書
けないのだしハイフンを挿⼊できる位置を⾃分で調べるとい
う⼿もあるにはあるが……(機械的にできるのか利⽤可能な
辞書があるのかまったく不明)。
word-break:break-allから始まる⼀連のもぐらたたきの結
末は、word-break:break-allをやめて⾃分で分離分割許可ポ
イントをブラウザに提⽰することだった。
⼀般的に参考になるのはこちらの記事でしょうね。⾃分の場
合は優先順位が異なるので紆余曲折を経る必要があったわけだ
けど。
⻑い英単語を途中で折り返したいときの CSS の指定⽅
法: Days on the Moon
検索したら TeXとクヌース先⽣に⾏き着くのですね。ハイ
フネーションは第⼀義にはデータ圧縮問題だそうです。
packed trieとかなんとか出てきた(そこに⾄るまでに linked
trie, indexed trie, compressed trieなど。勉強になるなあ。
WEB+DB PRESS vol.42で読んだ『⾼速⽂字列解析の世界』
の⼈の記事はそれ⾃体が圧縮されていて何度読み返しても難し
かった)。いつもの、書いたからやる⽻⽬に陥ってるような気
がしないでもない。&shy;によるソフトハイフンは⼀番遅かっ
た Firefoxでもとっくにサポートされてるらしい。URLみたい
なのには、コピーには影響しないとしても、折り返し点でハイ
フ ン が 表 ⽰ さ れ て ほ し く な い な 。 う ま く 無 視 し て wordwrap:break-wordに任せるか、代わりに WBRタグを挿⼊す
る か 。 字 間 調 整 の た め に 挿 ⼊ す る ス ペ ー ス
(.wbr:before{content:"
"}) の 代 わ り に
&shy;
(.wbr:before{content:"\0000AD"}) を 挿 ⼊ し て み た け ど
Firefox で は 期 待 通 り の ソ フ ト ハ イ フ ン 。
Safari5.1.7/Opera18では異常な空間が⽣じる。IE9は単語間
調整を優先して折り返してくれない。ジャスティファイのやり
過ぎが嫌でいろいろやってるのに、調整幅の最⼤値を制限でき
ないせいで。ぐぬぬ。
Hyphenation
algorithm
-
Wikipedia,
encyclopedia(en.wikipedia.org) 経 由 で
the
free
Word Hy-
phen-a-tion by Com-put-er, patgen - TeX Users
Group(www.tug.org)
TypeSet - better justified web text | Typophile 経由で
TeX
line
breaking
algorithm
in
JavaScript
-
bramstein.com
@2013-12-27 text-justify: distribute
まだやっていました。textfunc5_nobr_over_asciiwordを
追加。これは textfunc2, textfunc3から英単語を分割する効果
のみを取り除くもの。分離効果が残ってるのがミソで、英字間
に両端揃えのためのスペースを分配はするが、英単語の途中で
折 り 返 し は し な く な る 。 こ れ は 要 す る に word-break:
normal;
text-align:
justify;
text-justify:
distributeを指定して得られるはずの結果と同じ。
⽇本語⽂では、ほぼすべての⽂字間隔が調整対象で、禁則を
例外としてどこでも折り返せるので、違和感なく両端揃えが
⾏われる。
英⽂では、単語間隔と⽂字間隔をバランス良く調整対象にす
ることで、単語や⽂字が散漫に散らばる印象を抑えることが
できる。
ハイフネーションによっても同じ効果が得られるがこれは
また別の話。
TODO: WebKit系の字間分配アルゴリズムが「右端から順
番に」なので⾏末がルーズになりがち。
⽇本語英語混じり⽂では、⽇本語⽂に対しては英単語内で折
り返せないことで、英⽂に対しては英単語間のスペースの数
が限られていることで、字間調整量が過⼤になりがちで、と
ころどころ散漫な⾏が⽬につく。混合⽂に限って wordbreak: break-allで ぶ っ た 切 る の が 無 難 だ と 思 う が 、
lang属性を積極的に活⽤する運⽤になってないので⾒分けら
れない。これの満⾜のいく表⽰が⼀番難しい。
⾒苦しい部分が少ないながら残るものの総合的にみて満⾜し
てる。Firefoxでスクリプトを切ってこの⽇記を表⽰すると、
より多くの散漫な⾏が⽬に⼊る。Opera18でスクリプトを切
って⾒ると、⾏末が揃わない、ぽっかり数⽂字分の空⽩がそこ
ここに現れる。IE9でスクリプトを切って⾒ると、何も変わら
ない……。IE9は英語でも⽇本語でもありえない表⽰は⾏わな
いし、text-justifyによって選択肢を提供してくれるけど、ス
クリプトによってそれを逸脱するような操作を⾏う余地がない
(何をしても効果が⾒られない)。ま、いじれなくてももともと
⾒られない表⽰ではないので構いません。字詰めに関してはど
のブラウザでも同じように効果を発揮してる。かぎ括弧の余⽩
が削れて満⾜。
@2014-01-05 JSLint
jslint.comで textfunc.ver2.jsのクリーンさをチェック。タ
ブインデントをオプションで許してもらうと、残ったエラーは
４つ。
Missing 'use strict' statement. line 19 character 55
var sorted_unbreakables = [];
Unexpected '--'. line 25 character 60
for (begin_first = this.length; 0 <= begin_fi
rst-1; --begin_first) {
Unexpected '++'. line 30 character 8
for (begin_last = begin_first; begin_last < t
his.length; ++begin_last) {
Move 'var' declarations to the top of the function.
for (var pos = begin_first; pos <= begin_las
t; ++pos) {
for⽂に関するものはスタイルの問題なので変えない(そうい
えば前に別のスクリプトで jslint.jsを試したときも forまわり
が 多 か っ た >20080212p01.02.01) 。 間 違 っ て る の は
JavaScriptの仕様です(letがデメリット無しで使えるなら var
から乗り換えるけども)。"use strict"; は早速ファイルの先頭
に置いてみたけど何も変わらなかった。varを１か所取り除い
て暗黙のグローバル変数を作ってみたらエラーが出たので無視
はされてないみたい。未来への保険 ⁑/保障⁂/保証 *4としてそ
のまま置いておく。
@2014-03-07 FLAutoKerning.jsの亜種。
jquery.kerning.js
｜
http://karappoinc.github.io/jquery.kerning.js/
Notice
使⽤するには、フォントに合わせたカーニングデータの
作成が必要です。 現時点では、ソースコードに付属してい
るテンプレートを参考に、使⽤するフォントに合わせたカ
ーニングデータを別途作成する必要があります。
※ フォントデータから⾃動的にjsonデータを⽣成するツー
ルを試作中です。
こういうのはカーニングデータの重要度が９割以上だと思
う。そしてカーニングデータはフォントに固有。そして使⽤さ
れているフォントをほぼ確実に知るためには Webフォントが
必 要 。 字 詰 め の 実 装 ⽅ 法 が letter-spacing で あ る と か 、
display:inline-block と margin-left、margin-rightの組み合
わせであるとかは些細な違い(といいながら興味津々でソース
をのぞいてるわけだ。俺の関⼼はそっち)。
@2015-01-19「⾳声出⼒環境における擬似要素(::before,
::after) の 内 容 (content) の 読 み 上 げ に つ い て ｜ Web 制 作
W3G」
content属性値は読まれてしまうそうです。空⽩⽂字に関し
ては、単語としての認識を阻害し、息継ぎが発⽣するらしい。
@2015-02-17「Webフォントサービス「FONTPLUS」に
⽂字詰め機能を実装｜ソフトバンク・テクノロジー株式会社の
プレスリリース」
提供するフォントから余⽩に関するデータを⼀括で削除し、
そこに CSSで余⽩を付けるという⼿順。フォント間の差異を
⼀度リセットすることで共通のカーニングデータを利⽤できる
ようにする試みなんだろうか。
同じ字でもあまり形が違うとフォント間でカーニングデータ
を流⽤できない
どうせ Webフォントを使うなら最終的にはフォント固有の
カーニングに⾏き着く
だろうとはいえ悪くはない。⼿抜きでも完璧でもないほどほ
どを狙ったサービスじゃないかと。
@2015-03-22 Opera28がやった！
百 聞 は ⼀ ⾒ に 如 か ず >20131101.html rendered by
Opera28.pdf(1.56MiB)<スクリプトなしで右端が揃っている
いくつか前のバージョンでは⽇本語英語交じり⽂の字間を暗
黙の text-justify:inter-wordで調整した結果(※IEと違い
text-justifyで他の調整⽅法を指定させてくれなかった)、わず
かな空⽩⽂字が何⽂字分にも引き延ばされたりまったく調整で
きていなかったりした。Opera28では、選択肢がないのは同
じだが、英字部分が text-justify:inter-wordで、⽇本語
部分が text-justify:distribute(inter-ideograph)相当
で調整されているらしく、これ以上を求めるなら個別に⼿作業
するしかないんじゃないだろうか。
英字部分が inter-word相当(distributeではない)ということ
で、英単語の中のアルファベット間には調整字間が分配されな
い。なので、⾏の⼤部分を英単語が占める場合に⽇本語部分が
散らかってしまうことがある。俺は⽇本語をメインに考えてる
ので、textfunc.jk.jsでは英字部分にもスペースを散らして
所々英単語を間延びさせていた(とはいえ、調整箇所が増える
と⽬に⾒える影響は減ることが期待される。あくまでも期待
>20140607)。優劣ではなく優先度の問題。これ以上の完璧
を求めるなら⼿作業が必要だということの理由。
他の Blink搭載ブラウザはどうなんだろ(インストールしてな
いから確認できない)。
TextLayoutInfo, ブラウザ検出と機能検出
textfunc.jk.jsが読み込まれてるページ(たとえばここ)でコ
ンソールを開いて
new TextLayoutInfo
と打ってみる。
Firefox22 Opera28
fontsize_zero_is_available
true
true
no_kinsoku_under_wordbreak_breakall
true
false
no_whitespace_distribution_inter_asciicharacter true
true
no_whitespace_distribution_inter_ideograph
false
false
true に な っ て い る 項 ⽬ ( ※ fontsize_zero... 以 外 ) が
textfunc.jk.js に よ る 修 正 対 象 。 以 前 の
Opera は
no_whitespace_distribution_inter_ideograph が true に な
っていたはずだが、いつの間にか falseになっている。その結
果 Firefoxの場合と同等の、処理の対象を英字のみに絞った低
負荷バージョンが選択されている。⾃動的に。これがブラウザ
検出ではなく機能検出を使う理由。
TextLayoutInfoによれば(※⾃作なのでいまいち信⽤できな
い ) 句 読 点 の 禁 則 に も 改 善 が あ っ た み た い 。 wordbreak:break-allでの、禁則を無視したありえない表⽰がなく
なったのではないだろうか。これに関しては⼀貫して IEがす
ぐれていたし、Firefoxが word-break:break-allに対応した
15以来ダメな点だ(今⽇の⽇記のタイトルを⾒よ)。
textfunc.ver2.js
(11.5KiB,
2015-03-17)
+
textfunc.jk.js (19.8KiB, 2015-03-11)
何であるか
word-break:break-allと text-align:justifyで各ブラウザに
起 こ る 諸 問 題 を 解 決 し 、 未 だ サ ポ ー ト さ れ な い textjustify:distributeを実現するためのスクリプト
具体的に
word-break:break-allでも(タグ境界を除いて)禁則。(Fx,
Safari, Blink Opera)
WebKit系でも justify. (Safari, Blink Opera)
word-break:normal下(=折り返しが制限されて justifyの調
整量が過⼤になりがち)でもなるべく調整の余⽩が⽬⽴たな
いように。(Fx, Safari, Blink Opera)
(同じ仕組みを利⽤したおまけ) メイリオの約物の等幅チッ
クな余⽩を詰める。(IE, Fx, Safari, Blink Opera)
備考
各ブラウザのバージョンは IE9, Firefox23, Safari5.1.7,
Opera18.
Presto Operaでは最⼩フォントサイズ設定が災いして⽂字
が散らばってしまう(content属性で挿⼊する⽂字をタブ⽂字
に す る こ と で 影 響 を 最 ⼩ に で き る ) の で 、
TextLayoutInfo.fontsize_zero_is_availableで こ れ を 検 知
して処理を諦める(諦めちゃいます。先のない Presto限定な
ので)。
変更履歴
2015-03-17
- Firefox で 実 ⾏ 時 間 の 短 縮 。 こ の ペ ー ジ で い う と
2000msから1200msへ。詳細
2015-03-11
- unbreakable_element_to_range
unbreakable_class_to_range
を
と
廃
⽌
し
、
unbreakable_style_to_rangeに統合。
2015-03-10
- unbreakable_element_to_range
追
加
。
(textfunc.ver2.js)
- textfunc6_non_strict_kinsoku
追
加
。
(textfunc.jk.js)
2015-03-04
-
構成変更。「本来別ファイルに分離すべきもの」とコ
メ ン ト し て た 部 分 を
textfunc.ver2.js か ら
textfunc.jk.js として分離した。
2015-02-19
- action_to_range追加 (js/textfunc.kururi.js で 利 ⽤
するため)
- textfuncに渡されるテキストが前から順番になるよう
に深さ優先で。
脚注 ✝ FOOTNOTES
* 全⾓⽂字の字間は拡⼤するが英字はそのままなので、⼀部は間延
びして⼀部は詰まって⾒える。全体に散らした⽅が⽬⽴たないの
に。@2013-11-19 Safariと同じ⽅法をより限定された対象に適
⽤するだけで矯正できるのでやってしまった。対象を限定しなくて
も副作⽤はないけど処理負荷を考えて限定した。コピペコード率⾼
し(だが構わない。分岐直後なので当然のこと。ツールファンクシ
ョンは共有してもいいけど)。@2013-12-16 ■の連続も分割され
ないな。どういう Unicodeプロパティを参照してるんだろ。
？ @2013-11-09 勘違いしてたけどこの部分は Rubyなのでパタ
ーンの中にパターンを埋め込む⽅法で繰り返しをなくせる。それに
後に明らかになったように、この後の書き換えは各種ブラウザの
JavaScript で 無 効 な 、 Ruby で し か 使 え な い ⽅ 法 だ っ た 。
ECMAScriptとしてあまりありがたくない動作が規定されてるのか
も。
！ 雰囲気で動詞化してみました。
@2015-03-04,(2) textfunc.ver2.js の⼀部を textfunc.jk.js
に分離した。
⁑ 今は無駄だけど将来のうっかりな変更にそなえて。
⁂ うっかりな変更を許さない。
*4 うっかりしたコードが存在しないこと。
詳細 getComputedStyleを textfunc内から取り除くことは機能
低下を招いてできないので、中間データをすべてため込んで DOM
操作を最後にまとめて⾏うことにした。それだけ。副作⽤で GCで
きない使⽤中のメモリが⼀時的に増える。ちなみに
Blink(Opera28)では悪化も改善もしない。Firefox(23)には最適化
の余地があるってことだ。
See also...
カテゴリ[Firefox]の他の⽇記
1. 2014年10月30日p01CSP WARN: Directive inline script base
restriction violated
2. 2014年 3月12日p01[tDiary] input type="text" フォーカス 全
体選択 キャレット位置喪失
3. 2013年11月 1日p01[tDiary][正規表現][javascript]
Firefoxが句点を⾏頭に送ってしまうのがあまりに⽬障りで
もう耐えられないので〜正規表現(Rubyに劣る
ECMAScript仕様)〜禁則処理(IE完璧。Firefox/Safariに
指導)〜両端揃え(IE完璧。Firefox満⾜*。Safariを補完)
〜画像とCSSのDPI〜字詰め
4. 2013年 2月 9日p01クラッシュに備えてアドオンリスト。
5. 2010年 8月28日p02plugin-container.exe
カテゴリ[javascript]の他の⽇記
1. 2013年11月 1日p01[tDiary][Firefox][正規表現] Firefoxが
句点を⾏頭に送ってしまうのがあまりに⽬障りでもう耐え
られないので〜正規表現(Rubyに劣るECMAScript仕様)
〜禁則処理(IE完璧。Firefox/Safariに指導)〜両端揃え
(IE完璧。Firefox満⾜⁑。Safariを補完)〜画像とCSSの
DPI〜字詰め
2. 2011年11月 9日p01[本] アマゾンの URLに含まれる ISBNっぽ
い数字を紀伊國屋書店BookWebで電⼦書籍検索するブック
マークレット。
3. 2011年 9月16日p01trailing commas ,
4. 2010年11月25日p01アマゾンの URLに含まれる ISBNっぽい数
字をジュンク堂で検索するブックマークレット。
5. 2010年 1月31日p01JSLint
カテゴリ[tDiary]の他の⽇記
1. 2013年12月 9日p03脚注プラグイン(footnote.rb)とセルフリ
ンクプラグイン(my-ex.rb)の組み合わせ問題
2. 2013年12月 9日p01[正規表現] tDiary⽤MathMLプラグイン(xmath.rb)の置換⽤正規表現
3. 2013年11月 1日p01[Firefox][正規表現][javascript]
Firefoxが句点を⾏頭に送ってしまうのがあまりに⽬障りで
もう耐えられないので〜正規表現(Rubyに劣る
ECMAScript仕様)〜禁則処理(IE完璧。Firefox/Safariに
指導)〜両端揃え(IE完璧。Firefox満⾜⁂。Safariを補完)
〜画像とCSSのDPI〜字詰め
4. 2012年11月28日p01Wikiスタイル(hikidoc.rb)にルビを。
(impl_ruby_markup.rev1.1.patch)
5. 2012年 1月15日p01SourceForge.net: tDiary:
TDiary::Plugin の多重初期化を減らしたい
カテゴリ[正規表現]の他の⽇記
1. 2013年12月 9日p01[tDiary] tDiary⽤MathMLプラグイン(xmath.rb)の置換⽤正規表現
2. 2013年11月 1日p01[tDiary][Firefox][javascript]
Firefoxが句点を⾏頭に送ってしまうのがあまりに⽬障りで
もう耐えられないので〜正規表現(Rubyに劣る
ECMAScript仕様)〜禁則処理(IE完璧。Firefox/Safariに
指導)〜両端揃え(IE完璧。Firefox満⾜*4。Safariを補完)
〜画像とCSSのDPI〜字詰め
3. 2010年 9月 7日p01[SakuraEditor] 検索。置換。
4. 2010年 7月 9日p01[SakuraEditor] 「⻤⾞と bregonigに
hitEnd(20100531p01)機能が搭載されることを願う他⼒本
願⽇記」
5. 2010年 5月31日p01requireEnd(), hitEnd()
翌⽇へ 前⽇へ
この⽇記上またはこの⽇記からリンクしたこのサーバー上のファイルのスクリプトとソースコードのうち⾃分の
⼿によるものは「煮るなり焼くなり好きにしろライセンス(NYSL Version 0.9982)」に従います。
Generated by tDiary version 2.3.3.20091124
Powered by Ruby version 1.8.7-p371