Quick question

16 posts / 0 new
Last post

How is it possible to render a fxl HTML content document while using CSS without using scroll bars?

It seems to be that the combination of "CSS" and "fixed layout" necessarily mandates the using of scroll bars.

As far as I understand it, different from SVG it is not defined, how to present an XHTML document providing some author indication about viewport as in SVG with viewBox.
Neither die EPUB 3 recommentdation seems to mention this, nor the referenced and inaccessible Apple source for the meta information.
Both scaling/panning/zooming or scrolling or something different seem to be possible, it is up to the viewer.
This 'fixed layout' for XHTML documents seems to only implicate the width and height of the document and a clipping beyond this.
Obviously this may result in problems, because authors can newer precisely predict, how much space is needed to display text in XHTML, because there can be always a user-stylesheet applied to ensure, that the font-szie is large enough for the audience.
As well not obvious, what might happen, if the audience switches off the CSS interpretation to ensure better readablilty, because such a viewport information according to EPUB3/Apple is an attribute value, not just CSS decoration.
Taking this into account, surely not a wise idea for authors to use this 'fixed layout' for books with some relevant content marked up with XHTML.
Better to use only SVG, if something with graphicaly relevance has to be expressed, this has some information, how to present something, depending on viewBox, preserveAspectRation and width and height attributes - what is mentioned in EPUB 3 about this, does not really fit completely for the correct behaviour decribed by EPUB 3, therefore one almost ignore the information in EPUB 3 about the intended SVG behaviour.

I think, there is a CSS working draft obsoleting this questionable proprietary Apple approach, maybe this is better, but currently of course not allowed for EPUB 3.

The only logical solution would be to use scroll bars to contain the content that has spilled "out" of the viewport dimensions. E.g. if you had an HTML document (with or without CSS) coded in such a way that it expected width and height to be 500 by 500 but the actual page/screen is 400 by 400.

If one can apply gestures on a device, for example with fingers, some panning is reasonable as well - and scaling seems to be in use as well - not sure, if in use for EPUB books, but I think this Apple feature was orignially intended for their mobile phones. I have seen some stupid scaling on a mobile phone with a microsoft internet explorer for one of my pages, which indicates no specific size at all, designed to be readable for any viewport size, but this mobile MSIE mangaged to display it not readable due to a scaling down the content until a gylyph had a size of one or two pixels, obviously assuming a fixed layout without having any information about it ;o)
But then it was possible to zoom and pan as for an SVG with large width and height, to be able to read a few words before one has to pan again.
Of course, both horizontal scrolling and such extreme scaling, zooming and horinzontal panning to read something ist completely annoying for the audience, but developers of such programs and designers seem to believe, that this has some meaning for text in (X)HTML as well, not only for scalable graphics. Design and graphical appearences seem to be more important for them as the meaning of the text content ;o)

I think you're confused I'm not talking about Apple's reading system at all. I'm talking about the intended behaviour of an EPUB 3 reading system that is rendering a fxl page. I imagine a fixed layout page is intended to render as a regular browser page (within an epub "book"). Note that reflowble pages have completely different semantics from regular web browser pages.

So using a browser engine like WebKit may be the most expedient way to render these fxl pages.

Let's use this web page as an illustration:

http://www.idpf.org/epub/301/spec/epub-contentdocs.html#sec-css

The above web page is very similar to what an EPUB 3 fxl page is intended to look like. It does not reflow and therefore necessarily scrolls. Imagine it in the context of an EPUB 3 book. Typically, the author chose to use fxl as a way of preserving the way the page looks in the print version or perhaps as an alternative to SVG. The author imagines it is being rendered on a 10" tablet/reader and designs his page accordingly. However, a situation arises where the book is being perused on a smaller screen, the reading system has to deal with this problem somehow so it uses scrolling. My query really is to ratify this assumption.

An alternative to scrolling would be to shrink the page to fit the reduced screen real estate but I don't think this is a good idea because that wasn't the author's intention when he made the page in fixed dimensions. Shrinking of content is natural in a reflowable context, but not in the fixed context. Of course, the reader may have the option to change variables like font size and font family, but the default behaviour must be assumed to be the author's.

The EPUB3 itself references the Apple thing for mobile phones, therefore this inaccessible Apple thing becomes part of the recommendation.
http://www.idpf.org/epub/301/spec/epub-contentdocs.html#sec-fxl-xhtml-sv...
There are meta tags referenced pointing to an apple developer page.

