見たことがありません。例があれば挙げてください。明示するものを知りません。あれば例を挙げてください。明示するツール」を凌駕する数あれば,考えを改めます。具体的に根拠を書かなければ根拠不明とまで非難されることは想定外です。用紙サイズのような,出力媒体のサイズであり,クリップアートのような図形の大きさとはまた異なる概念です。このため他の文書に挿入される用途を前提とした図形のバウンディングボックスとしては本来,不適切です。↑この記述はよくわかりません。不適切なのに使っているのはなぜ?といわれてしまうでしょう。することを考慮すると「不適切」という言い方は不適切です。↑これこそ意味不明です。その「ほとんどのアプリケーション」が仕様違反かもしれないのでそっちに文句言いましょう。注意書きはないので,文句を言える筋合いはありません。あれば,他は明示しなくても自由なのです。「仕様違反かもしれない」そんなわけない。仕様書を読み直してください。他にも出版用途の様々なボックスがあり,どれを選ぶのが適切なのかは混乱を招きます。参考にするのが適切かと予測されます。これこそ,「使う人がどれをどう使いたいか自由」と書いているではないですか。下に「ひとつの指針」とあなた自身が引用しているように,規則ではないのです。指針のレベルにすぎず,恣意的なものです。画像のバウンディングボックスを決定します。違反かどうかはおいておき,こういう順序で読むという事実を伝えるべきでは。仕様に違反しているかのように吹聴する方々がいます。クリッピングやフォールバックを実装してあります。仕様と異なることがわかっているからです。仕様書の記述を無視してあなたの独断を述べても意味はありません。「仕様書の記述を無視して」はむしろ逆にこちらからあなたに言いたいです。オプションだけ仕様に揃えたという開発者の判断は妥当だと評価しております。仕様違反だから使うなとかダメだと批判するつもりは毛頭ありません。意見は書いていないつもりでした。採用します」という事実だけ書いていました。それが違反かどうかは二の次。決められているのはデフォルト値が何かというだけです。ないとデフォルト値の存在意義がありません。いうことは別問題です。別問題ではないと思います。デフォルト値の定め方に文句を言わないといけないことになってしまいます。私はデフォルト値の定め方に文句を言うつもりはありません。恣意的な仕様解釈で自論を振りかざしてもなんにもなりません。しょうがなくフォールバックするという動作になります。そのユーザに聞いてみないとわからないでしょう。(かつ仕様とも齟齬をきたさない)とは個人的には思っていますが。いう仮定が正しい根拠はどこにもありません。試行錯誤したという事実があるのかどうかは私は知りません。図形の大体の大きさを知るのに用いられます。組版する際に必要となる「画像のサイズ」を表す数値の組として利用されます。図形が実際に占める領域をちょうど囲む矩形なのですが,バウンディングボックスとして設定された領域から図形がはみ出していることもしばしばあります。↑の方針に沿って書いてみました。自身の機能ではなく,実際はプレビュアーや変換ソフトなどの「ドライバ」がそれを担います。組版するうえで必要なのは,「その図形を版面に配置するために,どれくらいの幅と高さを確保するか」だけであり,その際に利用されるのがバウンディングボックスです。本来の意味でのバウンディングボックスは,それぞれの図形に対して一意的に定まるものです。画像フォーマットなどによっては,これはあいまいさを伴います。そのような状況では,バウンディングボックスを何らかのやり方で推量する必要が出てきます。出力処理を行うドライバとの間で,推量のやり方に不整合が起きると,意図せぬ結果となってしまうという問題があります。幅で出力してしまったなどです。利用すべきバウンディングボックスの意図された値を決めてやる必要があります。本項目では,「バウンディングボックスの推量において不整合が起きない値」のことを「正解の値」と呼ぶことにします。使うバウンディングボックスの値はドライバに合致した「正解の値」でなければなりません。利用すべきバウンディングボックスの「正解の値」について説明します。形式の図を様々なメディアに挿入し,配置するための画像フォーマットで,バウンディングボックス情報を持ちます。ファイルの冒頭には,バウンディングボックスを指定する行を持つことが仕様で定められています。通常,唯一のバウンディングボックスを情報として持つので,特にあいまいさなく図形の大きさが決定されます。ファイルによっては,より桁数の多い高精度なバウンディングボックスをあわせもつこともあります。言語には「座標系」の概念があることに注意)。見つけ,これを利用します。これを自分で読むことができます。」と昔はよく言われていた所以です。↑これがその所以ではないでしょう。形式の画像は好まれなくなりました(参考:[[古い情報]])。いった記述がありませんので,なんらかの方法でバウンディングボックス情報を取得する必要があります。エンジン自体を拡張し,これらのバウンディングボックスを取得することができるようになっています。画像のサイズを知る手段がありません。いう「バウンディングボックスを抽出するプログラム」を実行し,バウンディングボックス情報を取得します。いう概念がありますが,これとは必ずしも一致しませんので注意してください。中で定義されています)。とってのバウンディングボックスの「正解の値」を知ることができるのです。ビットマップ画像が実際にどのくらいの大きさを占めるかを知るには,想定された出力機器の解像度の情報が必要です。ビットマップ画像の場合のバウンディングボックスは,左下隅を原点とみなし,解像度とピクセル数から算出できる物理的な寸法です。データなどに解像度情報を含めることができ,そこから画像の意図された大きさを算出することができます。画像形式でも,オプションとして想定される解像度情報を含めることもできます。とりこんだ画像のサイズが異常に大きかったり,小さかったりする場合は,このデータが原因です。ページが最終的に印刷される物理媒体の領域を表します。ファイルにも明示されています。ついては,アプリケーションによっては追加で明示することもあるという程度です。プログラム,特にバッチ処理プログラムが,どのようにこれら複数の画像サイズに関連した値を使うかは不明瞭なところがあります。順に探し,''明示されている最初のもの''となります。うちどれを使うか指定することも可能です。しても思うようにいかない場合は使ってみましょう。ほとんどのひとはこれらBoxのことなんて知りたくもありません。関係が説明されていて当然だと思います。書かれているわけではなく,専門的に知りたい方のための場所だと思います。ファイルのバウンディングボックスを表示する機能を持ちます。5つのバウンディングボックスの値を確認することができます。ファイルのバウンディングボックスを表示する機能を持ちます。異なり「余白をクリップした,実際に文字や図形がある領域」の矩形を返します。余白をクリップしたバウンディングボックスの値を確認することができます。余白をクロップしています。不要だと判断されましたら,削除してください。無意味な蘊蓄の披露はやめましょう。「正解」の値ってなんですか?「正解」なんてありません。ユーザが「意図する」値やプログラムがそうと推測する値があるだけです。この不整合が起きるような値を「間違い」という言い方で表現しているのです。不整合が起きない値のことを,「正解」と呼んでいます。カギカッコつきで「正解」と言っている理由は,そういう意味です。以外は「必須」との文言はないですので無くても良いものです。