search

w3c / publ-cg

EPUB 3 Community Group Repository
Other
44 stars 16 forks source link

Design feature to allow image bleed in reflowable epub #3

Open dauwhe opened 7 years ago

dauwhe commented 7 years ago

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 commented 7 years ago

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 -> https://github.com/dvschultz/99problems/issues/32 https://github.com/dvschultz/99problems/issues/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 notifications@github.com 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 https://github.com/w3c/pub-cg/issues/3, or mute the thread https://github.com/notifications/unsubscribe-auth/AGmy-habtCF-x5pmm5ERtYAIWX3r8rJuks5r7HGQgaJpZM4NffWP.

teytag commented 7 years ago

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?

rs4 rs3 rs2 rs1

rickj commented 7 years ago

@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 commented 7 years ago

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?

screen shot 2017-05-28 at 1 21 43 pm screen shot 2017-05-28 at 1 38 42 pm screen shot 2017-05-28 at 1 38 24 pm

artbyrt commented 7 years ago

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

dauwhe commented 7 years ago

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 commented 7 years ago

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

JayPanoz commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

screen shot 2017-06-02 at 12 25 09 pm screen shot 2017-06-02 at 12 25 36 pm screen shot 2017-06-02 at 12 26 17 pm screen shot 2017-06-02 at 12 32 38 pm screen shot 2017-06-02 at 12 32 55 pm

rickj commented 7 years ago

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 commented 7 years ago

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

screen shot 2017-06-02 at 8 32 21 pm

nekennedy commented 7 years ago

@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 commented 7 years ago

Hi all,

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

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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” https://github.com/w3c/publ-cg/issues/11#issuecomment-306828550. 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 https://github.com/w3c/publ-cg/issues/3#issuecomment-306883377, or mute the thread https://github.com/notifications/unsubscribe-auth/AbI7Ie3D6kt9g591OGuPHivqIDWURA9Vks5sButJgaJpZM4NffWP .

bobbytung commented 7 years ago

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 commented 7 years ago

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

rickj commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

danielweck commented 7 years ago

@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 commented 7 years ago

@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.