Design feature to allow image bleed in reflowable epub

[dauwhe]

Some initial thoughts are on the wiki.

We may want to raise this issue in some other places, such as Readium. I would love to see some experimental implementations in reading systems before we try to specify this.

[teytag]

The box-model (relative CSS) is very important topic for EPUB reflowable design. Not a problem if epub designer use to correct box-model CSS. But this draft article (CSS Page Floats) is very good for all EPUB editor apps. It's startup point. Look: ADE 2.0+ has some odd stacking behavior when multiple floats are used #32 -> dvschultz/99problems#32 <dvschultz/99problems#32> N. Erhan Uzumcu Art Director and EPUB Developer W3C EPUB Community Group Member TEYTAG Founder (Turkish Electronic Publishing Desing and Research Group - Istanbul, Turkey) https://independent.academia.edu/NErhanÜzümcü http://teytagblog.blogspot.com.tr http://www.teyid.org/ePub3Lib/ @ePub3Lib #teytag

…

On May 18, 2017, at 7:28 PM, Dave Cramer ***@***.***> wrote: Some initial thoughts <https://github.com/w3c/pub-cg/wiki/Rendering#image-bleeds> are on the wiki. We may want to raise this issue in some other places, such as Readium. I would love to see some experimental implementations in reading systems before we try to specify this. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGmy-habtCF-x5pmm5ERtYAIWX3r8rJuks5r7HGQgaJpZM4NffWP>.

[teytag]

Hi @dauwhe,
You know, reading systems have UI design areas. (Red areas in the pictures) Reflowable design is shown between these (render) regions. How to get images out of render region with CSS-epub-bleed technique? Will reading systems accept this technique?

[rickj]

@teytag I'd be curious for you to try this with Bookshelf. We should support CSS enabling bleed to the edge of the web view, which on iOS and Android is the edge of the screen, edge of the render window on Mac/Windows. You can side load any EPUB file using the instructions here: https://support.vitalsource.com/hc/en-us/articles/203256896-Sideloading-EPUBs-with-Bookshelf

[teytag]

hi @rickj
Thank you for reminding me of the Bookshelf reading system. There may not be a technical problem in reading systems that display browsing behavior. But will this new CSS technique (-epub-bleed) be valid in any important reading systems?

[artbyrt]

However, Bookshelf does not fully support a11y for rich-media EPUB3 content (see attached summary chart:) VitalSource Bookshelf this is a proprietary educational reading system and I think that I did not have sufficient permissions to access it’s full functionality; it failed in numerous ‘a11y’ tasks Test Using VoiceOver (I did not have access to any keyboard commands; the system began at the top and continued) • does call out <ul> as ‘list’ or ‘group’ • did read the contents of ‘alt’ attribute • did read out the aria-labelledby text for video and diagram • there was no ‘a11y’ button for instantiation of video or audio • there were no call outs for ‘image’; the ‘alt’ text was read as if it were part of the ‘body’ content text Tests for support appearance of XHTML5 and CSS captions disappear, if the video is opened to full-screen (these tests were conducted as part of submission for thesis exploration of EPUB3 as digital alternative to print - 2016)

…

On May 28, 2017, at 6:45 AM, teytag ***@***.***> wrote: hi @rickj <https://github.com/rickj> Thank you for reminding me of the Bookshelf reading system. There may not be a technical problem in reading systems that display browsing behavior. But will this new CSS technique (-epub-bleed) be valid in any important reading systems? <https://cloud.githubusercontent.com/assets/6927098/26528096/7167a7f2-43ab-11e7-9efd-f112f99ca04d.png> <https://cloud.githubusercontent.com/assets/6927098/26528097/76ac1cd4-43ab-11e7-98a7-1c181acb935f.png> <https://cloud.githubusercontent.com/assets/6927098/26528098/77461726-43ab-11e7-88f4-3f997ef5baa1.png> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMwGgJ8mXoL5psc5K5A8zhLmLwd3lSjOks5r-VBHgaJpZM4NffWP>.

[dauwhe]

But will this new CSS technique (-epub-bleed) be valid in any important reading systems?

We are a long, long way from that. We're just exploring solutions to a common problem right now. The solution may be entirely different, or reading systems may not want to implement anything. This is just the brainstorming phase :)

