' 'グリフ'と'文字'？

グリフはテキストのレンダリング方法に関連し、文字はテキストの解釈方法に関連します。 &貼り付けをコピーすると、通常、ソースアプリケーションはいくつかの形式を選択できます。プレーンテキストは合字をfとiに分解し、HTML形式は引用したcharエンティティに変換するか、fとiに分解する場合があります。

一般に、文字とグリフの関係はnです。 m。インド語では、一部の文字が2つのグリフに分割され、単語の異なる場所に配置されます。ラテン語では、その状況に最も近いのは、éを2つのグリフ（eと ´）としてレンダリングすることです。アラビア語では、各文字は単語内の位置に応じて異なるグリフを持ちます：イニシャル、ミドル、ファイナル、または孤立。

文字からグリフへの変換は、各アプリケーションとそれがサポートする活版印刷機能に固有です。ラテン語のテキストの場合、この翻訳は以前は簡単でしたが、OpenTypeフォントでは、合字、スワッシュ、代替フォーム、スモールキャップスなどの追加機能が導入されました。

実用上の理由から、アプリケーションの実装方法を実装するときは、グリフのみに関心があります。テキストをレンダリングするとき、フォントをデザインするとき、または一部のグリフを他のグリフ（合字など）に置き換えるOpenType機能を適用する場合。それ以外の場合は、Unicodeコードポイントが友だちです。

コメント

• こんにちはuser322483、GDSEへようこそ。回答ありがとうございます。ご不明な点がございましたら、ヘルプセンターをご覧になるか、グラフィックデザインチャットでお問い合わせください。 a>あなたの評判が十分になったら（20）。貢献し続け、サイトを楽しんでください！
• あなたは”と書きますアラビア語では、各文字は単語内の位置に応じて異なるグリフを持っています：イニシャル、ミドル、ファイナル、または孤立。” < — ‘これらは異なる文字ではありません。英語にはAとaがありますが、コンピューティングトークでは、Aとaは異なる文字です。各グリフは異なるコードにマップされます。ヘブライ語にはチャフと最後のチャフがあり（単語の最後にある文字のチャフは異なって見えます）、’確かに’コンピューティングでは別の文字と呼ばれます。

「あなたの理解が間違っているとは思わない」ユーザーが望むと思うものを貼り付けることによってユーザーを助けようとするシステムを見ているだけです。一部の合字（ “fi”、 “fl”）は植字システムの外部ではかなり一般的であるため、ソフトウェアは、ユーザーがおそらくそのグリフを入力しなかったことを認識します。むしろ、別のアプリが型付き文字を変換しました。

要するに、 ：文字は言語単位を指します。グリフは、大文字、小文字、スモールキャップ、歴史的、またはスタイルのバリエーションであるかどうかに関係なく、そのユニットの設計されたインスタンスを指します。

コメント

• コンピューティングでは、Aとaは異なる文字です。ASCIIには128文字があり、文字という用語にはAとaが別個の文字として含まれています。
• エンジニアは’他の業界の前例と一致します。あなたの良い例が1つあります。
• “文字

  および”グリフ” f最初に？グラフィックデザイナーまたはコンピューターエンジニア？ i ‘ dは、コンピューターがグラフィックデザインよりも前にあると考えていました。しかし、グラフィックデザインに先行し、ある意味で議論の余地のある先行するコンピューターや、現代のコンピューターよりも古い印刷業界が存在する可能性があります。現在のグラフィックデザインに最もよく答えることができるのは印刷業界だと思いますが、’印刷業界のスタックエクスチェンジはありません。しかし、’誰が誰から、どのようにキャラクターという用語を借りたかを知ることは興味深いことです。

• タイポグラフィは以前に長く来ましたソフトウェア工学。研究をして起源を見つけたら、ここに投稿してください。私の推測では、それは17世紀のいつかになるでしょう。おそらく早くも16日の半ばに最初のタイポグラファーです。

ここにはいくつかの回答がありますグリフと文字についての良い情報を提供しますが、コピーと貼り付けに関する混乱の原因に実際には対処していません。

