Meeting minutes
<ivan> Date: 2024-04-05
wendyreid: Welcome to the PMWG, we have a guest today
jaclyn_retallick: I work at Rakuten Kobo with Wendy, I'm an intern at the QA team
<wendyreid> https://
Publishing the FXL A11y WG Draft Note
wendyreid: there's been a join task force between PMWG and Publishing CG
… with the focus to produce guidelines to make FXL ebooks more accessible
… the question today is to make the note published as a draft note, to get a broader review
… this document is a practice and recomandations document
… it will have a techniques document where we'll list how to achieve the goals proposed
George: before we approve this (6 month from now), do we aspect to have authoring tools or publishers or reading systems that will support it?
wendyreid: because it's a note it doesn't require the process of the rec, so is not required to have implementations
… at the same time we based our suggestions from real life ebooks and tools
George: do we want to test it?
<AvneeshSingh> It would be helpful to know what draft note mean. Does it mean that structure of note is freezed, or is it a more mature version of editor's draft, and structure can be revisited?
wendyreid: it's not mandatory, but may help
wendyreid: it's a more mature version of an editors' draft
… having it published as TR we'll make it more visible
ivan: the difference between a draft note and a note is more on the naming, then on the content or the stability of the document
Dale0: I asked big retailers specs about FXL, they sent me links both to new and old version of EPUB
wendyreid: Yes, I know that documents, reading systems normally try to support all versions of EPUBs
gpellegrino: Two questions, before publishing as a draft note, do we want a short period of review for this group?
… one of the last notes about accessibility exemptions, we requested an OK from APA, since we speak about Accessibility, do we need to ask them to review?
ivan: to the second question, we have no requirements to ask for an horizontal review
… I'm comfortable in publishing it now as a draft note
… as an aside I asked Kevin and Shawn to ask them a review
AvneeshSingh: APA review may not be important for a process point of view, but maybe before the official release may be good to ask them a review
… maybe we can ask also to the AG WG
… since WCAG are involved
… for the time to review I suggest 2-3 weeks for internal review
tzviya: I think that publish the draft note doesn't impede us from update it later
wendyreid: is there any concern in publish it?
… I think it's ok to publish it in draft note status
ivan: I understand the reactions, but I would prefer to publish the note to make it known by the world
… the document is under discussion from fairly long time, so I think it is the right time now
AvneeshSingh: two things, I think we should ask APA before publish it as "official" note
… I think an internal review should be useful, having the notice about it 10 days ago would be great
… it's ok that for the task force the document is fine
wendyreid: we ave a publishing moratorium next week, but we may move it to the end of the month
shiestyle: I agree to publish it as a draft note, so it's more easy to have feedback from DAISY Japan
ivan: I propose to do something in the middle, I propose to vote via email for publishing the note
… everybody in two weeks reviews the note and in two weeks we take the decision about publishing it
wendyreid: I agree I can send it at the end of the meeting
… asking for review
gpellegrino: In the meantime, we still have the monday meetings of the TF, we can meet there and discuss there, we don't need the WG call to discuss
Webtoons discussion cont.
wendyreid: we would like to find some kind of consensus
ivan: on the GitHub comments Hadrien proposed a possible solution, but it requires to add a new normative feature in the spec, and we are not allowed by the charter
… I propose to put this charter question aside and we try to find the best solution based on consensus
… at the end if the best solution requires to change the charter we can work on it
shiestyle: the Japanese community doesn't want a new feature for publishing webtoons
… but if most people in the group want it, I'm not against it
wendyreid: I think one problem here is that we don't have enough knowledge about webtoons outside Japan
tzviya: we had a long discussion, we said that the user may select the preferred way to read ebooks (scroll o paginated)
… the webtoons that are being printed are paginated
Hadrien: for that content what you don't want to do is to have a page with a little content in the middle
… the problem is how to move forward and backward
… in a smartphone does the content have to fit the width?
… using reflow or FXL doesn't matter, they both don't work in this way
LaurentLM: tzviya said that is not about reading systems capabilities, it's about semantics
… in pre-paginated we speak about pages, and a viewport
… in webtoons we speak about tiles, each with different dimensions
… those are two different things
… if we want to use EPUB for webtoons (it's fine), but we need another approach
… if we use FXL a reading system will display tiles in "pages", with edges
… so I think we cannot use the pre-paginated world for webtoons
shiestyle: it depends: rendition-flow: scroll-continuos is for us a sign to say that the EPUB is a webtoons
… because we don't have another value to express it
wendyreid: a lot of these are coming down to implementations and reading systems
… however a lot of these will come down to user preferences and how they prefer to read content
… I can read with scroll both for reflowable content and FXL
<tzviya> +1 to wendyreid
wendyreid: we just want to give the content creator the ability to signal that scroll is the preferred way to consume that content
Hadrien: I'm trying to list requirements at high level:
… you want to have content that fits the full with of the viewport
… you want to list tiles on attached to the other (without borders)
… you want to access the whole content by scrolling it
… for this I think that the pre-paginated UX is not the good one
… an additional thing is how to deal with series and collections
… reflowable is all on the power of the user
… FXL is based on control by the content creator and as the assumption that you see the whole "page" in the viewport when you load it
… I think the UX would be much better if there is something specific, then using the FXL
ivan: the current disagreement is that some publishers are using a undefined combination of proprierties to signal that a content is a webtoon
<LaurentLM> +1 to Ivan, that is right
<Hadrien> +1 to Ivan, that's a good summary
ivan: what Hadrien says is to create a new value to express clearly what publishers want
tzviya: I think we are discussing all the same thing in these meetings; we have publishers already doing it, we have to help them.
shiestyle: I think we don't need a new feature, we are already using it, changing the old content may be challenging
<Zakim> ivan, you wanted to react to shiestyle
ivan: the way I understand it, is not to add requirements for new features in the reading system, but to better express the content nature
LaurentLM: I understand that in Japan the prototype was developed and coming to the standard body, and here the discussion is happening
… is good to have the prototype, now let's find a good way to express it
wendyreid: maybe we can do this iteratively
… we have also to think about expanding EPUB
… but this is only part of the solution
… right now it may be a little bit rough, but with better metadata, and OPF organization and etc. we can improve the UX
Hadrien: in reflowable is the user that decides how to read the content, we have seen few EPUBs using rendition-flow in the wild, and fewer reading systems supporting it
… I think that extending something that is poorly implemented in reflow is not a good idea to expand it to FXL