Плагин для рендеринга PDF в браузере

    Кажется, только недавно ребята из Mozilla начали разработку PDF.js — движка для рендеринга PDF-документов средствами HTML5 и JavaScript, и вот они уже вышли на финишную прямую. Качество рендеринга достигло такого уровня, что разработчики решили выпустить экспериментальную версию расширения для Firefox (файл XPI).



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

    Отметим, что PDF.js работает и выглядит ничуть не хуже, чем рендеринг PDF в браузере Chrome. Документы загружаются быстро, шрифты отображаются идентично оригинальным. При этом весь код PDF.js полностью открыт, в то время как модуль для PDF от Google не является частью открытого проекта Chromium.

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

    Хотя сейчас PDF.js поддерживает далеко не все экзотические функции PDF (см. спецификации PDF 1.7 на 1310 страницах), но абсолютное большинство всех существующих в Сети документов PDF вы уже сейчас можете открыть и в браузере с помощью абсолютно свободного кода.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 28

      +1
      Ждем файловый менеджер для ff как следующую ступень приближения к Kparts.
        +8
        Ищу flash.js
          +4
            0
            Ну так это же недорожденный зародыш (: версии 1 и 2 — ниапчом. PDF они поддерживают в гораздо более полном и полезном виде.
          0
          У меня ни один pdf так и не открылся.

          FF 7.0.1 Ubuntu
            +1
            Грузится гораздо быстрее плагина от Adobe. Замечательно, всю жизнь считал что такие плагины зло, но сейчас изменил свое мнение.
              +3
              А кошечку на фотки что ли замочили?
                0
                Еще бы нормальное расширение по работе с MHT… Эх.
                  +1
                  Мда.

                  Думаю, дело в minimum font size. Куда багрепорт писать?
                  0
                  А выделения текста как не было, так всё ещё и нет. Ну и кому нужен такой рендеринг?
                    0
                    Прошу прощения за вопрос, а в других браузерах тоже ведь должно работать?
                      0
                      С формулами полный швах

                      i.imgur.com/3fmUK.png
                        +2
                        Зато как красиво! :)
                        0
                        Увы, очередная зва-читалка не будет поддерживать автоматическую смену страниц, что критично для анимаций в презентациях.
                          0
                          *pdf
                            0
                            1. Насколько я знаю, анимацию последовательной сменой кадров поддерживает только Adobe Reader, а им пользуются не все. Поэтому, если хотите универсальное решение, вставляйте видео. Главное, чтобы кодек поддерживался.

                            2. Зачем запускать презентацию из браузера? Поддержку pdf в браузерах реализуют исключительно для удобства серфинга, чтобы документ не надо было скачивать на диск и открывать в сторонней программе. Вы же на презентацию приходите с файлом на флэшке, не так ли? Или скачиваете каждый раз по ссылке?
                              0
                              Презентацию из браузера запускать придётся потому, что люди подуамют «А зачем мне зва-читалка, у меня же Firefox pdf отображает» и (почти) все будут довольны.
                            0
                            При всем уважении, к большой проделанной работе, мне не нравится такой подход. JavaScirpt — неспешный скриптовый язык для простых задач. Рендеринг PDF надо делать библиотеками типа muPDF на Си. Да, на Си сложнее и дороже, но результат гораздо лучше. И сравнение с Хромом выглядит смешно. Никогда этот их PDF парсер не догонит сишный аналог.

                            И да, читать входной поток яваскриптом по байтику (!!!) — это ужасно. Правда, в JS из-за «нативной поддержки юникода», которую все грозятся добавить и в PHP, нельзя парсить PDF регулярками (или я ошибаюсь), но вот в том же PHP разбор регулярками выйдет в разы быстрее этого чтения по байтику и машины состояний. Так как разбор машиной состояний — это самый медленный способ парсинга файла, из всех, которые только есть в природе.
                              +4
                              > Так как разбор машиной состояний — это самый медленный способ парсинга файла, из всех, которые только есть в природе.

                              Вообще то любая регулярка в конечном итоге сводится к конечному автомату, кроме того, она точно также прочитает весь документ по байтику, а если учесть стандартные ограничение регулярных выражений, то становится понятно, что никто в здравом уме не станет реализовывать на них ни один серьезный парсер. Поэтому «разбор машиной состояний» только в вашем представлении является «самым медленным способом парсинга».

                              Думаю, просить вас привести список существующих в природе способов парсинга файлов бесполезно?
                                0
                                Думаю, он имел в виду, что конечный автомат самый медленный способ парсинга из всех, которые можно реализовать на яваскрипте. А регулярки в JS реализованы на более низкоуровневом языке, а значит работать будут быстрее.
                                  +1
                                  Во-первых, даже побайтное чтение файла в JS скрипте вовсе не означает что он действительно читается по одному байту. Во-вторых, добавим сюда JIT компиляцию JS, которая есть уже практически везде. И в-третьих, конечный автомат это единственный способ разбора документов со сложной структурой, который, кроме всего прочего, еще и автоматически обеспечивает проверку этой структуры, регекспы об этой структуре ничего не знают и знать не могут, уже одно только это делает их непригодными для разбора, добавим сюда необходимость загрузки в память всего фрагмента анализируемого текста и т.д.

                                  Вы все еще уверены что разработчики были не правы?
                                    –1
                                    > Во-первых, даже побайтное чтение файла в JS скрипте вовсе не означает что он действительно читается по одному байту.

                                    Он не читается, а разбирается по 1 байту. Файл c PDF засовывается в int8array и разбирается на яваскрипте побайтно. Я же смотрел код, прежде чем писать комментарий. Расскажите, как можно читать еще медленнее? По одному биту? Потому я и говорю, что это самый медленный способ.

                                    > добавим сюда необходимость загрузки в память всего фрагмента анализируемого текста и т.д.

                                    Весь PDF файл и так загружается в память.

                                    > Во-вторых, добавим сюда JIT компиляцию JS, которая есть уже практически везде.

                                    Ну JIT, если он там есть, и если он нормально работает, точно так же ускорит и код на регулярках. Но, учитывая динамическую природу JS, я сомневаюсь, что даже с джитом производительность можно сравнивать с кодом на Си. Я не видел примеров работы этого JIT'а и машинного кода. который он генерирует, но очевидно, что даже обращение к массиву в Си и Javascript будет реализовано по-разному.

                                    > И в-третьих, конечный автомат это единственный способ разбора документов со сложной структурой

                                    Да, но, возможно структура PDF вполне позволяет его разрывать на куски регулярками, например, разбирая большие бинарные блоки от картинок разом, а не побайтно. PDF вроде текстовый формат (с бинарным вставками для картинок).

                                    Регулярки, это конечно, неуклюже, но движок регулярок написан на Си, и он может раздирать PDF-файл на куски, возвращая в яваскрипт не отдельные байты, а отдельные блоки. Я уверен, что это быстрее. Тот же конечный автомат, но на Си.

                                    Да и вообще, мне не нравятся сравнения FF и Хрома. FF был хорошим браузером, он дал много новых идей другим разработчикам, но его время ушло. Вы не можете соревноваться с гуглом. У Гугл большая профессиональная команда, которая пишет гораздо больше кода — и лучшего качества. В то время как фаерфоксовцы исхитряются и упрощают себе жизнь (ценой снижения производительности браузера) — то они UI делают на XML и яваскрипт вместо Си, то Pdf просмотрщик на яваскрипте.

                                    Хотя опять же, не понимаю, почему не интегрировать тот же muPDF в фаерфокс — это (относительно) маленькая, быстрая и открытая библиотека.
                                      +1
                                      > Расскажите, как можно читать еще медленнее?

                                      Вам в любом случае потребуется один раз прочитать все символы, вот только сейчас это гарантированно происходит один раз, а в случае регекспов большинство конструкций потребуют многократного прохода. Поэтому сказать что регекспы будут быстрее нельзя. Хотя, было интересно посмотреть на регекспы реализующие спецификацию «на 1310 страницах».

                                      > FF был хорошим браузером, он дал много новых идей другим разработчикам, но его время ушло.

                                      Почему был? Он и сейчас, ИМХО, хорош. Настолько хорош, что не пытается установить в хром неудаляемый плагин для собственного обновления ;)

                                      > UI делают на XML

                                      Чем вас XML не устраивает?

                                      > то Pdf просмотрщик на яваскрипте.

                                      Разве не здорово, что то, что раньше могло быть реализовано на C/C++, сейчас можно реализовать на js?
                                        0
                                        В чем проблема использования XML для декларирования UI? Если учесть, что он разбирается и используется только во время старта огнелиса/активации плагина.

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

                                        Далее, да простят меня фанаты, производительность хрома — миф. Уже не единожды замечал и слышал от других людей — хром банально ест больше памяти. Так же как он позволяет себе тормозить/подвисать при одновременно открытых 5-6 вкладок с флеш проигрывателем, даже если играет только один из них (там, где этой же машине огнелис даже не задумывается, к слову) :)

                                        Что касается регулярок, то парсить ими — большая глупость. Там невозможно оценить асимптотику алгоритма и его конечную сложность, из-за этого невозможно выявить «узкие» места, остается только уповать на то, что «кто-то там явно умнее и сделал все правильно». Думаю стоит еще раз напомнить, что игру делает не выбираемый язык, а собственно сам алгоритм разбора.
                                          0
                                          FF был хорошим браузером, он дал много новых идей другим разработчикам, но его время ушло. Вы не можете соревноваться с гуглом. У Гугл большая профессиональная команда

                                          Так ведь одним из основных спонсоров разработки FF (до появления Хрома) был как раз Гугл :) Так что может потому время FF и ушло, что ушел Гугл с частью разработчиков (и денег)?
                                  0
                                  А чем плохи сторонние решения? Меня, например, полностью устраивает плагин от Foxit Reader, тормозов не наблюдал.
                                  Для любителей чего попроще есть аддон Google Docs Viewer, позволяющий открывать ссылки на документы (далеко не только pdf) в Google Docs.
                                    0
                                    Имхо, шустрее foxit'а.

                                    Only users with full accounts can post comments. Log in, please.