Формирование pdf из js

Обнаружилась интересная библиотека jspdf - позволяющая создавать простейшие pdf из js. Она основана на коде(скорее принципах и как пример) fpdf. Позволяет менять размер шрифта и размещать текст на странице - pdf возвращается как datauri, отлично работает в linux, но в windows есть несколько проблемок: ie не понимает datauri ни в каких формах, кроме как встроенное в страницу изображение, firefox при установленных обработчиках pdf(например: acrobat reader) происходит переход на этот url и показывается черный экран вместо контента страницы, иначе предложение загрузить. Это решаемо достаточно просто контент отправляется обратно на сервер как параметр POST, в ответ возвращается уже как контент с типом pdf - и все нормально работает.

P.S.: Я немного улучшил эту библиотеку добавив смену цвета шрифтов, поддерживается градации серого и полная RGB палитра.

gtkhtml

Прогресс добавления поддержки css:

libxml2

Может изменять кодировку поэтому дерево всегда приходит в utf8. То есть она частично снимает проблему конвертации - нужна только в ответном запросе.

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

После получения полного контента нужно отмечать что пришел последняя часть информации - если не указать то могут быть не полностью обработан полученные данные - разбор полностью выполняется только для полностью корректных частей. Если данные были не корректно отформатированы - то libxml всегда пытается  вернуть корректное дерево.

Сама библиотека:

Отрисовка дерева строиться на собственном виде дерева элементов - поэтому

четкого преобразования полученного DOM дерева  в дерево элементов один в один получить нельзя. Сейчас с моими изменениями пытаемся реализовать почти преобразование один в один - поэтому многие вещи отображаются не корректно. Например картинки - если они находятся на более чем одном уровне вложенности их не показывает, так как описания потока отображения(clue) - поддерживает только определенный вид вложенности - и определенные комбинации не могут быть отработаны так как код реализации выравнивания и раз размещения реализованы не для всех потоков(точнее по части функционала в каждом) .

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

Сейчас основной различие - применены все мои изменения для исправления мелких ошибок функциональности(выделены как патчи в bugzilla): исправления относительных путей, поддержка datauri и мелкие исправление в makefile. И не выделенные в качестве изменений: зависимости от гнома при компиляции(gnome-common,gconf), удален парсер html и рекурсивная обработка дерева.

В общем пока планирую - вернуться к не рекурсивному обходу дерева(стандартным старым функциям) и попытаться запостить патч в стандартную ветвь.

Стоит прочитать.....

Недавно дочитал книгу о физике Ричарде Ф.Фейнмане.'Вы, конечно, шутите, мистер Фейнман!' - очень веселая и интересная книга, рекомендовал бы в любом случая прочитать. Физика(и вообще наука) в книге упоминается очень вскользь и очень простыми для понимания фразами, можно читать книгу как собрание интересных историй из жизни.

Hybrid graphics...Очень кратко

Включение достаточно простое:

• патчим текущее ядро
• включаем kms в ядре и поддержку radeon(желательно все как модули)
• устанавливаем последние версии mesa и xf86-video-ati
• копируем прошивки R600_rlc.bin и R700_rlc.bin в /lib/firmware/radeon/

Перегружаемся и монтируем mount -t debugfs none /sys/kernel/debug в результате появляется переключатель /sys/kernel/debug/vgaswitcheroo/switch - из которого можно прочитать текущее состояние видеокарт. Если записать в него записать( echo some_thing > switch):

• DDIS - включение дискретной карты;
• DIGD - включение интегрированной карты;
• OFF - выключить лишнюю карту - позволяет серьезно продлить время работы от батарейки(при включении включены обе карты).

Благодарность Dave Airlie за решение этой маленькой несуразицы с поддержкой. :-) и авторам заметки asusm51ta-with-linux. Надеюсь это патч скоро попадет в основную ветвь ядра....

И маленькие логи напоследок:

glxinfo 3650
....
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: Mesa DRI R600 (RV635 9591) 20090101  TCL DRI2
OpenGL version string: 2.0 Mesa 7.8.1
OpenGL shading language version string: 1.10
....
glxgears 3650
......
9416 frames in 5.0 seconds = 1883.109 FPS
......
glxinfo 3200
......
OpenGL vendor string: Advanced Micro Devices, Inc.
OpenGL renderer string: Mesa DRI R600 (RS780 9612) 20090101  TCL DRI2
OpenGL version string: 2.0 Mesa 7.8.1
OpenGL shading language version string: 1.10
.......
glxgears 3200
.......
6627 frames in 5.0 seconds = 1325.309 FPS

Программный scroll на JQuery

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

Предполагаемый выход создание div ограничивающего общий обзор видимости(div_for_scroll), в нем большой div(scrolled_content_full) (его размер линейно зависит от реального количества элементов). Он нужен для получения нужного нам scroll. И уже в нем div(scrolled_content) сдвигаемый по вертикали в котором отображается список видимых в данный момент элементов.

Вот и вся идея.

HTML код:
<div id="div_for_scroll" style="height: 132px; overflow-y: scroll;">
<div id="scrolled_content_full" style="height: 1000px;">
<div id="scrolled_content" style="padding-top: 123px;">
This div contein scrolled content
</div>
</div>
</div>

Js код:

        var ElementsArray = {};
       
        //каждый элемент массива объект вида: {html:html, name:HumName, id:i}, имя нужно для сортировки.
       
        function refreshScroll() {

            var FontSize = 16;
            var newSize = parseInt((ElementsArray.length + 1.5) * FontSize);
            if (newSize<132)
                newSize = 132;
            jQuery("#scrolled_content_full").css("height", newSize + "px");
            var currpos = parseInt(jQuery("#div_for_scroll").scrollTop() / FontSize);
            var newHtml =  "";
            for (var i= currpos;i< (currpos + 10); i ++) {
                if (i < ElementsArray.length)
                    newHtml    += ElementsArray[i].html;
            }
           
            jQuery("#scrolled_content").html(newHtml);
            jQuery("#scrolled_content").css("padding-top",jQuery("#div_for_scroll").scrollTop());
        }

        jQuery("#div_for_scroll").scroll(refreshScroll);

Упрощение списка координат

Иногда нужно упростить список координат, например вывод kml(kmz) на маленьких уровнях увеличения - большая точность отображения не нужна, зато скорость очень важна.

Наиболее популярным вариантом в этом случае является Douglas-Peucker Algorithm дающим хорошую для человека результирующую траекторию. Но он является достаточно алгоритмически сложным, так как для удаления лишних точек удаляя определяя точки с минимальным векторный расстоянием между точками. 

Более простым вариантом является замена всех точек на точку в середине между двумя соседними - в результате получается на 1 точку меньше. Эту операцию поврторяем пока количество точек не станет удолетворять максимально допустимому для отображения. Недостатки - не учитыват важность точек(смена направления), срезаются углы и выравнивается границы.

Более хорошая версия - проход по точкам и высчитывается минимальное растояние между точками, если оно слишком мало, то увеличиваем его до минимально допустимого.

Затем запускается цикл по точкам и добавляются только те точки, которые располагаются на расстоянии от последней добавленной точки больше, чем минимально допустимое полученное на предыдущим шаге. Эту операцию повторяют пока количество точек не станет меньше максимально допустимого (вычисляется в общем-то на глаз, до тех пор пока время пересчета допустимо по времени ожидания и дефекты в контурах карт еще мало заметны). Также итерации могут продолжаться пока в контуре более 3 точек и площадь полигона больше допустимого для отображения, меньше можно просто отбрасывать(можно считать, что площадь линейно зависима от произведения минимального расстояния на количество точек, что, конечно, геометрически не всегда верно). Для упрощения математической сложности модно считать что расстояние равно не квадрату различий между точками((x1-x2)^2 + (y1-y2)^2 ), а сумме расстояний по координатам по модулю(|(x1-x2)| + |(y1-y2)|), что опять таки не всегда верно, но зато быстро.   

3D в linux

После обновления ядра до 2.6.33 и обновления Ubuntu до 10.04 (запуск обновления: update-manager -d ) с установленными обновлениями из xorg-edgers появилась достаточно быстрый рендеринг 3d и kms. Правда - с стандартным ядром у меня система не загрузилось,  на этапе создания splash screen  экран погас и на переключение консолей не реагировал, возможно причина в уже установленных обновлениях mesa. Без обновления до 10.04 33 ядро грузилось с поддержкой KMS, но без поддержки 3d. Сейчас есть только один артефакт - неправильное отображение воды в Cube2. 

Осталось  подождать поддержки Hybrid graphics и стабилизации версии mesa.