[73] PDF
[74] PDF p.25
[75] 通常状態の SI/SO PDF p.26
[76] alphageometric option の SI/SO PDF p.27
[78] opcode (operational code) + associated data parameters
[79] DRCS PDF p.38
[83] 仕様書が見るからに未完成.
[13] T.101 : International interworking for Videotex services, tsbmail, https://www.itu.int/rec/T-REC-T.101-199411-I/en
[49] PDF はフォントが埋め込まれていないらしく非ASCII文字は信用してはいけない。
[27] Videotex は日米欧3規格の統合に失敗した結果 T.101 は3規格を「Data Syntax」と称して並列に規定することになりました。
[1] Videotex character set - Wikipedia, , https://en.wikipedia.org/wiki/Videotex_character_set
[12] Viewdata - Wikipedia, , https://en.wikipedia.org/wiki/Viewdata
[20]
"complete code" environment
(ISO/IEC 2022 complete coding environment)
を切り替える DOCS
T.101 PDF1 p.18, p.20, p.41:
ESC
2/5 4/3 : Data Syntax I ESC
2/5 4/4 : Data Syntax IIESC
2/5 4/1 : Data Syntax III ESC
2/5 4/0 : ISO/IEC 2022[21]
各 Data Syntax から
PCD
を使って
ISO/IEC 9281 picture coding environment
の
audio mode,
photographic mode,
VEMMI mode
を利用可能。
T.101 PDF1 p.41
[19]
ASN.1
VideotexString:
ISO/IEC 2022,
Data Syntax I,
Data Syntax II,
Data Syntax III
DOCS
で相互に切替可能。
T.101 PDF1 p.41
[29] 3規格を識別するのみならず相互切り替え可能にする必要性はあったのか、 需要はあったのか、実装可能だったのかは謎です。
[39] Data Syntax の方に言及がない ISO/IEC 9281 picture coding への対応も、 実態はあったのでしょうかね?
[40] DI で識別される Data Syntax I と
PCD
で始まる ISO/IEC 9281
は区別可能だけどアーキテクチャとしておかしい。
また Data Syntax I から他に切り替える時どこにどう
DOCS
を挿入すればいいのか何も書いていない。
本体の状態遷移図に従うなら DI で識別されるバイト長が満了した後に
DOCS
や PCD
を書けるということか。
[41] 本体の状態遷移図には Data Syntax I に切り替えたらまず rank を書く(?)とあるが、その構文が本体にも附属書にも書いてなく謎。 (rank という概念は Data Syntax I に存在してはいるのだが。)
[113] Data Syntax II の profile は状態遷移図に書いてあり、 附属書にも規定があるのですが。。。
[46] 端末状態と照会・回答できる。 Data Syntax 共通。 PDF1 p.36, PDF1 p.102, PDF2 p.379, PDF3 p.119
host 1/15 2/0 4/0
terminal 1/15 2/0 bytes
bytes は 4/0 で終端するか、 7/15 [ 6/0, 7/15 ]* [ 4/0, 5/15 ] で終端する。
[22] Data Syntax I (CAPTAIN) - 日本向け PDF1 p.102
[31] 4モードあって、 DI (Data Identifier) で識別します。
[32] DI, LI, bytes を1セットとして繰り返します。
[33] LI (Length Indicator) は [ 0, 254 ] の1バイトでバイト長を表すか、 255 のバイトに続く大エンディアン2バイトでバイト長を表します。 ([ 0, 254 ] を1+2バイトで表すのも禁止されていない。)
[30] character mode (初期状態)
[35] transparent mode は PDU (Phorographic Data Unit) の連続。
[36] PDU は opcode (1バイト)、LI、bytes。
[34] DI(T) / DI(T-CNT) の境界と PDU の境界が一致していなければならないのか、 そうでないのかよくわからない。一致しなければならないとすると DI(T-CNT) は不要に思えるので、一致しなくても良いのかも。
[38] sound mode
[44] Sound tone set : 第1バイト Sound Tone Set (Pitch)、 第2バイト Sound Tone Set (Duration)
[45] Sound control
8 | 9 | |
---|---|---|
0 | SMC | SLV |
1 | SMP | |
2 | SRP | |
3 | ||
4 | EMC | |
5 | EPT | |
6 | ||
7 | ||
8 | LBL | LRT |
9 | JMP | |
10 | RPT | |
11 | BRA | |
12 | CTM |
引数付き
(引数は1バイトとは限らない)
numeric parameter: [ 3/0, 3/9 ]+ delimiter: 3/11
[37] message mode
[48] message mode の C1 は character mode の C1 の部分集合
[23]
C1 の P-MACRO
9/5 は
ARIB STD-B24 の MACRO
相当 + P-MACRO
4/2 P でマクロ文を返送要求
(ただしこちらは96集合で P は 2/0 ... 7/15)
[43] 特殊文字の集合 Display Control set, PDI set, MVI set: opcode が [ 2/0, 3/0 ], operand が [ 4/0, 7/15 ]。 opcode の後、 opcode 依存の構文・長さで operand が続く。
Display Control set
Display Control Command Set
2 | 3 | |
---|---|---|
0 | ||
1 | P-RESET | |
2 | P-DOMAIN | |
3 | LOGICAL PEL | |
4 | DISPLAY MODE | P-TEXT |
5 | AREA | |
6 | SET FRAME | |
7 | ASSIGN FRAME | |
8 | RASTER HEADER | |
9 | RASTER | |
10 | SET LUT | |
11 | ||
12 | P-WAIT | P-BLINK |
13 | ||
14 | ||
15 |
[50] Data Syntax II は欧州向け。
[51] VPDE (Videotex Presentation Data Element) の連続。
[52] VPDE は VPCE の後に VSCE (Videotex Service Control Element)。
[53]
VPCE (Videotex Presentation Control Element)
は
US
= 1/15
のあとに
P,
P は:
[56] PDF2, PDF2 p.49, p.53
[55] L-set PDF2 p.40
[117] row (line) の先頭でリセットされるというのが、 特定の符号だけではないらしく厄介
[118] G に戻るというのが G0/G1/G2/G3 のどれかではないので、 L に移動したときの前の状態を覚えておかないといけないっぽい
[58] attributes FOREGROUND COLOUR, BACKGROUND COLOUR, LINED, SIZE, FLASH, CONCEAL, INVERT, WINDOW/BOX
Fe は parallel C1 set の ESC Fe のビット組合せ、 例えば 4/1 が Red foreground を表す。
[66] US 2/3 DRCS 関係 PDF2 p.248
[59] Geometric なデータの符号化 PDF2 p.175
primitive は opcode の後に operand を何個かで表す。
operand は [ 4/0, 7/15 ] または文字列
文字列 character string は
SOS
9/8
から始まり
ST
9/12
で終わる
[68] PHOTOGRAPHIC PDF2 p.223
[69] TELESOFTWARE PDF2 p.322
TDU = CI field、LI field、Parameter field
ただし basic kernel (という実装水準) は一部 CI field のみの TDU を使う。
CI (Command Identifier) 種別を表す
LI (Length Indicator) 長さを表す。 1バイトで [ 0, 254 ]、 3バイト (先頭バイト 15/15) で [ 255, 65534 ]
Parameter field は LI で指定された長さ。
[70] basic kernel のとき CI のみ: CI = 3/1, 3/2, 3/8, 3/6
[67] TRANSPARENT = US 3/15 PDF2 p.262
不透明データ。最初のバイト N が長さを表す。
バイト値が指定されていれば、 N の次から数え始めてそのバイト数で終了。
バイト値に関わらず、次の VPCE が検知されたら終了 (中断)。
US
が出現すると次の VPCE とみなされる。回避するには2連続にする。
バイト数カウントは1バイト分になる。
[62] 状態リセット: 各種状態 + 文字コード状態を変更 p.264
[63] DOCS
の直後にはプロファイルを記述する p.398, PDF2 p.1
profile:
profile は display mode ごと (alphamosaic, geometric, ASCII) 複数可
[71] 北米向け (NAPLPS)
[72] PDF3 p.8, p.109
[120] 4つの96集合は元々当時の ISO 2022 に違反した独自仕様で 94集合用指示シーケンスを使っていたらしい。 現在は終端バイト4つとも他の関係ない94集合が登録されている。
[121] ISO 2022 に96集合の概念が追加されて以後96集合用の指示シーケンスを使うことになり、 以前のものは互換用の扱いになったっぽい。 96集合 7/13 は ISO-IR に登録されている。 96集合 5/7 は ISO-IR で登録されていないが、 予約されている (図形文字集合ではないためか)。 7/10、7/11 は未登録。
[122]
7/10、7/11 は ISO 2022 に DRCS の概念が追加されて以後、
DRCS 扱いにすることになったらしく、終端バイトの前に
2/0 が挿入されることになった。
そこで指示シーケンスは (当初仕様では) 両者を併記することになったらしい。
(それは未対応の指示シーケンスは無視される(だけで無害)というエラー処理を想定しているらしい。
そのような規定は ISO/IEC 2022 にも T.101 にも見当たらないが。
[123] つまり旧式扱いになっている終端バイトは登録も予約もされず放置されたらしい。 しかし NAPLPS の実装は全種類対応しなければならない (将来的には旧シーケンスは廃止する予定らしいことが書かれている)。
[84]
ISO/IEC 9281 PCD (識別子 2/4)
または
ISO/IEC 2022 DOCS
でこの構文に切り替えられる。
PDF3 p.120
[85]
ISO/IEC 2022 DOCS
を使う場合の構文が明記されていないが、
結局 PCD を使うということか?
[86]
ISO/IEC 9281 PCD
または
ISO/IEC 2022 DOCS
でこの構文に切り替えられる。
PDF3 p.131
[87] 画像は複数 PE に分割可能、 中途なら次のバイトは ESC 7/0 CMIp、 完了なら次のバイトは ESC or US
[89]
ISO/IEC 9281 PCD
または
ISO/IEC 2022 DOCS
でこの構文に切り替えられる。
PDF p.97
ISO/IEC 9281 CMI
[91] ISO/IEC 2022 の DOCS
で
ESC 2/5 4/1
で指示・呼び出しされる符号化体系は、
ISO-IR 108 です。 (←謎説明)
NAPLPS = Nothern American Presentation Level Protocol Syntax (北米ビデオテックス通信規約)。
[92] AT&T がカナダ政府の Telidon system (1970年代後半 から1980年代前半に使われていた。) を基に開発した PLP (Presentation Level Protocol) が1983年11月に 米国 ANSI X3.110‐1983 や加国 CSA T500‐1983 として標準化されました。
[93] 日本語機能仕様 NAPLPS (NAPLPS JAPANESE LANGUAGE) は日本語機能を追加したもので、1987年9月制定。
[94] いわゆる画像符号化って奴ですね。 Alpha geometric data であって dot の集合じゃありません。 Vector 画像と言われる奴の仲間ですね。
[95] 『Syntax of the North American Videotex/Teletext Presentation Level Protocol (NAPLPS)』。 ANSI X3.110‐1983 や CSA T500‐1983 で定義。
[96]
ISO/IEC 2022 から ESC 2/5 4/1
で指示・呼び出しされ、
ESC 2/5 4/0
で ISO/IEC 2022
を指示・呼び出しします。
7ビット符号の時は固定シフト + GL と
ESC Fe
を使い、
8ビット符号の時は GR と CR を使います。
G2 と G3 は単独シフトが使えます。
(SS2
= 1/9
,
SS3
= 1/13
)
(固定シフトも使えます。) ASCII は右には呼び出せません。
[124] 00000001.PDF - 108.pdf, , https://itscj.ipsj.or.jp/ir/108.pdf
[97] 標準状態では GL = G0 = ASCII, GR = G1 = PDI, G2 = 補遺集合, G3 = Mosaic が指示されています。
IR | 指示 | 指示(旧) | |
135 | C0 | ESC 02/01 04/11 | |
136 | C1 | ESC 02/02 04/06 | |
ASCII | ESC I4 04/02 | ||
PDI | ESC I6 05/07 | ESC I4 05/07 | |
マクロ | ESC I6 02/00 07/10 | ESC I4 02/00 07/10 | |
DRCS | ESC I6 02/00 07/11 | ESC I4 02/00 07/11 | |
128 | 補遺 | ESC I4 07/12 | |
129 | Mosaic | ESC I6 07/13 | ESC I4 07/13 |
[98] PDI の終端バイト(旧) 05/07 は ISO-IR で、互換のため 割り当てないとされています。 (PDI は図形文字集合でないので、 ISO-IR に登録してもらえなかったのかもしれません。)
[99] 96集合の指示の I6 の部分は互換性のため、実装は I4 になっていても読み込むのが良いんだそうな。 (94集合では 全然違う集合が割り当てられてますよ。おいおい。)
[100]
補遺集合中の結合文字は、最初の文字が結合文字
(現在位置の前進を伴わない文字) で、
2番目の文字が基底文字です。
[102]
MIME などの Internet 媒体型は image/naplps
を使います。 version
引数が必須で、値の形式は
4*DIGIT
(規格発行年) のようです。
[112] NAPLPS.TXT, https://www.fileformat.info/format/naplps/spec/c08f9438d54b4149b7f9c4b92e197191/view.htm