まず第一に、あなたの理解は基本的に正しいです：

文字は、言語での意味、グリフ、外観によって定義されます。したがって、美的に組み合わせるための合字fiは1つのグリフですが、2つの文字です。

文字のリストはUnicodeで定義されていることを強調する価値があります。標準は、Unicodeコンソーシアムによって公開されています。これは、「マシンで読み取り可能な形式でテキストをエンコードする権限があるためです。上記の定義は、基本的に、Unicodeコンソーシアムのメンバーが提案するかどうかを判断するために使用する主要なガイドラインです。 addit Unicodeへのイオンは文字であるため、含める価値があります。またはグリフであり、フォントレンダラーで処理する必要があります。

混乱しているため、これについて言及します。上記で経験したのは、Unicodeにいくつかの合字文字（グリフではない）が存在するという事実によるものです。たとえば、U+FB01は合字の文字です： http://unicode.org/charts/PDF/UFB00.pdf

Unicodeで合字文字を使用することは、合字が実際には独立した意味を持たないため、Unicode標準に文字としてどのような種類のものを含めるべきかについての上記の定義の精神には実際にはありません。他の2つのキャラクターの構成。 Unicodeの人々は当然これを認識しており、合字に関するUnicodeFAQ も同様に認めています：

既存の合字は、基本的に非Unicode文字セットとの互換性とラウンドトリップのために存在します。それらの使用はお勧めしません。

この文字の存在は、最終的に混乱の原因になります。

正しく実装されたソフトウェアでは、コピーテキストは、グリフではなく、指定された文字を常にコピーする必要があります。これは、3つの例で行われていることとまったく同じです。

1）最初の例では、fとiをIllustratorに入力しました。これにより、単一の合字グリフがレンダリングされました。 。レンダリングされたグリフを選択してコピーすると、Illustratorはf（U+0066）とi（U+0069）文字をクリップボードに追加します。

2）2番目の例では、合字文字（&#64257）のHTMLコードを入力ボックスに入力し、合字文字を表す合字グリフを正しく取得しました（基になる文字は実際には、前述のあいまいで比較的無意味な合字文字であるため、そのグリフは単一の文字をコピーしますU+FB01。

3）3番目の例では、レンダリングされた合字文字

文字は、テキストファイルに保存され、アプリケーションによって処理され、グリフは視覚的な表現ですが、動き回っています。

鮮明な画像を表示するために、アプリケーションが画面上にテキストの文字列をレンダリングしようとするとどうなるかを見てみましょう（少し簡略化された方法で）：

• アプリケーションは最初にテキスト文字列を読み取り、それがディスクまたはメモリに保存されている文字列であることを確認します。
• 次に、テキスト文字列をテキストレイアウトエンジンに送信します。目的のフォント、テキスト言語などの他のプロパティ：
  • Tテキストレイアウトエンジンは基本的にフォントファイルを開き、各文字に対応するグリフを要求し、グリフの置換を行います（fおよびiの合字グリフfi）と配置（カーニングなど）。
  • 最後に、レイアウトエンジンには次のシーケンスがあります。グリフ、それらの相対的な位置、および入力文字と出力グリフの間のマッピング。文字からグリフへのマッピングは、単語fileの最初の2文字が最初の2つのグリフ（fi合字）に対応することを認識できるようにするためのものです。 ）、3番目の文字から2番目のグリフ、4番目の文字から3番目のグリフ。
• グラフィックレンダリングライブラリを使用して、を使用してこれらのグリフを画面に「描画」します。フォントからの形状。
• ユーザーが画面で「グリフ」を選択すると、アプリケーションはレイアウトエンジンによって提供されるグリフからテキストへのマッピングを調べて、入力テキストのどの部分が何に対応するかを見つけます。ユーザーはそのテキストを選択して、ユーザーがコピーしたときにクリップボードに送信します。
• ユーザーがテキストの途中にカーソルを挿入して入力を開始し、マッピングによって入力テキストのどこに新しい文字を挿入するかが決定され、更新テキストがレイアウトエンジンに送信されて、 プロセスと再描画など。