2008.05.01

Live Mesh

面白いかもしれない。MS のファイル共有は Messenger はまだいいけど FolderShare は微妙だし、また一つファイル共有? と思っていたがそういうわけではなさそうだ。

An early look at Live Mesh for Developers の「Watch demo now」をクリックするとデモが見られる。Channel9 の Ori Amiga ビデオでは画面がよく見えなかったが、こちらの方が分かりやすい。ファイル共有、デスクトップ共有などのアプリケーションはあくまで実装の一つで、Live Mesh はプラットフォームだ、と Live Mesh の blog で言っているので、それなら、ともう少し見てみる気になった。

Silverlight が Flash に対する回答だとすれば、Live Mesh が AIR に対する回答になるのかもしれない。

| | Comments (1219) | TrackBack (0)

2008.02.01

WPF ListBox

WPF の ListBox は非常に強力で、ListBoxをカスタマイズして都道府県の地図を選択するUIを作成する なんてことができてしまったりする。配列データを表示する際には ListBox を使うと、データの追加処理や選択処理を全部やってくれるので便利だけど、まだ慣れないのか後で気がつくことが多い。

今回は Marquee。テキストの配列を受け取って、順次右から左にスクロールして表示する。最初 Canvas で考えていたけど、ListBox の親クラスである ItemsControl を使ってやる話が Web でちらほらとあり、そちらで挑戦。

WPF 流に慣れるまでに少しかかるけど、慣れれば便利。

| | Comments (3524) | TrackBack (0)

2007.12.14

WPF/XPS + IsSideways + Morisawa

WPF/XPS の縦書き Metrics を検証 から、キャノンの FontGallery など他数種のフォントを試して、TrueType および TrueType 出身の OpenType はだいじょうぶそうなことが確認できました。

とすると、Morisawa やおそらく他の Type 1 出身の OpenType が駄目なのは単なるバグではないかと。

互換性問題上厄介なバグを残してしまいましたが、WPF もどこかではもっときちんと縦書きをやる、という話もあるようだし、少なくともそこでは直るんでしょう。

| | Comments (53) | TrackBack (0)

2007.12.10

WPF/XPS の縦書き Metrics を検証

WPF 縦書き対応Font BlackBox の計算 とを組み合わせてみる。

MS Gothic
image

Meiryoimage

イワタ楷書
image

BlackBox が微妙に下にずれているのはご愛敬。

IsSideways なんて、縦書きとは無関係のプロパティだと主張しているようにも見えるが、縦書き用のテーブルを見て Baseline をきちんと中央に合わせているのが分かる。GSUB を見て自分で GlyphIndex を置き換えてやれば、「ー」や「。」も正しく表示される。

しかし。

Morisawa Jun 201 OTF
image

Baseline が合っていない。TrueType 系 OpenType はだいじょうぶだけど、Type 1 系 OpenType は駄目、ということかもしれない。

OpenType Specifications に日本語フォントの作り方が書いていないのでフォントのつくりに差が出てしまったか、WPF が Type 1 系に十分対応していないか、あるいはその両方の組み合わせか。

Word はしかしこのフォントでも正しく縦書きできる。それを XPS で保存しても正しく見える――と思ったら、XPS の中は Glyphs ではなく PNG 画像だった。WPF/XPS では対応しきれないフォントだとどこかで判断して、回避しているようだ。

| | Comments (1700) | TrackBack (1)

2007.12.08

Font BlackBox in WPF

フォントによって BlackBox の縦位置が正しく取れない問題 は、計算方法が違っていたらしい。だいたいにおいて高さが正しい BlackBox を取れていたのだから、TopSideBearingsBottomSideBearings を疑ったのは間違いだった。

image

DistancesFromHorizontalBaselineToBlackBoxBottom を使って BlackBox の下座標を取ることで、以前は BlackBox が上にずれていた英文フォントや一部の日本語フォントも正しくなりました。

あとは Vertical Origin が取れればそれなりの縦書きを実装できそうなのだが、これが見つからない。

| | Comments (147) | TrackBack (1)

2007.12.06

フォントによる WPF 縦書きの違い

IsSideways で正常に縦書き表示できるフォントの TopSideBearingsBottomSideBearings は正常に取得できる。

image

こうなってしまうフォントもある。このフォントでは IsSideways だけで縦書き仕様としてもうまく行かない。

image

GSUB の処理をアプリで回避したけど、縦書き用 GPOS  が処理できていないのか。あるいはフォント側の問題で、GSUB/GPOS ではなくて cmap を使ってレンダリングしてやらなければいけないのか。

Meiryo は縦書きできるけど、TopSideBearings と BottomSideBearings が怪しい。

