DXL Step-by-Step：#22）文字の装飾

DXL 活用の調査・検証で、実現できたことや発見したことご紹介する『DXL Step-by-Step』シリーズの第 22 回です。 今回は、段落内に配置されるオブジェクトの中からテキストについてまとめます。

文字の装飾 と font ノード

文字サイズや太字や斜体などの装飾を変化させた文字を 1 つの段落内に配置するサンプルを作成してみました。

この文書を DXL に変換すると次のようになります。

まず、大前提として、文字の装飾が指定されていない部分である "の" や "です" は par ノード直下にテキストノードとして存在ます。装飾が指定されている部分については同じ装飾が指定されている範囲を run ノードで括り、そのサブノードとして font ノードとテキストノードが存在します。そして、装飾は font ノードの属性で指定されています。

この構造さえ理解できれば、 font ノードの属性を指定するだけで、自由に文字を装飾できることになります。

文字のサイズ

文字サイズを指定するには size 属性でポイント数を指定します。設定できる範囲は、プロパティボックスの設定では、フォントサイズは 1 ～ 250 までの値がセットできます。確認する限り、範囲外のサイズを指定しても保存（インポート）時にエラーにはならないようですが、指定したサイズで表示されないようです。

設定	属性	設定値
サイズ	size	ポイントを整数で指定（'1pt' 以上、'250pt' 以下）。
	（なし）	指定しない場合、10 ポイント。

また、size 属性を設定しない場合、10 ポイントとして取り扱われるようです。ためしにフォームでリッチテキストのサイズを 24 ポイントにして、size を指定せずにインポートしたところ、10 ポイントで表示されました。指定しない場合、フォームのフィールドのフォントにゆだねるというわけではなさそうです。

文字のスタイル

太字や斜体などの装飾の設定です。代表的な 4 種のみ記載しています。複数のスタイルをセットする場合、スペース区切りで指定します。

設定	属性	設定値
太字	style	'bold'
斜体		'italic'
下線		'underline'
取消線		'strikethrough'

文字の色

色の指定を行う属性は color となっています。設定法については下表のとおり 2 種類あります。

設定	属性	設定値
文字色	color	定義済みの 16 色については文字列で指定。 'red' や 'purple' など（下表参照）。
		RGB を 2 桁の 16 進数で指定。 先頭に # をつけ '#8242ff' のように記述。

プロパティボックスで文字の色を設定する際の上部にある 16 色が定義済みの色です。

DXL で指定できる色名は、それぞれ以下の通りです（画像と同じ順）。

white	yellow	lime	aqua	blue	fuchsia	red	silver
black	olive	green	teal	navy	purple	maroon	gray

なお、何も指定しない場合は 黒 となるのですが、'black' と指定しても 黒 となるようです。

フォントの指定

ノーツは一般にデフォルトフォントを呼ばれる 4 種類のフォントを使用します。デフォルトフォントは『Notes クライアントの基本設定』でクラアインと PC 内の実際のフォントにマッピングする仕組みとなっていて、クライアントごとのフォントの違いを吸収しやすいように作られています。

もちろん、デフォルトフォント以外のフォントもダイレクトに指定できます。例えば、リッチテキストに次のようにフォントをセットして DXL に変換してみます。

結果は次のようになりました。

まず、フォント名の指定は name 属性で指定することがわかります。そして、デフォルトフォントでない場合には、pich や truetype など複数の属性が付加されていることがわかります。これら属性の役割は現時点で不明ですが、name 以外の属性を省いた DXL をインポートしたところ正しくフォントが反映されました。フォントは name 属性さえ指定すればとりあえず OK ということなのでしょう。

設定	属性	設定値
Default Sans Serif	name	属性を作成しない
Default Serif		'serif'
Default Monospace		'monospace'
Default Multilingual		'multilingual'
その他フォント		フォント名を直接指定

パーマネントペン

リッチテキストには文字を強調するため、蛍光ペンでマーキングしたように背景色を設定する機能があり、パーマネントペンと呼びます。

今回初めて利用したのですが、パーマネントペンには 3 色の設定があるようで、DXL では次のように表現されました。

パーマネントペンペンの設定は run ノードの属性となっている点に注意が必要です。操作的には文字の装飾と同等のように感じるのですが、DXL 的には少し違うようです。難しいですね...

