Здравствуйте, c-smile, Вы писали:
CS>Т.е. HTML там испоьзуется как layout manager и одновременно рисовальщик статиков : текста, картинок и пр. CS>Как резюме: реалистично говорить о кросплатформе в кторой 70-90% кода шарится между платформами. CS>!00% серебрянной пули нет по условиям задачи
А в это время Unity спокойно шарашит на все мыслимые платформы даже в html.javascript...
Здравствуйте, akasoft, Вы писали:
CC>>Ээээ? чо? A>Многие считают "зависло", если приложение не отвечает пару минут. Но дать приложению ядер, частоты или памяти многие не считают. А это напрямую влияет на "зависло".
Так и представляю — подзавис фар, встал и пошел покупать другой ноутбук, раза в два дороже.
Здравствуйте, Marty, Вы писали:
M>Тебе никто не обещал, что GDI выдаст тебе в любом масштабе абсолютно идентичную картинку. M>Но на GDI можно сделать рендерер PDF, и 99 процентов пользователей ничего не заметит по сравнению с адобовским.
На самом деле — наоборот. Рендерер сделать можно — их полно, только вот страница будет выглядеть совсем иначе. У адоба читать страницу очень легко, глаза не устают. А вот в рендерере где страница сделана через textout, читать неприятно, устаёшь уже через пару минут.
Акробат умеет менять масштаб на 1%, а вот у тебя точно видно, что этого нет и не будет в обозримом будущем.
Здравствуйте, Pauel, Вы писали:
P>Так и представляю — подзавис фар, встал и пошел покупать другой ноутбук, раза в два дороже.
И такое бывает.
Приходят, жалуются, система лагает, сёрфинг тупит, 3d max не едет, полечи. Смотришь, а там 2 ядра 4Г памяти.
Здравствуйте, Pauel, Вы писали: P>Акробат умеет менять масштаб на 1%, а вот у тебя точно видно, что этого нет и не будет в обозримом будущем.
Без шансов. Коллега нахамил, а когда его ткнули носом в неудачный результат, убежал обратно в политику.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>И очень зря. Одно дело, когда вы выводите одну отдельную строку (скажем, в заголовке окна). Тогда то, что она удлиняется неравномерно при росте зума — незначительное неудобство. S>Иное дело, когда вы выводите на экран целую страницу, которая свёрстана определённым образом.
Редакторы верстают страницы в памяти без всякого GetTextExtentPoint32 и им подобных тормозных вызовов, ес-но.
Один раз кешируются размеры глифов символов шрифта данного размера под некий высокий DPI (стандартом в вёрстке журналов на тот момент было, вроде, 300 DPI), причём, этот размер фиксирован для каждого символа конкретного абзаца, поэтому, вёрстка в памяти происходит точно. Текст в памяти был представлен 16-тибитными индексами соотв.глифов из кеша (ага, в старых Вордах более 64к вариантов глифов в одном док-те не получалось).
А вот вёрстка на экране может быть уже не столь точной, ес-но.
Только это не заметно, т.к. при выравнивании по ширине играют шириной пробелов, поэтому правый край будет выровнен.
А при отсутствии выравнивания (допустим, нет выравнивания справа) — оно и вовсе незаметно, т.к. не с чем сравнить, если все строки имеют разную ширину.
При печати же обычно оперируют другим DPI (300, 600, 1200) и там точность получше экранных 96 DPI.
В общем, вы обсуждаете ту проблему, которой в реальности для редакторов текста никогда не существовало.
Взять даже текст в таблице, при некотором масштабе символы на экране могут соприкасаться с линиями-границами ячеек, но работавшим на старых мониторах обычно было понятно, что вывод на экран оперирует невысоким разрешением, и что округление происходит грубо.
В те годы за компами вообще дураков было поменьше. ))
В конце 90-х пошли уже "бытовые" (т.е. дешевые) лазерные принтеры с разрешением 600 DPI и струйные 1200 DPI, тут уже последним дуракам стало ясно, что на печати текст выглядит вовсе не как на экране, а в разы чётче. А на экране для проверки некоей области док-та его просто просматривали под нужным увеличением.
Здравствуйте, Sinclair, Вы писали:
M>>Но на GDI можно сделать рендерер PDF, и 99 процентов пользователей ничего не заметит по сравнению с адобовским. S>Прекрасно заметят, когда текст, который был выровнен, начнёт плавать при кручении колёсика зума.
Каким образом?
Это надо чтобы текст был без пробелов?
Тогда это, скорее всего, одинаковый текст в строках, т.е. строки будут идентичными при любом зуме.
Здравствуйте, vdimas, Вы писали: V>Каким образом?
Очень простым. V>Это надо чтобы текст был без пробелов?
Не обязательно. Достаточно просто пользоваться TextOut. V>Тогда это, скорее всего, одинаковый текст в строках, т.е. строки будут идентичными при любом зуме.
Не обязательно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Sinclair, Вы писали:
S>>И очень зря. Одно дело, когда вы выводите одну отдельную строку (скажем, в заголовке окна). Тогда то, что она удлиняется неравномерно при росте зума — незначительное неудобство. S>>Иное дело, когда вы выводите на экран целую страницу, которая свёрстана определённым образом.
V>Редакторы верстают страницы в памяти без всякого GetTextExtentPoint32 и им подобных тормозных вызовов, ес-но. V>Один раз кешируются размеры глифов символов шрифта данного размера под некий высокий DPI (стандартом в вёрстке журналов на тот момент было, вроде, 300 DPI), причём, этот размер фиксирован для каждого символа конкретного абзаца, поэтому, вёрстка в памяти происходит точно. Текст в памяти был представлен 16-тибитными индексами соотв.глифов из кеша (ага, в старых Вордах более 64к вариантов глифов в одном док-те не получалось).
Это бесценная информация об устройстве Word, особенно, если она правдива.
То, что в режиме редактирования приходится идти на компромиссы — общеизвестно.
Но при отображении PDF такие вольности себе позволять нельзя. Попробуйте открыть в акробате любой документ и покрутите зумом — вы убедитесь, что интервалы между словами вовсе не плавают. Как это было бы, если бы акробат делал так, как вы предлагаете — компенсировал рывки ширины глифов изменением размера пробелов.
Вы лучше ответьте на вопросы про индексы — я жажду знаний про уникальность time-series, и про отличия n-tree от B-tree.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
P>>У адоба читать страницу очень легко, глаза не устают.
V>Наоборот, на мониторах с плохим разрешеним читать PDF в Акробате было невозможно из-за мылкости. V>Зато в Ворде — читабельно.
Типичный монитор он с хорошим разрешением. Напомню — сегодня почти 2023й год.
Где найти тот, что с плохим- не представляю.
Здравствуйте, 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.
Но это несущественная неточность, т.к. мы рассуждали о сжатии информации и оно, существенное сжатие, всё-равно присутствует.
Здравствуйте, vdimas, Вы писали:
V>Эта особенность была не только Акробате, но и в другой популярной на тот момент проге по верстке печатного материала — в Word Press. V>И все прекрасно понимали, почему так — потому что это инструмент для вёрстки, а не для работы над текстом.
Ну, то есть коненсус. Ок.
V>Если бы ты не кривлялся там, а был настроен на предметный разговор, я бы читал твои ответы. V>Но как только опять начинаешь маяться хернёй — просто облом тратить время, бо а смысл? V>Я там допустил только одну ошибку — в оценке размера реального дерева, на основе бинарного, которое со сжатией информации.
Размер реального дерева, хоть бинарного, хоть B-дерева, это O(N) от исходных данных. V>Оно там оценочного размера N/K, где K порой достаточно большое, а не log N.
Ну, то есть логарифма нет. V>Но это несущественная неточность, т.к. мы рассуждали о сжатии информации и оно, существенное сжатие, всё-равно присутствует.
Непонятно, о каком сжатии идёт речь.
На всякий случай напомню, что в обычном дереве ровно столько ссылок на сами данные, сколько записей в исходных данных.
Ваша идея про то, что можно одной ссылкой из дерева сослаться сразу на X записей исходных данных, в целом верна, хоть и лажает в деталях.
Например, кластерные индексы в MS SQL именно так и устроены — только они не зависят от наличия непрерывных диапазонов в значениях первичного ключа в исходных данных. Достаточно простой упорядоченности.
Просто "листьями" кластерного индекса являются сами страницы данных. Т.е. они тоже являются частью дерева, и никакого "сжатия" не происходит — в частности, алгоритмы split/merge при вставке и удалении записей применяются не только к branch-нодам, но и к страницам данных. И, тоже в частности, если таблица с кластерным индексом целиком влезает в одну страницу, то никаких дополнительных страниц на индекс не выделяется — сама эта страница и является корнем индекса. Если считать по вашей методике, это означает бесконечный "коэффициент сжатия" — нулевой размер "индекса" при ненулевом размере данных.
А если считать по общепринятой, то по-прежнему имеем O(N).
Страницы предыдущего уровня в ссылках на страницы данных никаких "длин диапазонов" не хранят — достаточно просто хранить PageRef на страницу данных и минимальное значение ключа на ней. Это позволяет увеличить branch factor по сравнению с вашей идеей.
Для time series, которые вам кажется удобно хранить просто в виде "отсортированного списка" напомню, что поиск по B-дереву всё ещё эффективнее бинарного поиска по отсортированному массиву, даже если его удалось поднять в память одним непрерывным блоком — из-за локальности кэша. Так что никаких отдельных "time-series" индексов не существует за ненадобностью.
Про мелкие ошибки в виде забытых значений ключей в branch-страницах B-дерева я уже и вовсе молчу — это можно списать на опечатки при наборе.
Самое главное-то в том, что PGM индекс по-прежнему уделывает B-деревья, эффективнее которых для диапазонных запросов за предыдущие 30+ лет ничего не придумали.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>На всякий случай напомню, что в обычном дереве ровно столько ссылок на сами данные, сколько записей в исходных данных.
И кто мешает дорабатывать структуры данных?
S>Ваша идея про то, что можно одной ссылкой из дерева сослаться сразу на X записей исходных данных, в целом верна, хоть и лажает в деталях.
Нет там никакой лажи, натуральная физическая сортировка записей по первичному ключу вводится в БД именно за этим.
S>Например, кластерные индексы в MS SQL именно так и устроены — только они не зависят от наличия непрерывных диапазонов в значениях первичного ключа в исходных данных. Достаточно простой упорядоченности.
Да, в терминах MS SQL этот индекс назвали "кластерным".
От замечания про прерывность или непрерывность диапазонов поржал, конечно.
Ты разве не в курсе про самые первые алгоритмы сжатия графики в GIF и ICO форматах?
Непрерывные последовательности пикселов одинакового цвета кодируются одной записью.
Понятно, что таких записей будет больше, если "диапазоны" прерываются.
Подобные способы сжатия информации — одни из очевиднейших, используются со времён царя Гороха.
И тут ты даёшь ссылки на "новейшее исследование" по давно известному. ))
В общем, опять попёр от тебя примитив какой-то, опять резко стало скучно, дальше не читал...
Здравствуйте, Sinclair, Вы писали:
V>>Чем не устроил ExtTextOut? S>Он с точки зрения обсуждаемых вопросов ничем от TextOut не отличается.
Отличается принципиально — вёрстка документа выполняется не ср-вами GDI в момент вывода текста (где GDI TextOut вынужден каждый раз расчитывать лейаут выводимого текста перед прорисовкой, отчего тормоза), а эта вёрстка выполняется предварительно в некоей "виртуальной" модели док-та и, с т.ч. задач отображения, статична.
Именно поэтому даже старенькие Ворды довольно шустро листали док-т (т.е. шустро обновляли его изображение на экране), что задача вёрстки была отделена от задачи отображения.
Ты это упустил в рассужениях, поэтому лажал. ))
Если бы помнил о таком разделении, то с полутыка догадался бы, что "виртуальная вёрстка" в памяти происходит точно, а на экране отображается с учётом допущений, связанных с низким разрешением экрана, где приоритет был отдан чёткости изображения букв перед позиционированием.
Плюс мои рассуждения про отыгрывание выравнивания пробелами, в общем, задача отобразить док-т достаточно точно не выглядела неразрешимой — выравнивание по правому и левому краях в Ворде и других редакторах всегда было идеальным. Поэтому спор заведомо бестолковый.
Здравствуйте, Sinclair, Вы писали:
V>>Текст в памяти был представлен 16-тибитными индексами соотв.глифов из кеша (ага, в старых Вордах более 64к вариантов глифов в одном док-те не получалось). S>Это бесценная информация об устройстве Word, особенно, если она правдива.
Кстате, в какой-то момент они перешли на прорисовку ср-вами DirectX.
Вряд ли это было ускорения ради, т.к. ср-вами GDI шрифты рисовались драйверами этого GDI более чем эффективно.
Думаю, это была попытка обойти ограничение на 16-битные индексы глифов в GDI, бо в DX можно кешировать произвольное кол-во глифов.
А всякие 3D эффекты текста и плоских фигур появились после перехода на DirectX, ИМХО, "потому что теперь так можем". ))
На самом деле — наоборот. Рендерер сделать можно — их полно, только вот страница будет выглядеть совсем иначе. У адоба читать страницу очень легко, глаза не устают. А вот в рендерере где страница сделана через textout, читать неприятно, устаёшь уже через пару минут. 
