Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
IT Technology

30 Years of Change, 30 Years of PDF (pdfa.org) 53

PDF Association, in a blog post: We live in a world where the only constant is accelerating change. The twists and turns in the technology landscape over the last 30 years have drained some of the hype from the early days of the consumer digital era. Today we are confronted with all-new, even more disruptive, possibilities. Along with the drama of the internet, the web, broadband, smart-phones, mobile broadband, social media, and AI, the last thirty years have revealed some persistent truths about how people use and think about information and communication. From the vantage-point of 2023 we are positioned to recognize 1993 as a year of two key developments; the first specification of HTML, the language of the web, and the first specification of PDF, the language of documents. Today, both technologies predominate in their respective use cases. They coexist because they meet deeply-related but distinct needs.
This discussion has been archived. No new comments can be posted.

30 Years of Change, 30 Years of PDF

Comments Filter:
  • ...and the first specification of PDF, the language of documents. Today, both technologies predominate in their respective use cases.

    I have always wondered why Microsoft's XPS format for documents never got its Internet Explorer moment - a moment where it became the "default" for lack of a better word, even for a few years!

    • by dmay34 ( 6770232 )

      XPS came a bit late for MS. Their monopoly ruling really slammed them pretty hard and limited what they were allowed to build into windows. People forget how important that ruling was to the creation of the modern world we live in now. If it had gone the other way, then firefox would never have existed, Flash Video would never have existed, iTunes for Windows would never have existed, Google, if it existed at all, have be come an MSN extention, the entire internet as we know it would just be a secondary ex

      • by DarkOx ( 621550 )

        Firefox should never had existed. It was nothing more than a removal of perfectly useful features from Seamonkey because a mail reader and irc client were 'bloat' that with in a handful of releases grew to have a larger runtime footprint than Seamonkey ever had.

        Firefox is a great example of something that was all hype of absent any real value. Which is not say the the Mozilla technology under both browsers was of no value, but FF should not have been code fork, it should have been a re-brand and refocus.

        • There are a couple of things wrong with that.
          The Mozilla suite was derived from the Netscape Suite level 4.x, there were then two developments:
          - Firefox was split off - as you say - as a lightweight browser-only component.
          - The Mozilla Suite was renamed Seamonkey, it consisted of Browser, Mail/News, Web Editor and Calender (later dropped). At that point it was still possible to install Seamonkey without the Mail/News component. At some point Seamonkey was been reduced to importing Firefox changes to fix s

    • Comment removed based on user account deletion
  • PDF's proliferate largely because HTML/DOM cannot control text positioning and size accurately. It's unrealistic that every content producer be an expert on "responsive layout" so that the same content auto-flows to fit watches and wide-screen desktops at the same time. Even developers struggle with that goal*. Thus, they use PDF's.

    Further, if HTML/DOM at least had the option of precise positioning, then it would be much easier to make and have interactive diagrams, such as click-able flowcharts, class diagrams, ERD's etc. Auto-flow works poorly on charts; they really need direct positioning to do right. (SVG and Canvas lack most the interactive and form input features needed for such.)

    It's time for a new web standard to supplement HTML/DOM: a state-ful GUI markup language that does CRUD & GUI well, and has precise text positioning, at least as an option. It could directly support the missing-or-defective GUI elements of HTML/DOM [reddit.com] so that we don't have to keep reinventing GUI engines using the ill-suited JS+DOM. (JS is a glue language, not an infrastructure-building language.)

    * I'm more a full-stack-developer, so don't have time to micromanage the full screwiness of CSS and DOM's auto-flow UI nightmare. An org generally has to hire a UI specialist to do such well, but that's both expensive and creates a dependency on a UI specialist. DOM is inherently too flawed to do GUI's correctly without tons of testing, trial-and-error, or a giant learning curve. Common internal CRUD should NOT require rocket science. Most internal biz apps are not even used on phones nearly often enough to pay the big auto-shrink-tax over. YAGNI & KISS still matter. Stacks that handle too many what-if's become WTF's: Swiss Army Spaghetti. There are ways to get a degree of auto-stretch and WYSIWYG at the same time, but first we need a more controllable UI standard.

    • > PDF's proliferate largely because HTML/DOM cannot control text positioning and size accurately.

      So true and very frustrating. Same problem making SVGs.

    • I thought the idea of HTML was to tag the content and let the browser flow the text and stuff?
        How does the content creator know what the browser is set up to display or upon what it is displayed/printed/spoken?

      • by Tablizer ( 95088 )

        Sometimes you don't want to let the browser auto-compute the layout because:

        1. It isn't smart enough to do what you want, and/or
        2. Inconsistent across browser brands/versions, and/or
        3. You want to control placement yourself for various reasons (or via a server-side layout engine).

        Auto-flow has its use cases, but it shouldn't be the ONLY option.

    • Comment removed based on user account deletion
      • by Tablizer ( 95088 )

        > That complaint really disappeared 10-20 years ago. You can be extremely specific with fonts, font sizes, text positioning, etc. It's trivially easy to convert a PDF to standardized HTML, just stick every text object in its own element, and place the element using absolute coordinates, display block, every aspect of the font, etc.

        Those who tried that say it doesn't work; they end up having to draw text bit by bit in emulators (or at least vector by vector). OS DPI settings, zoom levels, and other factor

  • Acrobat Reader was originally priced at $50 per user till the IRS purchased a right to distribute Reader 1.0.
    after that then it be came the way to read PDF files.

    • When it first came out it was positioned as a way for desktop publishers to send everything to a printer independent of the desktop publishing application. You used to send whatever version of quark express and fonts etc. to the printer with you docs so the printer could print it out. It was a real pain in the ass. I don't think anyone at the time thought PDF would become a web standard.
  • PDF stands for Proprietart Document Format. Very shortly after it because a document format, it became a very specialized tool for the distrubution of malware. It is not a "Document" format, it is a Malware Distribution Format.

    One may take action to turn off the Malware Distribution Features and return it to a Document format. but almost noboty can be bothered to do that -- hence PDF is one of the most dangerous file formats in existance, save that Flash crap.

  • Many websites are - let’s face it - mostly navigation to help visitors find a specific PDF.

    I'll grant that PDF documents are, for better or worse, important, that statement simply doesn't stand up to investigation.

    I don't know what percentage of websites are "mostly navigation to help visitors find a specific PDF", but I'll wager a bet it's low.

    PDF has a torrid history of being closed source - it was a proprietary format right up to 2008. Sure, that's pretty much half it's current lifespan, but the pa

The unfacts, did we have them, are too imprecisely few to warrant our certitude.

Working...