設定	属性	設定値
黄色	highlight	'yellow'
ピンク		'pink'
青		'blue'

まとめ

今回は、リッチテキスト内の文字の装飾と DXL の関係についてまとめました。

run というノードで括りその範囲に対して文字の装飾を font ノードとその属性で詳細に指定するという点がポイントですね。

前回

DXL Step-by-Step

次回

DXL Step-by-Step：#21）段落内に入るオブジェクト

DXL 活用の調査・検証で、実現できたことや発見したことご紹介する『DXL Step-by-Step』シリーズの第 21 回です。

近い将来、DXL を利用したサンプル DB の公開の計画があり、そこで使用する機能までは記事にしておきたいと、この連載を連投しています。もうしばらく DXL ネタが続きますが、ご了承ください。また、サンプル DB が公開されましたら改めて紹介記事を投稿いたします。

さて、前回までは段落を表す par ノードの定義について数回にわたってまとめました。要は段落全体の書式設定に当たる部分でした。今回からは、par ノードの中身、段落内のコンテンツがどのように表現されるかについてまとめます。

サンプルと DXL

サンプルデータとしてリッチテキストに次のようなデータを入力した文書を作成してみました。

文字だけでなく、イメージリソースや URL リンクなどを配置しています。なお、各行は Shift + Enter で改行しており、全体が一つの段落となるようにしています。

この文書を DXL に変換すると、リッチテキストフィールドは次のように表現されます。

まず、par ノードは１つしかありませんので、段落が 1 つであることがわかりますね。

そして par ノードの中には、入力した文字やさまざまなサブノードが作成されていることが確認できます。このように、各種ノードを順に配置することにより、段落内に柔軟にオブジェクトを配置できる仕組みとなっています。

では、各サブノードを順に確認しましょう。

テキスト

最初は文字（テキスト）です。DXL の以下の部分です。

入力した文字がそのまた羅列されているただの文字列ですが、DXL では、これもノードとして取り扱われます。NotesDOM クラスでは、NotesDOMTextNode で扱われます。タグで挟まれていないのが特徴ですね。

段落内の改行

次は Shift + Enter で入力する段落内の改行です。ノードは次の通り "<break />" となります。

画像

画像は <picture> タグで表されます。属性で画像のサイズを指定しています。また、サブノードで表示する画像を指定しています。今回はイメージリソースなので、その名称を指定されていることがわかります。

画像の横には『← 左の画像はイメージリソースです』と表示していました。この文字列が <picture> タグに続き、テキストノードとして出力されています。このような構造となることで画像の横に文字列（テキスト）が配置できています。

文字の装飾

次は太字や色の変更を行う文字の装飾です。まず、<run> というタグで設定する範囲を決定し、サブノードとして装飾の設定 <font> タグとテキストノードが存在します。

<run> というタグ名からこの機能が想像できないので、辞書で run という単語を調べてみたところ、『［範囲などが］及ぶ、広がる』という意味があるようです。私は英語は苦手なのですが、きっとこれが理由なのでしょうね...

URL リンク

最後の例は、URL リンクです。以下の赤枠の部分が URL リンクの DXL です。URL は href 属性で表されていますね。また、リンクの文字列はテキストノードとなっていますが、装飾を指定するため <run> ノードで括られています。

URL の前後には、リンクではない文字列を配置していました。これらが、<urllink> タグの前後に存在します。ここまでの例を総合すると”なるほど”という感じですね。

まとめ

段落 <par> ノードの中に配置されるサブノードを事例とともに紹介しました。どのような構造でリッチテキスト内のコンテンツ（オブジェクト）が管理されいるのか概要がつかめたかと思います。

今回は概要をつかむことが目的だったので、各オブジェクトのノード名を紹介する程度の解説にとどめました。 今後はそれぞれのオブジェクトについて掘り下げたいと思います。

前回

DXL Step-by-Step

次回

DXL Step-by-Step：#20）pardef と par ノードの関係② インポート時

DXL 活用の調査・検証で、実現できたことや発見したことご紹介する『DXL Step-by-Step』シリーズの第 20 回です。前回に引き続き、pardef と par ノードの関係の調査なのですが、今回は、テスト的に手書きした DXL を文書としてインポート（保存）させ、より詳しく条件を調査します。

定義位置のテスト

padef の定義の前に id を使用した場合のテストです。次のように、pardef の前後にその礼儀を使用した段落 par を配置してみました。