I did not look into the CSS document of the referenced page, but I think the text has mainly a max-wdith in em or ex to ensure, that the text lines are not too long to find the next line without problems.
If one reduces the width of the available viewport, the width of the text is adjusted automatically.
With the Apple approach one can not even use meaningful units like em or ex, only pixels.

EPUB 3 mentioned only, that everything is clipped, what is outside the viewport, but it does not mention, whether it is necessary to make it accessible somehow or how, if this is done.
This seems to be only meaningful for raster images as only content.

CSS has an concept about priorities: First the default styling of the viewer, second the styling of the author, third and most important the styling of the audience or user.
If a user specifies for example a minimal font-size or some other restrictions, this has priority and ensures, that the content remains readable for the user. In case of further trouble, the user needs an option to switch off the author styling completely, to get the default styling - additionally there is a requirement to be able to switch between alternative author styles, if the author provides them - always a good idea to do this to improve accessiblitly for different users,
Her questionable as well, what happens, if different alternative styles require different sizes of the viewport in case of a fixed layout? Or if one style fixed, another not?
To resume hiere, this fixed layout feature is not well-thought-out and does not fit to other requirements of EPUB, CSS, SVG, XHTML.
And EPUB does not require a specific behaviour for it at all, only this clipping issue without information about what should happen for users to get access to the clipped part of the content.
Scaling would be the simplest solution to avoid at all, that some content has to be clipped, but
this might mean a conflict with minimal font-size of the user or readability, if this is ignored.

And obviously, by only using styling with CSS, it is no problem to get fixed width and height in meaningful units and a defined behaviour about what happens with overflowing content, there is no really need for additional information, resulting in conflicts.

O.H. I can tell by the totally off-tangent nature of your comments that my very simple question confuses you.

@odeyemi
Either scale the page to fit your viewport (CSS transforms), or make it scrollable. To fully support the specification and provide some backwards compatibility you should also support Apple's viewport meta tags.

Why should I support Apple's viewport meta tags. My eReader has nothing to do with Apple's eReader.

Well, this is a pretty complex topic. Not to be flippant, but you are ALL right.  

Yes, you can use SVG to lay out the page, but as noted, you would need to either know the size of the page beforehand, or count on the RS to read the viewbox and scale the page to fit the page specified for the RS to lay the page out in.  Otherwise, your graphic will get clipped and the overflow won't be visible.

