Six months ago, Fred Chasen and Julie Blanc started to work on a library to paginate content in the browser. Today, that tool has a name, and even if it’s not bulletproof yet, i wanted to show an exemple of what we can do with it. And the best is that it’s only the beginning.
What is the Paged Media initiative?
At the beginning of the year, we announced the Paged Media initiative as a community driven open source solution to help anyone who wants to print content with web technologies. Before looking at what we’ve been up to for the last five months, in upcoming articles, let’s have a look at what’s possible the gaps we’re trying to fill.
Paged Media approaches : page floats
In CSS specifications, the float property is very interesting. The property indicates that an element is to be removed from the normal flow and instead be placed into a different place – currently, on the right or left side of its container. Text and other inline elements will then surround the floated element.
Editoria — Building a Book in a Browser
A couple of years ago, the University of California Press and the California Digital Library partnered with Coko to begin an ambitious project to develop a workflow application that would allow books to be built in a browser using entirely open source technologies. Editoria is that app.
Introducing Hederis, and Why We Care So Much About Pagination
At Hederis, we’re combining the concepts of WYSIWYG design and automated publishing in an attempt to solve the problems I’ve seen time and again in both the traditional and automated book-making workflows.
Paged Media approaches (Part 2 of 2)
In the previous post, I wrote about different paged media approaches. Now, in Part 2, we focus on another method based on the CSS Paged Media Module and the CSS Generated Content for Paged Media Module.
OpenStax : One textbook, many displays
My presentation from the workshop covers extensive examples of OpenStax’s Sociology textbook in many different formats and locations and then looks at the ways that we use css and transforms to create print and web versions of the books that can be used coherently together.
Paged Media approaches (Part 1 of 2)
Designing a book or a print-ready PDF requires that you think by pages. This is the major difference between formatting for the web and for PDF/Print. In a browser, we are able to implement a fixed height block with overflowing/scrollable content or automatic height block based on content. But for print/PDF, we need to be able to create pages of HTML content i.e. we need to be able to fractionate the content.
Book production with CSS Paged Media at Fire and Lion
Multiformat thinking is hard. The whole point of our digital-first approach is to store content only once, and produce multiple formats automatically. This puts tremendous pressure on project managers, developers, authors, editors, designers and proofreaders to think in multiple formats at once.
Thank you for the feedback! "Inline-start" and "inline-end "are indeed a better choice of keywords, I made the change in the demo and updated the article Finally, thanks for the links to open issues and discussions, I had no idea there were discussions about it.
Nice explanation and demo! I'd like to give some comments. In some keyword combinations of your proposal, "before" behaves like inline-start, and "after" behaves like inline-end. In Antenna House's page floats implementaion, the "before" keyword means block-start and "after" keyword means block-end. That was because of W3C's old logical (flow relative) direction terminology, before/after/start/end, that was used in the W3C XSL-FO spec and changed to block-start/block-end/inline-start/inline-end in 2013 CSS Writing Modes. So I think we should avoid "before" and "after" keywords here. I think we should use "inline-start" and "inline-end" keywords rather then "before" and "after". e.g. `float: block-start inline-end`. Please see also css-page-floats open issues on https://github.com/w3c/csswg-drafts/labels/css-page-floats-3 and the csswg "Page Floats Redesign" discussion minutes on https://lists.w3.org/Archives/Public/www-style/2017May/0052.html
Fantastic explanation. Thanks so much!
Bravo! Fantastic to see this progress from Editoria. And btw I think all your choices in its development have been spot-on. Well done! --Bill Kasdorf
[…] other types of digital files has always been a challenge, as Nellie McKesson notes in her recent blog post on Hederis. So, a couple of years ago, the University of California Press and the California Digital Library […]
[…] In the next part of this post, we’ll identify additional features we need for making sophisticated layouts and the drafts or propositions currently being developed. We also see what the W3C proposes (or not) for specific styles and content elements needed to make a book: generated content, color management, baseline and typographic matter, and so on. […]
Thanks, Antoine. I haven't tried Hugo yet. I'm very tempted, but realistically I'm unlikely to find time soon, and we are very deeply invested in the Jekyll setup, particularly its integration with GitHub Pages. One of the challenges with using a given tool for real client work – at least when you're a small team like ours – is that you have to stick with your early decisions, and you're unlikely to get a realistic chance to revisit them. I also haven't tried forestry.io myself properly. I can't see any reason it wouldn't work as a convenience for semi-technical Electric Book users. The difference with the EBM of course is that the EBM is designed specifically for non-technical users editing books, so it deliberately hides a lot of complexity that a more generic Jekyll admin interface might need to provide. As far as I can tell, forestry.io, cloudcannon.com and siteleaf.com are not open-source, which is another important consideration for us. I don't think any publisher trying new things should risk using proprietary tools right now. With open-source, you're not going to get locked out of your toolset if its owner's business model changes. We originally considered building the EBM on top of an existing open-source Jekyll manager, but couldn't find one that was established enough and open-source. Prose.io of course influenced our thinking, and the jekyll-admin plugin looks promising.
A great post for a great project! Thanks Arthur! I have two questions : - today Hugo (a fast static site generator) seems to be faster and more flexible than Jekyll, would it be relevant to use Hugo in your workflow? - do you think that a web-based editor (like https://forestry.io/) can manage the contents like your Electric Book Manager?
[…] These are slides and notes for a presentation I gave at a Paged Media meeting in Boston on 9 January 2018. The meeting, organised by the Collaborative Knowledge Foundation and funded by the Shuttleworth Foundation, aimed to kick-start an open-source community centred around book production using CSS Paged Media. I gave participants an overview of the use of HTML and CSS Paged Media to produce print books in particular. Erich van Rijn from the University of California Press has written a good overview of the event. […]