[teytag]

Yes, This is just the brainstorming phase :) In the future a third render option can be created. (Fixed, reflowable,?)

[JayPanoz]

Took a quick look at the wiki and some first-sight remarks.

Bleeds

.full-page {
  height: 100vh;
}

One should note 100vh has been problematic on mobile, especially because of browsers’ chrome.

In practice, I’m currently using an arbitrary 99vh in reflow because 100vh tends to overflow on the next page in a lot of RS, even with box-sizing: border-box. Sure this would be “another context” but I guess it would be a lot easier to get rid of that and let RS developers deal with the height when -epub-bleed is used. Or maybe set the rule that -epub-bleed overrides it so that it can serve as a fallback (because we’ll need one).

what happens when the image doesn't exactly fit the screen? Aspect ratio must be preserved (always?)

The easiest solution probably lies in object-fit (cover, contain, scale-down, etc.) on the authors’ side (and perhaps on the RS’ side as well). It’s not currently supported in EdgeHTML but development has started.

controls for both vertical and horizontal alignment?

object-position should do the trick as well. Again, just thinking about what CSS currently has to offer for dealing with this.

idea of page float necessary for text to continue normally before/after image; otherwise there could be huge gaps before image

Already kind of possible with a good old float in current RSs, but can impact pagination in awful ways, especially when CSS multicol is used—the spec/implementations probably need updating by the way, since it is very hostile to modern layout specs (flexbox, grid, etc.). I’ve found a bunch of nasty bugs lately and it seems to me this is becoming a real huge barrier which makes evolution super painful.

My biggest concern is about the following though:

EPUB reading systems typically display author content inside a div or frame, with unknown styling applied both outside and inside the frame.

As I can see it, from the outside, it’s either implementing the stuff using awful hacks to make it happen or “refactoring” the RS to accommodate it. But I’m no RS dev so maybe I’m wrong.

To be honest, it’s very difficult for me to imagine Apple (for instance) doing the latter since it looks like they’re not even willing to fix their implementation for media queries (it’s been 2 and a half year the issue is open).

Overrides

no author styles for html and body elements?

I’m kinda cool with the idea Reading Systems may ignore some “layout” styles if needed (margins, padding and stuff) but how do you build a solid cascade if you can’t style body and let that to RSs? All of a sudden you have to use bloated selectors or add styles to an awful amount of elements, which might even worsen the overrides and user settings issues to some extent.

no !important in author CSS?

Authors will simply overqualify selectors or use obscure proprietary CSS props to get around this limitation—it is already the case because !important doesn't work. Or worse, inline styling. Maybe even an "!important-in-JS" apocalypse.

best practices for units (a common problem is for margins in ems causing massive problems on small screens)

Fundamental problem as well, I think.

You can't make any assumption about the RS config. px fails because for some reason Amazon Kindle or android apps have a viewport in physical pixels (and not @ 2x or @ 3x), % may become huge depending on the container (which can almost be the size of the screen) or play not very nicely with outside list-type for instance.

For the record, I tried to hack my way at some point, the idea was to get decreasing/increasing horizontal margins depending on the current font-size.

And yeah I know you could probably abuse max-width, margin-left: auto and padding-left (to emulate a min-margin-left) but you’re still dealing with px or %.

what about resets and frameworks like Blitz

[Disclaimer: For those of you who do not know, I created and designed Blitz.]

Obviously, it doesn’t solve all of the authors’ nor Reading Systems’ problems. It just makes it more predictable for authors, on their side.

Once you throw the CSS in a RS, nasty stuff can happen so we tried to make it compatible with a selection of Reading Systems, which basically translates to “it doesn’t break shit in there” (especially user settings).

metadata to request that RS not override ebook styles?

I’ve already shared my fear about that a few months ago but I can see authoring software declaring this metadata by default and then RS just ignoring it—or even not implementing it in the first place because they can foresee the abuse.

To be honest, if I were a RS developer, I would refuse to implement it until some popular authoring solutions fix their CSS output. Maybe this is opinionated but in practice, this is the root of one evil.

I’ve been wondering if this complex issue can be fixed for months now. Unless authors and RSs share a set of building blocks somehow “à la AMP”, which could be entirely overridable, I must admit don’t see how.

