Announcing The Scarlet Lemming! February 3,2010My next project, The Scarlet Lemming, will be kicking off on February 15!
Topic Tag: Discourse February 1,2010“Nutella,” said she, “I decree, is the greatest substance in the world.”
New Mystery Underway! February 1,2010You may not know it, but a new Mystery is underway at 1889.ca!
Uhopping Chapter 5: Electric February 1,2010This is part five of the Uhopping adventure that is spanning lots of webfic sites…
Topic Tag: Ohh, Yes! January 28,2010“I’m serious,” wrote Anna, late in the evening, “you are.”
Topic Tag: The Glitch January 28,2010The bank heist was not going as planned.
Liveblog: iTablet Press Event January 27,2010PTTBT’s Erin Barkley brings you inside Apple’s iTablet press conference, LIVE!
Programming Note: Liveblogging Tomorrow January 26,2010Tomorrow at 10AM PST, 1889.ca will bring you the Apple press event LIVE!
A Hell of a Morning January 26,2010Daylight savings meant the hell-hounds wanted walking an hour early.
On Formats and Friction
I’m not going to play the blame game, but it’s all @shutsumon’s fault this post exists. The question is: what do we need out of an ebook format?
Note: Liza Daly rightly points out that my argument is with the implementations of ePub, and not the standard itself. I most agree with that sentiment, upon reflection. Mostly 
Let me state up front that I think all the current formats suck beyond words. We live in a world where a web app can behave just like a really fancy desktop app… where onscreen design can easily surpass what is economical in print design, and where a great many devices (desktops and smartphones at least) have enough raw power to get the job done. And yet we’re stuck with something akin to a spit-and-polish version of the Mosaic browser. For those of you who don’t know, that is a VERY OLD BROWSER. My eyes bleed just thinking about it
The problem is this: epub (the heir-apparent to print) is a horribly crippled format. It offers so little support for CSS (styling) that you can’t really specify anything beyond italics and bold, and maybe the occasional header. Something as fundamental as small-caps isn’t supported. It’s clearly “design by coder”, where the imperative is on creating something stripped-down, functional, and verifiable. The less crud, the better. Function before form… and hell, if we can just get rid of the form altogether, that’s even better!
The problem with this is that it removes the beauty from books. Choosing the right font, the margins, the spacing, all that stuff… it seems like a pretty mundane thing, but having it done right is part of the reading experience. It’s not just for fun, either. If you get the balance wrong, you’ll reduce the comfort level of reading, and subtly push your audience away. Design is a complex science dedicated to making everything seem simple. Epub assumes none of that matters, and the user should be in charge of changing all aspects of their reading experience on a whim. It seems like a nice ideal, but it’s like letting a child decide how many chocolate chips go into their cookies: they’ll toss so many in the bowl that they’ll make themselves sick.
Now of course designers will say the solution is to let them design the books themselves, and they’ll probably be expecting to hand-craft each page one at a time. But when you have a file being read on a Kindle, then an iPhone, then a desktop browser, then a desktop browser on a 29″ screen, or a tiny mobile screen… you can’t really design that easily. Text needs to re-flow, so fine-tuned typography is a thing of the past.
How do you design for a page that can change shape and size and scale at any time? How are margins figured? Can we say that each page has left and right margins equal to 1/8 the size of the page? Is that safe? Is the formula more complex? How about line spacing? Should we set it by the number of lines onscreen at a time, or by some other measure? If we have a graphical treatment to the page, does it scale to fit the page, or does it re-align itself? If it scales, how does it scale (if the page is much taller than expected, does it repeat, or just stretch, or…) Is there a way to design a book in such a way that it is truly cross-platform, or is that asking too much?
Coders will say none of this matters. The benefit of epub is that we leave all that behind. But truly great design won’t happen in the format until it’s possible, which means — despite any tendencies towards being the MP3 of the literary world — the format won’t really take off. What needs to happen is for the coders behind epub to stop using this as a second chance to right the wrongs of the CSS revolution (where they lost control of the web to the designer hordes) and try to come up with a clear, precise, validatable methodology that lets designers have room to play. If you don’t define the tools, they’ll come up with something crazy on their own, and you’ll spend the next 10 years trying to make it make sense.
Personally, what I want out of epub is this:
- full CSS support
- embeddable fonts (via @font-face, already in CSS)
- a switch to change elements when the device only supports black and white
- reducing the customizability in readers like Stanza, so well-developed design concepts can’t be trod on willy-nilly
- finding an open-minded typographer to re-imagine how ebooks should look, keeping in mind the limitations of the medium, and use that as an example of what SHOULD be done.
How about you? What do YOU want to see in the perfect ebook format?
tbh, I'm probably just like the devs there. Maybe it's just you, but I'd be just fine reading a txt without newfangled shenanigans like “bold” and “font”.
Bold and font? Kids these days! When I was a youngster, we ran our fingers along the punchcards because we couldn't afford the computer to put 'em in! Now get off my lawn!
I definitely see the point of the devs (being a dev myself), but the price you pay for too many restrictions is a web page that's one big JPG (with text rendered in a nice font, but completely inaccessible) and a bunch of image map links to get to the other pages on the site… which are all JPGs too.
If devs don't make a few conciliatory steps, things will turn out badly
I'd like LIT back, please. I can't stand ePub, either as a coder or a reader.
Ah, I only played with LIT a little bit because it was Windows-only. Did it not cause aneurisms in developers like ePub? That must have been fun…
LIT honors your CSS. Code it any way you like, plug the (x)html through ReaderWorks (free, but lacks some features of the pro version), and voila, sweetness'n'light.
It has good metadata drill-down, and it automatically hyphenates words on full justify.
IMO, it's the best reader out there in terms of being (as) faithful to book design (as possible) and ease of reader use (i.e., eyeballs).
In a post the other day, I blogged that “Epub is not a business model”, adding in part:
… A variation on the Heisenberg uncertainty principle: you can specify appearance, or you can support use, but you can’t really expect to do both simultaneously. Between html and xml, control moves from appearance of content to the rules for presentation of content.
Folks laboring mightily in html to craft the perfect e-book remind me of the monks of the middle ages, carefully copying pages of previously published manuscripts. The works were often beautiful, but they took time to produce and there were just a few of them around.
It may be that the limited tools are limited because both editors and designers prefer that they not give users much control. Your call for a methodology you can validate is a good one, and it would shift the emphasis from control to use (and reuse) of content.
I must investigate this LIT thing further. If only to see how it's done. I feel like we're all getting too settled into the ePub way of thinking, and it scares me
You might like this:
http://b10mediaworx.com/peculiarpages/fobbible/...
Illustrations and poetry.
Oh definitely. I know designers would rather use PDF, even if it means creating a dozen different PDFs for each device. A great many designers would rather give up their sight than work in a shiftable medium like the web, but in the end, that's where the market is going. The question will be “how do we create a methodology for eBook design that's as robust as the one we've developed for print?” I personally find the whole issue very exciting, but then I don't mind a little drama.
What we really need is a really good designer to sit down and say: “Knowing that I can't be there each and every time this is seen, I would say these are safe guidelines for how to approach the design of this content, which you may apply programmatically from now on.”
That designer will be hard to find, I think
I have a confession – I've never actually seen an ePub ebook. I've only downloaded Stanza this evening. So I'll have to take your word that it's ugly.
It's about the give and the take though – the last thing we need is a format as rigid as PDF. They may have been the first ebooks but PDFs are a pain in the ass to read unless you print them out. I love PDF as a layout tool for things meant for printing but reading them onscreen 9which i have to do quite a bit) is just *ouch*.
To make a better ebook format we need people who can work out the coding for the layout and people who can make apps for the various devices that need to support them. If it's going to follow epub or mobi and be xml/xhtml based then the latter task is probably the easier. Is epub opensource? If it is then it literally may be a case of getting someone who knows about such things to mess with it until it does what you want.
As a writer and coder and somebody who likes pretty things arranged prettily, I have to say I'm in the middle of this.
People who read e-books want content. I hesitate to say that design isn't important, because it is, but it needs to be designed in accordance with the device capabilities.
For instance, I think ragged right looks terrible, but I have run across a lot of people who HATE full justification in e-books because their device has the capability of fully justifying it if they want it, if it's not hard-coded.
Ditto with fonts. Mobipocket reader (the one BlackBerry uses) will give you any font you have on your machine as long as it's not hard-coded. these are important things to thing about.
So while I think it's important to have good design in e-books, it's not as important as all the bells and whistles in print, and it's certainly not as important as A) metadata and B) ease of reference.
In other words, the print book reading experience and the e-book reading experience are entirely different and must be treated as such. I strive to make my e-books as pretty and as easy to navigate as possible within the limits of the device I'm coding for.
ePub is an open standard, yes. And I really do think the ideal is to take it and extend it, and prove that it works better when it's improved. Basically, assume that most modern devices have a web engine of some kind, and depend on that to display the content. WebKit and Gecko are easily-accessible, so upgrading Stanza to allow full XHTML/CSS/Javascript goodness shouldn't be that big an issue. All you do is change your renderer. With that done, we've totally revolutionized how ePubs work, and the world is a much richer place.
If you want, download one of my books (try http://read.1889.ca/epub/vector/en) and change it from .epub to .zip, and then decompress and look through the guts. It's an amazingly simple format. It's truly absurd it doesn't do more already.
I only have read PDF ebooks on my computer, which is basically like reading on a website but without the need for internet access. I hadn't really given thought to what I wanted – I don't use e-readers and don't have an iphone, so…..
Some of them are of course much better produced than others, and take into account the nice things about books e.g. spacing, artwork, etc.
But PDFs are fairly restrictive. I guess it'd be cool if an ebook could also be interactive, like include capabilities for sound clips and such. Maybe?
I don't know. I'm a computer luddite.
The great thing about PDFs is that they let you really construct the page. But if you move that to a device like an iPhone (which isn't a certainty, but it's likely that's in your future at some point
then you're going to have a terrible time reading it. So the ideal is to make something that can look as polished as a PDF, but be flexible enough to follow you from device to device. Thus far, we have two opposite sides of the field, and no middle ground. That's why I'm cranky all the time 
And here I thought you were just generally cranky!!
Oh. Well… uh… that too.
Do you remember that time not so long ago when standards compliance in the bloody browsers was rare and they didn't even fail to comply in the same places? Some sites got round it by detecting your browser and calling the correct stylesheet. It's rarer now because it's easier to make a site cross-compliant (if you just ignore earlier browsers anyway).
I'm not being random here, I'm just thinking the beauty of content style seperation is that you can change the style sheet and leave the content up with no tweaking and the way it looks changes.
Perhaps a partial answer once you have full css support is to have different stylesheets for different devices and the file detects where it's being read and loads the appropriate sheet. That way if it's a tiny phone screen it loads so it looks pretty on a phone screen and if it's a larger screen/tablet/reader it could load appropriately for that. It's certainly not ideal and graphics may well still cause issues but it might improve the design issues (right up until some antsy designer comes along and makes it flash up messages on smartphones demanding people get a proper reader to read their book anyway. Guess who found all those “Oi! Get this browser to view this site” messages really annoying)
Ah, but what is the device you're coding for? That's the holy grail, I think. Write once, display anywhere. Make “smart” layout that knows how to adjust depending on the device, but maintains the same gist across all platforms.
There's got to be a way, but I can't quite put my finger on it yet. Took me years to be comfortable with web design methodology… this is like a whole other can of worms.
(as for customizability: there needs to be a list of Evils vs Wish-Nots for design… justification? probably “Wish-Not”. Swapping fonts? Probably Evil, honestly. If you can embed a font and have it display well across all devices, it honestly is part of the experience. Better to not let that get overridden if you can. Tho all of these things are hard to pin down)
I like your idea of including the ability to change elements for b/w devices. Could we also include a set of rules for display types such as micro-devices, eReaders, and desktops? It might be nice to query display window size in pixels. Otherwise, a designer could create two different versions of an ebook: one for larger displays and one for phones. A single truly cross-platform format might be too much to ask.
Good design for multiple displays reduces the need to allow the reader to alter everything like in Stanza. The reader only needs to adjust following preset rules like zoom, or device settings like brightness.
I think there is a compromise somewhere between a rigid PDF and ePub.
I was just recommending those messages to pressure ePub reader-makers to adopt proper CSS in their products
The answer is probably somewhere in the CSS linking. A lot of the elements could be standardized across all devices (font, spacing etc), but other things like margin or graphics would be swapped in and out depending on the use.
I love web technology sometimes.
Sometimes.
I guess it would be some variation on the stylesheet loading tricks already used for websites. Maybe define classes of devices by screen size, then also by colour depth? The reader loads the file and says “I'm an iPhone” and so it gives you 320 pixels wide and full colour. At a minimum, it can display the plain text in black-and-white.
Ideally, you'd also be able to make an online engine that would be able to display one of these files as a normal web page, and have it behave properly with no fudging of the code. That's the ideal, I think. If you separate the content from the styling well enough, cross platform should be doable.
I think, anyway
I think that's where EVERYBODY is right now. In my case, I have a limited amount of time and a whole lot of things to cram into it. For me, at this point in time, simpler is better.
Mojo knows of what she speaks, especially considering her experiments to prettify her books on Smashwords caused our Meatgrinder to commit hara-kiri on at least two occasions. If an author wants to e-publish a novel or other straight form narrative work, they're best off devolving the formatting to simple text plus bolds, italics and indents. I've seen too many authors screw up their ebooks by trying to replicate the printed page across all ereading devices. It's a losing battle. By liberating a book as plain text +, the book will beautifully and reliably shape shift across all devices and formats, allowing readers to enjoy their book their way. One of the reasons authors cannot and should not try to impose layout on a straight narrative books is that you don't know how the reader wants to consume your book. They may prefer pink palatino 16 point reverse type on black, double spaced, justified, against a blue marble background (this is possible on Stanza). They want your words their way.
Some books require controlled layout for readability purposes, and for these books ebook formatting is more of challenge. The opportunity for authors is to take a fresh look at their books and ask, “is it possible for me to add value to this book for my reader by re-imagining the book in a simpler, more reflowable form?” Often the answer is yes.
And both times it was with a CSS/HTML file.
That book has a LOT of specialized formatting (newsprint, blog posts, e-mails, press releases, transcripts). The print book uses almost 20 fonts. I had to exercise some real creativity to get it into txt+ for the Meatgrinder.
Mark, I love Smashwords more than anything in this world, but this is one place I strongly disagree with you.
A book is more than its text. Or at least it should be. I appreciate that some users want to use pink palatino 16 to read my book, but those people are — and I mean this with all possible respect — stupid.
I know a lot of people view book design as something any monkey could do, and that the conventions are silly nonsense with no relevance in the real world… but those are conventions for a reason. They're done that way because it's been proven to be the best way to communicate text to human beings. It's not arbitrary, it's science.
Put another way: imagine if you had someone tell you that using global variables and eval() with unvalidated input was the proper way to code a website. Or if someone said running your car on tomato juice was the right way to go. Or if your doctor wanted to use toddler scissors to do your surgery. No problem, right? It's just out-dated thinking that suggests scalpels are better, isn't it?
Now, that's not to say that there aren't better conventions to be made, and that these conventions won't look totally different than what's gone before… but to assume that books have somehow been hindered by design all these years, and now they're freed… that's just silly.
We should be working towards a standard where reflowable content can be as artfully designed as the printed page. Adaptable for sure (font size, invert colours etc), but by god, don't throw us back to the days of ascii BBSes just because it's easier to validate.
you are correct sir! I think there may be a special “make it pretty” format in the future, but frankly, with devices coming out every quarter, reflowable, adaptable formats are the key. Besides, if you really need your page formatting to be picture perfect, what are you compensating for? Bad or lackluster prose?
Should be doable, but there might be a few textbook designers trying to include illustrations and other features that might prove interesting for extremely differing displays.
Like you said, we need to find some designers to define ebook format. Get away from print design thinking. I'm glad you brought this topic up. I like to think about things like this.
I don't see why you can't have a standard that can look nice while also reflowing. There are plenty of websites that look nice with variable and dynamic content. At a minimum, a designer should be able to set the font characteristics for optimal reading. Design isn't about flashy backgrounds and rounded-corner boxes, it's about a clean and professional experience to enhance the reading experience. You can take Shakespeare and put him in magenta on yellow, and it doesn't matter how good he is, you'll never finish the story. More subtly, having too little space between lines on a page can cause fatigue, meaning people will have trouble reading as long as they might have otherwise. The ideal should be to get the best of both worlds, and make something that can adapt as new devices come out.
Unfortunately, as I understand it, you need Microsoft Reader to read .lit. And Microsoft reader is inelegant at best.
Too many people are still thinking in book format. Maybe we should stop calling them ebooks
I agree that 'pages' have to go; they are irrelevant in the electronic medium.
Proper reflow is also needed; reading ebooks on my iPAQ can be so painful it's not funny. Especially PDFs, which do really odd things around chapter breaks.
And not every book needs bells and whistles, but the opportunity should be there for other content, where it suits the object. Functionality and portability yes, but what about beauty?
Sure, an argument on functionality in design can be made. We're already very close where functional appearance are concerned.
Personally, as someone who has formatted for every format made I'm a firm believer that readers who cheer for a pretty page should stick to paper.
As for this debate, well, whatever so called lasting solution we end up with will be the one that leads to the most customers. My prediction is that someone will improve existing software or create new software that makes content easier and more natural to read. Coders won't have much of a say.
I say thank God. I've formatted sixteen books over the last year and nine months for more eBook file formats than I can count. As long as my readers can get lost in the story I'm telling, I don't give a damn how they read it and the less I have to do for formatting the better.
If you're wondering what I do for the good old obsolete tree killing paper book market, well, I just make my work look like standard 6×9 TPB. No one's ever complained.
I'll save my design time for my website and anything else with color.
I'm posting this on behalf of Liza Daly, who ran into problems with Disqus (it ate her comment). She wrote (via Twitter):
Your post confuses what's missing from some implementations vs. the contents of the spec. Not the same issue at all.
An earlier tweet that gives context is:
Seeing misinformation about what CSS epub supports. Just check the spec. (Yes it includes embedded fonts and smallcaps) http://bit.ly/zNnxX
and then
I disagree w/ the decision to limit to a subset of CSS2.1, but the properties removed are minor & CSS3 wasn't finalized when epub was
(I'll reply below this)
That's very true. I don't make a distinction between the format and the implementations. The standard is definitely less advanced than I'd like, but the real problem is readers like Stanza don't even support the basics that they should (I'll make a note on the post above so that's clear).
That said, I think the standard should be able to be more advanced than it is. I can't see any reason not to support the full range of features that all modern web browsers have, especially since there are so many robust open source engines to choose from. If you treated the content of an ebook as unfiltered HTML with CSS (and Javascript, preferably, as an option), things could get so much more interesting. Pushing well past “a book on a screen” to something really fantastic.
you have mixed up apples and oranges
and crescent rolls and crescent wrenches.
the problem with the .epub format is _not_
that it was designed by a bunch of “coders”.
on the contrary, it was designed _without_
much input from actual programmers at all
(who could have given some excellent advice
about how to make things easier for coders),
but rather by a bunch of format wonks who
were reacting to their past instead of doing
the much harder job of imagining the future.
it's also the case that they didn't incorporate
input from book designers and typographers.
but their worst mistake was their belief that
all they had to do was make up a format and
their job was done. i guess they thought that
programmers are just a bunch of drones who
will step in and do what they are told to do…
a full decade ago — when .epub was still known
as o.e.b. — i told these idiots that if they didn't
come up with a reference implementation –
preferably one that was open-source, with a
solid base of programmers working on it –
for _both_ their viewer-application _and_
their authoring-tool, that their precious format
wouldn't go anywhere. and that's were it went:
nowhere. and now the situation is even worse,
because we've got multiple implementations
and they're all incomplete, in different ways,
so we're reliving “browser incompatibilities.”
and, exactly like microsoft sabotaged o.e.b. by
wrapping it up in their own proprietary d.r.m.,
adobe is now in the process of sabotaging .epub
by wrapping it up in their own proprietary d.r.m.
and when adobe finds that their lock-in strategy
didn't work, they will exit, leaving us in shambles,
just like microsoft exited, leaving us in shambles.
now, you might say, “why didn't the publishers
learn their lesson from that earlier experience?”
except that question implies that the publishers
_want_ .epub — and e-books — to actually work.
but they don't. they're using .epub as a diversion.
they hope this needlessly-complex and buggy
format will hamstring mammal self-publishers,
raise the cost of entry and worsen our products,
and give corporate dinosaurs some extra time…
if the corporate publishers wanted .epub to work,
they would be using it themselves. they're not…
instead, they're turning to crap like scrollmotion.
that's where they spend their development dollars.
meanwhile, too many so-called e-book supporters
fell into the e.pub trap, because they are stupid…
***
i wrote the above before reading the comments…
you commenters here seem to be suffering from a
different problem. you can't seem to visualize a
reflowable format that looks good on the screen,
(you dream it, but don't know how to achieve it.)
it's not that hard. the iphone app “eucalyptus”
has already achieved it, to a very large degree…
and the astonishing thing is that eucalyptus uses
the ascii e-text version of project gutenberg files.
in other words, you do not need to do _any_
fancy formatting — .epub or otherwise — if your
readers are using an intelligent e-book program.
there are some details you need to master, yes,
but i won't go into them here, except to say that
they're very simple to learn and put into practice.
first you need to stop drinking the .epub kool-aid.
-bowerbird
Hi MCM, I have great respect for the science of design, and I agree much improvement is needed in ebook formats and tools so authors can better present their works across multiple devices.
My point is that many authors don't realize how they can make something *more* by making it less. With ebooks, if you give the reader the power to manipulate (mangle?) your content, it's sometimes more valuable to them.
I'm reminded when I attended a presentation by one of the Twitter founders, years before Twitter became what it is today. He said the powerful idea behind Twitter was, “less is more.” There's a reason they limit posts to 140 char.
Often, strict design is imposed on the page when it's unnecessary (like every time a novel is sold only as a PDF file). To the reader, the person we want to satisfy, I think it's not our place to tell them how to enjoy a book. If I'm a producer of the world's best caviar, I might consider it sacrilegious to allow my customer to cook my fish eggs in the microwave, boiled in buttermilk, strawberry jelly and chocolate covered crickets and monkey brains, but hey – it that's the way they like it, all the power to them.
I should apologize for mixing up format wonks with coders. I suppose I bundle them in my mind, which is a whole other level of offensive.
As for the ePub kool-aid… I can see your point, and I definitely appreciate what you mean about the major publishers trying to distract us from the real battles… but I think that with ePub, history may have caught up with them for once. I think the surrounding ecosystem has evolved to the point where ePub can be useful despite the flaws.
It's basically this: ePub files can be websites with a table of contents and some metadata. You can wrap all this enhanced content in the package (which won't validate, naturally) so that it degrades gracefully, just like a website. The smarter readers will learn to render it (which should take minimal effort) and the dumber ones will die off. The better presentation support will draw better and more “beautiful” ebooks, and eventually ePub (which already has extensive market penetration) will either become the standard, or at least set it.
If we try and do it from scratch, properly, we'll have a full uphill battle again. If we use the container as a vessel to sneak in the back door, we might just be able to do something cool.
I guess it comes down to the Mac/PC argument (ha! didn't see THAT coming, didja?)
The Windows paradigm is to let the user change anything about their system, to tweak it until it's their unique space, and if that leaves them with a half-functional mess of colour and space… well, that's their business.
The Mac paradigm is to limit choice to an optimized set which has been designed for user satisfaction (whether they realize it or not). You can't mess with the fundamental UI concepts that have been proven to work.
As a writer, my concern is that I'll work hard to create a book, and some (pardon the rudeness) fool will try reading it right after experimenting with yellow-on-blue in Stanza, develop a massive headache, and blame my story for it. In the nanny state of my mind, I feel the need to protect my readers from themselves. And also show them some cool design (if I can).
Less is more, but reducing literature to a long stream of undifferentiated text is reducing it as an art form. You can have minimalism within a structure, and I'd argue you SHOULD.
Inelegant as a software or inelegant as a renderer, because I hasten to assure you, as a renderer it's tres elegant.
I've formatted ebooks using illustrations and poetry (link above). It wasn't easy, but it (somewhat worked). I should've used SVG, but didn't have time to learn how to do that before I had to get it out there.
Sorry, I meant inelegant from a reader perspective. I really hate using it.
> If we use the container as a vessel to sneak in the back door,
> we might just be able to do something cool.
there is some merit to that thought.
the thing is, it would mean that e-book producers would still
have to go through the rigamarole of creating e-book files, and
e-book libraries and e-book-stores would have to stock them,
and e-book viewer-programs would have to deal with them,
and researchers would have to unpack them to analyze them
and then dodge their obtuse markup, and so on and so forth…
and all of these difficulties are unnecessary…
it will be far easier for everyone along the toolchain to convert
to a simpler, flat, ascii/unicode, light-markup e-book file-format.
i've already written authoring-tools and viewer-programs and
analysis-tools for this light-markup format, in various languages,
and i'm just a garage hacker/programmer with few special skills,
so i know this approach returns the best cost/benefit ratio to us.
and — to return to the original point here — it gives us the ability
to create beautifully-formatted books that are also very powerful
– without having to deal with the difficulties of obtuse markup –
with customization options that allow users to get what they want.
-bowerbird
[...] This post was mentioned on Twitter by aadilanis. aadilanis said: On Formats and Friction | 1889.ca: We live in a world where a web app can behave just like a really fancy deskto.. http://bit.ly/IZHRi [...]
[...] This post was Twitted by brianspaeth [...]
I don't know anything about the technicalities of coding, but I know one of my books has jokes and elements directly related to font, and those are lost in at the Kindle version.
Also my chapter headers in that same book are also big and bold and over-sized – in a specific font – which also plays into a more subtle joke. Again, gone.
I don't know anything about the technicalities of coding, but I know one of my books has jokes and elements directly related to font, and those are lost in at the Kindle version.
Also my chapter headers in that same book are also big and bold and over-sized – in a specific font – which also plays into a more subtle joke. Again, gone.
[...] On Formats and Friction Let me state up front that I think all the current formats suck beyond words. We live in a world where a web app can behave just like a really fancy desktop app… where onscreen design can easily surpass what is economical in print design, and where a great many devices (desktops and smartphones at least) have enough raw power to get the job done. And yet we’re stuck with something akin to a spit-and-polish version of the Mosaic browser. [...]
[...] e-book market forward is to settle on a standard file format, the most likely being ePub, despite its many obvious deficiencies. The idea is that this would help level the playing field–all devices would work with ePub [...]