作成した文書は次の通りで、１行目には行間がセットされず、２～３行目は正しくセットされています。この結果より、pardef の定義は使用する前に設定しないと無視されるようです。

ちなみに、作成した文書をもう一度 DXL に変換すると次のようになりました。１行目の前に pardef ノードが挿入され、id が再付番されています。

この結果より、DXL で記述した通りに保存されるのではなく、ドミノオブジェクトとして正しい状態に調整して保存していること、id は関連付けが目的で番号自体に意味はないことがわかりますね。

定義位置と id

続いては複数の実験をまとめて行います。テスト項目は次の３点です。

1. pardef の定義は直前である必要があるか？
2. pardef は使用する順で定義しなければならないか？
3. id は 1 から連番で付与する必要があるか？

テストする DXL は次の通りです。

この DXL はエラーもなくインポートでき、正常に２～３行目だけ行間が設定されました。

pardef は先頭にまとめても正常に動作するんですね。まとまっているほうが、見やすいですし、書式の種類の確認など簡単になると思うんですけどね...

複数フィールドと id

最後に複数のリッチテキストがある場合についてテストします。前回の確認では、既存文書を DXL に変換すると次のような変わった仕様が確認できました。

• pardef の定義はフィールドごと
• id は文書内でユニーク

これが必須なのか確認するため次のような DXL を作成してみました。各フィールドで同じ id を設定しています。

インポートは正常に終了し、各フィールドとも行間は正しく設定されていました。この結果より、フィールド内で整合性が正しければ正常にインポートできることが確認できました。

まとめ

pardef と par の関係を２回にわたって調査しました。その結果をまとめると次のようになります。インポートでは、今回の実験で最低限守ればよい条件を記述しています。

	エクスポート	インポート
pardef	初回使用の par ノードの直前	使用前に定義すればよい 先頭にまとめてもかまわない
id 付番	文書内で連番	フィールド内でユニークであれば連番でなくてもよい
定義の重複	同じスタイルを複数の pardef で定義しても問題なし

DXL を利用してリッチテキストを含む文書を作成する場合、pardef と par ノードを正しく記述できないと、希望通りのフォーマットで表現できません。

ただ、今回のテストで、思った以上におおらかな仕様であることがわかりました。エクスポートと同じ仕様で DXL を自作するなら大変そうですが、今回の実験で得た最低限の条件を守るだけなら少し楽ができそうですね。

前回

DXL Step-by-Step

次回

DXL Step-by-Step：#19）pardef と par ノードの関係①

DXL 活用の調査・検証で、実現できたことや発見したことご紹介する『DXL Step-by-Step』シリーズの第 19 回です。リッチテキストの構造を理解する上で一番不明瞭と思われる pardef と par ノードの関係について整理します。

pardef と par ノードとは

まずはおさらいです。#15）リッチテキストを構成する基本要素 で、これらノードの役割を紹介しました。

• pardef ノードは段落のスタイルを定義
• par ノードは段落のコンテンツを定義
• par ノードに適用されるスタイルは、def 属性に pardef の id で指定

上記 DXL を例にすると、段落スタイル（pardef ノード）の id は '1' と '2' の 2 種類が定義されいいます。コンテンツ（par ノード）で、def='1' のなっている行は '1'、def='2' のなっている行は '2' の段落スタイルが適用されます。リッチテキスト内で同じスタイルを複数回使用する場合、事前に定義した id を指定するだけでよく、記述が簡素化できるようになっています。

また、pardef による定義は、par ノードで使用する前に定義しておく必要があるようです。

なお、入力の仕方にもよるのですが、スタイルの id が再利用される場合（def='1'）とされない場合（def='3'）がありました。同じスタイルを複数の id に定義することができるようです。そして、id の '1' は必ずしも、何も設定されていない <pardef id='1' /> に限定されているわけではなく、属性が設定されることもあるようです。

複数のフィールドの場合

３つのリッチテキストフィールドを持つフォームを作成し、それぞれに同じ段落スタイルで文字を入力した文書を作成してテストします。

これを DXL で出力すると次のようになりました。

この結果より、pardef による定義はリッチテキストごとに実施する必要があることがわかります。ところが、id の付番については文書内でユニークとなるようです。なかなか複雑？不思議？な仕様ですね。

次回の予告

今回は既存文書を DXL で出力させ、pardef と par ノードの関係を調査しました。結果、さまざまな条件や仕様が見えてきました。次回はこれらが必須条件なのか確認するため、テストの DXL を文書としてインポート（保存）させる実験を行います。

前回

DXL Step-by-Step

次回

DXL Step-by-Step：#18）段落の定義③ インデント

DXL 活用の調査・検証で、実現できたことや発見したことご紹介する『DXL Step-by-Step』シリーズの第 18 回です。前々回からまとめている段落の書式を定義する pardef ノードに関してです。今回はインデントの設定を紹介します。

インデントの設定

段落の設定で最初の行を字下げすることをインデント、その逆でほかの行よりも左に出すことをアウトデントと言います。ノーツのプロパティボックスでいると以下の設定ですね。

ショートカットキーでは、インデントが F7、Shift + F7 がアウトデントの設定になります。私はプロパティボックスを使用するより、左余白を操作する F8、Shift + F8 とあわせて、キーボード操作で行うことが多いです。

また、より詳細な位置設定をする場合には、ルーラを使用します。▼ がインデント、▲ が左余白の設定となります。ちょっと小さくてドラッグしにくいですが、視覚的に設定できて便利ですよね。

では、以下のように設定したリッチテキストを DXLで出力してみます。１つ目の段落がインデント、２つ目の段落がアウトデントの設定をしています。

出力した DXL のリッチテキスト部分は次の通りです。

firstlineleftmargin という属性が出力されています。その名の通り、１行目の左マージンの設定です。前回登場した leftmargin 属性と組み合わせて、leftmargin ＜ firstlineleftmargin ではインデント、leftmargin ＞ firstlineleftmargin ではアウトデントとなるということですね。

この属性の設定についてまとめると次の通りとなります。

設定	属性	設定値
最初の行	firstlineleftmargin	１行目の左マージンインチで指定（'0in' 以上）。 ２行目以降は leftmargin 属性で設定。 設定がない場合、すべての行が leftmargin でそろう。

pardef ノード まとめ

第 16 回 から 3 回にわたって  pardef ノードの属性について整理しました。

pardef ノードは、段落の書式を定義するためのノードで、行間や文字揃え、余白の設定、インデントの設定を紹介しました。そのほかにも、リスト（箇条書き）やタブ位置の設定も pardef  ノードの役割となっています。

まだ紹介していない属性は、別途まとめるとして、話を先に進めたいと思います。次回は、pardef ノードと par ノードの関係について、実験結果をまとめます。

前回

DXL Step-by-Step

次回

DXL Step-by-Step：#17）段落の定義② 余白の設定

DXL 活用の調査・検証で、実現できたことや発見したことご紹介する『DXL Step-by-Step』シリーズの第 17 回です。前回に引き続き、段落の書式を定義する pardef ノードについてまとめます。

余白の設定

文字のプロパティの［段落余白］の設定です。

まずは、使用頻度の高い余白の "左" の設定です。以下のようにいくつかの設定を行い確認します。

変換された DXL は次の通りです。余白の左の設定は、leftmargin 属性で記述されていて、単位はインチとなっています。

設定されている数値より、F8 や Shift + F8 による余白の移動量は 0.5 インチ単位であること、デフォルトの位置が 1 インチであり、その場合は属性が出力されていません。また、最小値は 0 インチであることが確認できます。

続いては、右の設定と相対位置の設定に関してです。

以下のように余白の右を絶対位置で 10cm、左右を相対位置（％）で指定した場合を確認します。

DXL に変換した結果は次の通りです。

プロパティボックスで 10cm と入力したのですが、DXL ではインチに変換され '3.9368in' となっています。内部的にはすべてインチ管理のようですね。プロパティボックスで、9.999cm となっているのも変換時の誤差によるものなのでしょう。きっちりした値が cm で入力できない理由がよくわかりますね...

余白設定まとめ

上記実験結果を整理して、余白の設定と DXL の関係をまとめます。

設定	属性	設定値
左	leftmargin	絶対位置ではインチで指定（'0in' 以上）。 相対位置では百分率で指定（'0%' 以上、'100%'以下）。 左右とも設定する場合、左 < 右。
右	rightmargin

インチとセンチ

今回の調査で、DXL の長さの単位はインチとわかりました。少なくとも国内においてはセンチメートル（以下 cm）になじみのある方の方が圧倒的かと思います。そこで、この連載においては数値で扱うのは cm、DXL に入出力するときだけインチに変換することとします。

