ZedAI telcon 20090629
From zedwiki
Note: this meeting will be held at 1300h UTC. Find the meeting time in your geographical location.
Contents |
Present
Markus (scribe), Josh, James, Ole, Kenny, Matt, Marisa
Regrets
Boris
Previous Telcon
Action Items
New
- Marisa bring Boris's annotation role property suggestions to Request_A_Role
- Markus startup the Braille formatting feature on the SVN. On the feature team: Ole, a slice of Matt, someone from TPB, perhaps VA also.
- Markus contact TPB for participation in the braille feature work
- Kenny check with VA re participation in the braille feature work
Brought Along
- Boris come up with initial set of properties for use in annotation@role. DONE
- markus remove summary from table DONE
- markus change object content model back to dual block/inline DONE
- Kate provide concrete examples and desc of problem to emailing list. DONE
- Markus book date with James for core element set + feature exposed elements discussion DONE
- Markus book date with Per to move on with content selection feature DONE
- markus add all math issues clearly to tracker
- Dennis/Josh contact QTI and ask about replacing the HTML with host language text content set.
- Markus to add spec prose on cascading level for inline styles: "For the purposes of the CSS cascade, these values are considered author-level"
- Markus to create wiki page devoted to level issue
Agenda/Minutes
Roles for annotations (Boris)
Here are a few suggested roles that annotations could have. I'm sure you all can refine the list or add more. Note that these are supposed to be orthogonal to the question of who created the annotation, for which we already have the required @property attribute.
structure description (eg, table structure summary) content description source or attribution introductory note commentary clarification correction
Bng
@Marisa to move these to request-a-role, and ask Boris about the source/attribution one - overlap property
Item-of-the-week: running headers (#44)
[From Kate]
I have been asked to provide some more info and perhaps an example of the running header in braille - so here goes.
- Running headers (also known as a "running titles") appear at the top of every braille page, and enable the reader to easily orient themselves within a braille book. Braille books are generally very bulky and comprise of a number of volumes, so the running header allows a reader to determine exactly where they are in the book on any page.
- Running headers also allow the reader to flick through or skip to a particular chapter within a volume, without using the table of contents.
- Running header text traditionally contains at least the chapter, part or section name/number, and sometimes the book name as well. A running header is updated with new text each time a new braille chapter/part/section begins.
- I'm not sure about other countries, but in Australia we do not include running headers if there are no chapters or section names/numbers in a book - ie. if the only information contained in the running header would be the title, the running header would be omitted from the braille.
- In some other countries, formatting guidelines recommend the use of a running footer instead of a header. It is my understanding that a running footer functions in the same way as a running header, but just appears at the bottom of a page instead of the top.
- Text in the running header sometimes needs to be abbreviated to fit within the allowed number of braille cells - as running headers can not take up more than one line.
- Eg: a print book called "The Willows" has twelve chapters ... braille running headers could be:
the willows ch1 the willows ch2 etc.
- Eg: a print book called "Costumes and Fashions Through the Ages" has parts and chapters ... braille running header could be:
- costumes part 1 ch3
or simply
- part 1 ch3
Anyway, I hope this is helpful. I'm sure Matt and some others can probably add additional information about how braille running headers are used in their countries...
Notes during the concall
Markus: wouldnt a Braille processor be able to do this without explicit support from the authoring format?
James: yes, the needs expressed above are already supported (chapters, titles etc)...
Ole: in Braille the running header could be the name of a chapter, but in abbreviated form. We use a single line with a limited number of characters allowed; and we want full automation from ZedAI to the braille file.
Matt: we dont store this in the master format; braille transcriber provides the needed information to the braille processor. Also, this may be particular form producer to producer.
James: perhaps Oles use case can be solved with a local (DBB) namespace.
Markus: to get off-the-shelf support for this in Braille processors, we would benefit from standardizing it...
James: looking at running head provision as part of the braille production process.
Ole: you can have a situation where what goes into the running header is not part of the book.
James points out that interchanged files will be unlikely to contain DBB-compatible headers; in this case full automation is not possible.
Ole: could perhaps be enough with an annotation with role of abbreviation; or an attribute on the heading
Discussion about the potential of a Braille formatting feature; as a place to put things as requirements arise.
James: hopefully be generic enough to support different Braille flavors. We just need to provide good containers for the data.
Decision: start a braille formatting feature. This is a test/prototype for evaulation, may be abandoned. On the team: Ole, Matt, Markus
@markus contact TPB for participation in braille feature
@kenny check with VA re participation
@markus startup the feature on the SVN
Item-of-the-coming-week
Suggestion: #57
Periodicals profile: status update
Kenny: sample document from the rolling stone
This week, review and revise this document.
Will try to do a printed newspaper as well; as it may be sufficiently different from monthly magazine.
