Meeting to be held at MIT Press (Cambridge, MA) on 9 January 2018
Paged Media Open Source initiative
Designing book covers in the browser
If we can make books in browsers, we can also make cover too in the browser too, right?
Unfolding the @page
Let’s say you need to make a poster and you need to give to the client the possibility to change a few things on this poster, like the date, or even the title. HTML can be the right way to go: it works in all browsers, it does not need any particular applications to be installed, fonts and colours are already set up by a professional designer, and the pdf will be ready for print without any problems.
A Bag Full of Stories
As we wander the internet, gathering images, videos and text to make stories, how do we carry them back to camp, how do we share them with our community?
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. […]