1. Forum
  2. Usenet
  3. COMP.TEXT.PDF

  • Why do some pdfs open quickly in-browser, but others don't?

    From luserdroog@21:1/5 to All on Tue Jun 21 22:02:03 2016
    What's the determining factor in the UI for pdfs on the web?
    OTOH it must be the server. For pdfs served up by an archive
    eg.

    http://web.archive.org/web/20160404161549/https://code.google.com/p/xpost/downloads/detail?name=spiral-fill.pdf&can=2&q=

    You have to just download it. But for other pdfs, served up
    as part of a "document-service" (for want of more informed
    terminology) can feed a bit of needed pre-parsed metadata
    that the browser plug-in can chug with. eg.

    http://arxiv.org/pdf/1605.06640v1.pdf

    And for a specially-powered few of these "document service"
    httpd extension suites, it can feed the xref tables first
    (which lie physically at the *end* of the pdf file) enabling
    the plugin to start displaying page 1 as soon as its elements
    are present. eg.

    http://algorithmicbotany.org/papers/abop/abop.lowquality.pdf

    And still-more-powerful systems like GitHub can even wrap
    their own html around it. eg.

    https://github.com/luser-dr00g/ibis.ps/blob/master/ibis.pdf

    Am I right? Apache packages?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anonymous@21:1/5 to All on Sat Jun 25 23:08:30 2016
    What's the determining factor in the UI for pdfs on the web?

    I don't think you're looking at the right components. But perhaps it
    would help you to know that the pages in a PDF can be reordered
    internally without changing the presentation order in a process called "linearizing". E.g. "qpdf --linearize <pdf file>" will ensure the
    first page loads immediately.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Beanfish@21:1/5 to luserdroog on Wed Jun 22 17:56:18 2016
    On Tue, 21 Jun 2016 22:02:03 -0700, luserdroog wrote:

    What's the determining factor in the UI for pdfs on the web?
    OTOH it must be the server. For pdfs served up by an archive eg.

    http://web.archive.org/web/20160404161549/https://code.google.com/p/
    xpost/downloads/detail?name=spiral-fill.pdf&can=2&q=

    You have to just download it. But for other pdfs, served up as part of a "document-service" (for want of more informed terminology) can feed a
    bit of needed pre-parsed metadata that the browser plug-in can chug
    with. eg.

    http://arxiv.org/pdf/1605.06640v1.pdf

    And for a specially-powered few of these "document service"
    httpd extension suites, it can feed the xref tables first (which lie physically at the *end* of the pdf file) enabling the plugin to start displaying page 1 as soon as its elements are present. eg.

    http://algorithmicbotany.org/papers/abop/abop.lowquality.pdf

    And still-more-powerful systems like GitHub can even wrap their own html around it. eg.

    https://github.com/luser-dr00g/ibis.ps/blob/master/ibis.pdf

    Am I right? Apache packages?

    PDF file has to be optimized for web delivery (can be done when creating
    or later by utilities.) And the web server has to support "ranges" aka
    byte serving.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)