41–49 of 49 posts
Cudos! PDF has a god-awful spec., with which I am intimate. I am impressed with what you have been able to do. I don't think most people realize that the spec. for PDF is over 1,000 pages is and was written by bipolar sadists.
Earlier quoted context omitted.
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/
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.
Earlier quoted context omitted.
> 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.
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...
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?
>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?
Earlier quoted context omitted.
Side note: Under the hood, PhantomJS uses wkhtmltopdf. You can probably save yourself some overhead using the wkhtmltopdf binary directly.
No I believe both use QTWebkit directly.
Does this support svg images (e.g. d3.js charts)?
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?
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