Hacker News Reader

Comment by adiM | Hacker News Reader

Just looked at the sample on the playground section of the website. No hyphenation, no ligatures, and overall the output looks ugly (compared to TeX). What is the advantage over simply creating an appropriate LaTeX/ConTeXt document in the background and serving that?

View on HN

For the same reason everything eventually gets rewritten in Javascript: sometimes you want to do it in a browser.

In my case, I have a Javascript app that stores critical information for offline use, and users want to be able to print that information nicely. So I generate PDFs in Javascript. This could make that much easier.

> For the same reason everything eventually gets rewritten in Javascript: sometimes you want to do it in a browser.

Indeed:

http://manuels.github.io/texlive.js/

Deprecating TeX is long overdue - for example creating non-book layouts (i.e. magazines) is a real pain.

So: A a TeX compiler that can be called from JS can only be an intermediate solution.

I think http://txtjs.com/ goes in the right direction.

Actually with css-hyphens[ch], I think html/css has finally taken a leap towards usable text -- something that has been sorely lacking (mostly due to a kind of regression across browsers, where everyone seem to have given up on making html work for text, without a ridiculous amount of css, and maybe even js/canvas/svg. This is related to the avoidance of user style-sheets, and the idea that a bare bones hypertext documents could actually be useful. There's not really anything preventing browsers from presenting an un-styled html-page like how A-list-apart styles their articles -- absent any css-reset/css-styles).

I don't really think calling TeX from js is a very good idea, nor do I really think canvas is a good idea either.

I do wish Adobe had gained more traction with css regions[cr] -- although I also understand some of the arguments against them[ch].

I still think the idea is good: css for style, semantic html for ... semantics -- and "layout html" for layout. I think pairing semantic markup with css columns is just a bad idea -- and it gives the kind of "half-power" that initially lead people to use tables for layout.

So Lie is right in that css regions aren't a great fit for html[ch] -- but I still think they're the best fit for html I've come across. I might be convinced that css regions are the kind of things that fit well with js/poly-fills[pf] -- although I'm sceptical. We know fonts are turing complete and have had security issues -- I don't see why we should need to implement core layout with js. At least I suppose "rogue" software vendors can choose to support css regions[cr] -- For eg an e-book reader based off of a subset of html+css, css regions might be a good fit, while avoiding the complexity of adding js support, and trying to make that secure (including proof against denial of service etc).

Thanks for the link to texjs, though -- I'll definitely have a closer look.

[ch] http://caniuse.com/css-hyphens

[ha] http://alistapart.com/blog/post/css-regions-considered-harmf...

[cr] http://caniuse.com/css-regions

[pf] http://webplatform.adobe.com/css-regions-polyfill/

Agreed on the LaTeX front. The best part is that it's native and cross-platform on the backend, but there also exist libraries to render client-side in JS, though I can't say I've used any of them.

>overall the output looks ugly (compared to TeX)

what doesn't!

>What is the advantage over simply creating an appropriate LaTeX/ConTeXt document in the background and serving that?

the obvious advantage is that you wouldn't have to learn LaTeX/ConTeXt, no?

Pdfmake could generate LaTeX, which can then be properly compiled to a pdf (potentially with texlive.js).

In Haskell this is possible with similar DSLs. Very useful to generate reports.

You do need to learn _a_ way to generate document. I don't see how the JS method is easier than, say, using a ConTeXt Lua Document (CLD). I'd really like to compare samples.

pdfmake was not meant to be a LaTeX replacement

If you want to print a book or a perfectly aligned article do it in LaTeX

If you have a web-application however and it prints invoices or other documents pdfmake can be a good choice and an efficient solution

People don't want to wait 2-3 seconds these days to get a simple document on their printer. With pdfmake lots of standard documents will print in less than 300 ms and... it scales - as you do everything on the client side you don't have to care about server overhead, no matter how many concurrent users you have

Reply on news.ycombinator.com