Meeting minutes
TPAC Agenda https://github.com/w3c/epub-specs/discussions/2815#discussioncomment-14751130
Agenda for TPAC
Wendy Reid: I've put a link in the chat to a rough agenda, there are some openings.
Hadrien Gardeur: We will do a full hour on HTML in EPUB?
Wendy Reid: yes
… we are trying to push things that need more people to the afternoons because of the time differences
Shinya Takami: after the business group meaning the first time slot
… I propose Japanese session
… Japanese industry group is moved to DPXPA
… we have EPUB 3 Guidelines
… that we have been working on for 10 years. It will be released tomorrow
… I would like to present it then
… the business group could join the working group
Avneesh Singh: Pleases consider the accessibility schedule on the 10th
Wendy Reid: thank you for the reminder
Wendy Reid: feel free to comment on the discussion in Github if you have more suggestions
Images in Spine - w3c/epub-specs#2792
Wendy Reid: we've had a constellation of discussions about this
Brady Duga: what is the current proposal? Is it a PR or best practices
Hadrien Gardeur: we've had more discussion than proposal
… the proposal would be to add images to the spine, it would be a
… strong recommendation to provide image description
… in comics we know that people wrap images in html and it causes nothing but pain
… we know that browsers can show images without html
… so it would be better to align with the web
Matt Garrish: I wonder where we are with HTML in the spine
… these two seem bound together
… if we can't have html in the spine, how can we have images in the spine?
... won't it cause the same issues?
... can we make this call before we know how the industry thinks of this?
Hadrien Gardeur: I don't think these are necessarily connected since we are introducing a new kind of layout
… rolled documents will require support, so it isn't much more of a workload to support images
… we know that images have been used for quite a while, with fallbacks
Brady Duga: that is an important part of this proposal
… images in spine but only for rolled documents?
Hardrien: that is one possibility but we should consider fxl
Brady Duga: so if we open it up to fxl we are opening it up to reflowable documents as well
Shinya Takami: we should separate the discussion about rolled comics and images in spine
… for Japanese this is good, better for comic over all, rather than just for rolled comics
Wendy Reid: @duga is right. Additionally, people aren't good at reading the spec
… even if we limit images in spine to rolled documents people will use them where they want
… we should do it for all types of documents because we know that's how it will happen in practice.
… we've had discussions about full bleed images
… theoretically you could have fixed layout pages in a reflowable document
… this hasn't been seen often, but publishers have asked for it
… this is another avenue for images in spine
Dale Rogers: from a creator/publisher point of view, we want to be able to create one document for all reading systems
… I would like to know that one document can be created and RS will know what to do with it
Brady Duga: I both agree and disagree with Wendy Reid
… people will be putting images in the spine, and epub check will complain
… people will then just change doctype to roll
… so we will see images popping up in weird places
… I disagree that this is easier than doing fxl in the middle of a reflowable document
… I think there's lots of designs out there that mix those and it's not easy to do
… fxl is much better for full bleed images
… in the middle of a reflowable document an image could be made accessible
… I don't think its any easier to have images in the spine than having mixed modes
… I would love to hear from other RS representatives
… it would be great to hear from them, this is similar to adding HTML
… where is the push back? Should we have a survey
Hadrien Gardeur: we have discussed this with our members
… they believe this removes the guesswork
… they use BISAC to indicate something is a comic
… we've heard from mulitple, some big names, that this would make things easier for comics
<Daniel Kimberg> i wanted to hear your comment first, brady
Brady Duga: I agree with Hadrien it is really annoying trying to guess that something is a comic
… but I'm not sure how this helps. Is adding an image to the spine mean an EPUB is a comic?
… even if we limit images to rolled documents
Charles LaPierre: we had an fxl meeting, Ken Jones created a tool
… he will share it when we merge the fxl, comic and accessibility groups
… working with Calibre you can select regions in InDesign
… change the reading order, add in image and region descriptions
… the reading system was able to zoom in and speak the text on the page
… we should get Calibre to share what they are doing
… Ken is doing interesting stuff with new features on a Harry Potter book series
Daniel Kimberg: the idea of mixing comic and reflowable is terrifying, but adding images is not
Hadrien Gardeur: I agree that it will make things harder, it would be easier than having to detect the HTML file
… checking for images is way easier
… because of historical content, we will keep this messiness for sometime
… what I've seen from Ken and Colibrio doing they are using region navigation
… interesting but doesn't have a bearing on our discussion here
… region navigation isn't incompatible with images in the spine
Brady Duga: are you saying "images in spine are only used in comics"
… which is untestable. If I must use this as a key to determine if this is a comic
… I've seen lots of crazy fxl documents, I bet we will see more craziness
Hadrien Gardeur: agreed it is probably more for all illustrated content
Dale Rogers: I guess in this case "comic" means that every page in the content is an image
… similar to Kindle Create
@Shinya Takami: I think if we add a new layout, comic, in addition to roll, we can
… only adopt the image in spine for both of these
… we use fxl for comics in Japan but it is so different than manga
Hadrien Gardeur: I wouldn't really do it that way. I think comics are files that have all images in spine
… we have spent a lot of time looking at edge cases
… we have made things difficult for years
… what we require people to do doesn't add value
… people have to guess, to go through rule sets to get what they want
… we will always find weird cases that require mixed modalities
… we are not helping the industries by focusing on these edge cases
… we should address the huge number of comics out there
Brady Duga: we have solved the issue of front and backmatter by making them horrible and unreadable
… but our readers are used to that, so unfortunately we can ignore that case
… using the images in the spine to indicate that something is a comic is deceptive
… there are kids books that do this too
Wendy Reid: the current way to do comics is a bit more work, and automation exists
… its not hard to build comics with images inside html
… this will exist for a long time going forward because this is how people's workflow function
… and sometimes this causes issues with RS
… but from a User perspective this is transparent
… people will see that this is possible, and do it.
… we are making something easy just to make it easy without thinking about what is best for the user/reader
… we've been managing just fine all this time
Hadrien Gardeur: I don't get your point. The fact is that the user experience isn't good
… its not true that adding bitmaps in spine will make things any worse for anyone
… people already produce things that way
… I have a hard time hearing how this will negatively affect accessibility
… or user experience
… I remember that we were very close from accepting images in the spine
… at the beginning of fxl spec
Wendy Reid: agree! about accessibility, I'm concerned about images in the spine
… if you distribute books to Europe they must be acceptable
… let's say we stick with fallbacks for this
… how do I signal that that is what I need?
… how do I tell the reading experience to give me the image experience?
… we have to be careful about the security and privacy of users
… right now we don't have to worry about that with text imbedded in the HTML
… I'm concern about how we trigger the fallback
Hadrien Gardeur: that would be true if all reading systems were using web view
… many reading systems simply extract the image
… even if you have the description, you might not be able to show this to the reader
… even if a reading system wants to be accessible comics, it can't
… allowing images in the spine won't make them less accessible, they already aren't
… we are conflating spec with legal requirements
… of course we should make accessible content
Avneesh Singh: There is a default mechanism where HTML provides accessibility even if the publisher doesn't
… in the new proposal, you are asking more of the reading system
… theoretically it can be aligned with accessibility but it doesn't align with what is available now
… if these images in spine are used everywhere, things will get worse for accessibility
Brady Duga: I sort of agree that we shouldn't conflate the spec and the legal requirements
… as long as we have the mechanism to do things
… we will still have inaccessible content
… right now if someone makes an accessible kids book
… it is an expensive process that can be read via a screen reader
… if they can do the same thing with images in the spine
… if I just take that image and see it in a web view, will it correctly extract that metadat?
… now we are putting a burden on the RS. If they get an accessible ebook
… but don't display it that way, it could lead to problems
Hadrien Gardeur: You always have to consider who is doing what
… it isn't common for comics to work with web view
… having the metadata in a file might be easier than extracting it from HTML
… some people work with web views, but not everyone
… for everyone else, images in spine make life easier
… this is probably the area with the most specialized reading systems
Brady Duga: Comics aren't going to be accessible, regardless of what we decide to do
… there are other kinds of content that will benefit from images in spine
… comics and kids books have very different kind of readers
… you don't want to mix those up
… there is a lot of illustrated content that isn't comics and still needs to be supported
Hadrien Gardeur: some kids books still use images, but European regulators will say you can to better than that
… can we force people not to use images?
… I'm not sure I see the problem, as long as we provide a means for alt text
… it won't make the experience even worse than currently
… we're not talking about technical issues, but best practices
Brady Duga: I think we are speaking technically
… if I can put the description in my image, as an implementor
… I now have two different accessiblity methods to support
… I don't think playbooks does anything for accessibility in comics
Wendy Reid: I think if allow metadata in the image, you're going to need to build that
… and if it is html we can add semantics
… we can't do that with metadata
… the other thing, we have a lot of stake holders
… the person who makes the ebooks, the tools to make it, the distribution system, the vendors, and the readers
… we don't always put pressure evenly.
… we probably do want to have more of a discussion about what we expect from reading systems
… how do we do this that is easy for the reading systems and are secure for the readers
… but we don't talk about the tools.
… if we can make children's books accessible, we can make comics accessible
… we agree that the current state of fxl isn't ideal
… we need to spread the pressure more evenly
… we will continue this discussion
… next week we will meet with the APA
Shinya Takami: this is a good topic for Kobe