Hacker News new | comments | show | ask | jobs | submit login

Huh. So, if you can express your PNG / PDF rendering in terms of HTML, SVG, Canvas, and WebGL... How much easier, faster, more reliable would it be to use Headless Chrome and --screenshot, rather than other means?



HTML & CSS are not really suitable for "pixel perfect" text. Even text in SVG works just like text in an HTML document in the sense there is not a way to control precisely where text will wrap. You'd have to disable the browser's word wrapping & come up with your own logic for where to insert <br /> tags, even then you have issues like browsers ignoring CSS rules because of 3rd party browser extensions, missing fonts & such.

Look at this jQuery plugin for evidence - http://simplefocus.com/flowtype/

As you resize your browser, you see the browser re-layout the page & the text jumps around. The text wraps at different positions as you resize your browser around. You'd have to essentially render text to an image server-side, then scale the resulting image in the browser. And if you already have an image, there's no need for tools like wkhtmltoX or phantom for creating an image (you already have an image)... So headless browsers are not suitable for rasterizing documents that contain text [in my experience].

Converting HTML to PNG/PDF is like comparing apples & oranges. The conversion will be imperfect.


> HTML & CSS are not really suitable for "pixel perfect" text.

...and a lot of people don't care.

> You'd have to disable the browser's word wrapping & come up with your own logic for where to insert <br /> tags

...unless you don't care.

> even then you have issues like browsers

"BrowserS"? Plural? No. This is one implementation - headless Chrome. Which you could use to do your own rendering. There's no plural. You would use one browser to do your headless rendering.

> You'd have to essentially render text to an image server-side

That is. What this is.

> then scale the resulting image in the browser

What? It depends entirely on what your use case is. If you want to email a PDF, then you could use headless Chrome to turn HTML into a PDF, and then email it.

> So headless browsers are not suitable for rasterizing documents that contain text

I feel like you're off in this weird space, very different from what I've experienced. And I've experienced it again, and again, at different companies.

> Converting HTML to PNG/PDF is like comparing apples & oranges. The conversion will be imperfect.

...but potentially faster, lower effort, and "good enough" for many use cases.


That's a small trade-off I'm willing to take. It beats having to have a completely separate engine for the PDFs (compared to just using what you're already displaying on the web) and it's way more complete than using something like DOMPDF which doesn't even have support for some of the most basic CSS features.


Tell that to PrinceXML:

https://www.princexml.com/samples/

Print CSS is pretty complete if only the major browsers would support it.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: