Fixed Format Made Reflowable Why is This Spec Not Real?

13 posts / 0 new
Last post

I've just got into this entire world of creating eBooks and I'm stupefied as to why we have the codability to create such dynamic web pages and yet we can't seem to make eReaders capable of handling dynamic yet relatively fixed content.

Here is a quick example of how a dynamic yet relatively fixed content would look like:

(Edited: version 10 uses "vh" and 11 uses "vw". All positioning is absolute by top and left percent. All sizing is dynamic by percent.)
https://jsfiddle.net/am3Ly00p/10/
https://jsfiddle.net/am3Ly00p/11/

(Edited: Working Prototype)
https://jsfiddle.net/am3Ly00p/22/

(Edited: "position: relative" design with working "onload" function. Will NOT throw errors in epubcheck:)
https://jsfiddle.net/j994tnu2/9/

The ONLY issue here is that the font-size: *vw; DOESNT work in eReaders! We could have reflowable content in a jiffy if we just made a specification that allowed for dynamic viewports (that actually worked) and then setting the font size to this native css "vh" and "vw" font sizes.

I am stupefied as to why this is so complicated. That little jsfiddle could EASILY be automated to take in parameters from programs like Indesign or even .doc files and grab the fundamental percent distances of those regions, grab the text frames available and then style the content accordingly.

Please someone enlighten me as to why this epub/mobi world can't seem to get it together. All we need are smart eReaders...the code will just do its job if we let it. This seems akin to the browser compatibility world of problems that just doesn't need to be repeated. If we have browsers that can do it all dynamic now, why are readers so dumb? And no, I don't think JavaScript is required. I think if the viewports were ALLOWABLE then I'd already have my book coded up to look exactly as I want in EVERY screen.
...WITH page numbers.

So again, just want to reiterate that if and only if the text is able to be fixed in its volume-fill of the container through dynamic font-sizing then this jsfiddle example would NEVER have text overflow regardless of the viewing window's size. Which that is really the problem with eReaders. They don't allow for viewport to be set to "device-width" and "device-height". You can only put in a static pixelated resolution. This is just wrong. There is no reason why something like this shouldn't be allowed.

You are correct. AFAIK, it should be allowed, though EPUB does not allow certain CSS styles. I am checking with the EPUB working group  on that.

 I created an EPUB with your fiddle. It DOESN'T work in Readium Chrome Extension but it sort of works in iBooks.  I have logged an issue on it.  We're looking into it.

If for any reason the viewport/"vh","vw" doesn't actually create the effect that text in a container has fixed volume regardless of the window, then W3 should just create a spec that does this or eReaders should just support JavaScript, since JavaScript can do this easily.

One or the other. That's what I'm seeing.

I missed the sizing of the pageContentContainer and edited it from "100%" to the correct "80%" and edited the main post.

Also, for deployment the borders probably must be removed since they do add in static pixel width/heighth which will (depending on the viewing window) be enough % difference to throw off the relative fitting of the containers.

I took the liberty of making that little epub into a 4 page epub that shows vh/vw/borders/no borders just in case the borders are in fact making it look bad or not. You can get it here:

https://drive.google.com/file/d/0B-N6e2IfI6y6ajluVXBfV0pGV2M/view?usp=sh...

Here is a prototype of what I would like to have happen:

https://jsfiddle.net/am3Ly00p/17/

The red container is the predefined fill of the text from the original format and the blue is the actual fill size of the text. The text will now resize itself dynamically seeking to fit to the red container. The final transform of the text is lossy and so is done at the end only if necessary given a certain level of tolerance. It's definitely not perfect or "true" but it would do the job for most books if it had support. This would allow books to be formatted in a print fashion but then deployed to a reflowable eBook format, without losing page numbers or the desired look of the author.

Hmm, can't you provide accessible examples?
The Goggle-pages seems to be empty and at jsfiddle there seems to be only source code, so sample (maybe pessimised with scripts?)

However, what is the problem with something like font-size: 1em
this should adjust the font-size to what is preferred by the audience.

I understand, that new units like vw, vh etc have some good use for the arrangement of structures not in the linear flow and for media queries, but why for font-size?
The new unit rem looks relevant for font-size.

But unfortunately the W3C CSS working group did not manage yet to bring the CSS 3 units module to a stage of a recommendation, maybe this happens next year, before one cannot expect, that new issues really work in viewers.
And this module is not part of EPUB yet.
Anyway, unfortunately EPUB 3 requires already a few CSS 3 modules, which are no recommendations yet, already this is pretty strange ...

I clicked the 2 links I provided back to back: the link in Google Drive does not have a preview but it can be downloaded and every link to jsFiddle is working just fine. So what do you mean by "accessible"? You can resize the bottom right viewing window in jsFiddle to see the effect that I'm looking to get out of 'vh' and 'vw'. Or at least what I thought 'vh' and 'vw' would do for font-size. In the first 2 examples, resizing the window will create text overflow if you make it small enough. In the 3rd example resizing the window never creates text overflow or underflow (95% of the time).

Now font-size: 1em is literally the same as font-size: 100%. Where that is 100% of the parent element's font-size. If no font-size is explicitly stated for the parent element then the parent's element is 100% of its own parent element's font-size. This inheritance will go all the way up to the device's own system default font-size for the viewing window. So obviously, in order to get a "fixed-volume content display" through "em" every device would have to have the same exact default font-size relative to the resolution of the screen. What I mean by that is if the screen is 800x1200 with default font size 16px then another screen 600x900 would have to have 12px default font size (12/16 = 9/12). But as it is with different screens they do not match each other proportionately.

So 1em being used on the creation process will be the result of the actual font-size of Indesign or of your word document (let's say 12px). When this is exported to epub as a fixed format, then it is HTML marked up to have the same amount of text inside of the page for every page. This same amount of text is then put through a new device with let's say 16px font-size default. Your 1em is now literally 16px. But your content is fixed in the amount of words/characters so then there is text overflow. It will not fit the original page frame that you started with.

The idea is that I want a fixed layout book, that dynamically resizes itself to fit the screen. So let's say I make a 5"x8" tradeback print format with 200 pages. This is the fixed layout. The resolution is fixed and the pages are fixed. When exported to epub that will be marked out by HTML within the epub file. But now this book has no associated resolution but it still has the same amount of pages and the same amount of words in each page. So when fit into a new resolution this text is either shrunk in or expanded out. Either instance is not acceptable since a fixed layout book separates every single page into its own HTML file. And therefore the eReader does not have any more text to work with because each new file mandates a page break. So you are left with many pages within a chapter that obviously should have made a new page or took in more text to fill the page.

Currently the method of Indesign's export to epub fixed layout takes the absolute position of every single word in the page and applies that to the style of the epub. With new resolutions you will get text overlapping itself or too far expanded from itself. It's effectively a forced justify styling which is not desirable. I want my fixed layout to just fill the page exactly as it should and in order to do this, the font-size has to adjust to fit that original fill size from the original format. What I've shown in the latest jsFiddle version is that this is VERY easy to do in JavaScript and can be automated and should become a part of the epub specification. Either this or W3 needs to be told to make a screen size font-size which is supposed to be the 'vh' and 'vw'. The problem with these is that changing the viewing height of the window will not change 'vw' styled fonts and changing the width will not change 'vh' styled fonts. It just doesn't do this job. On top of this my concern is that in epubcheck you are forced to write the metadata viewport as its original resolution you started with (the 5x8) rather than an altogether web-acceptable-standard "device-height" and "device-width". Using these attributes will throw an error in epubcheck thus disallowing for 'vh' and 'vw' to work in the first place.

Goggle page with CSS interpretation activated - empty white page, CSS switched off a link to login and a word for a menue.
Fiddle - some menue, else empty with CSS interpretation activated, CSS switched off some boxes (iframes) with source codes. It claims to provide a 'result', but no action, if one clicks this.
Both projects seem to be borked and not accessible.
Why not to link to static examples without some Goggle-Fiddeling around - would be no problem to look into the source code anyway ;-)

1em or 100% for the font size for the root element (or 1rem) refers to what the audience has identified to be the optimal font-size for their personal capabilities and the appearence of the currently used device. Authors cannot know the size of a device, the viewing distance and the personal power of seeing of the audience.

vh or vw takes into account the size of the current viewport, but is not related to what is meaningful for the optimal font-size of an individual reader using this device.
I use no 'indesign' or 'word' to create EPUBs, I write the XHTML, SVG, CSS documents directly with a text editor. 1em is not related to any px font-size the author might use to preview something on such creation programs.
Fixed layout is not useful at all for digital text beyond a few words, typically located in an SVG document, this only causes accessibilty problems for the audience, they have to scale to get the optimal font-size, after this they either have to scroll horizontally to read one line of text or they have a pretty tiny viewport with text on a large sceen - typically they will assume, that such a styling is completely borked - if they know how to do this, they will switch off CSS interpretation to get a readable presentation ;o) If not, they will look for other, not borked documents.

For comics I have something like scalable fixed layout, it is mainly graphics, simply SVG with width and height set to 100% and a viewBox.
If there is some text outside the graphics I use an XHTML document containing the SVG as fragment.
The SVG fragment again is sized in such a way, that the size is related to the available viewport.

For digital book typically you can forget about pages as in printed books.
You should keep a structure as one one document per chapter, section, subsection, for comics maybe one document per graphic.

Your description of this indesign program sounds like a completely borked program - why do you use it. Maybe you should report simply bugs to the developers and forget about it until it provides meaningful outputs?

The PR (note: not a recommendation yet!) for the CSS 3 module values and units notes about vw, vh, vmin, vmax:
'The viewport-percentage lengths
are relative to the size of the initial containing block. When the height or width of the initial containing block is changed, they are scaled accordingly.'
Therefore if a viewer interprets already vh or vw and do not scale, if the viewport changes, this is a bug of the viewer.

This meta element with name viewport mentioned in EPUB seems to be derived from apple, it seems to assume px units, but the precise definition referenced in EPUB seems not to exist anymore. I think there is a better draft now from W3C:
https://www.w3.org/TR/css-device-adapt-1/#viewport-meta
(It is an early working draft, not mentioned to be available in EPUB yet.)

What I found about the meta element with name viewport
https://wiki.whatwg.org/wiki/MetaExtensions#viewport
contains no precise definition, this seems to be only an intitial proposal, maybe already outdated due to the CSS draft.

Until this CSS draft becomes a recommendation, one might only use CSS to define the size of the elements html or body in appropriate units, if one really needs this.

Did you resize the viewing window in the jsFiddle? Both in versions 10, 11 and 22 or 17? If not, please resize them until you get overflow of the text.

I understand everything about they the epub3 specification is right now. But this post is about a changing and evolving standard. This post is a demonstration of how easy it is to get fixed layouts but with dynamic, resizing of texts. The application for this is that you could make one print book. That file becomes the standard file for all devices and the format in print stays the format in digital. The "book" becomes the eReader. The experience of reading a physical book (turning pages and having page numbers) is maintained and the design of the author is maintained across every eReader without having to create new fixed layouts for every type of device.

That is fantastic. And is definitely not what epub is right now. Epub needs to grow and change to match the demands of a growing industry both in versatility and application.

Lastly the viewport must have dimensions set, if posted as metadata. The "vh" and "vw" will use these dimensions as their basis for sizing. I believe if the viewport is not set then the initial containing window is used. Therefore, I'm looking into not using it at all and seeing if the "vh" will be sufficient to resize text dynamically for every screen to leave no overflow in a fixed layout book without the viewport. Up to this point I had thought the viewport was required and I've learned that you can simply throw it out. If so, then there is no problem with "vh" and "vw" in of themselves and also the epub3 standard. But I'm looking into seeing if it does in fact create the effect that I'm talking about in this post (fixed percent volume content). If it doesn't then a new standard needs to support this feature or JavaScript must become widely used in every reader.

I've come up with a working example of what I'm talking about where it is true to the code. (As far as code may be true I guess) Here is the jsFiddle:

https://jsfiddle.net/j994tnu2/7/

In this example everything is style with "position: relative;" which will not throw errors in EPUBCHECK. So halelujah. Not only that, this only uses native JavaScript, no external libraries, which will make this very easy to get support in an eReader. The JavaScript looks messy (and probably because it is) but it is just 3 sets of about the same exact code repeated for 2 different scenarios: Loading the page and resizing the window. Loading the page required the content to be resized twice in order to have accurate proportional text.

And that's it. This could easily be automated and supported in every reader, creating not only a new standard for epub but a more versatile approach to fixed layout books. Now the look of the author can be preserved in every device without having to create a separate file for every format. One master format: print and it becomes digital.

Now to see how it is actually supported in eReaders.

Secondary menu