Здравствуйте, Sinclair, Вы писали:

S>И очень зря. Одно дело, когда вы выводите одну отдельную строку (скажем, в заголовке окна). Тогда то, что она удлиняется неравномерно при росте зума — незначительное неудобство.
S>Иное дело, когда вы выводите на экран целую страницу, которая свёрстана определённым образом.

Редакторы верстают страницы в памяти без всякого GetTextExtentPoint32 и им подобных тормозных вызовов, ес-но.
Один раз кешируются размеры глифов символов шрифта данного размера, причём, этот размер фиксирован для каждого символа конкретного абзаца, поэтому, вёрстка в памяти происходит точно. Текст в памяти был представлен 16-тибитными индексами соотв.глифов из кеша (ага, в старых Вордах более 64к вариантов глифов в одном док-те не получалось).

А вот вёрстка на экране может быть уже не столь точной, ес-но.
Только это не заметно, т.к. при выравнивании по ширине играют шириной пробелов, поэтому правый край будет выровнен.
А при отсутствии выравнивания (допустим, нет выравнивания справа) — оно и вовсе незаметно, т.к. не с чем сравнить, если все строки имеют разную ширину.

При печати же обычно оперируют другим DPI (300, 600, 1200) и там точность получше экранных 96 DPI.

В общем, вы обсуждаете ту проблему, которой в реальности для редакторов текста никогда не существовало.

Взять даже текст в таблице, при некотором масштабе символы на экране могут соприкасаться с линиями-границами ячеек, но работавшим на старых мониторах обычно было понятно, что вывод на экран оперирует невысоким разрешением, и что округление происходит грубо.
В те годы за компами вообще дураков было поменьше. ))

В конце 90-х пошли уже "бытовые" (т.е. дешевые) лазерные принтеры с разрешением 600 DPI и струйные 1200 DPI, тут уже последним дуракам стало ясно, что на печати текст выглядит вовсе не как на экране, а в разы чётче. А на экране для проверки некоей области док-та его просто просматривали под нужным увеличением.

Здравствуйте, Sinclair, Вы писали:

S>И очень зря. Одно дело, когда вы выводите одну отдельную строку (скажем, в заголовке окна). Тогда то, что она удлиняется неравномерно при росте зума — незначительное неудобство.
S>Иное дело, когда вы выводите на экран целую страницу, которая свёрстана определённым образом.

Редакторы верстают страницы в памяти без всякого GetTextExtentPoint32 и им подобных тормозных вызовов, ес-но.
Один раз кешируются размеры глифов символов шрифта данного размера под некий высокий DPI (стандартом в вёрстке журналов на тот момент было, вроде, 300 DPI), причём, этот размер фиксирован для каждого символа конкретного абзаца, поэтому, вёрстка в памяти происходит точно. Текст в памяти был представлен 16-тибитными индексами соотв.глифов из кеша (ага, в старых Вордах более 64к вариантов глифов в одном док-те не получалось).

А вот вёрстка на экране может быть уже не столь точной, ес-но.
Только это не заметно, т.к. при выравнивании по ширине играют шириной пробелов, поэтому правый край будет выровнен.
А при отсутствии выравнивания (допустим, нет выравнивания справа) — оно и вовсе незаметно, т.к. не с чем сравнить, если все строки имеют разную ширину.

При печати же обычно оперируют другим DPI (300, 600, 1200) и там точность получше экранных 96 DPI.

В общем, вы обсуждаете ту проблему, которой в реальности для редакторов текста никогда не существовало.

Взять даже текст в таблице, при некотором масштабе символы на экране могут соприкасаться с линиями-границами ячеек, но работавшим на старых мониторах обычно было понятно, что вывод на экран оперирует невысоким разрешением, и что округление происходит грубо.
В те годы за компами вообще дураков было поменьше. ))

В конце 90-х пошли уже "бытовые" (т.е. дешевые) лазерные принтеры с разрешением 600 DPI и струйные 1200 DPI, тут уже последним дуракам стало ясно, что на печати текст выглядит вовсе не как на экране, а в разы чётче. А на экране для проверки некоей области док-та его просто просматривали под нужным увеличением.