Неверный размер шрифта в .NET GDI +?

Question

Я разыгрываю свои мозги, пытаясь понять несоответствие между размерами шрифтов, которые пользователи выбирают или задают (например, используя FontDialog) и размер em, указанный . Шрифт класс в .NET.

Например:

using (FontDialog dlg = new FontDialog()) { 
    if (dlg.ShowDialog() == DialogResult.OK) { 
     Console.WriteLine("Selected font size: " + dlg.Font.SizeInPoints.ToString("0.##")); 
    } 
} 

Используя приведенный выше код, вы получите некоторые запутанные результаты:

Выбор 11 в диалоге производит 11,25

Выбор 12 в диалоге производит 12

Выбор 14 в диалоговом окне производит 14.25

Выбор 16 в диалоговом окне производит 15.75

Это поведение происходит независимо от выбранного шрифта. Как видно из вышеизложенного, в расхождении нет шаблона, оно, по-видимому, изменяется случайным образом между +0,25 и -0,25.

Я обойду это в пользовательских интерфейсах, только когда-либо отображая размер шрифта в виде округленного целого числа, но я клянусь, что видел пакеты обработки текстов/DTP, которые позволяют пользователям выбирать размеры дробных шрифтов - и эти пакеты не показать поведение выше при взаимодействии с диалоговыми окнами шрифтов Windows.

Может ли кто-нибудь дать рациональное объяснение этому? Существует ли наилучшая методика отображения размера шрифта в пользовательском интерфейсе? Как насчет того, когда пользователю нужен дробный размер, такой как «10 .5»?

Answer 1

нет никакой закономерности в несоответствии

Как вы можете видеть, размер шрифта произойдет с шагом 0,75.

Редактировать: вы можете точно настроить размеры, если вы не используете диалог шрифта, но результаты, которые я подозреваю, будут менее приятными, чем «предпочтительные» размеры.

Answer 2

Рассмотрим эти лакомые:

• дюйма, в результате, однако эти вещи решаются в истории, содержит 72 пунктов.
• Обычно люди работают под управлением Windows с разрешением : логическое разрешение - 96 точек на дюйм.
• Хм, хорошо, у нас есть точки, дюймы и точки - три единицы, чтобы иметь дело с здесь.
• GDI хочет знать, сколько точек сделать ставку, и пользователь выбирает баллов.
• И, наконец, соотношение 72 точек на дюйм/96 точек на дюйм = 0,75 пункта за точку.

Это 0.75 неудачно! Это означает, что если мы разрешим пользователю выбирать точки прямо вверх, тогда идеальный рендеринг будет использоваться только на части логической точки. Было бы неплохо, если бы мы могли привязать весь рендеринг вверх или вниз к ближайшей целой логической точке.

Готов? Вот так!

---

• 11:
  • 11 баллов/72 точек на дюйм = 0,153 дюйма * 96 точек на дюйм = 14.667 точек, Barf!
  • Давайте объединимся до 15 точек,
  • SO затем 15 точек/96 точек на дюйм * 72 точки на дюйм = 11,25 пункта.

---

• 12:
  • 12/72 * 96 = 16 точек.
  • Я могу жить с этим, не нуждаясь.

---

• 16:
  • 16/72 * 96 = 21,3333, BARF!
  • Давайте округлим до 21 точки/96 * 72 = 15,75, намного приятнее.

---

Вы получаете идею.

Помните, что эти цифры будут меняться, если пользователь изменяет свое логическое разрешение (96 точек на дюйм, 120 точек на дюйм и т.д.)