サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
ニコニコ動画
www.y-adagio.com
小町 祐史‡ 大阪工業大学情報科学部, 〒573-0196 枚方市北山 1-79-1 E-mail: e1c04065@info.oit.ac.jp, †e1a04072@info.oit.ac.jp, ‡komachi@y-adagio.com あらまし マルチメディア情報機器が提供する情報は,人間だけでなく,ペットに対しても興味を引くまたは強い反応を引き起こすことが多い.そのため,ペットが情報機器に対して攻撃をかけたり,情報機器が提供する情報がペットに不快な刺激となる可能性が高まっている.以前IEC/TC100で提示されたこの問題について,マルチメディア情報機器の設計上の視点からさらに検討を深め,対応を検討する. キーワード ペットプロテクション,情報機器設計,マルチメディア情報 Manabu SASAKI Ayumi SAKITANI† Yushi KOMACHI
目次 | 前 | 次 11. 例外 Javaプログラムが,Java言語の意味制約に違反するとき,Java仮想計算機は,このエラーを例外(exception)としてプログラムに知らせる。 それらの違反の例として,配列境界の外でのインデクス付けがある。 あるプログラミング言語及びその処理系には,プログラムを強制的に終了することによって,それらのエラーに対応するものがある。他のプログラム言語では,処理系が任意又は予測不能な方法で対応することを許しているものもある。 これらの方法のいずれも,Javaの設計目標,移植性及び頑健性とは適合しない。 代わりに,Javaは,意味制約に違反したとき,例外を投げ,例外が発生した点からプログラマが指定可能な点への非局所的な制御の移動を引き起こすことを規定している。 例外は,それが発生した点から投げられる(thrown)と言い,制御が移動する点で捕捉される(cau
XMLパス言語 (XPath) 1.0 XML Path Language (XPath) Version 1.0 序文 この標準情報(TR)は, 1999年11月にWorld Wide Web Consortium(W3C)から公表されたXML Path Language (XPath) Version 1.0 勧告を翻訳し, 技術的内容を変更することなく作成した標準情報(TR)である。 0. 適用範囲 XPathは, XML文書の部分を番地付けするための言語であり, XSLT及びXPointerの両者によって用いられる設計となっている。 1. 導入 XPathは, XSL変換[XSLT]とXPointer[XPointer]との間で共有される機能に関する共通の構文及びセマンティクスを提供するための活動によって得られた。XPathの主要な目的は, XML[XML]文書の部分を番地付けする
序文 この標準情報(TR)は,1998年9月にInternat Engineering Task Force (IETF)から公表されたRFC 2426, vCard MIME Directory Profileを翻訳し,技術的内容を変更することなく作成した標準情報(TR)である。 0. 一般 0.1 適用範囲 この規定は,vCard電子名刺に基づいて,電話帳人物オブジェクトのディレクトリ情報のための,MIME内容型[MIME-DIR]のプロファイルを定義する。このプロファイル定義は,特定のディレクトリサービス又はプロトコルとは独立とする。このプロファイルは,フォーマット化及び構造化された名前,フォーマット化及び構造化された配達用番地,電子メール用番地,複数の電話番号,写真,ロゴ,音声クリップなど,個人に関する様々な情報を表現し交換するために定義される。このプロファイルで使われるディレクト
明朝体と明体の違いについて 広島大学 総合科学研究科 鈴木 俊哉 明朝体・明体の識別の動機 中文組版のセリフつき書体には宋体と明体がある 宋体の例: SimSun (簡体字) 日本の宋朝体ではないことに注意 明体の例: MingLiU (繁体字) 中文組版において書体差なのか字体差なのか不明確 HKSCS2004の例示フォントは名称は明体だが宋体に見える そもそも宋体と区別した「明体」という分類は無いのが普通? – 中文信息処理(傳永和,1999)には宋体はあるが明体はない 現在の中文組版で一般的な宋体と、 和文組版で一般的な日本の明朝体の識別は容易 宋体のほうが筆書きの性格を残している ISO/IEC 9541-1には明朝体という分類はあるが 宋体という分類は無い 明体と明朝体の区別は明らかでない 明確に線引きできるものではなく、デザイン傾向の違い? しかし、和文漢字を明体で組
まえがき 序文 1. 一般 1.0 適用範囲 1.1 経緯及び目標 1.2 定義 2. 文書 2.1 整形式のXML文書 2.2 文字 2.3 共通の構文構成子 2.4 文字データ及びマーク付け 2.5 コメント 2.6 処理命令 2.7 CDATAセクション 2.8 前書き及び文書型宣言 2.9 スタンドアロン文書宣言 2.10 空白の取扱い 2.11 行末の取扱い 2.12 言語識別 3. 論理構造 3.1 開始タグ, 終了タグ及び空要素タグ 3.2 要素型宣言 3.2.1 要素内容 3.2.2 混合内容 3.3 属性リスト宣言 3.3.1 属性の型 3.3.2 属性のデフォルト 3.3.3 属性値の正規化 3.4 条件付きセクション 4. 物理構造 4.1 文字参照及び実体参照 4.2 実体宣言 4.2.1 内部実体 4.2.2 外部実体 4.3 解析対象実体 4.3.1 テキスト宣
Working Group 7, IPSJ (Information Processing Society of Japan) Trial Standards Committee E-mail: g_nagamura@orion.ocn.ne.jp, †mpsuzuki@hiroshima-u.ac.jp, ‡komachi@y-adagio.com 1. まえがき 情報処理学会情報規格調査会は,2007年11月に傘下の学会試行標準専門委員会に次に示す試行標準(TS: Trial Standard)の開発を行う方針を決め,作業グループWG7小委員会[1]を設立して,開発作業に着手した. a) 名称 フォントリソース参照方式 b) 適用範囲 書体を表す多くの属性の体系の枠組みを決め,フォントプロバイダ間およびプロバイダ-利用者間で異なる書体分類を相互変換できるようにし,柔軟性の高いフォント参
目次 | 前 | 次 5. 変換及び昇格すべてのJava式は,その式の構造,並びに,その式の中に記述された,リテラル,変数及びメソッドの型から演繹できる型をもつ。しかし,式の型が適切でない式を書いてしまうこともできるので,コンパイル時にエラーとなる場合もある。 例えば, if 文(14.8)内の式が boolean 以外の型をもてば,コンパイル時エラーが発生する。文脈によっては,式の型が受理可能な場合もある。Java言語では,プログラマに明示的型変換を要求するかわりに,指定された式の型から,式をとりまく文脈にとって受理可能な型への暗黙的な 変換(conversion) を実行することを図る。 型 S から型 T への特定の変換によって,型 S の式を,あたかも型 T をもつかのようにコンパイル時に扱うことができる。この変換の正当性を検査する実行時動作,又は式の実行時の値を新しい型 T にと
3. OWL Liteの言語記述 この3.では,OWL Lite言語機能の非形式的な記述を提供する。これらの機能の固有構文の議論は,行わない。定義については OWL 機能一覧を参照されたい。各言語機能は,より多くの例及び使用に際しての手引を提供するために,OWL 手引の適所にHTML版ではハイパリンクされている。 OWL Liteが使用するのは,OWL言語機能の一部にすぎず,OWL DL又はOWL Fullに比べて,機能の使用に際しての制限が多い。例えば,OWL Liteでは,クラスの定義は名前付き上位クラスに関する場合に限られており,上位クラスが任意の表現であることはない。さらに,ある種のクラス制限だけが使用できる。クラス間の等価性及びクラス間の下位クラスの関係も名前付きクラス間だけで使用でき,任意のクラス表現間では使用できない。同様に,OWL Liteにおける制限は,名前付きクラスだけ
標準情報(TR) TR X 0045:2001 ディレクトリ情報のためのMIME内容型 目 次 まえがき 序文 1. 適用範囲 2. 表記 3. MIMEディレクトリ型の必要性 4. 概要 5. text/directory内容型 5.1 MIMEメディア型名 5.2 MIME下位型名 5.3 必す(須)パラメタ 5.4 オプションパラメタ 5.5 符号化への考慮 5.6 セキュリティへの考慮 5.7 相互接続性への考慮 5.8 公開仕様 5.9 MIMEメディア型を使用するアプリケーション 5.10 追加情報 5.11 詳細情報を得るための連絡先 5.12 意図する使用法 5.13 著者及び変更の管理者 6. 定義済み型 6.1 SOURCE型定義 6.2 NAME型定義 6.3 PROFILE型定義 6.4 BEGIN型定義 6.5 END型定義 7. multipart/relat
値 この部分は,特性に関する妥当な値の集合を指定する。値の型は,次のいくつかの方法で指定してよい。 a) キーワード値 (auto, discなど) b) "<"及び">"の間に現われる基本データ型 (<length>, <percentage>など)。この規定の電子版では,基本データ型の各インスタンスは, その定義にリンクする。 c) 同じ名前をもつ特性と同じ範囲の値をもつ型 (<'border-width'> <'background-attachment'>など)。この場合, 型名は, "<"及び">"の間の特性名(引用符付きの完全な名前)とする(<'border-width'>など)。 この規定の電子版では,非終端なこの型の各インスタンスは, 対応する特性定義にリンクする。 d) 特性と同じ名前を共有しない非終端。この場合,非終端名は,"<"及び">"の間に現われる(<border
A.1.6 縦組文書における数字の表記方法(案) 序文 これは,2004 年度の e-Book 調査研究における標準化に関する調査研究をもとに,従来は ほとんど省みられることがなかった情報処理の分野において,表示のために縦横変換等を 行なうときの数字表記の混乱をなくす目的で,縦組数字表記方法をまとめたものである。 1.適用範囲 構造化文書においては,文書の内容と組版スタイルは分離されている。組版スタイルを付 与する場合,利用目的等によって縦組・横組といった基本組体裁を任意に選択できること が暗黙のうちに期待されていると考えられるが,この変換時に問題となるのは拗促音,括 弧類だけではなく,数字表記においても組み方向にあったルールを確立しておかなければ 正しい変換はできない。 とくに,原稿はテキストエディタを用いることが多いため,横組を前提にした用語を用 いて執筆しがちであり,これを縦組に
9 視覚フォーマットモデル 9.1 視覚フォーマットモデルの導入 9.及び10.では,視覚フォーマットモデルを示す。具体的には,利用者エージェントが視覚メディアの文書ツリーをどのように処理するかを示す。 視覚フォーマットモデルでは,文書ツリーの各要素は,ボックスモデルに従ってゼロ個以上のボックスを生成する。これらのボックスのレイアウトは,次によって支配される。 ボックスの寸法及び型。 位置決め方式(通常のフロー,浮動及び絶対)。 文書ツリーの要素間の関係。 表示域のサイズ,画像の固有寸法などの外部情報。 9.及び10.で定義される特性は,連続メディアにもページ付けしたメディアにも適用される。しかし,ページ付けしたメディアに適用する場合は,マージン特性の意味は様々になる。詳細については,ページモデルを参照すること。 視覚フォーマットモデルは,フォーマット化のすべての局面を規定するわけではない
ハイパテキストマーク付け言語(JIS X 4156:2000)の利用者ガイド User's Guide to HyperText Markup Language [HTML: JIS X 4156:2000(ISO/IEC 15445:2000)] 序文 この標準情報(TR)は, 2000年5月にISO/IECから発行されたUser's Guide to ISO/IEC 15445:2000 HyperText Markup Language (HTML)を翻訳し,技術的内容を変更することなく作成した標準情報(TR)である。 0. 導入 JIS X 4156:2000(ISO/IEC 15445:2000)が規定する言語(これをISO-HTMLとも呼ぶ。)は,ISO 8879(JIS X 4151) SGML(標準一般化マーク付け言語)のアプリケーションであって,ハイパテキスト文書を構成し
14.2 背景 文書作成者は,要素の背景(すなわち,レンダリング面)を色又は画像のどちらかとして指定できる。ボックスモデルに関しては,"背景"は,内容領域及びパディング領域の背景を表す。境界色及びスタイルは,境界特性を用いて設定される。マージンは常に透明なので,親ボックスの背景は常に透けて見える。 背景特性は継承されないが,'background-color'の初期値が'transparent'であるため,デフォルトで親ボックスの背景は透けて見える。 ルート要素が生成するボックスの背景は,描画面全体を覆う。 しかし,HTML文書の場合, 文書作成者がHTML要素ではなくてBODY要素に関して背景を指定することを推奨する。利用者エージェントは, 次の優先規則を遵守して,背景を埋めることが望ましい。HTML要素に関する'background'特性の値が'transparent'ではない場合は,
目次 | 前 | 次 3. 字句構造 3.では,Javaの字句構造を規定する。 Javaプログラムは,Unicode (3.1) で記述するが,字句変換(3.2)を提供することで,ASCII文字だけを用いて任意のUnicode文字を含めるようにし,Unicodeエスケープ(3.3) を使用可能とする。行終端子(3.4)は,一貫性のある行番号を維持するとともに,既存のホストシステムでの異なった慣例を使用できる定義とする。 字句変換によって生じるUnicode文字は,空白類(3.6),注釈(3.7)及びトークンからなる入力要素(3.5)の列に還元される。トークンは,Javaの構文文法の,識別子(3.8),キーワード(3.9),リテラル(3.10),分離子(3.11)及び演算子(3.12)とする。 3.1 Unicode Javaプログラムは, Unicode文字集合第2版を用いて記述する。Un
8 ボックスモデル CSSボックスモデルは,文書ツリーの要素に対して生成される長方形のボックスを記述し,視覚フォーマットモデルに従って拡張する。ページボックスは,特殊なボックスであって,ページ付けしたメディアの箇所で詳細を記述する。 8.1 ボックスの寸法 各ボックスは,テキスト,画像などの内容領域をもち,オプションで,その周囲にパディング,境界及びマージンの領域をもつ。各領域のサイズは,以降で定義される特性によって指定される。次の図は,これらの領域がどのように関係しているか,並びにマージン,境界及びパディングの断片を参照するために使用する用語を示す。 マージン,境界及びパディングは,左部,右部,上部及び下部に分けることができる。例えば,図では,左マージンは"LM",右パディングは"RP",上境界は"TB"などとなっている。 四つの領域(内容,パディング,境界及びマージン)の各周辺を"辺"
15 フォント 15.1 導入 文書のテキストが視覚的に表示される場合, 文字(抽象的な情報要素)は, 抽象グリフに対応付けられなければならない。一つ以上の文字は, 可能な文脈依存の方法で一つ以上のグリフによって描かれてもよい。 グリフは,抽象グリフの実際の芸術的表現であり,ある印刷スタイルをもち,画面又は紙に描くことができる輪郭線又はビットマップのフォームをもつ。 フォントはグリフの集合であり, そのグリフはどれも, デザイン,サイズ,外観,及び集合全体に関連するその他の属性に従って,同一の基調を守り, 文字から抽象グリフに対応付けられる。 視覚利用者エージェントは,実際に文字をレンダリングする前に,次の課題を確認しなければならない。 この文字に直接又は継承によって定されるフォントは存在するか。 利用者エージェントは, 利用可能なこのフォントをもつか。 もつ場合,この文字又は文字シーケン
目 次 まえがき 序文 1. 一般 1.0 適用範囲 1.1 経緯及び目標 1.2 定義 2. 文書 2.1 整形式のXML文書 2.2 文字 2.3 共通の構文構成子 2.4 文字データ及びマーク付け 2.5 コメント 2.6 処理命令 2.7 CDATAセクション 2.8 前書き及び文書型宣言 2.9 非依存文書宣言 2.10 空白の取扱い 2.11 行末の取扱い 2.12 言語識別 3. 論理構造 3.1 開始タグ,終了タグ及び空要素タグ 3.2 要素型宣言 3.2.1 要素内容 3.2.2 混合内容 3.3 属性リスト宣言 3.3.1 属性の型 3.3.2 属性のデフォルト 3.3.3 属性値の正規化 3.4 条件付きセクション 4. 物理構造 4.1 文字参照及び実体参照 4.2 実体宣言 4.2.1 内部実体 4.2.2 外部実体 4.3 解析対象実体 4.3.1 テキスト宣
この解説は,本体及び附属書に規定・記載した事柄,並びにこれらに関連した事柄を説明するもので,標準仕様書(TS)の一部ではない。 1. 公表の趣旨及び経緯 1.1 公表の趣旨 W3C(World Wide Web Consortium)がウェブ環境で意味的な処理を実現するために提案したセマンティクウェブの体系の中で,メタデータ及びその枠組みの上位に位置付けられる機能としてウェブオントロジが示され,それを記述する言語としてOWL Web Ontology Languageが開発された。ウェブ上での使用を前提とし,分散指向に基づくこのウェブオントロジ言語の基本構成要素は,クラス,特性及び個体であり,この言語で書かれたOWL文書においては,クラス,特性及び個体に関する記述がなされる。 参考 哲学ではオントロジは存在論と訳されることが多いが,ここではオントロジと片仮名表記する。 OWLの規定は,20
目次 | 前 | 次 4. 型,値及び変数Javaを,強く型付けされた(strongly typed) 言語にした。それは,個々の変数及び個々の式がコンパイル時に既知の型をもつことを意味する。型は,変数(4.5)が保持できるか,又は式が生成できる値を制限し,それらの値に対する演算を制限し,演算の意味を決定する。強い型付けは,コンパイル時にエラーを検出するのに役立つ。 Java言語の型は,二つのカテゴリ,プリミティブ型及び参照型に分けられる。プリミティブ型(4.2)は, boolean型(論理型)及び数値型に分ける。数値型は,整数的な型である byte,short,int,long 及び char,並びに浮動小数点型である float 及び double に分ける。参照型(4.3)は,クラス型,インタフェース型,及び配列型に分ける。特別な型 null もある。Javaのオブジェクト(4.3.
1. 日本語XMLプロファイルの必要性 [TR X 0008]は,符号化文字集合として[JIS X 0221]及び[Unicode 2.0]を採用しており,これは日本語文字をすべて含む。文字符号化スキームとしてはUTF-8及びUTF-16を推奨し,これらの実装を義務付けている。既存の文字符号化スキームも, [Unicode 2.0]の文字だけを扱う限りオプションとしてすべて許容している。 しかし,[TR X 0008]では,日本語文字の交換に広く使われてきた既存の文字符号化スキームはほとんど説明されてなく,オプションの一つとして許容されているに過ぎない。SMTP及びHTTPなどのプロトコル並びに情報交換用ファイルで,どの文字符号化スキームを用いるかについても,特に定められてはいない。 既存の文字符号化スキームと[JIS X 0221]及び [Unicode 2.0]との対応も不明確である。
まえがき 序文 0. 適用範囲 1. 動機及び概要 1.1 記法及び利用法に関する備考 2. 名前空間の宣言 3. 修飾された名前 4. 修飾された名前の使用 5. 要素及び属性への名前空間の適用 5.1 名前空間のスコープ 5.2 名前空間のデフォルト 5.3 属性の一意性 6. 文書の適合性 附属書A XML名前空間の内部構造 A.1 従来の名前空間の不充分さ A.2 XML名前空間の区画 A.3 展開された要素型及び属性名 A.4 展開された属性名の一意性 附属書B 貢献者 附属書C 引用規定 解説
まえがき 序文 0. 適用範囲 1. 導入 1.1 目的 1.2 要件 1.3 定義 1.4 動作概要 2. 記法の規約及び共通文法 2.1 強化BNF 2.2 基本規則 3. プロトコルパラメタ 3.1 HTTPの版 3.2 統一資源識別子 3.2.1 一般構文 3.2.2 http URL 3.2.3 URIの比較 3.3 日時フォーマット 3.3.1 省略なし日付 3.3.2 差分秒(delta-seconds) 3.4 文字集合 3.5 内容符号化(content-coding) 3.6 転送符号化(transfer-coding) 3.7 メディア型(media-type) 3.7.1 正準化及びテキストのデフォルト 3.7.2 マルチパート型 3.8 製品(product)トークン 3.9 品質値(qvalue) 3.10 言語タグ(language-tag) 3.11 実体タ
ハイパテキスト転送プロトコル HTTP/1.1 Hypertext Transfer Protocol HTTP/1.1 序文 この標準仕様書(TS)は,1997年1月にInternet Engineering Task Force (IETF)から公表された Hypertext Transfer Protocol HTTP/1.1 (RFC 2068)を翻訳し,技術的内容を変更することなく作成した標準 仕様書(TS)である。 0. 適用範囲 この標準仕様書(TS)は,分散協調ハイパメディア情報システムのためのアプリケーションレベルプロトコルであるハイパテキスト転送プロトコル(Hypertext Transfer Protocol,HTTP)を規定する。それは,要求メソッドの拡張によって,名前サーバ及び分散オブジェクト管理システムといった多くの作業に利用できる,共通的な状態のないオブジェク
標準情報(TR) TR X 0026:2000 ポータブル文書フォーマット PDF 目 次 まえがき 序文 1. 導入 1.1 適用範囲 1.2 構成 1.3 PDF規定の履歴 1.4 記法 1.5 著作権許諾 第1章 ポータブル文書フォーマット 2. 概要 2.1 ポータブル文書フォーマット 2.2 PDFの使用方法 2.3 一般特性 2.4 PDF及びPostScript言語 2.5 PDFの理解 3. 共通システム 4. オブジェクト 5. ファイル構造 6. 文書構造 7. 一般データ構造 8. ページ記述 9. 線形化されたPDF 第2章 PDFファイルの最適化 10. PDFファイルの最適化のための一般的技術 11. テキストの最適化 12. グラフィクスの最適化 13. 画像の最適化 14. クリッピング 附属書A. PDFファイルの例 附属書B. ページ組版の概要 附属書
序文 この標準仕様書(TS)は,2000~2001年度における(財)日本規格協会 情報技術標準化研究センター(INSTAC)の電子出版技術調査研究をもとに工業標準化の促進に関連して特に重要と判断される技術情報をまとめたTR X 0059:2002に対して,さらに2003年度の電子出版技術調査研究において機能追加を施し, 標準仕様書(TS)タイプⅡとして公表するものである。 1. 適用範囲 この標準仕様書(TS)は, XML文書に対する変換処理を共有する手段としてのXSLTライブラリを規定する。変換対象のXML文書における文書構造要素はXPathによって制限し, 変換先はXML文書又はHTML文書とする。 2. 引用規定 次に示す規格等は, この標準仕様書(TS)に引用されることによって, この標準仕様書(TS)の規定の一部を構成する。 TR X 0048:2001, XSL変換(XSLT)
次のページ
このページを最初にブックマークしてみませんか?
『Start Page-Japanese only』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く