... I've decided to just migrate all this work for EPUB for various reasons but I'm also going to migrate to one continuous 'page' due to the CSS pagination issues I mentioned above.
Holy Moly, this Polar thing looks amazing! And it’s open source too!! I was definitely not expecting that when I followed the link nor when I started reading about it.
Document management, and saving web pages is a huge deal and something that I have been looking for a solution for but which until now I have not found anything that would quite fit, and most of the ones I have looked at and seriously considered would require too much integration work and customization to be usable. But Polar looks really really promising!
I have avoided Electron based software until now for the same reasons you often find people echoing in the HN comments section when the topic comes up, but for Polar I would make an exception because it looks to be perfect for me so I am willing to sacrifice some of my precious RAM for Polar and am willing to accept a certain degree of UI and performance problems that I associate with Electron based apps.
Since a web browser extension is in the works though, would you recommend that I wait until that is released or should I start using the Electron based app now and then migrate/switch?
> Holy Moly, this Polar thing looks amazing! And it’s open source too!! I was definitely not expecting that when I followed the link nor when I started reading about it.
Thanks... 2.0 should come out next week too so it's going to be interesting to see how the community responds.
The browser version is almost on par in terms of features with the desktop version. The main features that we're missing in the web version are offline support (which will be resolved soon), support for syncing with Anki, and web capture.
We're working on porting web capture to completely run within the web extension though. I think the web version should be completely on par with the desktop/web version in the next month or so.
Also, it's really not THAT much of a resource hit. On my machine it burns like 100MB or RAM and say 300MB of disk space.
I open this link. The fan of my T480 starts blowing audibly and is getting louder. I can feel a delay when marking some text. All it does is render some text. Thankfully, scrolling stays smooth. I close the page. My fan calms down.
We are still working on a site for this so sadly not much to point to yet, but might be worth checking out the sneak peaks post with a few codepens running paged.js at https://www.pagedmedia.org/pagedjs-sneak-peeks/
Same here. There is an /examples folder in the top repo from the linked gitlab instance, but it just contains a lot of inline js and I’m on mobile so can’t try to run it.
I think pagination works better in books because books are finished. Websites get updates all the time, so when you mentally organize an idea as being part of page 3, that might just lead to confusion next week.
The embedded links and ads everywhere we look just throw garbage all over the place too, or else published news articles might match pretty well
Thanks for your work. I've been re-reading Knuth's _The TeXbook_ as a reminder of fine points in typography. So much can be covered in just provisioning for floating blocks, top-floating blocks, widows and orphans, a few counters, some flexibilty in headers and footers, and such. It seems like you and/or CSS are hitting those high-points.
I hear you emphasizing this might just be for print, but something like a Kindle in-browser reader (hidden nav; spacebar or < or > to turn a page) can also provide a nice experience (different to scrolling) in reading longer works.
I searched through the site and still couldn't find a demo hosted anywhere. The idea of making paged media a more pleasant in-browser experience sounds neat, but the lack of examples is troubling.
Is it possible to use it to convert a web page to a paginated mode in the browser? Like the reader mode but put the content in pages instead of continuous mode.
This might be a hot take, but I think this is unnecessarily complicated and is a solution looking for a problem. My thoughts apply more broadly to the CSS Draft for pagination as well.
In general - why does the Web need this? This is a less-flexible CSS grid, with some auto-increment and @media(print) styles mixed in.
The use case for faithfully representing a textual work is not convincing - this can be done already, more accurately, and in a far less complicated manner by using images or PDF or any other format more suited than hypertext markup and CSS.
We already have pagination on the Web, it's called a webpage.
I think (hope?) it is for printing, and not for reading in the browser. The example has `@media print{..}`, so I assume that is what the intended end result is for this project.
It's definitely made to print books and pages from the web. You can preview in a browser, but that's not the goal. It's a polyfill for CSS properties made for print.
Although, you can't tell for sure what people want to do with tools and library right? :)
Eh, I'm not so sure. I spent more effort than I should have to find an example of this working and I'm not impressed [0]. Everything about it seems worse than browsers' reader mode for accessibility. It's also very slow, but I'll let that skate since it's probably just the polyfill[1].
I don't get the appeal. This isn't anything like a book, since I'm still scrolling, squinting, and reading words from a backlit screen instead of a physical page. Not to mention, using the browser's zoom functionality just straight up doesn't work (the pages and text stay the same size). So much for accessibility?
Printing books directly from the browser isn't a solved problem, so it seems like a good project, to me.
I don't see any evidence on their website this is intended for reading in the browser, and tons of clues that it's intended for printing books from the browser. I mean, there are tools for physical page sizes, blank pages, front/back matter, page counters, etc. Things that make zero sense in the browser and are necessary for a nice book printing.
So, what makes you think this is intended for reading in web browsers? As you note, it's horribly unpleasant in a browser...seems like they would have noticed that if they were testing in the browser, rather than using it to print books.
The example you showed is previewing in the browser. The intention is to use this with @media print and just to get nicely flowed, filled, and typeset output when sending to a printer.
You would either use this for stuff that is only useful printed (e.g. a boarding pass could be HTML instead of PDF) or as secondary, print-specific styling for web content that is frequently printed to paper.
It's basically a css print file, which includes a lot of css properties that are not built in browsers yet, with a preview you can see on screen.
print is just another aspect of responsive web design. And paged.js add the possibility to add things that the paper need and the browser don't (page number, cross rereferences, running-head, etc.)
The use case is when I buy a plane ticket it comes with a 3 page receipt and E-ticket, and rather than downloading a PDF, we can have HTML specify how to flow the document into a document. It seems the necessary extensions are almost TeX like, alternating headers, columns, sections, page break.
HTML is already exceeding good at flow layout, we can flow text into desktop, mobiles. Why not extend the rules so they flow into a piece of A4 document, or two columns?
Another use case is reports, where there are tabular data, where headers should be repeated at the top of every page. Wouldn't it be nice if HTML/CSS could specify this instead of resorting to Crystal Reports? It'd certainly make us doubly productive.
In my opinion it's a first-principles kind of thing with respect to "what is the purpose of a web browser."
To me, a web browser's purpose is to render markup into something useful for a user, dependent on variables like screen size, user preferences, browser zoom, accessibility needs, etc. A browser's purpose is not to render-a-document-as-an-A4-printout-specifically,-because-no-other-format-will-do.
"Make it look exactly like this" is not an expectation we can or should have about web browsers, and this proposal is an attempt at that.
Anyway, to specifically address your use cases:
> The use case is when I buy a plane ticket it comes with a 3 page receipt and E-ticket, and rather than downloading a PDF, we can have HTML specify how to flow the document into a document
HTML can already specify that document. Why does the browser care that it would be 3 different physical pages? Why would a user care? We're letting the tail wag the dog - just put the information in HTML.
> Why not extend the rules so they flow into a piece of A4 document, or two columns?
Two-column layouts are a concession of print formats due to constraints of needing to get all the other content onto the physical page. We don't have those constraints in Web, there's no need to introduce them.
> Another use case is reports, where there are tabular data, where headers should be repeated at the top of every page. Wouldn't it be nice if HTML/CSS could specify this instead of resorting to Crystal Reports? It'd certainly make us doubly productive.
If we're spinning up this whole AlmostPostscript.js thing to render a <table> with a sticky header, I really don't want to be a modern web developer anymore.
You're missing the point here. I have created an electron app that renders reports via json and svelte. They are intended for print not the web and the easiest way to get the data printed was using the browser engine which gladly outputs to PDF. However, styling these pages would be a lot easier with better page support in CSS. Or at least better support of those CSS specs. I really look forward to having these polyfills. Using paged media is in a lot of contexts easier than latex. Especially when it comes to dynamic content.
Definitely a hot take. Scrolling is not the best UX for all content across all use cases. I'm sure you can imagine some use cases where pagination is superior.
And sure, paginating fixed content is easy. Paginating dynamic length content? Having poked around at the problem, I'm very curious to give this library a try.
One of the main virtues of HTML/CSS is separation of style and content. This is useful when you want to style your content for both print and the screen.
Currently, this requires you to use something like pandoc to generate LaTeX and HTML from the same source document, then use two different languages for styling. I don't want to do that. I want to have a single HTML file with one stylesheet that applies a few extra rules to print nicely. I can sort of do this now, but there are lots of features missing that make it impractical for many use-cases. For example, it's currently impossible to make a footnote always display at the bottom of a print page in CSS alone.
Pagedown[1] leverages paged.js to create reproducible scientific documents. It's still a little rough but I prefer it to fiddling with LaTeX templates.
This looks interesting. I work on a project to help convert articles into printable PDFs. Created a video a few years ago showing how CSS can be used to control columns based on paper size and orientation: https://www.youtube.com/watch?v=854Csokl3QA
The page printing of this website is somewhat broken on firefox. The two columns are neat I guess, but the subtitle overlaps the text, the top margin is unreasonably small, and decreasing scale (to save paper) makes right margin very big.
I understand that some people may not care about Firefox, but can you at least not break things for it?
Firefox does not support the page size declared in the @page when printing. The page is in A4 or letter by default, it is necessary to manually modify the size of the page in the personalized sizes. If it's not done, strange things happen. We care a lot about Firefox and paged.js team tried to have a discussion several times on this point. It should be moving in the next few months, I hope.
These two concerns seem rather unrelated. I mean, pagination is valid for 2 pages. A book is hundreds of pages, and the concerns there relate to that very long length. (I would settle for a nice in browser solution for merely the former!)
I don't want to sound snarky but this is a sincere question: why?
Why would I want to make a browser act like a book? Or vice versa? Didn't we kinda try this with Flash? And didn't we realize they are two different mediums?
It is not about making the browser act like a book. It is about using HTML (a document markup language) and CSS (styling independent of semantics) to write paged media. I personally need to write the same documents fairly often in both latex and HTML in order to make them pretty for paper and screen. I would love to use HTML/CSS for both.
The issues I had were mostly to do with converting to pagination and I decided that in practice it just wasn't worth it.
The problem is that pagination on web pages just doesn't work. People have figures and so forth that need new page breaks to properly work.
CSS has extensions for this but the problem is that no one uses them because they're not intending their pages to be printed or paginated.
I have more work on this if you're interested:
https://getpolarized.io/2019/10/06/Whats-Next-For-Web-Captur...
https://getpolarized.io/2019/05/11/portable-web-documents.ht...
... I've decided to just migrate all this work for EPUB for various reasons but I'm also going to migrate to one continuous 'page' due to the CSS pagination issues I mentioned above.