Meeting minutes
Topics for F2F - https://github.com/w3c/epub-specs/discussions/2815
wendyreid: We created a discussion in Github for topics for the f2f
Hadrien: There are many publishers/distributers who are doing remediation for accessibility
… sometimes they generate the image description or infer metadata
… this is important right now, because there is no way to indicate that the descriptions and metadata have been generated
… mostly an accessibility issue
… similar to another topic, the ability to identify synthesized voices
… overall how do we indicate that something was generated in EPUB
wendyreid: we can include that too
ivan: we had some discussion about the publication manifest
Font Obfuscation - w3c/epub-specs#2807
<ivan> w3c/
ivan: I started this discussion and it took an unexpected turn
… I was reviewing another PR and realized that the obfuscation section uses a SHA1 for hashing
… I realized that SHA is one of the algorithm that is considered out of date
… because of security issues and lack of unique hashes
… [1] will retire SHA1 soon which leads to governments and other orgs
… not being able to use it
… I proposed that we update the version of SHA
… Brady saw this as an opportunity to retire obfuscation from the spec
… not 100% because we have to be backward compatible
… we can add text saying that people should avoid using obfuscation
… and use WOFF fonts
… in the discussion there was agreement that this is the way to go
… mattgarish has already made a PR
… that includes other obsolete but still usable section
… these are not specifically deprecated
… we ask that people not use these technologies but reading systems with continue to understand them
… do we want to remove obfuscation in 3.4, and include the new section?
… it makes sense to move older features to a separate section
… it cleans up the spec, we don't have to keep all the font obfuscation specs for ever for example
duga: I thinks its better to use WOFF fonts than to rewrite the obfuscation spec
… the reality is that SHA1 isn't broken, there is no maintenance required
… just some won't use it
'…it is not the end of the world if we choose to do nothing
… it is still used. So it is a little weird if one of the major tools, InDesign, still uses obfuscation
… it still makes sense to move it into older features
<wendyreid> s/'.../...
SueNeu: Can confirm, Adobe Indesign still produces font obfuscation
ivan: leonard did chime in on the thread and said he didn't see any reason we couldn't go ahead with WOFF fonts
… perhaps this is an incentive for InDesign to change
wendreid: are we all in agreement that we are deprecating font obfuscation?
duga: is deprecate the right term?
mattgarrish: obsolete but conforming is what is used now
ivan: the question we also have to answer is what do we expect epub check to do if it sees obfuscation?
mattgarrish: right now, we expect it to say nothing as long as it is used correctly
Proposed: Make font obfuscation an obsolete but conforming EPUB feature in EPUB 3.4.
<shiestyle> +1
<rdeltour> +1
<duga> +1
<mgarrish> +1
<ivan> +1
<SueNeu> +1
<toshiakikoike> +1
<Hadrien> +1
<wendyreid> +1
<MasakazuKitahara> +1
<CharlesL1> +1
<SueNeu> s/mattgarrish /mgarrish
RESOLUTION: Make font obfuscation an obsolete but conforming EPUB feature in EPUB 3.4.
wendyreid: resolved
CharlesL: do we have anything that lists all the features that are OK but can't really be used anymore from EPUB check?
… can it give a publisher a list of things they shouldn't be doing the future
rdetour: ordinarily we issue a note that they should not use these features
Alternatives in spine - w3c/epub-specs#2806
<SueNeu> s/redetour /rdeltour
wendyreid: there was some discussion on this issue, so we need something in the spine
… besides fallback, that indicates something has an alternative
… we've had a lot of ideas about this
… including mapping between resources using something like SMIL
… I wonder if this creates other issues especially with overlay files
Hadrien: A good number of people have been using fall backs for this, particularly for comics
… I don't know if these is part of the main spec or part of the comics group
… it isn't good if something is widely used but not mentioned in the spec
… I think of newspapers and magazines where this is widely used
… I've seen this implemented as getting a list of alternatives like Libby app in the US/Canada
… it is not a one-to-one mapping
… for some publications you could tap on the article and it would open in another view
… to do something like Libby we wouldn't need SMIL
… to do a one to one mapping we would need something more like SMIL, Rendition mapping or region mapping
… there are a lot of organizations that do this with EPUB or PDF. They've invented their own way to do this
… as an extension of the spec to enhance newspapers and magazines as fixed layout epubs
wendyreid: If I understand correctly, you're saying there is a missing thread
… we could continue to let people use fallbacks but we need some way of indicating why they are being used
… we could extend properties or add something new that says the fallback is being used as an alternative
… at large many reading systems may not see the fallback that way and won't provide the necessary UI
Hadrien: fallbacks wouldn't cover the Libby use case
… fallbacks have mostly been used because we don't allow images in the spine
… for what you've described, we do have multiple renditions, though I am not a fan
… I'm not sure it has ever been implemented by anyone other that B&N
… if we want this kind of concept, we could reopen multiple renditions or we could use collection
… I'm worried about introducing something new. We could start with what is in our spec
… because something new may never be implemented
duga: I have a question, this came from the fxl group, but are there other use cases?
… are we trying to fix this in committee without going to the people who are trying this
Hadrien: yes, people who are members of EDRLab are already doing this
… mostly in newspapers, magazines and textbooks
wendyreid: there are tool makers who are also trying to solve this
… and there isn't a lot of clarity for fxl accessibility
… and reading systems aren't jumping on this either
… no one really knows what an accessible fxl book looks like
… there's no reason why this isn't possible, we've seen examples in closed instances
… people aren't doing this on a large scale
… the push for this in 3.4 is that publishing moves slowly and this will be needed
Hadrien: we could invite people building these tools or using this content to the task force
… so they could give us a better understanding and we could identify the needs
… do we just need to map between resources or fragments?
… what are the criteria for need these alternates?
… before we push solutions
… I can try to get this in place before heading to Japan
AvneeshSingh: it would be great to get the use cases in place first
… the main use case in DAISY is braille vs text
… and demand is coming back for this
ivan: let's suppose multiple renditions is still in use. Would we be OK with that
Hadrien: that's a tough question. I don't prefer that. It wouldn't be good enough even if some parts are good enough to sue
… I'm pretty sure major changes would be required if we decided to go to Multiple renditions again
ivan: what I am afraid of is that we are reinventing the wheel, and a wheel we already have
… are we repeating a lot of work others have already done for us
wendyreid: I don't know multiple renditions well, and have never seen one in action
… I understand that multiple versions of the epub are in the same file
… are they completely separate? Can you switch between them? or view them simultaneously?
… in fxl a11y there is a need to see things at the same time
… for instance you can see the full page image but still read the text in a way that can be adjusted for size etc
Hadrien: you can think of multiple renditions as multiple items in the same file
… rendition mapping is used to link resources among different documents
… that's the part I think is not so great right now
… the worst part of multiple renditions is the mapping part
wendyreid: I notice the reading system conformance instruction is that RS must support switching between renditions
… so it would address the use case I mentioned above
… is your problem with CFI?
Hadrien: I don't know why CFI is used so heavily
… I may be able to find my arguments against it
ivan: if you use epub CFI to point to a resource or part of a resource
… we are working on something like this in the annotation task force
… perhaps we could use what we come up with in the annotation TF instead of CFI?
Hadrien: we may not need the complexity that is needed in annotation anchoring
duga: you only need fancy things like CFI if you don't control the publication
… so we could get rid of that
… are we reworking multiple renditions?
… and CFI?
wendyreid: maybe the new way of targeting text fragments is better than CFI
duga: we could talk about CFI all day
wendyreid: I am convinced that some of our ideas that aren't still used were just ahead of their time.
… we will continue talking about this. EPUB 3.4 is going to be the big fxl revision
… it would be helpful to get any feedback you can get
Hadrien: I will go back to people and ask if they are comfortable talking about it publicly
wendyreid: please add any ideas you have for the f2f
… we are trying to schedule a meeting with APA before TPAC