Здравствуйте, Sinclair, Вы писали:
S>Но при отображении PDF такие вольности себе позволять нельзя. Попробуйте открыть в акробате любой документ и покрутите зумом — вы убедитесь, что интервалы между словами вовсе не плавают.
Ес-но, поэтому текст в Акробате такой мылкий на мониторах с невысоким разрешением, поэтому такой трудночитабельный.
Но речь шла о редакторах, и там техника относительно проста.
Одно время было достаточно инфы о представлении данных в редакторах текста, об индексировании глифов и наличии в АПИ операционок ф-ий по выводу цепочек глифов (в X11 и в Windows GDI такие АПИ присутствуют, в новом АПИ WinRT, которая начиная с Win8, — тоже).
И ничего с тех пор не изменилось — примерно так же обстоят дела в библиотеке рендеринга FB2/FB3, разработанной русскими программистами — никакой мылкости.
Т.е. в приоритете чёткость изображений букв, а не попиксельная точность вёрстки.
S>Как это было бы, если бы акробат делал так, как вы предлагаете — компенсировал рывки ширины глифов изменением размера пробелов.
Эта особенность была не только Акробате, но и в другой популярной на тот момент проге по верстке печатного материала — в Word Press.
И все прекрасно понимали, почему так — потому что это инструмент для вёрстки, а не для работы над текстом.
Текстовые блоки помещались в Word Press уже в готовом виде.
В то время как MS Word — это text processor.
Соотв, приоритеты расставлены чуть иначе — чёткость изображений букв на первом месте.
Я вообще ХЗ о чём тут спор, это же азы любой инженерии — анализ сценариев, постановка задачи.
Плюс, приоритет задач по верстке печатного материала уже давно достаточно низкий, т.к. сейчас всё больше инфы живёт онлайн, и браузеры ведут себя примерно как MS Word. ))
S>Вы лучше ответьте на вопросы про индексы — я жажду знаний про уникальность time-series, и про отличия n-tree от B-tree.
Если бы ты не кривлялся там, а был настроен на предметный разговор, я бы читал твои ответы.
Но как только опять начинаешь маяться хернёй — просто облом тратить время, бо а смысл?
Я там допустил только одну ошибку — в оценке размера реального дерева, на основе бинарного, которое со сжатией информации.
Оно там оценочного размера N/K, где K порой достаточно большое, а не log N.
Но это несущественная неточность, т.к. мы рассуждали о сжатии информации и оно, существенное сжатие, всё-равно присутствует.