[JayPanoz]

Actually, the more I think about it, the more I am convinced having a real fragmentation model is a prerequisite to -epub-bleed.

Is there any hope to “involve” Microsoft in this, especially as they’re now supporting EPUB in MS Edge? As far as I can tell, @gregwhitworth has been repeatedly expressing an interest in reviving and improving regions.

[teytag]

hi @rickj
Bookshelf does not support RS detect script (navigator.epubReadingSystem). But Readium and iBooks support this script. EPUB Reading System detect script is very important than UA (navigator.userAgent) to create the dynamic CSS. teytag test EPUB3 -> http://www.teyid.org/testet/#05032014

[rickj]

Bookshelf does not support RS detect script (navigator.epubReadingSystem). But Readium and iBooks support this script. EPUB Reading System detect script is very important than UA (navigator.userAgent) to create the dynamic CSS. teytag test EPUB3 -> http://www.teyid.org/testet/#05032014

Yeah, that’s a known bug with our native clients. We actually DO support that API. But if you call it before the reading system object is actually set up (which happens on page load when we initialize our scripting) then you won’t find it, because of course it isn’t there yet. So the problem here is you are trying to call it on page load, too, and our object just isn’t set up yet.

If you had a button in the page that called rsDetect() and pressed it, it would work because it would be getting called later.

For our browser client we have a custom event that tells people that our JavaScript is still initializing.

[teytag]

Hi @rickj
Thanks for info. I did revision it and test. Perfect!...
Test epub -> http://www.teyid.org/testet/#05032014

[nekennedy]

@teytag: The ability to have a mixed-rendition document (where the rendition declared in the OPF is overridden by an optional property on the itemref in the spine) existed in the 3.1 spec:
https://w3c.github.io/publ-epub-revision/epub31/spec/epub-packages.html#layout-property-flow-overrides

I know it was implemented by some systems, but broke pretty badly on others:
http://epubtest.org/testsuite/epub3/feature/spine-override/ (I know epubtest is out of date 😞 )
(Round of applause for those that implemented it!)

Working with reading systems to get this existing properly implemented is one potential way of solving this issue. I feel that if our primary goal is full bleed images, fully implementing spine overrides might not be the most efficient way to get there (although I don't write reading systems, that's pure conjecture on my part).

[jacqueslelezard]

Hi all,

Just to summarize a few things that we said in the public-epub3@w3.org mail list:

• image bleed in an interesting feature since it allows more creative layout
• however we could go further and think generic by adding a property which tell the reading system to get ride of the automatic margin.
• During the EPUB 3.1 revision cycle there was a discussion about some kind of "leave me alone" (aka LMA) property, like it is already the case for fixed layout.
• Perhaps this is analogous to a full-screen mode in a browser: we aren't styling content, just requesting that all available space be provided to the content.

