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

At Crocodoc we tested out a similar approach using the Canvas element to render pages, but ultimately opted to go the @font-face route for a number of reasons, including:

- Near-instant client-side rendering (albeit a one-time ~5 second wait during server-side processing)

- Native font rendering (Canvas rasterizes all text and doesn't benefit from technologies like ClearType)

- Native text selection (which is important for overall UX and our annotation tools such as highlighting)

- Better performance on mobile devices (this is an ongoing project)

Here's a comparison of the test file micheljansen links to (thanks!) compared with the same PDF in Crocodoc:

- Canvas rendering: http://bit.ly/kU0mlW

- Crocodoc rendering: http://bit.ly/je2wcv

Edit: By the way, we're really impressed by this canvas implementation :-)




I had never heard of crocodoc and was very impressed with this rendering. What browsers do you guys support?


IE7 - IE9, Firefox, Chrome, and Safari


So why hasn't Google bought them?


Wow, I'm impressed at how well it renders math. Great job guys!

http://crocodoc.com/EfqW081


The only reason this project is interesting is because it does not use any server side processing (beyond serving).


I expect PDFs could be rendered client-side with @font-face by using data URIs.


Crocodoc looks great! Just out of curiosity: do you have a set of fonts ready to deliver to the client in order to make the font-face approach work? What do you do if the PDF if using some obscure font type? Are you using Poppler for server side processing?


Do you guys also (plan to) build directly from LaTex?


Any plans on supporting Opera? The rendering on 11.11 is a little off, and canvas rendering does not work.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: