学術文書のフォントのオーバーロード


19

私は暗号学の研究者であり、控えめに言っても素晴らしい美しさの対象ではない学術論文を定期的に読み書きしています。最近、ドキュメントで2つまたは3つ以上のフォントを使用しないというガイドラインが定期的に軽視されており、これにどの程度関係があるのか​​疑問に思います。

これが私の例です(コンテンツはもちろん無関係です):

学者がフォントを使用する方法のサンプル

完了したことは、物事のカテゴリごとに異なるフォントを使用することです。

  • 本文にはセリフ、見出しには太字、強調には斜体。
  • Sans-Serifまたはアルゴリズム名のモノスペース(例では「KeyGen」など)。
  • インライン数学用の斜体(ただし、少し異なるフォントで)
  • sans-serif、セキュリティ概念の名前の太字またはスモールキャップ(上記の例のスモールキャップ)。
  • 「黒板太字」、「書道」、「フラクチャー」など(LaTeXで利用可能なさまざまなオプション)アルゴリズムのコレクション、プロトコルの参加者などのさまざまなクラスの。
  • 等々 ...

私の質問は:

  • 上記の例は少し混乱しているように見えます。それは主にフォントの数ですか、それとも他の主要な設計原則が欠けていますか?
  • 技術的または学術的な文書でさまざまなフォントを使用してさまざまなカテゴリの事柄を示すことにデザインの観点から何かポイントがありますか、それともすべてに同じフォントを使用する方が良いでしょうか?
  • 「カテゴリごとに1つのフォント」の議論は、読者が私がどのようなことを言っているのかを一目でわかりやすくするようなもののようです-これには正当化がありますか?または同じことを達成するためのより良い方法は?
  • 私はこのGDトピックを読みましたが、学術論文の見栄えを良くするための指針はありますか?

6
間隔に関するサイドの質問に関する簡単なメモ-段落間の半行と行の間隔を追加すると役立ちます。
user56reinstatemonica8

2
LaTeXコードでMWEを追加して表示テキストを取得できると便利だと思います。どのフォントを使用しましたmicrotypeか、使用しましたか?
メンシュ

回答:


10

ご指摘のとおり、多くの問題があり、それらはすべてTeXの実装(またはおそらく使用方法)に起因しています。

はげリストについては、私は引用

  • スコッチローマの顔の使用
  • 文字間隔が悪い
  • 行の間隔が狭すぎる
  • フォントの混ざり具合が悪い(sansとscript)

TeXのスコッチローマの顔は古風でうるさいです。これらすべてのセリフ!より大きな指導力を必要とするのは、この混乱です。文字間のスペースが不十分なことは役に立ちません。一部の文字は他の文字よりもgreat屈です。ciphertextという単語を見てください。スモールキャップは実際のスモールキャップではありません。サイズを単純に縮小して、比率を同じに保ちます。小型株はそれをしません。sansとscriptフォントは、メインフォントと同じ光学密度を持っていないため、うまくミックスされていません。アルゴリズム名にsansを使用しても問題ありませんが、そのコンテキストで目立つ必要はありません。

テキストのリセット例を次に示します。メインフォントはCallunaであり、使用したソフトウェアはfiやffiの合字に対応できず、シンボルに使用できるフォントの範囲は限られていました。また、ネイティブでスモールキャップを行いません。「スモールキャップ」を設定し、幅を115%に増やして、実際のスモールキャップのように見せました(メインストロークを同じ幅に保ちます)。最終結果は、インクの均等な分布です。

リーディングは、シンボルの混合と読みやすさの維持に役立つため、増加します。斜体は適切に設計されており、テキストの全体的な黒さを変更しません。Sansの言葉はCalluna Sans Lightに設定されています。これはCallunaから派生しているため、文字の形状は非常に似ており(同じサイズです!)、Lightバリアントを再び使用すると、光学濃度が保持され、突き出ることはありません。これにより、見出し語が見出しになります。

他の人が示唆しているように、パラグラフ間にさらにスペースを追加する余地は確かにありますが、これが小さなアイテムのリストである場合、それを分割しすぎる可能性があります。一般的に、リストの先頭を増やしてページに光を入れることで十分です。より大きな「実際の」段落は、空白の余分な半行の恩恵を受ける可能性があります。

テキストをリセット


