Apply a different style to each button on a ToggleButtonBar

<?xml version="1.0"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">
	<mx:Style>
		.styleA {color: #333399;}
		.styleB {text-decoration : underline;}
	</mx:Style>
	<mx:Script>
		<![CDATA[
			private function creationCompleteHandler():void
			{
				Object(test.getChildAt(0)).setStyle("styleName", "styleA");
				Object(test.getChildAt(2)).setStyle("styleName", "styleB");
			}
		]]>
	</mx:Script>
	<mx:ToggleButtonBar id="test" creationComplete="creationCompleteHandler();">
		<mx:dataProvider>
			<mx:Array>
				<mx:String>AAA</mx:String>
				<mx:String>BBB</mx:String>
				<mx:String>CCC</mx:String>
			</mx:Array>
		</mx:dataProvider>
	</mx:ToggleButtonBar>
</mx:Application>

SVNをめぐる攻防

あるクライアントとのVPNがようやく開通….ああ、よかったあ。
それにしてもなかなかつながらなかったなあ。

ファイルのバージョン管理については2年ほど前から掛け声が響く割になかなかうまくいかず、まずはローカライズチーム内の担当者とSkypeで1時間にわたるテストを行った。「アーだめだねえ!エンハンスするね!」ということになり、しばらくそのまま。いつまでこのままなのかなあと思っていたら、どうやら2月末までには絶対につなげ!というお達しがあったらしく、気合いが入ってきた。
一斉に再テスト開始。
接続テスト用の資料は整備されていたが、情報が「ちと古い」ため Cisco クライアントの自動インストールができない。クライアントをサイトから直にダウンロードしてインストール。リポジトリのあるサーバーにアクセスしてみたが、やはりつながらない。こっちの問題じゃないよなあと、「問題はこちらにはない!そちらにある!」的アピール資料を弊社のエンジニアMさんがいろいろ作ってくれて、あれやこれやの手で粘り強く伝えた結果、ようやく「やっぱこれ内部的に悪いのかも」ということになったらしい。あーよかった。一歩前進。そのうちなんとかサーバーの入り口までは繋がるようになった。でも依然リポジトリまではつながらない。

MさんはMSの更新プログラムが原因かも!ということで、その更新プログラムを外した環境を作って試してみたりもしてくれたのですが、やっぱり駄目。

そのうち、「君のアカウントはExpireしているよ!」と言われた。えー!でもそのアカウントでポータルに行けてるよ!と伝えると、「interesting………」となりまたしばらく動きのない1か月が過ぎた。

大企業だとこういうアカウントの管理は各チームが個別に行っていて、串刺しで一気に変更!みたいなことは出来ないらしい(確かこの会社こういうの一気にできるアプリケーションを開発しているんじゃなかったっけなあ)。

中国が春節の休暇に入り、また一週間凍結か、と思いきや、突然問題がエンハンスされ、担当にアサインされた担当者から1対1のセッションが通告された。つまり、いまだに接続できないベンダーをマンツーマンで1ベンダーごとつぶしていく、というやり方。本気になればやはり大企業はすごい。各Certificateの担当者がONLINEで繋がる中、USAの西海岸時間に合わせた朝7時からの2時間半にわたるセッションの結果、やったーーーー!やっとつながったーーーーー!

さて、何が悪かったのか。どうも、特定のアカウントのCertificateの期限が外部対応と内部対応で異なっていたということらしい。つまり、外部的にはOKだったアカウントが実は内部的にはExpireしていたため繋がらなかったのだ。
まあ原因はどうあれ、結果オーライ!

さあこれからマニュアルをしっかり読んで実地開始です。
それにしてもエンジニアのMさんの粘りには本当に助けられました。ありがとうございました。お疲れさまでした。粘りもDEPROのFeatureです!

IE9のType1フォントにまつわるバグ

ie9_type1

Windows 7への移行も順調に進んでいたところ、ちょっとした問題に遭遇してしまいました。その原因と解決法をご紹介します。

問題
特定のhtmlファイルをIE9で開くと、何も表示されないか、ブラックアウトしてしまう。

解決法
フォントフォルダにインストールされている次の(Postscript)Type1フォントを削除する。

「Courier、Helvetica(場合よってはTimes、Symbol)」

事の発端は、同じWin7でも環境によって表示できないオンラインヘルプがあるということでした。キャッシュの消去や設定の初期化、ビデオドライバの更新などを行いましたが、問題は解決出来ませんでした。

あれこれ調べていくうちに、次のサイトに辿り着きました。

IE9にはType1フォントを上手く扱えないバグがあるとのこと。CSSにHelveticaやCourierの指定があると問題が発生します。回避策は該当するフォントを削除する、あるいはIE9用CSSを使用するなどが紹介されています。

MSはこの問題を把握しており、今後修正するとしています。しかし、IE10にも同様な問題があるところをみると、修正のプライオリティは残念ながら低いようです。

今回のケースはWin7の問題と言うよりもブラウザの問題なのですが、IEで開けないページがあるようでしたら、まずはフォントフォルダをご確認いただければと思います。WindowsでType1フォントをインストールするユーザといえば、デザイン、DTP業界かと思いますので、くれぐれもご注意いただければと思います。

2013年は64bit元年

今年もよろしくお願いします。

2014年4月にWindows XPのサポート期間が終了するのをご存知でしょうか。サポートの終了で、新たなセキュリティ修正プログラムの提供も行われなくなります。

これを受けて、弊社でもWindows 7 64bit版への移行を開始しました。2013年は「64bit元年」として新しい環境への引越しを加速していく所存です。

すでに数台の移行を完了しましたが、互換性のトラブルは予想よりも少なく「案ずるより産むが易し」といったところです。ハードウェアキー(ドングル)を使用したアプリでドライバが提供されないという問題もありますが、仮想環境の活用で対応できればと考えています。

移行にまつわるtipsでこれはというものがありましたら、今後こちらでご紹介できればと思います。

sdlxliffの保存に時間が掛かる

Trados Studio 2011からsdlxliffを保存する際、異常に時間が掛かるという現象が発生することがあるようです。その場合、数メガのファイルであっても、完了まで30分ほどを要します。

環境の詳細
Windows 7 64bit
Trados Studio 2011 SP2R
Microsoft Security Essentials(MSE)

原因
MSEのリアルタイム保護とTrados Studio 2011のコンフリクト
→ 試しにMSEのリアルタイム保護を停止してから保存を行うと、僅かな時間で完了する

回避方法
今のところ(2012.12.7 現在)、根本的な解決方法はありません。
A、Bのいずれかの方法を実行して回避します。

A. 他社のセキュリティソフトを使用する
B. MSEの設定で、Trados Studio 2011を監視対象から外す

ただし、Bの方法はセキュリティの監視レベルを下げることになりますので、一時的な特例措置と考えたほうがいいかと思います。

Tradosはパッチを当てて最新に

最近、Trados2011の案件がポツポツ出てくるようになりました。
少しずつノウハウを蓄積している最中なのですが、早速ちょっとしたトラブルに見舞われました。

ソースファイルはFrameMaker(mif)。sdlxliffからmifに書き出すと、クロスリファレンスのマーカーテキストが消えてしまうというものです。マーカー自体は残っており、その内容だけが綺麗さっぱり無くなっています。ちなみに、クライアントからはパッケージとしてファイルが支給され、プロジェクトの読み込みなどには問題が見られませんでした。

試しに自前の環境で同様にパッケージを作成し、mif書き出しを行なってみたところ、マーカーテキストはちゃんと残っていました。そこで、先方から支給されたsdlxliffと当方で作成したものを比較すると、明らかな違いが見つかりました。その抜粋をご覧ください。

当方でパッケージ作成したファイル(SDL Trados 2011 SP2R

<tag id=”3″>
<ph name=”Cross-Ref” word-end=”false” seg-hint=”IncludeWithText”><mk name=”Cross-Ref”/></ph>
<props>
<value key=”mtype”>9</value>
<value key=”mcurrpage”>9</value>
<value key=”unique”>1059038</value>
<value key=”markerValue“>マーカーテキストの内容</value>
</props>
</tag>

先方から支給されたファイル(SDL Trados 2011 SP1

<tag id=”3″>
<ph name=”Cross-Ref” word-end=”false” seg-hint=”IncludeWithText”><mk name=”Cross-Ref”/></ph>
<props>
<value key=”mtype”>9</value>
<value key=”mcurrpage”>9</value>
<value key=”unique”>1059038</value>
<value key=”value“>マーカーテキストの内容</value>
</props>
</tag>

赤色の部分のみの違いですが、これよってマーカーテキストが削除されてしまうことがわかりました。確認してみたところ、先方で使用しているTrados 2011はSP1とのこと、こちらでは最新のパッチを適用しSP2Rとなっています。

これはTradosすべてのバージョンにおいて起きうる問題です。たとえば、Trados 2007ではPowerPoint(pptx)用フィルタが当方で確認しただけでも3種類(バージョン)あります。数種類ある修正パッチの適用の差異で、インストールされるフィルタのバージョンも変化します。これがターゲットに書き戻せないというトラブルの原因となります。

弊社のポリシーとして、Tradosは常にパッチを当て最新のビルドを使用するようにしています。社内では統一が取れており細かいバージョンの差異は問題ないのですが、お客様とのやり取りの中でこのようなトラブルに見舞われることもあります。

解決法としては、やはり「常にパッチを当て最新のビルドを使用する」に尽きるのではないかと思います。クライアント、翻訳者、各々の環境において、最新パッチを見送らなくてはならない特別な理由がないかぎりは、最新パッチの導入にご協力を賜りたくお願い申し上げる次第です。

Change background color of specific rows for a Spark DataGrid

Change background color of specific rows where value in a cell matches the string “sample”.

<fx:Script>
	<![CDATA[
		import mx.core.ClassFactory;			
		import spark.skins.spark.DefaultGridItemRenderer;			

		private function test_itemRendererFunction(item:Object, column:GridColumn):ClassFactory {
			if (item == null) {
				return new ClassFactory(DefaultGridItemRenderer);
			} else {
				// if(item.d1=="sample") 
				if(item[column.dataField]=="sample") {
					return new ClassFactory(GrayGridItemRenderer);						
				} else {
					return new ClassFactory(DefaultGridItemRenderer);
				}
			}
		}			
	]]>
</fx:Script>

<s:DataGrid>
	<s:columns>
		<s:ArrayList>
			<s:GridColumn dataField="d1" headerText="h1" itemRendererFunction="test_itemRendererFunction"></s:GridColumn>
			<s:GridColumn dataField="d2" headerText="h2" itemRendererFunction="test_itemRendererFunction"></s:GridColumn>
			<s:GridColumn dataField="d3" headerText="h3" itemRendererFunction="test_itemRendererFunction"></s:GridColumn>
		</s:ArrayList>
	</s:columns>
</s:DataGrid>

GrayGridItemRenderer.mxml

<?xml version="1.0" encoding="utf-8"?>
<s:GridItemRenderer xmlns:fx="http://ns.adobe.com/mxml/2009" 
					xmlns:s="library://ns.adobe.com/flex/spark" 
					xmlns:mx="library://ns.adobe.com/flex/mx" clipAndEnableScrolling="true">	
	<fx:Script>
		<![CDATA[
			override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void {
				super.updateDisplayList(unscaledWidth, unscaledHeight);
				if (data && data[column.dataField]!=''){
					lblData.text = data[column.dataField];		
				}
			}
		]]>
	</fx:Script>
	<s:Rect top="0" bottom="0" right="0" left="0">
		<s:fill>
			<s:SolidColor color="#E0E0E0" alpha="0.5"/>
		</s:fill>
	</s:Rect>
	<s:Label id="lblData" top="7" left="7" bottom="5" color="0x000000" alpha="0.5"/>	
</s:GridItemRenderer>

Sort as a numeric type String for a Spark DataGrid in Flex 4

correct: 1,2,3,4,11,12,21
incorrect: 1,11,12,2,21,3,4

private function sortCompareFunction(obj1:Object, obj2:Object, column:GridColumn): int {
	var p1:Number = obj1[column.dataField];
	var p2:Number = obj2[column.dataField];

	if (p1 < p2){
		return -1;
	} else if (p1 > p2){
		return 1;
	} else {
		return 0;
	}
}
<s:DataGrid>
	<s:columns>
		<s:ArrayList>
			<s:GridColumn dataField="d1" headerText="h1" sortCompareFunction="sortCompareFunction"/>
			<s:GridColumn dataField="d2" headerText="h2" sortCompareFunction="sortCompareFunction"/>
			<s:GridColumn dataField="d3" headerText="h3" sortCompareFunction="sortCompareFunction"/>
		</s:ArrayList>
	</s:columns>
</s:DataGrid>

ノーブレークスペース

普通日本人が文書を書くとき大抵文字コードはシフトJISですが、ローカライズ業務やWEB業務では大抵ユニコード(utf-8またはutf-16)ですよね。中国語だろうが韓国語だろうが大抵の文字は埋め込めるので楽ちんなわけですが、それらのユニコードテキストファイルを読み込んで操作するプログラムを書くとき、いろいろはまることがあります。
今日は「半角スペース(U+0020)」と「ノーブレークスペース(U+00A0)」が混在したテキストではまりました。実体参照で書いてあればいいんですが文字そのものが入っていると普通のエディタで開いても一見同じ半角スペースなので違いが分からないんですよね。

Framemakerの奇妙なバグ

FramemakerからのPDF出力で、思わず「うーむ」と唸ってしまうバグに遭遇したのでご紹介します。

現象
PDFを出力すると、全ページ空白、あるいは210mm x 1mmという奇妙なサイズとなる。

環境
Windows XP SP3
プリンタドライバ Adobe PDF(Ver8/9)
Framemaker 7.2(p158)/9.0(p255)

原因
プリンタドライバ「Adobe PDF」の設定項目のうち、グラフィックス→印刷品質において
値が「3600dpi」あるいは「4000dpi」に設定されている
※ デフォルトは「1200dpi」


先日、wordの印刷で問題が発生しトラブルシューティングとして解像度を変更しました。それを忘れて元に戻さなかったのがいけなかったようです。

それにしても、FMからの出力はひと筋縄で行かないことが多いように感じます。そのたびに検証をするのですが、今回のパターンはドキュメント自体には問題がなく、ドライバの設定に辿り着くまでには時間がかかってしまいました。