If the page is XHTML, then you have to count on the RS to decide how to lay out the page within the viewport it is given.  The key question is what happens to the "overflow" (i.e. the page content that doesn't fit within the initial viewport.  Readium, for example, supports two strategies:

  • lay the page out within the fixed viewport defined by the viewport defined by the browser engine and create new "pages" into which the additional content is flowed.  The user can then (presumably) use some page-navigation affordance to navigate from one page to another.
  • create a series of artificial pages which get concatenated to form a "galley style" page with scroll bars 

For XHTML, you could also use CSS (within the page) to scale the XHTML content to fit.  However, I suspect this would rarely result in a presentation that would match what the author expected. You would instead end up with something looking like a normal web page rendered on a small phone.

Worth noting that one of the implications of all of the above is that there is a very strong link between the authoring tools and what the author intends and how the RS renders the content.  In an ideal world this would not be the case, but it's hard to see how that can be achieved.  The author MUST specificy, at least to some level of detail, how the content should be laid out.  The idea that the author could specify content like the Gettysburg address, a comlex poem,  Hamlet's soliloquy or some long-form text and they all would render properly on a small phone, a tablet or a huge monitor is admirable but probably not realistic.

 

rkwright I understand you're talking about reflowable EPUB but you don't understand my question. I'm talking about EPUB 3 fixed layout.

When you specify in the individual spine items of an EPUB, the following,

<itemref ... properties="rendition:layout-pre-paginated"/>

you are saying that the content document must not be reflowed. With these documents when things get too LARGE you have to put in scrolling or panning and zooming as you prefer to state.

rkwright I understand you're talking about reflowable EPUB but you don't understand my question. I'm talking about EPUB 3 fixed layout.

When you specify in the individual spine items of an EPUB, the following,

<itemref ... properties="rendition:layout-pre-paginated"/>

you are saying that the content document must not be reflowed. With these documents when things get too LARGE you have to put in scrolling or panning and zooming as you prefer to state.

@odemyi: I do understand that (having been on both sides, authoring and reading systems).  The point I was making is that the problem here is that we have a page which the author has written which given its intrinsic or explicit styling does not, when laid out, fit within the viewport specified (either implicitly or explicitly using the appropriate EPUB metadata tags) by the EPUB.  What then to do with the “overflow” (using the CSS terminology)?  There are basically three options:

  1. Clip the overflow and throw it away
    • This is unlikely to be what the author intended
  2. Generate scrollbars so that the “overflow” is laid out as (virtual) pages that are laid out as a virtual galley page (sort of like a normal web-page) that the user can navigate 
    • This is probably acceptable in many situations, but not if the author thought it was to be laid out in a two-up series of pages because some of them are full-bleed photos across two-page spreads, for example
  3. Lay out the pages as a series of separate pages, apparently within their own viewport
    • This probably fits best what most authors EXPECT

The problem with both the second and third solutions is that they are VERY hard to implement.  Sure, most of the simple cases (maybe even most) can be done pretty well.  But there are MANY edge cases that simply break and have problems, most often because of of the interaction between the layout engine and the demands of (CSS) styling (but also more interesting use-cases like complex animations or video).  Understandably, the authors of the content that doesnt work are upset.

There are three basic strategies to achieving these strategies:

  1. Somehow use the browser’s own implementation of CSS and its (very weak) layout capabilities to simulate either the scrolling or paginated views.
    • This is what Readium does (using CSS columns).  It succeeds fairly well, but again and again we run into a wall when one or the other browser engine behaves differently (according to us) from the CSS spec.
  2. Don’t even try to use the browser to lay out the pages.  Flatten the CSS cascade completely and take over ALL layout, allowing the browser to only lay out only individual lines, not paragraphs much less pages.
    • There are implementations like this, see http://sorotokin.com/adaptive-layout/.  This is a wonderful approach, but is very computationally intensive and hard to maintain across many browsers and platforms, not to mention the code’s own implementation and maintenance. (Please understand I know this from personal experience).
  3. Some combination of the above. 
    • Several of the current commercial EPUB implementations use this approach (Readium does too, though we are closer to #1 than most).

What is a reading system supposed to do then? In an ideal world, there are two solutions:

  • Depend on the browser engine to layout pages or do the scroll-layout itself. 
    • This would be wonderful!  However, it isn’t available now and I am pretty skeptical we will ever get there.  Still, one can hope.  But one cannot depend on that to develop and ship a product.
  • Write your own browser engine that implements exactly what you want.  
    • Been there, done that (RMSDK).  It is REALLY hard.  Our team had some of the best engineers on the planet, but we had great difficulty in doing it with a team that was small enough that the company could afford it.

The answer then appears to be to rely on the browser engine and leverage the contributors to implement the code to implement the layout for scrolling and paginated content.  This is what Readium is trying to do.  Have we succeeded?  Yes and no.  Given that Readium runs on some 8-10 platforms (depending on how you count) - both native and web-based – I think it does pretty well.  Is it a total success?  No.  Are we trying to do better? Yes.  Can you and others help, directly?  Absolutely, both through constructive criticism like this thread as well as actively contributing to the product.  And by contributing I don’t mean diving into the C++ or JS code (thought that is of course more than welcome), but the there is documentation, testing, evangelism and many other areas one can help.

Thanks Ric Wright, Readium Foundation

rkwright, you really don't understand fixed layout EPUB. Read the spec:

http://www.idpf.org/epub/fxl/

The spec gives the following definition of pre-paginated,

"The given spine item is pre-paginated. Reading Systems *must produce exactly one page* when rendering this spine item."

Is my question still unclear? We're not talking about multiple pages here as that option is not permitted. We're talking about how to present this one page to the reader, if the page happens to be larger than the viewport. Does the page shrink?

My apologies.  I do very much understand fixed layout EPUB (more than I

would like sometimes).  I was distracted by a family crisis and

misinterpreted your question.  

 

You are quite correct, my answer assumed REFLOWABLE content.  For fixed

layout, you are correct that the spec does not really say what should be

done with overflow (which we should correct in 3.1 - I will raise this

issue).  However, the clear implication (to me) is that is would be

treated the same as a bitmap image I.e. The overflow should be clipped.  

As I mentioned in my previous reply, scaling it to fit is unlikely to be

what the author intended.  Unlike SVG, (X)HTML does not have any metadata

for indicating how the content should be fitted into the viewport.

Supplying XHTML content that will not fit within the viewport indicated by

the metadata is, in my opinion, an authoring error.

Secondary menu