Meeting minutes
Title: PDF-AAM Task Force Teleconference
Title: PDF-AAM Task Force Teleconference
github: w3c/
PD-Dom
github: w3c/
Zakk: Existing project that Matthew turn to me
Daniel: No specifics for today
Zakk: Just make editors aware of this
JamesC: Is it worth mentioning this in the readme?
Alphabetize AAM entries
Alphabetize AAM entriesgithub:
Alphabetize AAM entries
Alphabetize AAM entries
github: w3c/
Zakk: Mirror the html ,aam and core-aam to put them in alphabetical order
Add explanation for PDF namespace
github: w3c/
JamesC: Can someone summarize PDF namespaces for me?
William: similar to xml namespaces. The didn't have namespaces in PDF1 but they do in pdf2
… It's a different logical tag
… They have a PDF2 part different from PDF1
… the default namespace is actually the PDF1 namespace. Confusing, but backwards compatible
… Similar to PDFUI2 tags. The PDF1 tag did exist, and they can be used
… You are only allowed to use the PDF2 tags except if there is no correspondence
… If all you have is PDF1 tags you still can conform
spectranaut_: How do you specify that a document is using PDDF2 tags?
William: Dictionary entry for the structural element that points to the namespace. If you don't sspecify, that's where the PDF1 default is
… Everytime you use it
… The actual namespace object you'd only have in one sspot, and then it'll all be referencing to that spot
Duff: The namespace mechanism is the vehicle for us to introduce MathML in PDF2
Duff: It's a fundamental element of the enriching of PDF and accessibility of enriched content in PDF
JamesC: it was problematic back in the day when there was the split between HTML and XML
… The idea that nothing makes it into the spec until there are at least two implementations comes to mind
… Acrobat is the target for this although there are other clients
… People may see this as an opportunity for extensibility, and they may assume it works for all the clients
… This is why W3C introduces this guardrails, so that the things we put in the specs are either stable or emmerging
… MathML you could extensively insert into XHTML or XML. They are now part of HTML, which is different than opening up another dedicated namespace for this
… Igalia have made the implementation for several browsers
… Overall, I recommend proceeding with caution on this
William: One of the requirements of PDF-UA and well tagged PDF is that everything that is not well tagged needs to have a standard mapping as to how it should be tagged
… The behaviors of your custom tag need to match the standard tag
… Even if you comoe up with new tags that needs to be the case
JamesC: Fallback rules exist
… I don't see this as an issue for implementing AAM, there are still some chunks of PDF overall implementation that might be problematic
Duff: A universal implementation of PDF features is not likely to be achieved
… If you a re going to implement a feature you must do that fully and completely
… The MathML implementation didn't happen in the context of two independent implementations
JamesC: The core specs are effectively following that pattern now
… Incubation's goal is to prototype these new features so that then what the spec is closed to reality
Duff: Not sure if the goal of the PDF specs is to get closed to reality
JamesC: Surprised for you to say it's an expectation that there won't be interoperability in some parts of the implementation
Duff: What's the true meaning of SHOULD then?
… Browsers for a very long time haven't implemented PDF beyond baseline features and that's oK
… a printer is some sort of another PDF implementation
… Softwware may process PDF according to their specific use case, and there are reasons for this, complexity among others
… In the case of tagged PDF, if theey want to do it, they should it right
JamesC: See my link above for the SHOULD
JamesC: By implementations I mean the reading of the PDF
… Part of the goal of bringing PDF to the web platform is for you to be able to take advantage of this infrastructure to be able to more reliably test, for example, AT implications
JamesC: Core specs are in general very well tested
Zakk: There's alignment in accessibility
Duff: And challenges that we'd have to tackle
… Our definition of semantic model doens't have a paralelism in HTML
JamesC: It may have it in SVG
… Most SVG container elements can have titles
… And I think the HTML equivalent is the document itself
William: Not really equivalent. The SG title is for various pieces, but or PDF is the whole document
… I am talking in the content title
Duff: In html that'd be the h1, but we reserve this as part of the content
Zakk: MAking sure the interoperability exist, for PDF on the web to be accessible is the main goal here
Next meeting
Next meeting will be 5 Nov