Comments 28
Ждем файловый менеджер для ff как следующую ступень приближения к Kparts.
Ищу flash.js
У меня ни один pdf так и не открылся.
FF 7.0.1 Ubuntu
FF 7.0.1 Ubuntu
Грузится гораздо быстрее плагина от Adobe. Замечательно, всю жизнь считал что такие плагины зло, но сейчас изменил свое мнение.
А кошечку на фотки что ли замочили?
Еще бы нормальное расширение по работе с MHT… Эх.
Мда.
Думаю, дело в minimum font size. Куда багрепорт писать?
Думаю, дело в minimum font size. Куда багрепорт писать?
Нашёл, куда.
А выделения текста как не было, так всё ещё и нет. Ну и кому нужен такой рендеринг?
Прошу прощения за вопрос, а в других браузерах тоже ведь должно работать?
Увы, очередная зва-читалка не будет поддерживать автоматическую смену страниц, что критично для анимаций в презентациях.
*pdf
1. Насколько я знаю, анимацию последовательной сменой кадров поддерживает только Adobe Reader, а им пользуются не все. Поэтому, если хотите универсальное решение, вставляйте видео. Главное, чтобы кодек поддерживался.
2. Зачем запускать презентацию из браузера? Поддержку pdf в браузерах реализуют исключительно для удобства серфинга, чтобы документ не надо было скачивать на диск и открывать в сторонней программе. Вы же на презентацию приходите с файлом на флэшке, не так ли? Или скачиваете каждый раз по ссылке?
2. Зачем запускать презентацию из браузера? Поддержку pdf в браузерах реализуют исключительно для удобства серфинга, чтобы документ не надо было скачивать на диск и открывать в сторонней программе. Вы же на презентацию приходите с файлом на флэшке, не так ли? Или скачиваете каждый раз по ссылке?
При всем уважении, к большой проделанной работе, мне не нравится такой подход. JavaScirpt — неспешный скриптовый язык для простых задач. Рендеринг PDF надо делать библиотеками типа muPDF на Си. Да, на Си сложнее и дороже, но результат гораздо лучше. И сравнение с Хромом выглядит смешно. Никогда этот их PDF парсер не догонит сишный аналог.
И да, читать входной поток яваскриптом по байтику (!!!) — это ужасно. Правда, в JS из-за «нативной поддержки юникода», которую все грозятся добавить и в PHP, нельзя парсить PDF регулярками (или я ошибаюсь), но вот в том же PHP разбор регулярками выйдет в разы быстрее этого чтения по байтику и машины состояний. Так как разбор машиной состояний — это самый медленный способ парсинга файла, из всех, которые только есть в природе.
И да, читать входной поток яваскриптом по байтику (!!!) — это ужасно. Правда, в JS из-за «нативной поддержки юникода», которую все грозятся добавить и в PHP, нельзя парсить PDF регулярками (или я ошибаюсь), но вот в том же PHP разбор регулярками выйдет в разы быстрее этого чтения по байтику и машины состояний. Так как разбор машиной состояний — это самый медленный способ парсинга файла, из всех, которые только есть в природе.
> Так как разбор машиной состояний — это самый медленный способ парсинга файла, из всех, которые только есть в природе.
Вообще то любая регулярка в конечном итоге сводится к конечному автомату, кроме того, она точно также прочитает весь документ по байтику, а если учесть стандартные ограничение регулярных выражений, то становится понятно, что никто в здравом уме не станет реализовывать на них ни один серьезный парсер. Поэтому «разбор машиной состояний» только в вашем представлении является «самым медленным способом парсинга».
Думаю, просить вас привести список существующих в природе способов парсинга файлов бесполезно?
Вообще то любая регулярка в конечном итоге сводится к конечному автомату, кроме того, она точно также прочитает весь документ по байтику, а если учесть стандартные ограничение регулярных выражений, то становится понятно, что никто в здравом уме не станет реализовывать на них ни один серьезный парсер. Поэтому «разбор машиной состояний» только в вашем представлении является «самым медленным способом парсинга».
Думаю, просить вас привести список существующих в природе способов парсинга файлов бесполезно?
Думаю, он имел в виду, что конечный автомат самый медленный способ парсинга из всех, которые можно реализовать на яваскрипте. А регулярки в JS реализованы на более низкоуровневом языке, а значит работать будут быстрее.
Во-первых, даже побайтное чтение файла в JS скрипте вовсе не означает что он действительно читается по одному байту. Во-вторых, добавим сюда JIT компиляцию JS, которая есть уже практически везде. И в-третьих, конечный автомат это единственный способ разбора документов со сложной структурой, который, кроме всего прочего, еще и автоматически обеспечивает проверку этой структуры, регекспы об этой структуре ничего не знают и знать не могут, уже одно только это делает их непригодными для разбора, добавим сюда необходимость загрузки в память всего фрагмента анализируемого текста и т.д.
Вы все еще уверены что разработчики были не правы?
Вы все еще уверены что разработчики были не правы?
> Во-первых, даже побайтное чтение файла в JS скрипте вовсе не означает что он действительно читается по одному байту.
Он не читается, а разбирается по 1 байту. Файл c PDF засовывается в int8array и разбирается на яваскрипте побайтно. Я же смотрел код, прежде чем писать комментарий. Расскажите, как можно читать еще медленнее? По одному биту? Потому я и говорю, что это самый медленный способ.
> добавим сюда необходимость загрузки в память всего фрагмента анализируемого текста и т.д.
Весь PDF файл и так загружается в память.
> Во-вторых, добавим сюда JIT компиляцию JS, которая есть уже практически везде.
Ну JIT, если он там есть, и если он нормально работает, точно так же ускорит и код на регулярках. Но, учитывая динамическую природу JS, я сомневаюсь, что даже с джитом производительность можно сравнивать с кодом на Си. Я не видел примеров работы этого JIT'а и машинного кода. который он генерирует, но очевидно, что даже обращение к массиву в Си и Javascript будет реализовано по-разному.
> И в-третьих, конечный автомат это единственный способ разбора документов со сложной структурой
Да, но, возможно структура PDF вполне позволяет его разрывать на куски регулярками, например, разбирая большие бинарные блоки от картинок разом, а не побайтно. PDF вроде текстовый формат (с бинарным вставками для картинок).
Регулярки, это конечно, неуклюже, но движок регулярок написан на Си, и он может раздирать PDF-файл на куски, возвращая в яваскрипт не отдельные байты, а отдельные блоки. Я уверен, что это быстрее. Тот же конечный автомат, но на Си.
Да и вообще, мне не нравятся сравнения FF и Хрома. FF был хорошим браузером, он дал много новых идей другим разработчикам, но его время ушло. Вы не можете соревноваться с гуглом. У Гугл большая профессиональная команда, которая пишет гораздо больше кода — и лучшего качества. В то время как фаерфоксовцы исхитряются и упрощают себе жизнь (ценой снижения производительности браузера) — то они UI делают на XML и яваскрипт вместо Си, то Pdf просмотрщик на яваскрипте.
Хотя опять же, не понимаю, почему не интегрировать тот же muPDF в фаерфокс — это (относительно) маленькая, быстрая и открытая библиотека.
Он не читается, а разбирается по 1 байту. Файл c PDF засовывается в int8array и разбирается на яваскрипте побайтно. Я же смотрел код, прежде чем писать комментарий. Расскажите, как можно читать еще медленнее? По одному биту? Потому я и говорю, что это самый медленный способ.
> добавим сюда необходимость загрузки в память всего фрагмента анализируемого текста и т.д.
Весь PDF файл и так загружается в память.
> Во-вторых, добавим сюда JIT компиляцию JS, которая есть уже практически везде.
Ну JIT, если он там есть, и если он нормально работает, точно так же ускорит и код на регулярках. Но, учитывая динамическую природу JS, я сомневаюсь, что даже с джитом производительность можно сравнивать с кодом на Си. Я не видел примеров работы этого JIT'а и машинного кода. который он генерирует, но очевидно, что даже обращение к массиву в Си и Javascript будет реализовано по-разному.
> И в-третьих, конечный автомат это единственный способ разбора документов со сложной структурой
Да, но, возможно структура PDF вполне позволяет его разрывать на куски регулярками, например, разбирая большие бинарные блоки от картинок разом, а не побайтно. PDF вроде текстовый формат (с бинарным вставками для картинок).
Регулярки, это конечно, неуклюже, но движок регулярок написан на Си, и он может раздирать PDF-файл на куски, возвращая в яваскрипт не отдельные байты, а отдельные блоки. Я уверен, что это быстрее. Тот же конечный автомат, но на Си.
Да и вообще, мне не нравятся сравнения FF и Хрома. FF был хорошим браузером, он дал много новых идей другим разработчикам, но его время ушло. Вы не можете соревноваться с гуглом. У Гугл большая профессиональная команда, которая пишет гораздо больше кода — и лучшего качества. В то время как фаерфоксовцы исхитряются и упрощают себе жизнь (ценой снижения производительности браузера) — то они UI делают на XML и яваскрипт вместо Си, то Pdf просмотрщик на яваскрипте.
Хотя опять же, не понимаю, почему не интегрировать тот же muPDF в фаерфокс — это (относительно) маленькая, быстрая и открытая библиотека.
> Расскажите, как можно читать еще медленнее?
Вам в любом случае потребуется один раз прочитать все символы, вот только сейчас это гарантированно происходит один раз, а в случае регекспов большинство конструкций потребуют многократного прохода. Поэтому сказать что регекспы будут быстрее нельзя. Хотя, было интересно посмотреть на регекспы реализующие спецификацию «на 1310 страницах».
> FF был хорошим браузером, он дал много новых идей другим разработчикам, но его время ушло.
Почему был? Он и сейчас, ИМХО, хорош. Настолько хорош, что не пытается установить в хром неудаляемый плагин для собственного обновления ;)
> UI делают на XML
Чем вас XML не устраивает?
> то Pdf просмотрщик на яваскрипте.
Разве не здорово, что то, что раньше могло быть реализовано на C/C++, сейчас можно реализовать на js?
Вам в любом случае потребуется один раз прочитать все символы, вот только сейчас это гарантированно происходит один раз, а в случае регекспов большинство конструкций потребуют многократного прохода. Поэтому сказать что регекспы будут быстрее нельзя. Хотя, было интересно посмотреть на регекспы реализующие спецификацию «на 1310 страницах».
> FF был хорошим браузером, он дал много новых идей другим разработчикам, но его время ушло.
Почему был? Он и сейчас, ИМХО, хорош. Настолько хорош, что не пытается установить в хром неудаляемый плагин для собственного обновления ;)
> UI делают на XML
Чем вас XML не устраивает?
> то Pdf просмотрщик на яваскрипте.
Разве не здорово, что то, что раньше могло быть реализовано на C/C++, сейчас можно реализовать на js?
В чем проблема использования XML для декларирования UI? Если учесть, что он разбирается и используется только во время старта огнелиса/активации плагина.
Как показывает практика выбор одного лишь языка никак не способствует удовлетворительной скорости реализации, и можно на любом интерпретируемом языке написать программу, которая отработает быстрее, чем написанная менее опытным программистом на Си.
Далее, да простят меня фанаты, производительность хрома — миф. Уже не единожды замечал и слышал от других людей — хром банально ест больше памяти. Так же как он позволяет себе тормозить/подвисать при одновременно открытых 5-6 вкладок с флеш проигрывателем, даже если играет только один из них (там, где этой же машине огнелис даже не задумывается, к слову) :)
Что касается регулярок, то парсить ими — большая глупость. Там невозможно оценить асимптотику алгоритма и его конечную сложность, из-за этого невозможно выявить «узкие» места, остается только уповать на то, что «кто-то там явно умнее и сделал все правильно». Думаю стоит еще раз напомнить, что игру делает не выбираемый язык, а собственно сам алгоритм разбора.
Как показывает практика выбор одного лишь языка никак не способствует удовлетворительной скорости реализации, и можно на любом интерпретируемом языке написать программу, которая отработает быстрее, чем написанная менее опытным программистом на Си.
Далее, да простят меня фанаты, производительность хрома — миф. Уже не единожды замечал и слышал от других людей — хром банально ест больше памяти. Так же как он позволяет себе тормозить/подвисать при одновременно открытых 5-6 вкладок с флеш проигрывателем, даже если играет только один из них (там, где этой же машине огнелис даже не задумывается, к слову) :)
Что касается регулярок, то парсить ими — большая глупость. Там невозможно оценить асимптотику алгоритма и его конечную сложность, из-за этого невозможно выявить «узкие» места, остается только уповать на то, что «кто-то там явно умнее и сделал все правильно». Думаю стоит еще раз напомнить, что игру делает не выбираемый язык, а собственно сам алгоритм разбора.
FF был хорошим браузером, он дал много новых идей другим разработчикам, но его время ушло. Вы не можете соревноваться с гуглом. У Гугл большая профессиональная команда
Так ведь одним из основных спонсоров разработки FF (до появления Хрома) был как раз Гугл :) Так что может потому время FF и ушло, что ушел Гугл с частью разработчиков (и денег)?
А чем плохи сторонние решения? Меня, например, полностью устраивает плагин от Foxit Reader, тормозов не наблюдал.
Для любителей чего попроще есть аддон Google Docs Viewer, позволяющий открывать ссылки на документы (далеко не только pdf) в Google Docs.
Для любителей чего попроще есть аддон Google Docs Viewer, позволяющий открывать ссылки на документы (далеко не только pdf) в Google Docs.
Имхо, шустрее foxit'а.
Sign up to leave a comment.
Плагин для рендеринга PDF в браузере