[-empyre-] empyre Digest, Vol 111, Issue 8

adamhyde adam at flossmanuals.net
Mon Mar 3 00:57:18 EST 2014

On 03/02/2014 01:32 AM, verlag at traumawien.at wrote:
> ----------empyre- soft-skinned space----------------------
> Those are good links, but you are talking Browser/Tablet html5 and i 
> think we are talking 'already archaic e-ink devices' w generative Back 
> Ends and a static, burnt-in Front End (as long as they exist yet, at 
> least at the moment, there is a huge 'difference' to html5). Not to 
> mention b/w. There won't be an _http://alongslide.com/_ with e-ink, or 
> does it? I stopped using it, but i like e-ink and especially it's 
> boundedness. So the difference maybe will be devices like digital 
> Paper compared to the one and only App Browser, running everything.

Kindle, and many other e-ink readers, have web browser support (kindle 
browser is webkit based). But they don't really support dynamic content. 
But e-ink devices are really 'reader-only' devices and that market is 
being rapidly eaten up by tablets and phones. Its questionable if eink 
readers or any 'reader only' devices are going to survive 

To me that is a sign, yet again, of the arbitrarily enforced difference 
between 'ebooks' and the web. People want a device that will allow them 
to browse the web, watch videos, listen to music, check their email, use 
apps, and read. They want all these activities in the same place. So I 
think the lifespan of e-ink in this space is challenged and reader-only 
devices are also not likely to last.

Given that many tablets leverage existing browser engines for app 
functionality (notably webkit), including reader apps, the question 
arises - are books first class citizens of the browser or are they 
something else? Personally I think the space between the web and the 
ebook is collapsing on a technical level in much the same way as the 
difference between PDF renderers and browser engines are collapsing. The 
browser has become the typesetting engine of our time for print and digital.

There are many interesting issues that arise out of this. For example, 
if you are in publishing you probably want to know the tools of your 
trade and right at the top of the list of important technologies to know 
about is the *open source* engine webkit. IMHO if you want to know the 
companies that will have the biggest impact on the future of publishing 
then you need to look no further than here:

> What i could add is our ghostwriters graphics were actual Perl 
> programs directly related to the text and made on the fly while 
> content was being scraped. Graphics as accessible Software, just like 
> epub Trailer by Silvio etc, which i like a lot. Could suggest the list 
> to its perl programmer Bernhard Bauch if you want him sth to say about 
> it. Epub Designers def must heavily cooperate with programmers, no way 
> out. There's not much web design here to me, though. 
> http://traumawien.at/ghostwriters/b_033/

If you are referring to designing content that requires javascript and 
complex CSS (which is rapidly turning into a kind of scripting lang) 
then I would agree that many designers are going to have to learn basic 
scripting or they will need to work with programmers. However as scripts 
become more and more powerful it is increasingly going to be the case 
that complex scripted functionality is going to be more a matter of 
configuration than scripting - so the overlap between what a designer 
needs to do and what a programmer needs to do will always be a 
negotiated space.


