41–50 of 146 posts
This is an amazing piece of work. Thanks for making this open-source. The default way of generating beautiful PDFs in the backend these days is, running a headless browser and using browser APIs to turn HTML/CSS into PDFs. And apparently, it's a bit costly running instances of browser in the server and scale it properly for huge workloads. This is literally a game changer. Now it's possible to design PDFs using HTML/…
This is an amazing piece of work. Thanks for making this open-source. The default way of generating beautiful PDFs in the backend these days is, running a headless browser and using browser APIs to turn HTML/CSS into PDFs. And apparently, it's a bit costly running instances of browser in the server and scale it properly for huge workloads. This is literally a game changer. Now it's possible to design PDFs using HTML/…
As an aside its amazing how far the web has come, where the best way to make pretty pdf documents is to literally run a web browser on the server. This would have been so unthinkable back in the 90s & 2000s
For anyone struggling with flexbox, you can use this tool to streamline the process of creating responsive layouts, removing the need to focus on multiple properties: https://flexboxcss.com
I was looking at Glide Grid the other day, and it renders so fast, even with 1 million rows; it's somehow responsive. There should be an easier way to render HTML to canvas without resorting to low-level primitives. Why is canvas faster than the "regular" DOM renderer?
Earlier quoted context omitted.
I’m curious if you’ve implemented a rich text editor with this. I think Google Docs uses canvas. I hate the browser APIs for rich text and wonder if this could be more a viable candidate than using contenteditable for future projects
Google Docs uses canvas, yeah, and last I looked it used an empty contentEditable just to receive [rich text] input. I do think you could use this to write a document editor like Docs and side-step many of the problems with contentEditable, but I haven't tried to. Every time someone releases a new rich text editor I'm disappointed to find that it uses contentEdtiable. Would be very interesting!
Sciter is using its own implementation (obviously).
contentEdtiable thing is indeed quite limited for general purpose WYSIWYG editor.
For example Web platform is missing transactional update [1] mechanism that allows to put custom DOM mutation groups into unified undo/redo stack.
Sciter's element ( implement behavior:richtext - WYSIWYG ) allows to build specialized editors. For example it is used in Sciter.Notes [2].
[1] https://docs.sciter.com/docs/behaviors/behavior-richtext#ric... [2] https://notes.sciter.com/
Earlier quoted context omitted.
As an aside its amazing how far the web has come, where the best way to make pretty pdf documents is to literally run a web browser on the server. This would have been so unthinkable back in the 90s & 2000s
I'm fairly certain that using a headless browser on the server is mainly about sandboxing all the security concerns that PDFs have, not aesthetics, but yes.