1 インチは 2.54 cm です。インチに変換する際は 2.54 で割ればよいことになります。先の例で、10 cm は '3.9368in' に変換されていました。電卓で計算すると 10 ÷ 2.54 = 3.93700...、プロパティボックスの値をもとにすると 9.999 ÷ 2.54 = 3.9366... となります。

状況からすると、10 cm という入力に関して、インチに変換した値を cm に戻しプロパティボックスに表示、それをまたインチに変換しているようです。そして、変換時は少数第 5 位で四捨五入していると想定できます。

少し細かな話になりましたが、端数処理はおおらかな処理となっているようですね。

変換用関数

今後 DXL のコーディングでは、この変換が発生します。そこで、あらかじめ関数作成しておきましょう。内部的にはすべて cm、DXL ではインチを使用することから、cm の値は数値、インチの値は文字列で扱い、取り違えをなくすよう工夫してみました。また、丸め処理に関しては、値が大きくなるのは避けるべきと考え、端数は切り捨てとしています。

作成した関数は次の通りです。また、今回からスクリプトライブラリ lsDXL を新規作成し、共通関数を管理することとします。文字列のインチから数値の cm を取得する関数 DXL_InchToCM と その逆の DXL_CMToInch の 2 つの関数です。

Option Declare Public Function DXL_InchToCM(ByVal vsDXL_Inch As String) As Double    Dim dCM As Double    Dim sTmp As String    On Error Resume Next    dCM = 0    '単位の "in" を削除    sTmp = Replace(vsDXL_Inch, "in", "")    '数値に変換    If IsNumeric(sTmp) Then       'cm に変換       dCM = CDbl(sTmp) * 2.54       '少数4桁目以降を削除       dCM = Int(dCM * 1000) / 1000    End If    DXL_InchToCM = dCM End Function Public Function DXL_CMToInch(ByVal vdCM As Double) As String    Dim dInch As Double    Dim sInch As String    On Error Resume Next    sInch = ""    'インチに変換    dInch = vdCM / 2.54    '少数5桁目以降を削除    dInch = Int(dInch * 10000) / 10000    sInch = CStr(dInch)    '変換エラーの場合は 0in とする    If sInch = "" Then       sInch = "0in"    Else       sInch = sInch & "in"    End If    DXL_CMToInch = sInch End Function

前回

DXL Step-by-Step

次回

DXL Step-by-Step：#16）段落の定義① 行間隔と文字揃え

DXL 活用の調査・検証で、実現できたことや発見したことご紹介する『DXL Step-by-Step』シリーズの第 16 回です。前回からはリッチテキストの構造についてまとめていますが、今回は、段落の書式を定義する pardef ノードについて整理します。

行間隔

まずは、文字のプロパティの［段落整列］タブ、行間隔の設定です。

この設定を変えながら DXL を出力して pardef ノードの変化を確認します。例えば、以下のように 1 段落目は 行間 1 / 上 1.5 / 下 2、2 段落目は 行間 1.5 / 上 2 / 下 1 とに設定します。

DXL で確認すると次のように出力されます。

この結果より、行間隔の設定と DXL の関係は下表の通りとなります。

設定	属性	設定値
行間	linespacing	'1.5' または '2' を指定。 '1'（デフォルト）の場合は属性を作成しない。
上	spacebefore
下	spaceafter

ちなみに、上記属性に '1' を指定して保存（Import）してもエラーにはならないようです。

文字揃え

続いては、文字揃えの設定に関してです。文字のプロパティでは 5 種類の中から設定できます。

行間隔と同様の方法で書く設定と DXL の関係を調べると次の通りでした。

設定	属性	設定値
左揃え	（なし）	指定しない。
中央揃え	align	'center'
右揃え		'right'
両端揃え		'full'
なし		'none'　（折り返ししない設定）

参考までに各設定を DXL で出力した結果は次のようになります。

まとめ

段落の設定で使用頻度の高い設定を例に DXL でどのように扱われているかをまとめました。個人的な感想ではありますが、難解な DTD を読み解くよりも、実際に出力させた方が端的でわかりやすいと感じました。手間と時間はかかりますが...

前回

DXL Step-by-Step

次回

DXL Step-by-Step：#15）リッチテキストを構成する基本要素

DXL 活用の調査・検証で、実現できたことや発見したことご紹介する『DXL Step-by-Step』シリーズの第 15 回です。今回からはリッチテキストフィールドの構造について調査した結果をまとめます。

リッチテキストと段落

まずは、単純な例です。リッチテキスト（Body フィールド）に 3 行分の文字を入力して DXL で出力すると次の通りとなります。

続いて、2 行目だけ行間を 1.5 に変更して、DXL を確認します。

これで、各ノードの関係が見えてきますね。

行間を変更した 2 行目の前の pardef id='2' の行が増えていて、2 行目を表すノードの属性が def='2' となっています。この結果より、各ノードの役割が読み取れます。

• pardef ノードは段落のスタイルを定義
• par ノードは段落のコンテンツを定義
• par ノードに適用されるスタイルは、def 属性で pardef の id を指定

ちなみに段落とはリッチテキスト内のコンテンツを管理する１つの単位ですが、文字プロパティの［段落整列］タブの設定が有効な範囲と言えばわかりやすいですね。

この段落に配置できるのは文字だけでなく、添付ファイルや画像、ホットスポットなどさまざまなオブジェクトがあります。これらはすべて par ノード配下のサブノードとして作成されます。

ただ、いくつか例外があるので確認しましょう。

表と DXL

リッチテキスト内に次のように表を追加した場合の DXL を確認します。

すべてを表示すると長くなるので、一部省略していますが DXL は次の通りです。表を挿入すると表の前後に 1 行ずつ段落が挿入されますよね。DXL では、その段落も表現されています。

表は table というノードで表現されています。表の構造については別途詳しくまとめますので、今回は割愛します。

現時点でのポイントは、table ノードは、段落（par ノード）配下になっていない点です。par ノードと同じ階層、並列に表現されていますね。

まとめ

上記事例のように richtext ノード直下には配置できるノードが限定されているようです。現時点で確認できている範囲では次の 4 種です。

pardef	段落の定義
par	段落
table	表
section	セクション

前回

DXL Step-by-Step

次回

DXL Step-by-Step：#14）文書のフィールドと DXL

DXL 活用の調査・検証で、実現できたことや発見したことご紹介する『DXL Step-by-Step』シリーズの第 14 回です。

今回は文書内の主なフィールドがのように DXL で表現されているかまとめます。文書にテストしたい形式のフィールドを作成し、DXL に出力した結果を整理します。

フィールドと DXL

まずは、基本的なフィールド形式を調査します。テキスト、数値、日付フィールドに単一の値と複数値（リスト値）をセットした場合の DXL です。

種類	単数値	複数値
テキスト	<item name='Text'>     <text>テキスト</text> </item>	<item name='Texts'>   <textlist>     <text>テキスト１</text>     <text>テキスト２</text>   </textlist> </item>
数値	<item name='Number'>   <number>123</number> </item>	<item name='Numbers'>   <numberlist>     <number>111.11</number>     <number>2.2222</number>   </numberlist> </item>
日付	<item name='Datetime'>   <datetime>20240102</datetime> </item>	<item name='Datetimes'>   <datetimelist>     <datetime>20240101</datetime>     <datetime>20240102</datetime>   </datetimelist> </item>

item タグの name 属性でフィールド名を表しています。これは、すべてのフィールドタイプで共通ですね。

DXL はただの文字列ですので、データ型を示すタグ <text>、<number>、<datetime> で値の型を表し、そのタグで囲われた範囲が値となります。複数値の場合は、<???list> とどのような型のリスト値か示し、その中に値が羅列される構造となっています。

単数か複数値で階層構造が違う点に注意が必要ですね。

選択フィールド

フォームに作成できるフィールドには、ダイアログリストやチェックボックスなど選択を補助する UI を持ったフィールドが存在します。

これらのフィールドは、文書のプロパティで見るとテキストフィールドと同じ形式でデータを保持しています。DXL での表現もテキストフィールドと同じとなります。例えば "CheckBox" というチェックボックスフィールドで、"bbb" と "ccc" をチェックした場合、次のようになります。

<item name='CheckBox'>   <textlist>     <text>bbb</text>     <text>ccc</text>   </textlist> </item>

フォームは、文書を表示するためにデザインや UI を提供する設計であり、文書（データ）とは分離して保持していることがよくわかりますね。

リッチテキスト

リッチテキスト内には、テキストだけでなく、表や画像、添付ファイルなどさまざまなオブジェクトを保存できるとても便利なフィールドです。このフィールドの中身についても、DXL は対応しています。単純な例でですが、リッチテキストを DXL に変換すると次のようになります。

<item name='Body'>   <richtext>     <pardef id='1'/>     <par def='1'>       ここは       <run>         <font size='12pt' style='bold' color='red'/>         リッチテキスト       </run>       です。     </par>   </richtext> </item>

フィールド内のデータ型を表す部分が <richtext> となっていて、その内部にリッチテキスト内のオブジェクトが文字列（DXL）で表されるという構造であることがわかります。フォントのサイズや装飾がタグや属性で表現されていることが読み取れますね。

次回以降の予告

リッチテキストをプログラムで操作するには、LotusScript の NotesRichTextItem などの標準クラスを使用することになります。詳しくは、別の連載『リッチテキストの基本操作』でまとめていますので必要に応じて参照ください。この連載の 第 13 回 の最後で少し触れましたが、標準クラスリッチテキスト内のすべての操作を行えるわけではなく、一部操作できないことがあります。

DXL では、リッチテキスト内部をかなり詳細に表現してくれます。構造を理解し、プログラムで操作することにより、標準クラスでは実現できなかったことができるようになります。

次回からは、リッチテキストの内部構造を紐解いていきたいと思います。まだまだ調査中の段階ではあるのですが、わかったことから順にまとめます。

前回

DXL Step-by-Step

次回

新企画：出直し!! ヘルプ

みなさま、あけましておめでとうございます。本年もどうぞよろしくお願いいたします。

今年は就職してちょうど 30 年、そしてノーツを担当して 30 年です。社会人生活をまるっと支えてもらった Notes/Domino にご奉公するべく、さまざまな活動をしております。アニバーサリーイヤーの本年はより積極的に活動しますので、どうぞよろしくお願いいたします。

さて、このブログもその一環で昨年 3 月に始めました。Notes/Domino に関する情報ってネット上に少ないですよね。それを少しでも補完することが目的で始めました。特に初中級の技術者がステップアップのきっかけになるようなネタを中心に進めているつもりです。

実はこのブログにはもう一つ別の動機がありました。それは自身が利用できるヘルプの構築です。

あんちょこ

日々開発作業をしているとよく使う機能があることに気がつきます。その都度、前回使ったであろうアプリケーションDBを思い出し設計を開いてコードを確認するのは非効率です。ライブラリ的なものがあれば便利だなと思っていました。

お客さまの環境、ノーツコンソーシアムの研究会など複数の環境を行き来して、Notes/Domino を利用しています。作成したライブラリをどの環境にいても参照するには、インターネット上のブログが最適だったんですね。

そこで、このブログ上にまとめることにしました。右メニューの［ラベル］から ”あんちょこ” を選択するとその一覧が確認できます。

現時点でこのラベルを一番利用しているのは私だと思います(笑)

出直し!! ヘルプ

もう一点、開発していて改善したい点があります。それは、ヘルプです。

Domino Designer にはヘルプがありますが、利用者目線では、次のような点が気になっています。

• ヘルプが英語（9.0.1 の途中の FP 以降）
• 情報量が多すぎておぼれる
• 実用的な例が少ない

もちろん、開発に必要な情報は網羅されてはいるのですが、Notes/Domino の守備範囲が広いため膨大な情報量です。必要なヘルプを探し出すのに慣れが必要で、階層が深く少し時間がかかります。

また、Domino Designer ヘルプはインターネット上で公開されていて、ブラウザの検索機能経由で必要なヘルプを簡単に見つけられます。ただ、日本語で記述された旧バージョンのものや HCLSoftware が公開している各バージョンのヘルプもヒットします。

ないのなら 作ってしまえ！ ということで、参照頻度の高いヘルプだけを掲載する『出直し!! ヘルプ：＠関数編』を始めることにしました。

記述にあたっては、使用頻度の低い構文や機能、引数などはあえて省いていることがります。すべてを網羅すると情報量が増え、それが雑音となり、わかりにくくさせるからです。すべての機能を正確に知りたい場合には、本家の Domino Designer ヘルプを参照ください。

また、掲載する命令の追加はその命令に関するブログ記事を書いた時を想定しており、不定期な更新となりますことをご了承ください。