何もいじっていないので、適切なスモールキャップとスペースが得られないのは奇妙です。LaTeX/ KOMAのスモールキャップテキスト用のデフォルトscrartclクラス\textscです。
ブリストル

4
それを言って申し訳ありませんが、あなたのポイントのいくつかに強く反対するので、私は最初のダウン票を与えました。まず、コンピューターローマには何も問題はありません。どんなに馬鹿げたファッションが存在していても、セリフが強いフォントは読みやすいと思います。第二に、2つの段落をやり直そうとする試みは非常に見苦しく、黒板の文字はスモールキャップサイズであり、段落のタイトルの後に余分なスペースがありません。唯一のポイントはベースラインストレッチの増加ですが、それを行う方法は多すぎます。
yo

@ブリストルしようとしたことがあり\usepackage{lmodern}ますか?CMフォントの多くの問題を修正します。しかし、それはタイポグラフィの側面よりもTeXの側面のほうが重要です。
yo

5

異なるカテゴリの要素に対する異なるフォントの原則は間違っていませんが、これらのフォントは多かれ少なかれ調和した方法で共存する必要があります。

これは私の個人的な意見です。個々の文字は問題ではないと思いますが(たとえば、2種類のGが必要であり、どちらもセリフで、同じ拡張家族に属しているように見えます)、 KeyGen sans-serifが少しおかしいとわかります。これは良い目的に役立ちます。これらの単語を他の単語と区別しますが、不必要に「誇張された」方法で区別します。私は通常、同じ行/段落でセリフとサンセリフを組み合わせません。どちらのスタイルも読みやすさについてはほぼ間違いなく同じですが(この質問を参照)、それらを混合することはより...問題がある可能性があり、これが起こる理由です。

読みやすさは個々の文字や単語を簡単に認識することですが、読みやすさはテキスト全体の最適な配置とレイアウトに関係しています。フォントは判読可能ですが、段落は判読可能ですか?あなたは特に複雑な例を持っているので、いくつかの変動性を辞任することは非常に難しいでしょうが、非常に多くのフォントを共存させる必要がありますか?私は尋ねます:あなたのすべての情報は等しく重要であるので、各要素に独特の外観を与える必要がありますか?答えはイエスかもしれませんが、あなたの定義が何を言っているのか私にはわかりませんが、次のものを失うことはできないと想像できます:異なる単一文字、大文字の頭字語、斜体の定義(たぶん?)、識別可能なアルゴリズム。

それが読みやすさに焦点を当てる理由です。読みやすさは複数の条件の相互作用であるため、行の長さ、行間隔、フォントのサイズ、フォントの幅、フォントの熟知度、段落サイズなど、他の要素を考慮する必要があります。スペースの制約がない限り、すべてをきつく詰める必要はありません。一緒に見えるフォントを見つけるのではなく(サンセリフを除いて!)、空白、特に段落間のスペースに取り組みます。


1

本当に言うのは難しいです。

多くの技術文書では、特別な記号を伝えるために特別なフォントが必要です。XXページの数式にフォントが必要な場合、同じフォントを数式全体で使用する必要があります。あなたのサンプルはある程度これに苦しんでいると思います。数式フォントがイタリック体フォントのように見えるのは残念です。イタリック体のない等式書体使用すると、読みやすさが向上します。

斜体は、特に名前に使用することもできます。ゲノム名は常に斜体で表示されます。サンプルでは、​​強調と同様に名前に斜体が使用されているように見えます。それは私にいくつかの混乱を作成します。イタリックを1ポイント大きく設定すると役立ちます。多くの場合、これは斜体です。それらは周囲のテキストより視覚的に小さく見える傾向があります(フォントが同じであっても)。斜体を1pt大きく設定すると、視覚的な違いを回避できます。また、他の形式の強調変更を使用することも有益です。ただし、他の書体のウェイトは使用できない場合があります。下線を使用することもできますが、まあ...私はそれらを嫌い、可能な限り避けます。

「KeyGen」などの異なる書体は、斜体または太字フォントを使用せずにそれらの項目を強調するために表示されます。それはいくらか理にかなっています。

私は個人的に最初の行をインデントしません。どちらかといえば、インデントするのではなく、最初の行をハングさせます。

そして、私はuser568458のコメントに同意します。段落間のスペースは大いに役立つでしょう。


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.