Then about "will reading systems accept this" I think we can produce some samples which clearly show the potential of such a feature (for example: https://andrewgribben.github.io/publ-cg ).

Elie

[JayPanoz]

Naïve question: is there any possibility to build from bleed in CSS Paged Media Module Level 3.

I mean, we’ve always been more or less at the juncture between paged and screen medias so maybe it’s time paged media takes EPUB into account?

[dauwhe]

Naïve question: is there any possibility to build from bleed in CSS Paged Media Module Level 3.

I mean, we’ve always been more or less at the juncture between paged and screen medias so maybe it’s time paged media takes EPUB into account?

I think the term "bleed" is somewhat unfortunate here. It's a natural way to speak for people from a print background. Books are printed on giant sheets of paper larger than the final book, and then trimmed to size. So an image needs to extend a short distance beyond the edge of the "page" so that, when trimmed, there won't be an ugly sliver of white. Those giant knives aren't always as accurate as one would hope.

I don't think we can do the same thing as CSS Pages does here. In CSS Pages, "bleed" essentially extends the area that will be rendered past the official page boundary by an author-determined distance.

What we want here is more complicated, since we don't know anything about the environment the EPUB will be displayed in. The authored content of an epub is generally rendered in some sort of frame that occupies only part of the device viewport. We want to use all of the viewport. But we don't know anything about the surrounding code (including whether it's HTML).

So maybe this is much closer to requesting fullscreen display than anything related to CSS, as @jacqueslelezard mentioned above.

[JayPanoz]

I think the term "bleed" is somewhat unfortunate here.

Right, this is kind of implied by the dependence of the auto value on the marks property. And although it doesn’t solve the frame issue, was just wondering if some Reading Systems could be open to managing the values automatically via some -epub-keywords for instance, especially if they’ve already implemented @page, because they manage the environment and have the values needed—assumption that should be confirmed though, because I do think you can’t design well with assumptions.

requesting fullscreen display.

Would it imply scroll? Or paginated?

At first sight it seems to me we’re lacking some important pieces for the latter: how do you set margins for pages that shouldn’t be full-bleed? how do you manage “pages” in the first place, etc.

Sorry to be that guy but the only full-bleed implementation I know of in reflow is “Kindle in Motion”, and it looks like they had to polyfill their own fragmentation model to make it work—which is just an educated guess based on what I know about KFX and their Reader but it looks like they’re using iframes as regions, in which they append contents dynamically.

Also, they had to (momentarily?) give up on reading modes (night/sepia/etc.), which is critical—a11y issue—, and two-up view, which is probably not → “In case of conflict, consider users over authors over implementers over specifiers over theoretical purity.”

[JayPanoz]

Just became aware that perhaps as a clarification, I should admit I’m eager to find “small wins” whenever possible, because non-implem of features/modules has been painful to deal with from the authors’ side—whichever the reason why they were not implemented, but I believe this is also why discussing with Reading Systems is critical.

Also, it seems to me that more globally, there’s been a lot of features/specs “relying on browsers” lately and, as an author, I’m super happy about it because I don’t have to deal with a huge mess anymore. Just think about flexbox (e.g. flex: 1 1 auto) and grid (grid-auto-*, auto-fit and auto-fill, minmax() etc.).

The more I can rely on rendering engines, the better, because I don’t want to waste my life hacking things.

Probably one issue with -epub-bleed is that it’s EPUB-specific, as the prefix tend to imply. Now, considering vh has been an issue on mobile, what about a global bleed property (or whatever since bleed is already spec’ed in paginated media) to solve that issue, especially as my understanding is “we won’t develop EPUB-only CSS specs”. Web designers/developers could possibly welcome such a feature although they’re dealing with it in JS currently. And then it’s up to Reading Systems to deal with it in paginated environments.

The more I think about it, the more the fullscreen display request sounds to me as a more global setting, possibly also related to rendition: flow in some way. Let’s say a balance between reflow and FXL (like FXL but with user settings). But it’s definitely not just about full-bleed.

[dualpixel]

Panoz, This way bellow sounds me very interesting. Mainly if there is a intention to mixing reflow and FXL layouts ePUBs The more I think about it, the more the fullscreen display request sounds to me as a more global setting, possibly also related to rendition: flow in some way. Let’s say a balance between reflow and FXL (like FXL but with user settings). But it’s definitely not just about full-bleed. Regards <http://www.dualpixel.com.br/> 2017-06-07 15:26 GMT-03:00 Jiminy Panoz <notifications@github.com>:

…

Just became aware that perhaps as a clarification, I should admit I’m eager to find “small wins” whenever possible, because non-implem of features/modules has been painful to deal with from the authors’ side—whichever the reason why they were not implemented, but I believe this is also why discussing with Reading Systems is critical. Also, it seems to me that more globally, there’s been a lot of features/specs “relying on browsers” lately and, as an author, I’m super happy about it because I don’t have to deal with a huge mess anymore. Just think about flexbox (e.g. flex: 1 1 auto) and grid (grid-auto-*, auto-fit and auto-fill, minmax() etc.). The more I can rely on rendering engines, the better, because I don’t want to waste my life hacking things. Probably one issue with -epub-bleed is that it’s EPUB-specific, as the prefix tend to imply. Now, considering vh has been an issue on mobile, what about a global bleed property (or whatever since bleed is already spec’ed in paginated media) to solve that issue, especially as my understanding is “we won’t develop EPUB-only CSS specs” <#11 (comment)>. Web designers/developers could possibly welcome such a feature although they’re dealing with it in JS currently. And then it’s up to Reading Systems to deal with it in paginated environments. The more I think about it, the more the fullscreen display request sounds to me as a more global setting, possibly also related to rendition: flow in some way. Let’s say a balance between reflow and FXL (like FXL but with user settings). But it’s definitely not just about full-bleed. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AbI7Ie3D6kt9g591OGuPHivqIDWURA9Vks5sButJgaJpZM4NffWP> .

[bobbytung]

In Japan, they have an recommend EPUB3 template to authoring service provider:

As I know, several reading systems in Japan support FXL pages in a reflow EPUB that follow EPUB 3 spec. Illustration between chapters or manga as a chapter to show whole page picture in this way.

But there are still illustration inline, they use class as follow:

.fit {
display:            inline-block;
page-break-inside:  avoid;
max-height:         100%;
max-width:          100%;
}

it's not working ideally because a few line text will appear in same page when screen aspect ratio vary.

I'll post this issue on Japanese ebook community to let them know and participate in.

[murata2makoto]

I did not know this feature in the EBPAJ guideline, but Bobby is very right.

[rickj]

@teytag To let you (and others) know, the loading issue is fixed in the current dev builds for Bookshelf, and will be released with updates coming on on the platforms later in the year.

[JayPanoz]

FWIW, it looks like the biggest “issue” is RSs’ implementations so getting RS devs to discuss this is probably critical. Just trying to be pragmatic there, because RS devs have other super important issues such as performance—especially on mobile—, ease of implementation—which may heavily depend on rendering engines/webviews—, multi-platform implems, etc.

More generally, it seems to me this type of features belongs to “paged media” (especially page templates). Maybe that should be the top priority (and such features mere details/parts), maybe I'm wrong but there are negative signals out there.

Chrome has been gathering data for -webkit-paged-x|y since March, in case they want to deprecate and remove it at some point. It relies on the multicolumn implementation BTW so you might think it doesn’t bloat Chrome that much… but they’ve been aggressively removing stuff which impacts performance in the source code for a while.

Maybe there could also be some works on columns. The specs’ and implementations’ limitations are notorious, nth-column isn’t a thing yet, column-span is all or nothing… It’s not like Opera showed there could be useful additions in 2012 and I just can’t understand why the multicol spec has been neglected for so long, especially as it is used for overflow: paged-x|y in webkit, and a lot of Reading Systems are using them to fake pagination. Also, it could ship with a JS API to make things a lot simpler (column count, etc.) Having some progress there could at least help in the short/mid term.

[toshiakikoike]

I'm posting a sample of FXL pages (images) in a reflow EPUB.

In Japan there is a genre of books in which illustrations are important, called "light novels".
Illustrations are expected to be displayed full screen, and as a double-page spread.

Here is a sample:
https://github.com/toshiakikoike/epub_file/tree/master/reflow_fxl
https://github.com/toshiakikoike/epub_file/blob/master/reflow_fxl.epub

The 2nd[*1] and 3rd[*2] pages are expected to be displayed as a double-page spread, without a gap in the center.
[*1] displaying image file "Right Page"
[*2] displaying image file "Left Page"

SVG is used to display the image full screen.
In the OPF, each page is specified in <spine> as follows:
<itemref idref="XHTML0002" properties="rendition:layout-pre-paginated page-spread-right" /> <itemref idref="XHTML0003" properties="rendition:layout-pre-paginated page-spread-left" />

Unfortunately, this sample is displayed as intended only in limited environments, such as Sony Reader[*3].
[*3] how its displayed: https://github.com/toshiakikoike/epub_file/tree/master/reflow_fxl_rendering_by_sonyreader

Otherwise the pages are displayed split, often with a margin in-between.

[laudrain]

This sample is displayed as intended in Readium Chrome extension too !

[danielweck]

@toshiakikoike thank you. Here is a direct Readium link (web/cloud reader): https://readium.firebaseapp.com/?epub=https%3A%2F%2Frawgit.com%2Ftoshiakikoike%2Fepub_file%2Fmaster%2Freflow_fxl%2F

[JayPanoz]

@dauwhe You might want to clarify page/screen by the way, because spread is not currently addressed in the wiki. I’m not sure you want a portrait image going full-bleed in a two-page spread config.