23:39:11 <RRSAgent> RRSAgent has joined #epub
23:39:11 <RRSAgent> logging to https://www.w3.org/2021/05/27-epub-irc
23:39:13 <Zakim> RRSAgent, make logs Public
23:39:14 <Zakim> please title this meeting ("meeting: ..."), dauwhe
23:39:28 <dauwhe> Meeting: EPUB 3 Working Group Virtual F2F, Day One
23:39:31 <dauwhe> chair: dauwhe
23:39:38 <dauwhe> chair: wendyreid
23:42:55 <dauwhe> present+
23:43:52 <wendyreid> present+
23:58:05 <rkuroda> rkuroda has joined #epub
23:58:42 <BenSchroeter> BenSchroeter has joined #epub
23:59:06 <MasakazuKitahara> MasakazuKitahara has joined #epub
23:59:12 <MasakazuKitahara> present+
23:59:23 <MattChan> MattChan has joined #epub
23:59:28 <shiestyle> shiestyle has joined #epub
23:59:43 <zheng_xu> zheng_xu has joined #epub
00:00:01 <BenSchroeter> present+
00:00:08 <MattChan> present+
00:00:22 <zheng_xu> present+
00:01:09 <duga> duga has joined #epub
00:01:15 <duga> present+
00:02:10 <shiestyle> present+
00:02:47 <duga> scribe+
00:03:00 <MattChan> scribe+
00:03:02 <dlazin> dlazin has joined #epub
00:03:08 <dlazin> present+
00:04:22 <duga> dauwhe: First up satellite specs
00:04:44 <marisa> marisa has joined #epub
00:04:45 <dauwhe> https://w3c.github.io/publ-cg/
00:05:09 <duga> wendyreid: We have a long tail of specs
00:05:14 <marisa> present+
00:05:45 <duga> ... Some we have discussed, eg multiple renditions, a11y, cfi
00:05:52 <duga> ... Some we have not discussed
00:06:03 <duga> ... We should figure out the fate of these docs
00:06:19 <duga> ... Currently they are in the archives, and will always be there regardless of what we decide
00:06:26 <dauwhe> Zakim, who is here?
00:06:26 <Zakim> Present: dauwhe, wendyreid, MasakazuKitahara, BenSchroeter, MattChan, zheng_xu, duga, shiestyle, dlazin, marisa
00:06:28 <Zakim> On IRC I see marisa, dlazin, duga, zheng_xu, shiestyle, MattChan, MasakazuKitahara, BenSchroeter, rkuroda, RRSAgent, Zakim, dauwhe, AramZS, wendyreid, tzviya, github-bot,
00:06:28 <Zakim> ... join_subline
00:06:40 <duga> ... Some are now moved to notes because we are discussing them
00:07:08 <duga> ... What do we do with the ones that we have yet to pull in?
00:07:22 <duga> ... Could be leave them alone, could be to pull them all in
00:07:38 <dauwhe> q+
00:07:50 <duga> ... personally, think we should only pull in the ones we plan to change/discuss, otherwise leave them alone
00:07:53 <wendyreid> ack dauwhe
00:07:56 <dlazin> q+
00:08:02 <duga> ... If we leave them, they continue to exist but are not w3c docs
00:08:18 <duga> dauwhe: We have an obligation to inform people which of these are viable
00:08:26 <duga> ... Most of them are *not*
00:08:57 <duga> ... If you make an epub against one these specs, you will waste time since they are not implemented
00:09:04 <wendyreid> ack dlazin
00:09:05 <dauwhe> ack dl
00:09:24 <duga> dlazin: Question about what we have pulled in. Looks like about 8
00:09:39 <duga> ... Not clear what we are trying to do with them from a w3c specs perspective
00:09:52 <dauwhe> q?
00:09:59 <duga> wendyreid: All docs that are currently notes are not on the rec track
00:10:21 <duga> ... They never have to become recs. The ones on the rec track are going through the rec process
00:10:40 <duga> ... Notes can be elevated, eg CFI could move to rec track
00:10:44 <duga> q+
00:10:49 <wendyreid> ack duga
00:10:58 <MattChan> duga: is it easy to make something a note?
00:11:21 <MattChan> ... so it doesn't hurt us to leave something where it is, right?
00:11:23 <MattChan> wendyreid: yes
00:11:39 <dlazin> q+
00:11:49 <MattChan> duga: does leaving them in the archive achieve the end of signifying that these are dead?
00:12:01 <MattChan> dauwhe: i was thinking of something more than that
00:12:08 <MattChan> ... especially with stuff like EDUPUB
00:12:33 <wendyreid> ack dlazin
00:12:44 <duga> dlazin: I do want consistency and clarity
00:13:21 <duga> ... It's unclear if something is in an archive to muddle through the history and figure out if it is supported
00:13:29 <dauwhe> q+
00:14:17 <duga> ... Fragmentation is bad, we should consider the user and pull in everything we think might be alive and add a note to the clearly dead ones
00:14:32 <wendyreid> ack dauwhe
00:14:36 <wendyreid> +1
00:14:36 <duga> ... Aim for being as tidy and helpful to new users as possible
00:14:49 <duga> dauwhe: Strongly agree
00:15:33 <duga> ... It is easier to change things in w3c web space, as opposed to IDPF web space
00:16:18 <duga> ... Feel more comfortable if we made the w3c stewardship more obvious
00:17:03 <duga> ... Might be good to point to w3c from idpf page, then pull in all specs as notes, with a specific comment about status
00:17:31 <duga> wendyreid: A single change that says "all docs are moved to www.xxx.yyy" is easier than lots of changes
00:17:57 <duga> dauwhe: Even the IDPF home page isn't that clear that it is over
00:18:37 <duga> ... Would like to get a feel from the WG what the general principles are
00:18:59 <duga> ... then on chairs calls we can decide on specifics, since there is a lot of w3c admin stuff
00:19:16 <duga> wendyreid: Question for the group, what do we think the best direction is?
00:19:25 <dauwhe> q?
00:19:54 <duga> ... Migrate all to w3c space with updates with disclaimer at IDPF, OR do we leave them in IDPF space?
00:20:13 <duga> ... Currently epub search goes to w3c
00:20:53 <duga> wendyreid: Of the current list, migrated are 3.3, 3.2, a11y, multiple renditions, and CFI
00:21:00 <duga> ... all are note or rec track
00:21:32 <duga> ... not moved are legacy (3.1, etc) and a whole bunch of docs we all forgot about
00:23:05 <duga> dauwhe: Scriptable components never really implemented, Adaptive stuff was too CSSy
00:23:13 <duga> q+
00:23:41 <MattChan> duga: Google implemented a bunch of these satellite specs
00:24:10 <wendyreid> ack duga
00:24:17 <MattChan> s/Google/Softpress(?)
00:24:47 <duga> wendyreid: Criteria is, will we use it?
00:25:28 <duga> ... we could pull them all in and add a deprecation note
00:25:44 <duga> dauwhe: Pull over if we need it makes sense and it is less work overall
00:26:19 <duga> ... but batch change might make it clearer in the idpf site
00:26:34 <duga> q+
00:27:10 <dauwhe> ack du
00:27:11 <MattChan> duga: i'm leaning towards pulling everything in, and adding deprecation notice
00:27:22 <MattChan> ... because right now its not clear who owns these specs now
00:27:41 <MattChan> ... on the other hand, this could clutter up W3C notes
00:27:47 <duga> dauwhe: I agree
00:28:33 <duga> wendyreid: No matter what, there will be a note saying it is a dead spec
00:28:52 <duga> ... Real question is do we want to do it at w3c or idpf
00:29:14 <duga> ... logistical question is where it is easiest/best to do it?
00:29:32 <duga> ... takeaway is go to Ivan and see what is easiest
00:29:50 <duga> dauwhe: Makes sense, we have an end in mind, need to talk to Ivan and Matt about the means
00:29:58 <duga> wendyreid: Next topic?
00:30:19 <dauwhe> https://github.com/w3c/epub-specs/issues/1464
00:31:02 <duga> dauwhe: When writing some spec tests, one of the foundational aspects is a core media type
00:31:11 <duga> ... ie something that does not need a fallback
00:31:31 <duga> ... so manifest fallbacks are also foundational
00:31:54 <duga> ... Wrote some fanciful tests with docbook, binary files, etc
00:32:08 <duga> ... NO reading system implemented manifest fallbacks
00:32:30 <duga> ... Some of the behavior was not ideal for the end user
00:33:04 <duga> ... for instance a .dmg file was downloaded to the local system [Scribe note: !!!]
00:33:26 <duga> ... Looks like everyone just throws it at a webview and let the webview handle it
00:33:44 <duga> ... Even Readium doesn't handle them
00:34:02 <dauwhe> q?
00:34:08 <duga> ... What are the implications of a core RS feature not working in the real world
00:34:12 <shiestyle> q+
00:34:20 <wendyreid> ack shiestyle
00:34:36 <duga> shiestyle: In Japan, in some cases manifest fallback is implemented, but may be domain specific
00:34:52 <duga> ... Would like to discuss with Voyager people in Japanese
00:35:00 <duga> ... [Japanese]
00:36:20 <duga> MasakazuKitahara: [via shiestyle] Voyagers RS does not support this in RSes, but in some places we do use the feature in Japan
00:37:18 <MattChan> duga: we have two pipelines at Google, 1 for publishers, and 1 for people sideloading
00:37:33 <MattChan> ... the 1 for publishers is better for support for this type of thing
00:37:49 <duga> wendyreid: Don't think it is supported by Kobo
00:38:33 <MattChan> duga: dauwhe can you make your sample epubs available?
00:38:37 <dauwhe> q?
00:38:41 <MattChan> dauwhe: yes, i'll let you know where
00:39:11 <duga> dlazin: I have some tests that are not checked in, because I don't know what the proper behavior is supposed to be
00:39:33 <duga> ... Do we need a graveyard for these sorts of things? Since I can't set the "does it pass" field
00:39:52 <duga> dauwhe: The tests are great, as it points to where we should be investigating
00:40:56 <duga> ... Seems like a case I would like more semi official information on what RSes support/claim to support with regard to manifest fallbacks
00:41:09 <duga> ... If no one implements it, we need to have hard conversations
00:41:17 <wendyreid> q+
00:41:21 <dauwhe> ack we
00:41:22 <duga> ... If there aren't implementations we need to remove it
00:41:34 <duga> ... But need to keep concept of core media type
00:41:51 <duga> wendyreid: Since we now have several tests without clear passes
00:42:12 <rkuroda_> rkuroda_ has joined #epub
00:42:12 <duga> ... Does it make sense to make a list and send the tests out to the community pre-CR
00:42:35 <duga> ... Typically this is done during CR phase, but would be good to know where we are in trouble
00:42:42 <duga> q+
00:42:54 <rkuroda_> rkuroda_ has left #epub
00:43:13 <duga> dlazin: To pursue, in my test sheet, I have some blank cells so we can add notes there
00:43:23 <duga> ... Can use that as a way to corral a list
00:43:26 <dauwhe> ack du
00:43:28 <rkuroda__> rkuroda__ has joined #epub
00:44:05 <MattChan> duga: this sounds like a problem, but if nobody has implemented manifest fallbacks, then maybe we just say that you can only use core media types in the spine, period
00:44:16 <duga> dauwhe: Part of this is how epub has changed over time
00:44:34 <duga> ... used to have the idea of general epub container, but that is not what really happened
00:45:17 <duga> ... Have several next steps to gather info and look into hard to test tests
00:45:26 <duga> ... Have enough useful take aways
00:45:48 <duga> BenSchroeter: Where did we leave the first conversation?
00:46:09 <duga> dauwhe: We have the goal of communicating the status, but where to do that is still an open question
00:46:28 <duga> ... Will check with Ivan and Matt to figure out the best path forward
00:47:02 <duga> dauwhe: Break now?
00:47:05 <duga> wendyreid: Yes!
00:47:13 <duga> dauwhe: Brady can eat dinner
00:47:29 <duga> wendyreid: Will reconvene at the upcoming whole hour
01:02:08 <dauwhe> https://github.com/w3c/epub-specs/issues/636
01:02:13 <MattChan> TOPIC: HTML Serialization
01:03:17 <MattChan> dauwhe: i've made epubs that have used HTML that was not well-formed XHTML
01:03:20 <MattChan> ... sometimes it works
01:04:01 <MattChan> ... but we hear that RS is sometimes built using XML toolchains, and would have to be reworked if they can't expect well-formed XHTML
01:04:31 <MattChan> ... there are arguments in favor, but I have not felt large support from authors, publishers, or RS
01:04:31 <dauwhe> q?
01:04:35 <duga> q+
01:04:40 <dauwhe> ack du
01:04:50 <Garth> Garth has joined #epub
01:05:03 <MattChan> duga: sounds like a lot of work, so maybe we should wait until there is need for it
01:05:04 <dauwhe> q?
01:06:02 <MattChan> dauwhe: in my mind epub 4 doesn't have to worry about backwards compat with epub 3, chief among which is support for XHTML
01:06:17 <dauwhe> q?
01:06:19 <shiestyle> q+
01:06:58 <MattChan> shiestyle: i have no objection, but we have to consider compatibility with existing epubs
01:07:12 <MattChan> ... so we must differentiate between HTML5 epub and XHTML5
01:07:38 <MattChan> ... now might be a good time to start talking about how spec would have to change
01:07:59 <MattChan> dauwhe: we would never mandate a change to HTML5
01:08:16 <dauwhe> ack sh
01:08:18 <MattChan> ... compat issues would arise where people begin to try to open new HTML5 epubs in older RSes
01:08:29 <MattChan> ... has Kobo looked into this?
01:08:48 <MattChan> wendyreid: when I looked into it I specifically talked to ingestion side (where most of the problems would pop up)
01:08:56 <MattChan> ... they said it probably wouldn't be too bad
01:09:07 <dauwhe> https://github.com/w3c/epub-specs/issues/636#issuecomment-849726220
01:09:14 <MattChan> ... we'd have to add in new libraries for parsing HTML, and maybe do some additional validation
01:09:20 <MattChan> ... not impossible, but work would be involved
01:09:42 <MattChan> ... agree that we might have to identify HTML5 epubs separately
01:10:01 <MattChan> ... speaking for Kobo, we have a long tail for device support
01:10:29 <MattChan> dauwhe: comment from Daniel Weck was that Readium would experience several issues if we did this
01:10:55 <MattChan> ... also issue with epub:type, given that it is namespaced, it won't carry over to HTML serialization
01:10:58 <dauwhe> q?
01:11:31 <MattChan> ... another issue was about CFI, which uses a very Xpath like syntax to point to places in XML files
01:11:41 <MattChan> ... concern that that might break in HTML serialization
01:11:58 <duga> q+
01:12:04 <MattChan> ... but it might break in XHTML serialization too (e.g. parser inserting tbody element)
01:12:17 <dauwhe> ack du
01:12:26 <MattChan> s/tbody element/tbody element into the DOM
01:12:39 <MattChan> duga: CFI was intended to work with the text, not with the DOM
01:12:45 <MattChan> ... so yes, that issue could arise
01:14:12 <dauwhe> q?
01:15:06 <MattChan> duga: this is a hard topic because of how much work would be involved, and the lack of a clear reason to do it, especially vs all the other features we could be working on
01:16:30 <MattChan> dauwhe: the other argument that has been put forward for HTML is that HTML tools could be used, but i've never seen an example of one that works on HTML and breaks on XHTML
01:17:07 <wendyreid> Proposed: Defer HTML serialization to EPUB 4, close issue 636
01:17:47 <MattChan> duga: if we're deferring, should it be closed?
01:18:09 <duga> +1
01:18:11 <shiestyle> +1
01:18:14 <wendyreid> +1
01:18:14 <MasakazuKitahara> +1
01:18:16 <BenSchroeter> +1
01:18:19 <MattChan> wendyreid: i think the idea for epub 4 is that we start with clean slate
01:18:22 <dauwhe> <plus one>
01:18:25 <MattChan> +1
01:18:26 <marisa> +1
01:18:59 <MattChan> wendyreid: not resolved yet. Will return to this with tomorrow's group.
01:20:03 <dauwhe> https://github.com/w3c/epub-specs/issues/1061
01:20:18 <MattChan> TOPIC: iframes and external content
01:20:42 <MattChan> dauwhe: example would be embedding youtube video in iframe
01:20:54 <MattChan> ... right now epub doesn't like this
01:21:06 <zheng_xu> zheng_xu has joined #epub
01:21:39 <MattChan> s/example would/example use case would
01:22:30 <MattChan> dauwhe: there are security issues here too
01:23:29 <MattChan> ... this issue was raised almost 3 years ago, but I haven't felt strong push for this from publishers, and I'm not sure why
01:23:47 <MattChan> BenSchroeter: i think publishers may be doing it already
01:24:16 <shiestyle> q+
01:24:19 <MattChan> dauwhe: i think there is a fairly high amount of epubs with video content in higher learning books
01:25:00 <MattChan> duga: but are those videos embedded in the epub, or a link to a youtube video that is supposed to open in a player?
01:25:21 <MattChan> ... from a security perspective, we disable networking in our webviews (at least on Android)
01:25:29 <MattChan> ... so this would be a fairly major change
01:25:41 <dauwhe> q?
01:25:42 <wendyreid> ack shiestyle
01:26:10 <MattChan> shiestyle: the epub spec should allow this external content, and RS should take care of making associated alerts to users
01:26:55 <MattChan> ... if we allow this sort of foreign resource, then RS should check this for users
01:27:32 <MattChan> ... the ability to have this sort of external content could be valuable to users, but for security reasons, RS should take care of the related risks
01:27:51 <MattChan> dauwhe: that puts a lot of burden on RS to evaluate every URL of this nature and try to figure out if it is safe or not
01:27:56 <duga> q+
01:28:21 <MattChan> shiestyle: the alert could just tell users that they are about to access a foreign resource, and that it may be dangerous
01:28:41 <wendyreid> q+
01:28:48 <MattChan> duga: users might be scared away by such alerts
01:29:08 <MattChan> ... and enabling network access means more than dealing with the linked URL
01:29:29 <MattChan> ... it could also present privacy issues in addition to the security issues
01:29:37 <MattChan> ... moreso if we also enable scripting
01:29:52 <dauwhe> ack du
01:30:02 <MattChan> ... authors could be trying to report all sorts of user behaviour
01:30:04 <dauwhe> ack we
01:30:12 <MattChan> wendyreid: agreed
01:30:17 <shiestyle> q+
01:30:37 <MattChan> ... we'd then have to address all of these issues in the security and privacy review
01:31:06 <MattChan> ... in issue Ken presented use cases, e.g. RS sending quiz results to a server somewhere
01:31:37 <MattChan> ... a valid use case, but also one which suggests an untold number of nefarious uses
01:32:16 <dauwhe> q?
01:32:21 <MattChan> ... within something like the VitalSource system, the user knows they can trust foreign resources also in the system
01:32:30 <dauwhe> ack shi
01:32:33 <MattChan> ... but the more generalized use cases are risky
01:33:02 <MattChan> shiestyle: how about adding features to RS to allow user to toggle whether to permit or deny things like foreign resources, scripting?
01:33:30 <MattChan> wendyreid: i think that's outside of scope. We can't tell RS how to handle privacy.
01:34:15 <MattChan> ... and sure, users could then choose to provide informed consent, but it presents an uncomfortable situation for both the user, and probably the publisher
01:34:42 <MattChan> duga: it also assumes that the user is legally able to give consent to whatever might happen
01:35:26 <MattChan> dauwhe: in some circles i've heard concern over how web handles this sort of issue today (e.g. ubiquitous cookie consent pop-ups)
01:35:59 <dauwhe> q?
01:36:05 <MattChan> ... but we will continue this discussion tomorrow. It doesn't feel like we are close to consensus right now. But we've raised good desires and concerns
01:36:40 <wendyreid> https://w3c.github.io/epub-specs/epub33/fxl-a11y/
01:36:40 <MattChan> TOPIC: Task Forces Update
01:36:47 <wendyreid> https://w3c.github.io/epub-specs/epub33/locators/
01:37:10 <MattChan> wendyreid: the TFs are both developing their own WG notes
01:37:47 <MattChan> ... the FXL a11y group is writing documentation to provide concrete guidance on how to produce more accessible FXL content
01:38:08 <MattChan> ... the link above will give you idea of structure and topics
01:38:24 <MattChan> ... the other TF is debating re-using CFI as a locating method
01:38:50 <MattChan> ... after a lot of discussion we've decided to pause, and put together a list of use cases to understand the problem space of locations in epub
01:39:16 <MattChan> ... and we're working towards potentially coming up with some sort of algorithm that creates segments within an epub that resemble pages but are not pages
01:39:59 <MattChan> ... i.e. a fallback location scheme should a pagelist not be provided (because epub is digital first and has no physical version, or they just left out pagelist to physical correspondence)
01:40:15 <MattChan> ... document will also have solutions for those use cases
01:40:26 <dauwhe> q+
01:40:29 <MattChan> ... might result in us recommending that we add something to spec, but we're not there yet
01:40:57 <MattChan> dauwhe: about that algorithm, would it be a script that use you on an epub? Or is it something that RS implements?
01:41:12 <MattChan> wendyreid: it would be script run by author, or maybe at distribution level
01:41:20 <MattChan> ... we want the locations to be as platform agnostic as possible
01:42:04 <MattChan> ... and we'd want to locations to be roughly identical to each other if the same book is distributed through various different platforms
01:42:20 <MattChan> dauwhe: is the FXL TF still working on the idea of alternate style sheets?
01:42:34 <MattChan> wendyreid: yes, and we have an explainer doc for that
01:42:44 <MattChan> ... but it is in very early stage of draft
01:43:09 <wendyreid> https://paper.dropbox.com/doc/Visual-to-Textual-Explainer--BLjK4236NIwnzgTMbvUWzaEKAg-K3nAwKn2vlVqRpFyZ9KHN
01:44:22 <MattChan> wendyreid: there are lots of a11y solutions for people who use AT to parse DOM, but not many solutions for low vision users
01:45:09 <MattChan> ... this proposal creates a method by which content creators can provide secondary style sheet for their FXL, that would allow compatible RS to switch reading mode from FXL to reflow
01:45:27 <MattChan> ... then user could change font size, font face, etc.
01:45:34 <MattChan> ... while preserving the reading order
01:45:47 <dauwhe> @media (-epub-prefers-reflow: reflow) {
01:45:47 <dauwhe>   /* styles for reflow */
01:45:47 <dauwhe>   @viewport { size: auto; }
01:45:49 <dauwhe>   body {
01:45:51 <dauwhe>   width: auto;
01:45:51 <MattChan> ... but there is still a lot to hash out
01:45:53 <dauwhe>   height: auto;
01:45:55 <dauwhe>   }
01:45:57 <dauwhe> p, div, h1, h2 {
01:45:59 <dauwhe> position: relative;
01:46:01 <dauwhe>  }
01:46:03 <dauwhe> }
01:46:16 <MattChan> ... one of the challenges we have is EUAA, which comes into force in 2025, and specifically states that content should be alterable by user
01:46:21 <duga> q+
01:46:31 <MattChan> ... under those requirements FXL would not pass as it is today
01:46:40 <wendyreid> ack dauwhe
01:46:43 <MattChan> ... lends additional importance to something like this
01:47:08 <MattChan> dauwhe: interesting, might be able to do link rel=alternate stylesheet
01:47:30 <MattChan> ... also media queries for user preferences (prefers dark scheme, prefers low motion)
01:47:37 <dauwhe> ack da
01:47:38 <wendyreid> ack duga
01:47:39 <dauwhe> ack d
01:47:47 <MattChan> ... so a lot of this might be able to be achieved using existing web technologies
01:48:16 <MattChan> duga: this is not legal advice from me nor my employer, but I think there is carveout in EUAA for content that cannot be reasonably modified to comply
01:48:34 <MattChan> ... e.g. a 1967 Spiderman comic book
01:48:54 <MattChan> wendyreid: right, like some kind of undue burden clause
01:49:05 <MattChan> ... one of the challenges is just the breadth of content that becomes FXL
01:49:21 <MattChan> ... e.g. novels that are FXLs
01:49:41 <MattChan> ... use cases like that will probably have a hard time bringing themselves within that carveout
01:51:18 <MattChan> ... this method will not work for all types of content, but for things like cookbook or textbook, where there is a lot of text alongside pictures, it could work
01:51:20 <duga> q+
01:51:23 <dauwhe> q?
01:51:27 <dauwhe> ack du
01:51:29 <wendyreid> ack duga
01:52:06 <dauwhe> q+
01:52:11 <MattChan> duga: it could work _really_ well for some books
01:52:18 <wendyreid> ack dauwhe
01:52:30 <MattChan> ... e.g. where publisher feels that layout is critical to the book, but reflow just makes it easier to read to end user
01:52:40 <MattChan> dauwhe: is there an issue where a spread extends across both pages?
01:53:31 <MattChan> wendyreid: i wonder if we're going to have to provide some sort of stitching hint
01:54:29 <MattChan> dauwhe: i see implementation issues with this
01:54:43 <MattChan> wendyreid: the other question was what to do with the images
01:55:12 <MattChan> ... in a particularly image heavy book, there might be a background image, with some images overlaid, and then a block of text too
01:55:28 <MattChan> ... so what happens if the background image is semantically relevant?
01:55:51 <MattChan> ... or what happens if a single image runs across the gutter in a spread?
01:56:15 <MattChan> ... might lose some of the meaning
01:57:24 <dauwhe> q?
01:58:17 <MattChan> dauwhe: we'll continue tomorrow
01:58:20 <dauwhe> zakim, end meeting
01:58:20 <Zakim> As of this point the attendees have been dauwhe, wendyreid, MasakazuKitahara, BenSchroeter, MattChan, zheng_xu, duga, shiestyle, dlazin, marisa
01:58:22 <Zakim> RRSAgent, please draft minutes
01:58:22 <RRSAgent> I have made the request to generate https://www.w3.org/2021/05/27-epub-minutes.html Zakim
01:58:25 <Zakim> I am happy to have been of service, dauwhe; please remember to excuse RRSAgent.  Goodbye
01:58:29 <Zakim> Zakim has left #epub
01:58:51 <dauwhe> RRSAgent: bye
01:58:51 <RRSAgent> I see no action items