| | Comments (565) | TrackBack (1)

2007.12.05

FamilyTypeface.DeviceFontCharacterMetrics

FamilyTypeface.DeviceFontCharacterMetrics から Unicode code point を使って CharacterMetrics が取れる、と書いてあり、ここには vertical origin はないものの、他の縦書きに必要な情報は取れそう、と思ったものの。

嘘です。FamilyTypeface.DeviceFontCharacterMetrics.Count は常に 0 のようです。他にも困っている人がいるみたい ですが。

| | Comments (354) | TrackBack (0)

2007.12.02

縦書きの XPS

WPF の縦書き、さらに続く でそこそこ表示できるようにはなったものの。

フォントによってはだめな場合がある、ということは、縦書きメトリックスの処理が XPS にきちんと入ってない、ということなんでしょうね。

横書きや BiDi では XPS が TrueType/OpenType のメトリックスを読んである程度までは並べてくれて、そこから上はアプリが処理、とわかれているのだから、本来であれば 中さんのおっしゃるよう に、XPS でももうちょっとサポートしてほしいのは確かです。

横書きでも、Word が XPS のレイアウトエンジンをそのまま使わずに、文字を分割してレイアウト位置を微調整することがある。どこまでが XPS で、どこまでがアプリケーションあるいはフレームワーク、という線引きはいつでも難しいけれど、横書きと縦書きで線引きの場所が違う、というのは、力の入れ具合の不足感を感じてしまいます。

縦書きって、BiDi のようにその国の人なら毎日必ず使うものではないので、という優先度なんでしょうが、やっぱりそれ抜きでは日本語組版を語れないかと。

| | Comments (70) | TrackBack (1)

2007.11.28

WPF の縦書き実証実験

句読点がこんな形の縦書き画面ショット だけ掲載しても後味が悪いので、さらに実証実験を続けます。

WPF の縦書き実証実験まず Word でメイリオを指定して、縦書きにして XPS で保存します。その中を覗くと、メイリオの句点「。」の縦書き用グリフインデックスが 9236 であることが分かります。

あとは、TextBox の Visual Tree を解析して GlyphRun を作る時に、「。」の場所だけ GlyphIndices を置き換えてやります。結果がこちら⇒

さて。できることは分かりました。句点の位置が少しずれただけだけど、先の画面での不思議な落ち着かなさがなくなりました。

あとは、フォントから GSUB を読み取って、vertvrt2 のテーブルに従って GlyphIndices を置き換えてやれば、すごく基本的な縦書きの表示まではできそうです。

問題は、これらのテーブルを読み取るための API が WPF にはないので、自作するか、Uniscribe を触ってみるか、というあたりで迷い中。

気がつけば、Microsoft Typography Specifications にはこれだけの言語のフォントの作り方がある のに、その中に日本語の縦書きについては記述がないですね。WPF 1.0 で縦書きを忘れられたのはこの辺から来ているのでは、という気もします。

| | Comments (201) | TrackBack (2)

WPF TextBox の Visual Tree

WPF の縦書きの続き にさらに続く。XamlPad で覗いてみる。

  • TextBox
    • TextBoxView
      • DrawingVisual
        • [0]=DrawingGroup
          • [0~n]=GlyphRunDrawing
            • GlyphRun

TextBoxView が TextFormatter.FormatLine を呼んで、帰ってきた結果の TextLine が GlyphRun を生成しているらしい。

LineServices は MurrayS が言っているように OS などに依存しない構造 なので、LineServices の callback を実装している TextLine あたりが Uniscribe で言うところの "Shaping" をしているのだろう。

WPF でまともに縦書きを実装するのがとても大変、というのはよくわかった。Wrapper をかませて、ちょいちょい、と遊ぶレベルでは実現できそうにない。

WPF の縦書き幸い、日本語の縦書き Shaping は、ほかの言語と違ってレイアウトに変更が出ない。固定幅フォントを使っている限り、縦書き用のグリフに置換しても文字の送りが変わらないからだ。

Visual Tree を VisualTreeHelper で覗いて、同じ構造を作りつつ、グリフ置換をすれば、なんとか縦に表示することはできそう。

とはいえ、グリフ置換をするためのテーブルを取得する API は WPF にはない。作るか、Uniscribe を使うか、というあたりで、これもなかなか難儀。まだ迷いは続く。

BiDi の Shaping をしっかりやったものを WPF 1.0 (.NET 3.0) にきちんと入れてきたんだから、日本の縦書きの Shaping なんて大したことないと思うですけどね。

| | Comments (281) | TrackBack (1)

より以前の記事一覧