> Bzgl Published Cramer Books as a Desaster. Why Desaster? We learned 
> everything from those texts. Why not cut them down and publish again?
> On Sat, Mar 1, 2014 at 4:44 PM, adamhyde <adam at flossmanuals.net 
> <mailto:adam at flossmanuals.net>> wrote:
>     ----------empyre- soft-skinned space----------------------
>     On 03/01/2014 02:58 AM, Michael Dieter wrote:
>         ----------empyre- soft-skinned space----------------------
>             But how does great epub design look like? I didn't see
>             much of it yet except to actually start 'think icon'.
>             Could you bring up some examples here?
>         Am interested in this as well.
>         EPUB3 has a lot of new affordances, but haven't seen a lot of
>         people
>         really exploring what's possible. The media overlays seem like
>         they
>         could be worth messing around with. Maybe Adam has some tips
>         here (if
>         he's following the list this weekend).
>     So...to think about good EPUB design you have to think like a web
>     designer. This is the interesting thing these days, are books
>     designed by 'book designers' (traditionally locked into DTP and
>     fixed page size) or are they to be designed by web designers (more
>     familiar with flowable page design environments) and HTML.
>     Its a kind of curious question to ask - what is the root design
>     approach? Its relevant here because EPUBs are not books, they are
>     just HTML. All the fixed page layout blah blah of EPUB3 is really,
>     IMHO, is there to placate those designers who cannot think in
>     flowables. Its a very stubborn feature of the spec. Fixed size
>     pagination is dead and we should let it go. Thats not to say paper
>     book design is dead but to say we need to start thinking about the
>     paper page as one form factor amongst many and use the same tools
>     to design paper books as we do EPUBs. We need to think about
>     design as re-flowable information regardless of weather the final
>     artifact is a paper book or an electronic book, an app or a
>     website. To think like that is to think in flowables.
>     Interestingly, while many are hoping for some form of fixed page
>     (book page) in EPUB and hoping against hope that this 'important'
>     remnant of the legacy printing era will survive in electronic
>     books, the important issue is pagination not fixed page
>     sizes/layouts. Pagination is not just important for ebooks but
>     increasingly HTML in the browser is becoming paginated. A lot of
>     libs that support resizing, flowing etc that are being built to
>     support mobile devices (mostly phones and tablets, not 'books')
>     and these are having quite an effect on webpage design. A good
>     example is snow fall of course
>     (http://www.nytimes.com/projects/2012/snow-fall/?forceredirect=yes#/?part=tunnel-creek)
>     but you can see many examples...here is one I just googled:
>     http://www.vondutch.com/com/
>     The above are experiments with pagination in 'single page'
>     websites. That is, IMHO, where things are going and its being
>     driven by the need for pagination not in books but for managing
>     information in small screen devices. Right now its all about
>     pagination and we should see pagination of flowables as the
>     central design issue not fixed page layout.
>     All of these pagination features are enabled by Javascripts and
>     mostly for use in mobile web browsing devices (and many apps use
>     webkit as a lib for information display) but all of this is also
>     possible in EPUB. And not just EPUB3. What many people forget, and
>     this is why I posed the question to Florian about the HTML engine
>     as a flowable typesetting engine for print and electronic media,
>     is that in many situations the renderer in ereaders *is* a
>     browser. iPad iBooks uses (a hacked up) webkit which is the engine
>     behind chrome. So you have always been able to use JavaScripts etc
>     in EPUB (JS, along side fixed page layout, was one of the promises
>     of EPUB3)....so I increasingly get confused about why there is all
>     this fuss about 'container' formats. EPUB is just a container
>     format - it is infact a portable website. Bill McCoy, presidento
>     of the IDPF (keeper of the EPUB standards) calls them 'a website
>     in a box'. If we could talk more frequently about them this way we
>     would be able to understand what is actually happening here and
>     what is possible.
>     Personally....I think EPUB is artificial. There is no difference
>     between the web and an ebook and there shouldnt be. The following
>     is just one project of many that actively blurs that distinction -
>     http://readk.it/. If you are confused by that project its because
>     ebooks are artifice but you don't know it yet. The whole idea of
>     an ebook is essentially being maintained because you can sell it.
>     You can sell books, even ebooks, but you cant sell websites.
>     So if you ask me what good EPUB design looks like I will say it
>     looks like good web design.
>     If you want to try some ebook design download one, change the
>     suffix from 'epub' to 'zip' and then unzip it. Get out a text
>     editor and go to town...(you need a non DRM ebook to do this, try
>     the one linked from here if you dont have one
>     http://www.resourcecontracts.org/blog/guides-to-contract-terminology.html)
>     adam
>         There's also the ongoing issue of compatibility with devices,
>         EPUB3
>         had a terrible adoption rate, not sure if it's improved on the
>         hardware vendor side, but certainly a lot of publishers are
>         still on
>         the older version.
>         Yeah, also reminds me, I spoke with representative of a major
>         academic
>         publisher a couple of months ago about some of this stuff,
>         after they
>         were really hyping their digital publishing services. I asked
>         whether
>         they had moved to EPUB3 - the response was that they had no
>         idea, it
>         was the first time anyone had ever asked a question like that,
>         and so
>         they would have to find out and get back to me. They also had
>         no in
>         house digital design team, everything was being outsourced.
>     _______________________________________________
>     empyre forum
>     empyre at lists.cofa.unsw.edu.au <mailto:empyre at lists.cofa.unsw.edu.au>
>     http://www.subtle.net/empyre
> _______________________________________________
> empyre forum
> empyre at lists.cofa.unsw.edu.au
> http://www.subtle.net/empyre

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cofa.unsw.edu.au/pipermail/empyre/attachments/20140302/48e66fee/attachment.htm>

More information about the empyre mailing list