> the better idea is to segment out what exactly you want to use it for and use a specific file format for it What I want is basically an entirely static (no j

> the better idea is to segment out what exactly you want to use it for and use a specific file format for it What I want is basically an entirely static (no javascript, forms, media elements, etc) copy of a web page, with a logical deterministic rendering, and a fixed page size (no reflowing). Basically, if you took a web page and printed in color on pieces of paper, the HTML + CSS that describes the stuff shown on the piece of paper is what I want a "portable document format" to be. (Along with a set of rules that specify exactly how that code should be rendered.) What I want in the spec is basically dictated by that: * vector graphics: yes, SVG is supported in all major browsers. https://developer.mozilla.org/en-US/docs/Web/SVG https://developer.mozilla.org/en-US/docs/Web/SVG * bitmap support: yes, let's start with PNG, JPEG, etc, and updates to the spec can introduce new formats * color management: yes, should be required by the spec * unicode: yes, we can probably be UTF-8 only at this point? * font rendering: deterministic; make it part of the spec. Fonts should be embeddable in the document. Ideally the font rendering for the end users should be as high quality as possible (this is quietly one of the things PDFs are already doing very well). * glyphs / ligatures: should look exactly as they are determined by the author of the document. The spec should allow for the full use of the capabilities of an OTF font. I think this probably covers the stuff 95% of people want from 95% of their PDFs, and it's vastly simpler than what's currently in the spec. Honestly, PDF/A comes pretty darn close to getting there. The most recent version allows embedding arbitrary files, however, and there's lots of annoying cruft from the PDF format. (Renderers have to support displaying embedded XML forms, for example.)