Hacker News Reader

Comment by mk_stjames | Hacker News Reader

I've done this for a project long ago, incredibly lazily, by using chrome/chromium to PDF and piping to a PDF to SVG tool. There are a few PDF to SVG pathways, I remember it using Cairo and the whole thing was quick and consistent.

View on HN

That was my first thought as well.

I'm genuinely curious if there are any advantages in Chrome->SVG as opposed to Chrome->PDF->SVG.

Are there any graphical effects (e.g. produced by CSS, like blurry text shadows or something) that PDF can't render without falling back to bitmap but SVG can?

Or is there other data that SVG usefully preserves that PDF discards, such as actual source text strings used for text? (As opposed to PDF where getting text out, e.g. when copying to clipboard, usually involves a lot of ugly "reverse engineering".)

Neither pdf or svg do text layout. They’re both pretty similar really, though the pdf spec is really deep and broad to cater for a million things.

My advice to everyone re pdfs is to crack them open by running `mutool clean -d file.pdf` And opening in a text editor. They’re just a tree (well, graph, I guess) of obvious objects.

Ps: mutool convert does a good job of converting from pdf to svg in a fairly faithful way.

Do you mean there's no dynamic text layout? Svg and pdf have perfect text placement capability, but I've never even looked to see if it supports defining broadly applicable rules for text presentation.

I mean there’s no layout engine to do things like wrapping and line height etc. Everything is explicitly positioned.

PDF seems a bit more bonkers because you render text as strings of glyphs and the conversion back to text is an afterthought. There’s a ToUnicode map that says “glyph 8 in the embedded font is an ‘X’” but that’s there for copy pasting / searching - not for rendering. PDFs are built to render glyphs at positions.

Edit: to go full meta, there are Type3 fonts where each glyph itself is defined as a PDF graphics stream. Which actually leads you in to what’s inside a font. Guess what? lots of them look just like PDFs inside, because the glyphs are defined in postscript. Fonts are PDFs kinda grew up together, and once you start digging into them the similarities are striking.

Yeah it's definitely a presentation format, but probably the most useful one there is for many. As someone who does print design, screen design, and development work, I'm glad PDF is what it is. Absolute subpixel-level perfection, support for raster and vector visuals, embedded fonts, multiple industrial color encoding formats, and other professional design features are essential for designers. Adding generalized formatting rules for dynamic layouts and content would needlessly complicate an already useful tool to adress use cases satisfied in other formats. That people, Adobe included, use it as a general document format is a problem with usage and product management, not the format. It pisses me off when it's used as the default export format unless it's sole purpose is for printing. I've had to write web apps that dynamically generated pdfs: it was a pretty miserable pierces that yielded mostly lackluster results. Glad to see Adobe has moved away from their cockamamie pdf interactive features that contributed little more to users than anxiety about security holes.

Epub should be the defacto standard when the included data remains important.

If you print to PDF, you'll have the page's print css applied. And it is probably paginated.

If you go direct to SVG the capture will use the screen css and not be paginated.

Yes, this. In the project I was doing, using chromium as a command-line interface I remember having options to do the pagination to a custom resolution, which I used to define a render 'window' as if the browser screen was on something like a 1600x18000 monitor. so I had the entire webpage displayed like a full scroll without page breaking like it would have if you just printed a PDF from Chrome. And this allowed me to then extract this giant full length vector graphics result of diagrams and text into a single SVG that was perfectly spaced and rendered in the aspect ratio I wanted.

It's also possible to emulate screen media queries[0] so that the pdf output uses the regular screen css.

[0] https://chromedevtools.github.io/devtools-protocol/tot/Emula...

I think the path is more clearly thought of as HTML+CSS -> display list -> *. The display list is some abstract definition of what needs to be drawn by a renderer. In theory anything that fully describes all possible operations works, including bespoke things like SkPicture or general purpose graphical languages like SVG or PostScript. In practice there's never a single language that can describe everything, because display capabilities evolve and new operations are added all the time (e.g. advanced typography features for fonts). PDF can cover a really broad set of use cases, but it also wasn't designed as an intermediate format (it was closely tied to the PDF reader) so it's easier to get into than out of. SVG is possibly a better candidate, as it is already used effectively as an intermediate representation (e.g. D3.js "renders" to SVG).

Reply on news.ycombinator.com