-
Notifications
You must be signed in to change notification settings - Fork 5
eBraille Working Group Meeting notes
Meeting notes will be added to this wiki page. New meetings will always be an h1.
George Kerscher, Beth Pieters, Jennifer Wenzel, Venus, Thomas Simpson, Michael Ryan Hunsaker, Svetlana Vasilyeva, Avneesh Singh, Bert, Dang Hoai Phúc, Matt Garrish, James Bowden, Charles, Christian Egli, Susan Osterhaus, Francisco Martínez, Sarah Welch, Jennifer Dunnam, John Ylioja, Melanie Romer Noel, Edwin Wong, Nicole Gaines, Jen Goulden, Ka Yat, Richard Orme, Caryn Navy, Willow Free, Bert, Robert S. Jaquis
Bert: May have some things not real use cases, so if no one volunteers for them will assume don’t need until someone comes up with them.
Helpful to have real use case examples; can then explain what is needed in HTML and CSS.
Line Breaking:
- Line breaking properties of soft hyphen and no-break space.
- Hyphen: Only shown if there’s a break in the word.
- No-break space: Similar, shows where lines can be broken in words with no hyphen.
JB: If examples are needed, he is happy to work on those.
Bert: Page breaking, avoiding orphan or widow lines or lines belonging to a block of text like paragraphs or list items ending up alone on a page.
JB: Also about making sure heading isn’t broken from the first line of text?
Bert: Have examples of this already. Now working on something where one line would be on one page, and the rest on another page. Would allow lists to be broken across pages, but don’t want just one line on a page.
WF: Have an example of this in BANA rules, like should avoid starting a list on the last line of a page.
- Also, in BANA, "The End" goes at the end of work or volume, and if it would be on a page by itself, can put it on the same page or line with other text so it isn’t by itself.
JB: Similar in UK where "The End" or end of volume can’t be by itself.
Bert: BANA rule already has example but no solution in CSS. First example given might be applicable.
JB: Can do an example of that.
SV: Has question about an example—like uses hyphenation a lot in her language but not much in English. Could make one in Russian braille for hyphenation in Unicode.
Bert: Not sure if this one is a real use case but looking for an example of a block of text with a line underneath, where the line does not go further left or right than the text.
JB: This happens in German. In England, line at bottom.
CE: Can make an example for this.
Bert: Horizontal line of type end marker to mark the end of a section. This was created by James.
JB: Can do an example.
Bert: Last issues about tabular data:
- One about abbreviating table headings. Sure this is done sometimes; thinks it’s mostly used when headers are repeated, so they need to be short. Abbreviations are explained in a key after the table.
JB: This is done in UK and BANA.
WF: Will make examples each of ways I can think of, so will make these.
Bert: Do for spatially arranged tables and list tables.
- Another issue: repeating table headers on subsequent pages might need some CSS formatting.
WF: Will take this as well.
JB: Should we add examples to ticket numbers?
WF: There’s a folder on GitHub. Go to "Best Practices Styling," then "CSS Best Practice Examples" folder. Make them Unicode BRF files.
- If can’t make Unicode BRF file, it can be converted.
- Can also email to her or attach to a ticket.
JB: Do we have examples of how tables should be rendered in all different formats?
WF: Have examples of some. Will generate different types of tables. Also, heading abbreviations and repeated table headings—this is easy with Braille Blaster.
JB: This is US-centric. UK has paragraph form tables.
CN: Have linear tables—similar but not the same.
WF: If you know something like a type of table for your region not represented, feel free to make an example. eBraille will make tables more valuable.
Bert: If unsure if something is represented, just send a BRF of the table layout.
CN: Are we trying to make tables more accessible in refreshable braille?
WF: Goal would be for user to have navigation and information about relationships in the table as if arranged spatially. This is the ultimate goal. Any size table could be rendered; the user would navigate horizontally and vertically. Will be more in users’ hands to decide how they want to read the table.
JB: Do we have a tag to instruct the reader for default table?
WF: Was in class names but very BANA-centered because knows those terms.
JB: Paragraph tables are a variant of linear. Can also have a 2-page spread.
WF: Has been thinking of dynamic braille of limitless pages. Teachers and readers will have to help shape thinking about braille pages.
WF: What have people done already? What level of support are you seeing in your organization or organizations involved in? This will help when going to developers.
JB: Three things need to happen for this file type to thrive:
- Hardware manufacturers need to support it.
- Software programs like translation software need to support it.
- Production houses need to produce it in the new type.
RNIB can’t produce anything until hardware and software are in place. Transcription team open to it but can’t.
WF: Fourth thing is users need to want this document type. People do seem excited. NFB is supporting; have talked about it publicly. To get 1 and 2, it’s helpful to have demand.
JD: Confirmed a lot of support from NFB and wants to do whatever is needed for support.
CE: Swiss Library for the Blind next year exploring the idea. Could have an additional format. Some form of eBraille would like to have example books waiting for creation of EPUBs with eBraille.
WF: Are examples coming?
JB: Was also wondering if samples are going to be available for demonstration.
WF: People should weigh in on the mailing list. This will help make sure this is supported by software and transcription programs. Have discussions on the mailing list.
WF: Matt Garrish made a rough example of an eBraille file using EPUB. Daisy had rights to it. Made it; just needs a bit of cleaning up. Need examples to align with best practices. Should use the same tagging and CSS. Right now it has print graphics. Some can be removed or replaced with alt text; some would be applicable as tactile graphics. Need a volunteer to be part of creating those tactiles. APH will help if can get other volunteers. All would just need to do a few.
MRH: Happy to volunteer.
WF: Will be in touch; help divvy them up.
WF: Will go through them. If it seems like too much, will ask on the mailing list. When finished, maybe should be PDF format. Now are JPG.
Most decorative; rest are maps—8 maps, some same maps focusing on different information.
At APH, making example of Winnie the Pooh. Does have map of Hundred Acre Wood. Easy book to transcribe, so giving experience without burden of lots of tactiles. CSS sheets holding back on getting these totally complete so tagging can align with CSS.
- Close to finish line.
- Need tools to create eBraille files.
- Need tools to open eBraille files—these are in the works.
- Ensure feedback is obtained.
- Need a validator: Would feed it what you think is an eBraille file, and it will tell you what’s wrong. Thinks Daisy is doing that.
- Need exemplars: Will need people to help produce these. This will be easier when tools like BRF-to-eBRF converter are available. Want to make this tool available early next year so people can make them. Students will use on Monarchs, then can get feedback.
Exemplars are the biggest thing needed from people.
Reading software is in development; will get more as files are created and used.
Goal now should be to focus on 1.0. Have established scope; don’t want to expand it. Should get everything done, call it 1.0, then can talk about next steps.
Have not forgotten about features requested in the past.
JY: Will we have a document that says we’re thinking about things not implemented yet? So users will know and can wait until certain features are done before making in eBraille?
WF: Thinking maybe can use issues list in GitHub. Can clean this up so reflective of what’s still working on. Is a link to the issues list in the spec and best practices. Will mean users need to take the step of looking at that, but keeps document from being unwieldy.
JY: Maybe OK to use issue list.
Bert: Have future directions for issues list.
WF: One thing dangerous about features list—seems like a promise. Don’t want it to look like a future features list because it may not be feasible. Is a good place to strategize with future directions for overview.
JB: Do we have a list of books for exemplars? Like novel, math book, music book, etc.?
WF: Good question. List just started based on those suggestions.
JB: No major changes in music formatting. Would not be difficult.
WF: Winnie the Pooh would satisfy the novel requirement. Could link to different chapters.
RSJ: Could link to books in Project Gutenberg. Is Duxbury looking at producing eBRF with Duxbury software?
CN: Yes.
WF: Did get Winnie the Pooh from Project Gutenberg. Matt’s example is like a textbook. Don’t need to produce a whole textbook—could show multi-volume navigation. Hard to find something like a math book in public domain.
JB: Is Everyday Calculus on Project Gutenberg?
WF: Do need multivolume example. Can use something easy to show.
JB: Book in a different language?
WF: Will make issues for these and make a tag and attach it. Can track these. If folks think of other examples, can make those.
BANA example almost done; others can tackle regional examples.
Next meeting in January.
Willow Free, Jennifer Wenzel, Sarah Welch, Thomas Simpson, James Bowden, Edwin Wong, Nicole Gaines, Jen Goulden, Matt Garrish, Matthew Horspool, Bert, Deborah Ting, John Ylioja, Francisco Martínez, Dan Gardner, Robert Jaquiss Steve Noble Svetlana Vasilyeva, Jennifer Dunnam, Anja Lehmann
WF: should make example a short demonstration of concept enough braille to make the point keep it short with that style should be uncontracted braille
Bert: maybe should be in English then braille code should not matter
WF: idea of eBraille is limited amount of styles in principle want represent as many kinds of braille formatting this makes buffet for creating own CSS
Bert: document explains CSS features what need to use s they need to use
WF: media queries section 2.1. The idea is you can match what the ebraille document is doing to the hardware that is trying to do it.
2.2-2.5 which are about spacing and indenting is majority of braille formatting
Starts with blank lines after paragraphs then into indentations
JB: How do you force blank lines? Is this example that is missing?
WF: Would need to specifically say need a blank there so will note multiple blank lines example needed
Bert: tried to make document not as technical so all should let him know what missing
WF: too many examples might be confusing, don’t have to figure all of this out today
Indentation: first line indenting in paragraphs block paragraphs and nested lists
JB: maybe different examples should be subheadings so not so hard to find
WF: can work on this so easier to navigate document
WF: need examples have example of table of contents but no dot indicators
JB and SV: dot indicators are used, JB will look into example he may have thought
needs example of increased line spacing like children’s books like making books for beginners see need for examples for word spacing, do we need examples for letter spacing? Lot of questions around spacing
JB: Maybe need letter spacing for word search or sudoku puzzles
JG: are some guidelines for puzzles like this, is this just on fringe?
JD: usually transcribers doing these so maybe don’t need examples for this
WF: will be kind of like other spacing do have preformatted option more give examples for things like this don’t need as many preformatted options
WF: white space handling does have issue like example for keeping white space
JB: has example in Wiki bar over bar music formatting
WF: also has matrix example
WF: Need example Unicode line breaking properties
JB: if split word at hyphenation point could be different rules for how characters used like in staff-room would be differences in how can use double f
WF: was thinking of optional hyphen for headings like if had centered item don’t know size of user screen could put in optional hyphen so centered heading could align properly
JB: that is conditional line break not hyphenation
WF: maybe this outside scope of ebraille
JB: up-to-the-minute would be in scope
WF: don’t think these are things need to do in CSS can do them with character
JB: is soft hyphen character allowed?
WF: soft hyphen and no-break space characters allowed
JB: want have no-break space for something like section 3
WF: maybe this could be in main spec because can use character
Bert: maybe this not in tagging best practices maybe is a formatting issue
WF: has been thinking of styling best practices as way to show people how to make CSS but maybe it is more for styling a document so maybe need more of these coding things
Bert: wide space also similar can control properties of spacing with CSS or with Unicode character maybe should keep everything together
WF: will note that soft hyphen and no=break space don’t have to have CSS but maybe should be included
JB: staff-room would be example of problem word; responsibilities would be good word no problem when breaking long web addresses liner math equations so might need to break
JB: example for choosing hyphen character would be for web address
JB: something like title page then page break then contents or contents then break then first chapter
JG: sometimes need force with tables
JB: that’s a conditional page break
JB: thinking contents to chapter 1 is always a page break at end of chapter in Britain have horizontal line markers they shouldn’t be on line 1 of a page come at end of chapter WF: this is “keep with next” situation and need examples of those too headings also a very clean way to use keep with next
WF: BANA also has examples of text shouldn’t be n line 1
JD: also attributions
WF: avoiding page break which is keep together
JB: this would be like table example
WF: don’t want split table if can avoid
WF: Also need example avoiding orphan or widow lines like one line of paragraph being on a page Also need example of column layout
RJ: maybe need this for computer code like C program
WF: could have word lists lot of examples for this
JB: in coding don’t want an end as orphan line kind of like don’t want single line of end on new page would move so hae two lines on a page this like orphan or widow lines
WF: borders and lines need example of shrinking content to fit in a border
Bert: thinking about having line under box don’t want it go past so like German headings can pull from example brf’s
WF: looking for braille example horizontal end markers
JB: can provide if needed
WF: will send out action items to email list people can reply volunteering to take different ones she will take ones she will do Looking for brf’s in uncontracted braille with enough braille to show what demonstrating don’t need page unless absolutely needed for what showing
JB and Bert agree border numbers need more explanation
JB: will provide example of box for Britain with certain strings of horizontal characters
WF: do have example of vertical box will point to the ones did not get to can figure them out in email next meeting Sept. 10 would like have best practices document released in September will need do some work via email to meet that goal
JB: where should he send examples
WF: could use mailing list probably this best use zipped folder make file titles clear for examples could just do as a document put multiple examples in zipped folder
SV: using email list is preferred
Caryn Navy, Edwin Wong, George Kerscher, James Bowden, Jen Goulden, Jennifer Dunnam, Jennifer Wenzel, Jmegginson, John Ylioja, Matt Garrish, Nicole Gaines, OsterhausS, Robert S. Jaquiss, Sarah Welch, Svetlana Vasilyeva, Willow Free
Each braille region doing their own CSS document. The best practices document provides an overview
GK – CSS is localization. We have a us bana version, then people localize their own. Like French for France. Localizations would be a different default CSS. Choose the one closest to your region’s rules to get started on your localization. Would items like Duxbury and braille blaster respect the CSS?
Wf – for braille blaster, the CSS is something to package with the file when display it. reading systems can also take advantage of the CSS files. For example, you can have different files available on device, user choose what version they want, like French.
JB – defaults. Are they declared at all? If people don’t use defaults can lead to disaster. Thought we agreed to use uncontracted braille in examples to make it easier for non-English speakers
Wf – will look into.
Jb – thought we agreed on uncontracted.
Wf – it doesn’t matter what braille is within the cells, but how it is laid out – for the example document. Not sure how defaults work with CSS. Mg – user region defaults styles supplied.
Jb – we want an ebraille file to come out correctly, want to define defaults so people do not start guessing for example would not want people adding blank lines before indented paragraphs
Gk – in the CSS – would you not have the default for all the common elements?
Jb – let’s assume the example in indentation, any sighted person designing a reading agent may erroneously conclude that we want a blank line by defaults before every paragraph. Define all common tags so the reading agents do the right thing.
Gk – we want to set the defaults for everything, and then additional CSS rules are applied if you want it to be different.
Jb – that’s right. We need to document in the CSS document.
Wf – CSS is “buffet” document. At the end of the day – if you are making a CSS file, you should know CSS and the braille rules for the region you are making it for.
Jb – we need to define default so we can prevent erroneous results.
JG – think this will work most of the time. Think we do need to keep in mind that some people will be trying to make files that do not know braille basics.
MG – think we are trying to push the work we are doing for the regional braille up a bit. Don’t know if that works. Our idea is that the default regional styles and then work from there. built in cascade CSS. Might wind up causing other problems.
Gk – so the user agent default styles would only be applied if no CSS is in the publication. This also raises the question. Braille blaster is going to do what it has been doing forever. Will you pre-format everything?
Wf – when the user is workingin Braille blaster, braille is formatting the way they want it. CSS generated when file is saved.
Gk – wont Duxbury and braille blaster have their CSS package that they use for the United States and wouldn’t the CSS from these 2 be identical.
Wf – no one is required to use the CSS best practices
JB – I would guess they would not be identical. Style names may change and be different between the different places.
Wf – This speculation beyond scope of this working group. included a better link for viewing the document. People can provide feedback on mailing list or create issues in GitHub
Jb – music example in the CSS document?
Wf – not currently. Something discussed in the editor’s call – can have too many examples where document is difficult to read. Can put additional examples in appendix. Like special math examples.
Jb – a version number is included in the metadata, in the dc code format
WF: meeting on 07/30 may be cancelled unless more topics come up on mailing list
Anja Lehmann, Avneesh Singh, Bert, Caryn Navy, Charles LaPierre, Christian Egli, Doug Schepers, Edwin Wong, Francisco Martínez, George Kerscher, James Bowden, Jen Goulden, Jenifer Wenzel, Jennifer Dunnam, Jmegginson, John Ylioja, Matt Garrish, Melanie Romer Noel, Nicole Gaines, Richard Orme, Robert S. Jaquiss, Sarah Welch, Steve Noble, Susan Osterhaus, Svetlana Vasilyeva, Willow Free
WF: We have talked about packaging format and file extension first draft complete need formal resolution going with Epub packaging format. Wants to make sure everyone in agreement before publishing. First file is MimeType like in Epub
AS: Checking if anyone has objections, if not can launch formal resolution
JB: This only affects authoring creation software, not players?
AS: Matt Garrish had good idea that reading systems should not have to search for INF files in reading systems
MG: Not an issue for reading system is more an authoring consideration is a zip file not complex for reading systems or authoring tools to handle
CLP: Document needs be compressed shows should open the ebraille file, not reject it because Mimetype is not just like EPUb reading systems should load
MG: Tested with reading systems so even though not officially part of EPUb does work
WF: Sounds like can proceed with this can put out this specification work on best practice documents metadata is moved into main spec will be bigger effort some people have been waiting to get more involved so now they can help with reviewing spec and testing so can go to final published version
FM – replacing BRL created with BRL produce date this follows what Daisy does would be same thing with different name makes things clearer what field for conforms with what already being done. Separate what is in original and what is in reduced file.
CE – DC date. DTB source date. DC is standardized by Dublin Core.
FM: intention to separate original from produced file so thought DC tags more for original publication BRL tags more to produced material so thought could change produced tags to BRL
CE: looking at specifications for talking books they are very specific DC date publication date for talking book source date is when original print book published
FM – does not agree. Some things are mixed up. Wants fields more specific. Up to the group what to decide
CE – don’t know if these decisions were best when done, but useful if adhere to daily talking book specification.
WF – this would lead up to BRL produced date. Decisions do not have to be in stone. Can adapt as feedback comes in. Put some comments on the ticket. Use BRL produces date. Will add to best practices document and main specification
We had a lot of discussion on how to handle referring back to the printed work.
CE – agrees with ticket
NG – use DC source for original work
WF – if no objections, then will add a comment that this is agreed upon. We replace dc source as previously used and use for original source.
FM – another attribute can be used to specify the originator. Chance to use the dc creator for all possible authors? Matt also mentioned this need specify if person has role of is translator editor or something else could use DC creator for any author then attribute role like author or translator
WF – dc creator being used to designate author and contributors.
Mg – when documents created, used bare minimum, dc creator can already be used in this way. is different way of adding information is using a property can be part of document package metadata this already exists not something needs be added
FM – does this means we need a control list of contributions?
Wf – quality does vary between transcribers. Can be good to have a record on who transcribed each piece.
NG – to chime in. not confusion user on what metadata refers to accessible format versus original. Don’t mix tags, have separate.
WF – need a brl creator / brl transcriber?
NG – that is the direction I would go with it. brl prefaced element to make clear. Should not confuse user with what refers to original material.
Ce – would go along with that. This also aligns with talking book that has DTB narrator
WF: so could add BRL transcriber so can use other roles for original source
FM: can add contributors for braille book
AS: maybe can provide examples of roles can get feedback about ideas for certain types of roles and names in different countries
MG: might want have some harmony in names like contributors vs. transcribers but some terms can come later
WF- maybe a place to use best practices document for these extra things. People can add things to the ticket
WF - Should be made clear that DC identifier which is required by epub 3.3 should reference work being transcribed pointing to source document not braille transcription seems like have to have this to fulfill epub requirement. Will need something identify the ISBN.
MG: just requires identifier to be specific to book producing so would be an identifier specific to this book doesn’t have to be ISBN created for braille book need specific identifier for book
CE: talking book has identifier for it is UUID
MG: lot of times people put in a number 1 in that field better if can use UUID make it unique ultimately is string of characters to identify the work
WF: can be about braille transcription this would align to what DT books does
NG: DC source would be used for ISBN Is there an unambiguous schema to make sure identifiers unique? Might have multiple people making ebraille for same textbooks so needs be unique is this just for each agency to determine?
GK: this most useful when reading system brought in publication to make sure doesn’t already have it in its bookshelf are tools to generate random unique numbers but no real proposed schema real use case is for reading system
FM: if same book produced twice should go o DC source ISBN this more for reader could put acronym of Agency then number to make sure unique
NG – though we agreed that dc source would be used for the isbn
WF- correct.
NG- is there an unambiguous schema that could be recommended for identify to ensure it is unique. Does this exist with dt book?
GK – tools out there to generate random numbers that end up being unique. Only a few hundred publications on a reading system, not millions
FM – go to ISBN of original publication to help avoid producing the same book twice. Can use an acronym of your organization before to help prevent duplicates.
NG - ISBN but with origination tag after that
JB – RNIB underscore then the ISBN
WF – dc source available for the ISBN. Dc identifier with suggestions in the best practices. Will come down to creation tools. Will be up to publisher houses to enforce.
JB – can do validation on that. Prevent junk numbers by requiring specific format.
AS – this may trigger a larger discussion.
WF – will need tickets for individual issues for discussion
CE: need DC Date to align with talking books DC Date would be date of ebraille production DC type don’t need because would be ebraille coverage could be used for if partial or complete transcription BRF source date would be publication of print book source publisher would also be for print book don’t maybe need revision date which is used in talking books
WF: do have DC Rights like further reproduction or distribution in other than accessible format prohibited” this one example. Ultimately would need make issues for individual changes then discussion on those especially where requiring something
FM: agrees can’t make decision on all of this now tickets work well for discussion
WF: people now aware Christian can make issues can group some together
Next email questions
CE: not sure why have metadata regarding tactile graphics
WF: would be way reading system knows have tactile graphic so if display or embosser can’t handle would know right away without reviewing whole file to let people know would help user if know can’t use them
FM: could also recommend best device to handle a file to a user
WF: dot number not clearer than dots just longer so could change to dot
FM: can we use cell not dots?
WF: cell type would be clear Christian will make tickets for any remaining issues
Bert has done a lot of work should familiarize yourself with what document trying to do especially if know braille well should see what might be missing. Needs to be more generalized because is region specific tags may be specific but will be general so can use it for documents in any region
CE: timeline on spec?
WF: trying get it published in July what is Matt thinking?
MG: close, need to get packaging and metadata then review on CSS maybe mid to late July should get draft
WF: Next meetings would be July 16 and 30 will send out invites
Avneesh Singh, Caryn Navy, Charles LaPierre, Christian Egli, Edwin Wong, George Kerscher, James Bowden, Jennifer Wenzel, Jmeggingson, John Ylioja, Matt Garrish, Matthew Horspool, Michael Ryan Hunsaker, Nicole Gaines, Robert S. Jaquiss, Sarah Welch, Steve Noble, Susan Osterhaus, Svetlana Vasilyeva, Willow Free
AS – want to future proof as much as possible. Looing at EPUB. Zip with extra caveats and constraints. Have many capabilities of daisy. And has much od html 5 standard.
MG – still need full epub structure. Will we have full epub file set?
GK – what is the container?
MG – must be the container file that gives path to the file. What reading systems look for to discover publication.
JB - concerned that we have different metadata than a standard epub. Do we need to change the way it is named?
MG - epub has a minimal set of metadata required. Can put anything you want in.
JB – what to allow? Discourage?
MG - all per preference. Structure within epub is up t the author.
CE - if we deiced to use the epub file set in the standard. Then we haven’t decided on the packaging formatting, like zipping it. what do we gain by not zipping this like a standard epub?
AS - to make it more navigable friendly.
Wf – any objection to using the epub file set? Can use existing validator. Should be easier for support. And have browser support relatively easy.
JB – need to specify that based on epub 3
WF – one of the ideas discussed for the browser – put the file in the root so that users can find easily.
MH - people used to only having one type of file to open.
Jb – system would work out what file to open
AS – are you coming from a brf file?
Mh - sounds like unzipping files is not CPU intensive
Wf – this approach gives us the best path to quick support
Wf – low-cost braille displays – the makers may need a separate converter to go to the lower standard.
Wf – how do folks feel about the epub file structure
Sv – what about braille translation software?
Clp – something in w3c when voting on issues that come up.
WF - sounds like everyone in favor or neutral of using the epub
Exploded versus simple versus epub. On the agenda next.
As – exploded is not for distribution. For server. Exploded will be there by default.
Jb - would vote for a simple zip with an ebrf extension.
Avneesh Singh, Caryn Navy, Charles LaPierre, Christian Egli, Dan Gardner, Doug Schepers, Edwin Wong, Francisco Martínez, George Kerscher, James Bowden, Jen Goulden, Jennifer Dunnam, Jennifer Wenzel, Jmegginson, John Ylioja, Manfred Muchenberger, Matt Garrish, Matthew Horspool, Melanie Romer Noel, Nicole Gaines, Richard Orme, Robert S. Jaquiss, Sarah Welch, Steve Noble, Svetlana Vasilyeva, Willow Free
Continuing discussion on documents. These documents will help us make a lot of other decisions.
Robert J – strong suggest whatever we do, we pick a format that is going to be useable for as long as we can. Would help put off needing to translate documents into new thing
Willow F – balancing act of future proofing and barrier for entry to file type
James B – strongly suggests that we need more feedback from manufacturers as they will need to support this. Particularly those with not off the shelf browsers
Willow F – browser support is great for desktops and phones. Not great for braille displays and embossers. Think epub makes more sense. A lot of braille displays that support document types support epub. Leaning towards epub
James B – you can used epub in browser if you push hard enough
Willow F – folks from daisy know more about that
Manfred M – think what James said is right. Should find a way to make a reading system manufacturer to be able to do in next 1 or 2 years. Something that takes as little effort as possible to encourage widespread acceptance. Changing standards later, can we dealt with at that time and will happen regardless.
Willow F – four kinds of tech to think about. Embossers which all work differently, terminal only braille displays would rely on browser (all displays are terminal displays), hybrid braille displays which are all very different have basic reader and functions some only txt and some more complicated, then notetakers which are best for support and have browser and reader and better specs. The multiline displays are some level of terminal only, hybrid, or notetaker.
Doug S – what operating systems do they use? Off the shelf?
Willow F – Linux and android are very popular. Android for notetaker. Linux for hybrid.
Doug S - browser engines open source that support. Does not seem like a barrier.
James B – some custom operating systems.
Robert J – some older ones run Windows CE.
Willow F – don’t know if we need to worry about older devices that no longer receive updates
Doug S - make decision informed by manufacturers. In my experience we should ask them to make an informed decision. Want to not make a bottleneck for every other system. Inform them so they can make an informed decision in the long run.
Willow F – reached out to different manufacturers and the feedback was generally positive. Personally, not as concerned. When we put out the first spec, it is not unchangeable at that point. When we put out the first spec, we will get even more feedback.
Doug S - does the spec specify that it is malleable. People may not be familiar with that. Might be worth pointing out specific design decisions we think people may have issues with and ask for feedback.
Willow F – good idea to be proactive. Think it will help when we have exemplars.
Avneesh S - first, when we say epub is better supported by braille displays. is it because of html is the parsers.
Willow F - good question.
Avneesh S second, think all are saying that the spec should be future proof and done in a way that current should be supported out of a box. Do more research on these? Principles: our specification that path of evolution available and done in a way to have support within six months to a year.
Willow F - agrees with the idea of adopting those as guiding principles. The part that is scary is delaying this decision too much longer, because too many other decisions depend on these.
George K – are there any braille display that currently support epub? Think HumanWare has easy reader. Are people mostly opening epub on computer and using as terminal?
Doug S - do we have documentation somewhere else than here of ground truth and implementation and support of current manufacturers?
Willow F - the only file type that has universal support is the basics, brf, txt. Comprehensive list is difficult to find all the braille displays and what file types they support.
Matthew H - thinks that brf file should not be disregarded. Many documents in repositories support these file types. Want to not break collection of brf files. Could be a significant failure point for adoption of ebrf.
Willow F - great point to not disregard how files are consumed today. Brf is great for casual reading, not for other situations. Like not great for classrooms. Principles were to consider less sophisticated devices, but not to be held back by them. Possible for companies to write converters for support.
George K - clear on epub to ebraille conversions. And ebraille to brf would be likely pretty straightforward
Matthew H – agrees that converter would not be difficult. The issue would be that users are not used to needing to convert. Then people may default with the most basic file. Want to avoid different filetypes with different companies
Willow F – yes want to avoid different file types with different companies.
James B – what are the main things that we want eBraille to do? The critical one is navigation. The metadata - what do we do with it? probably have to be custom.
Willow F – Avneesh had mentioned an idea to get support
Christian E – best of both worlds 0 what would that be?
Willow F – currently no braille transcription software supports ebraille
James B – how many epub reading software use a browser control?
Avneesh S - most of them
James B – so we are looking at browsers anyways
Avneesh S – when we talk about future proofing. The biggest thing is the dot epub. Browser cannot open dot epub. Complex zip. Is the struggle with dot epub. If you uncompress it – automatic support of browsers. The requirement of reading system goes away. Unzip it, open navigation system in browser, doesn’t touch reading system at all. This approach can be useful for ebraille.
George K – daisy does not have a packages form, all exploded. Exploded is unzipped.
James B - question becomes what is the performance hit of using compressed files versus the exploded? With exploded file sets you can store far fewer books. What is the typically compression of an epub versus uncompressed? How much memory do these braille displays have?
Avneesh S - we are not restricting people to use packaging.
James B – do we need to work out advantages and disadvantages of compressed versus uncompressed? How much time does uncompressing take on the fly.
Robert J – curious - Make a file with an epub extension with ebrf files. Download from bookshare. What is sighted teacher thinks is a book and starts opening it up. What about adding to end of file name ebrf or something so we know ebrf file versus ordinary epub file.
James B – would not call it an epub file. Would suggest the need to define a new file extension as a standard.
Willow F – in some cases the compressed versus uncompressed is huge, some minor. Will do more research on the file size and such and share on mailing list
Manfred M - distribution may be a topic. Would it be easier to distribute compressed or uncompressed. The navigation part of it is potentially a risk for full support.
Willow F – Avneesh can you write up your idea and send to mailing list
Avneesh S – will do.
Willow F – following up on discussions in email.
Avneesh Singh, Caryn Navy, Charles LaPierre, Christian Egli, Dan Gardner, Edwin Wong, Francisco Martínez, James Bowden, Jen Goulden, Jennifer Dunnam, Jmegginson, John Ylioja, Ka Yat, Maharshi, Matt Garrish, Melanie Romer Noel, Nicole Gaines, Robert S. Jaquiss, Sara Larkin, Sarah Welch, Steve Noble, Susan Osterhaus, Svetlana Vasilyeva, Willow Free
CSUN summit – no decisions being made here. Idea to see each other in person and to have discussions.
CSS best practices – wanting feedback and will make public soon
Nested items and lists – can be different ways
Packaging format to discuss next meeting
The paragraph or p element
Directions – div versus span.
James B - recommend a transcriber note be a span class. Any other html tags for paragraphs like block quote should be included. Display is also used in a mathematical context. Quote is more literary. Continuation paragraph is not a block paragraph with no blank lines.
Willow F - agree with the idea of adding block quote
Christian E - not familiar with BANA. Not sure what class values are to be. Not prefix things with BANA. Maybe something else is more universal than BANA.
Willow F - the idea is we would have definition with each of the class values. Even if not familiar with terminology you can see what was intended and see how it applies to your region
Jennifer D – in BANA transcribers note that is embedded would make sense as a span. But for transcribers notes that are a paragraph would it also need a div
Willow F - braille transcription software will do it. just put it in like you normally would do.
Jennifer D - wanted to make sure that it would be limited
James B – block quote is a 7 5, display is a 5 7. In the UK.
Willow F – could do a p with a class of a block quote. This would be bad practice. Pre-element is meant to be a last resort. Already transcribers that already do not apply markup. They just apply margins and blank lines. The same thing can happen with the pre-element. Marking up a puzzle to get tit to read correctly.
Christian E - thought meant for code snippets.
Willow F - there too, not just puzzles
Christian E – if we have code snippets. Seems like a perfectly legitimate use.
Willow F – legitimate uses for it. afraid of someone wrapping a paragraph in it. The point is to highlight something concerned about.
James B - in favor of having 3. Puzzle a great example. Example in document is a snippet of music with specific formatting requirements. Spaces are not compressed. Automatic line wrapping is disabled.
Willow F - that is a concern. Possible for software to catch that.
Matt G - chime in that format cannot force accessibility. Like from epub discussions where the content accessibility guidelines come into play. Get into using correct semantic structure for content. Can be dealt with. Push people to better markup practices.
Willow F - makes sense. Limit to what we can do. Adage of accepting the things that we cannot change.
Willow F - Tables are very complicated in braille. Places where you need guide dots, spaces needed. Intersection of different pieces of braille rules that need to work together. Also, other table types. HTML has very specific elements to handle tables.
Christian E – a bit confusing. All the elements in html that are part of how you mark up a table. Then mention class values. Class value only apply to the table element? Similar issue to lists? Make it clear where you can apply the class elements.
Matt G - comment on the line sizing table – common on mobile versus computer.
Willow F - great point about making sure it is clear. Agree that there is a need. These values can only be applied to the table. Best way to segregate.
Christian E - this section is about tables. This section is about elements. Discussion in the lists.
Willow F – in the discussion on GitHub. List everything we are going to care about. Ultimately still assuming that you will know which ones you are making a class element. Need a separate thing for things that cannot have a class.
James B - we should say what you can apply these classes to.
Willow F - will be clear what looks funny on first edit. Can always rework it.
James B - consistency thing
Christian E - might make sense to remove it. Then only have elements you can attach class values to.
James B - disagree – part of the reason is useful to spell out the elements to spell out the element that would be supported is to make sure it is supported. No version number of html written in spec. probably not support some parts of html like video.
Willow F - good point. Easier to say this is what we support. Then to list everything that we do not support.
Matt G - one possibility is to sub section the tables. Not just one big section where you are dealing with all of it.
Willow F - the big thing is the purpose of class elements are clear, which elements these are applied to.
Willow F - right now generic. Span or div, and a class value. Anyone have anything to add to that. Transcriber notes in the fact that they exist are universal. Other braille regions are going to care about boxes but might be in different ways.
Christian E – we do use asides. Some special braille formatting rules.
Willow F – great, make an issue for that.
Jennifer G – does it make a difference if a country separates the content from the box, but no start or end lines.
Willow F - they would do what they do. Might be more of an aside. The need for a definition for the reserved class values and definitions for the headings.
John Y – working with epub accessibility. Where a div comes up. Box sounds like idea of starting and ending line. Dividers. Can you have a box or class values for a certain type?
Willow F - box is a very specific class value at the moment. We could apply it to something else. Like an aside. And have that have a separate meaning to the CSS.
Caryn N - displayed paragraph. In BANA start display and everything within that gets indented. Then the end display. Displayed material for everything within that. Like a box or an aside.
Willow F - great discussion. A lot more clarity on things that need to be done is best practices tagging documents. 12th of March and 26th of March for the next meetings. Will get those invites out.
Amanda Whelan, Anja Lehmann, Avneesh Singh, Charles LaPierre, Christian Egli, Dan Gardner, Edwin Wong, Francisco Martínez, George Kerscher, Hrishi, James Bowden, Jen Goulden, Jennifer Dunnam, John Ylioja, Ka Yat, Kathy Segers, Maharshi, Matthew Horspool, Melanie Romer Noel, Michael Ryan Hunsaker, Nicole Gaines, Richard Orme, Robert S. Jaquiss, Sarah Welch, Steve Noble, Susan Osterhaus, Svetlana Vasilyeva, Thomas Simpson, Willow Free
Willow F - Big question – any point in best practices for tagging reserving class names at all? Just recommendations? Leave to software developers?
James B - What is the purpose of defining class names for particular things? CSS control formatting and layout. I have one – will state later to not bias Christian E – elements that are simply spans or dif, like a line number, would need class attribute to identify.
James B - mine is quick navigation. If we decide we want to navigate to a blocked paragraph, then you must reserve the class name for a blocked paragraph.
Willow F – my thinking of reserving specific class names – the user interface does not have to match what class names we use. What the reader sees can be called anything by the local software. Markup not seen by reader or creator. If we don’t reserve class names, then we are leaving a lot of work up to software developers. Might end up in a situation where braille files are fractures. We are already going to have to extend CSS. Taken off burden and ensures commonality
James B - think authors should be able to see the markup. Always edge cases where things do not work as you expect. Braille software already has templates. Just have to translate to ebraille. Braille displays depend on the CSS not the class names. Focus on templates and html
Willow F – the codes, like in Duxbury, do not have to change.
James B - they would change. New would rely more on styles and classes.
George K – no envision class attributes to be used for navigation. We already have navigation
Charles LP – having reserved class names is interoperability. The same file can be taken different places and countries, and it will confirm to the different style sheets to match the local formatting. You can have one class used in multiple different places.
Christian E – reiterate for page number and line numbers – no html element for markup. Need to attach a class attribute to this span.
Willow F – part of the problem is needing to facilitate communication between braille transcription and other software. Reserving class names makes it easier for transcriber software to support. The goal is to not have braille fractured where support is not universal.
James B – how is there a danger that a file from a specific software can’t be opened by a specific thing. Braille rendering is always the CSS.
Willow F – the big thing driving me is that braille blaster is about opening different file types. See strange things and is difficult to support. Class names will not eliminate problems, but can make easier.
Nicole G – to chime in on page numbers. To ensure where base line so that everyone doing a specific way. We want to make sure the page number Is available. Pagination is important for our students.
Richard O – reading systems toggling the display of certain things. To render items differently. Can be an interaction between a reading system and the CSS.
Willow F – good point.
Robert J – supports reserved class names.
Willow F - with the CSS style sheet – idea of limited number of types of formatting that you can do on the braille page. Reserved class names make the process easier. Should be able to switch between style sheets to have documents match the local formatting
James B - to summarize - defining objects with no special html tags, navigation on items, showing and hiding items, applying different style sheets, consistency of authoring.
Willow F - best practices document – what types of braille are not reflected?
Christian E - should we have the prefix to say a class name out of a set of class names.
Willow F - we can make it a ticket and discuss it in greater detail.
James B – music and multi examples exist.
Willow F – wants to investigate math more. Lot of use cases we can ensure we address. Math needs more clarity.
Jen G – BANA updating graphing calculator guideline. Would examples from that be helpful.
Willow F – it can be.
Avneesh Singh, Caryn Navy, Charles LaPierre, David Holladay, Doug Schepers, Edwin Wong, Francisco Martínez, James Bowden, Jen Goulden, Jennifer Dunnam, Jmegginson, John Ylioja, Ka, Maharshi, Melanie Romer Noel, Nicole, Richard Orme, Robert S. Jaquiss, Sarah Welch, Steve Noble, Susan Osterhaus, Svetlana Vasilyeva, Willow Free
Willow F – tagging document is the highest priority issue. Will start with metadata in meeting. Before we get into that – asks for people to review documents in meeting invite and make issues in GitHub. If not comfortable with GitHub – can email mailing list. The last option is to email Willow directly. This is least preferred because we want everyone to be aware of what is happening.
James B – way to find out when the wiki document is changed? Notifications?
Willow F – can set yourself as a watcher of the project. Will send instructions to the mailing list.
Avneesh S – changes will be a comment on the issue. Will alert watchers
Willow F – Nicole made a very helpful table. What to require versus what to make optional. The wiki is to make this into a simpler format. Broken down into where the data comes from. The idea is to agree on what we want to require. Then can make decisions on what schema to base metadata requirements on.
The first section is Dublin core – dc description for that.
John Y – in the Dublin core description is a synopsis, or do we just use as complete or incomplete status.
Willow F – was thinking complete or incomplete.
Doug S – don’t see the point in using a metadata field for something that is not a description. Makes it hard to find anything, or to impose microformats. Why not mint a new field. Make a field called quota extend
Willow F – great point. We need to revisit that issue in GitHub.
Doug S – I fear that we might be reusing existing fields rather than minting our own. Good to reuse or not to misuse.
Avneesh S – great feedback. Let’s split it into 2 parts. Is this information metadata should convey? Can dc convey this? In this case we need metadata to convey this information. We may need to investigate how to display this
James B – surprising that DC title is not listed. Title is the most important thing we need.
Willow F – probably an oversight on my part
James B – seem to recall something about using the html tag title. Looking at Daisy books, they seem to have both
Nicole – dc title
James B – dc metadata title
Nicole - if dc title is not showing up there. It should be.
James B - should we have dc colon date?
Avneesh S - the title in html is the title of that specific file. The dc title if the title of the publication
James B - dc date is also important. Date of the original source, date of the original production.
Willow F – possible that I left that off. Will review and update
Francisco M – metadata categorized as optional that I think should be required. Like subject. Does the publisher refer to the print or braille version? Date for print version or braille version? Think also should be there.
Willow F – good point. The original idea was only to require what we absolutely must. We can revisit on adding things to the original
Avneesh S - we need to think about if the field would be used by majority of people, or if mandatory then people would put garbage in. keep in mind
James B - was going to say a very similar thing. Not every book will have all these fields. Like not every file will have an isbn. Do we need required, recommended, and optional.
Willow F – good suggestion. Like the three categories
Nicole – important point about the isbn – rational to require a unique file set?
Willow F - our goal is to make as perfect as possible
Robert J – are we presuming that we are always starting with a print document into braille?
Willow F – has a minimum page size.
Robert J – thinking of music scores, and things where the original format of the braille page is important
Willow F can set minimum page size to whatever is needed.
Doug S – jumping back to the required optional thing. We may find that if something is optional people put in junk answers. Then if one thing is filled out then you must fill out associated fields. Think we want to capture that as a nested field.
Willow F - interesting idea
Doug S - will see if can find any examples and make issue
Willow F – take subject – made a good point about subject being required. Individual places can require subjects. Wouldn’t be required for the file type itself.
James B - how to check unique identifiers. GUID – globally unique identifiers. Way to make unique without the isbn.
Nicole - next question on how to get people to make
James B – get the authoring software to make them. Just need to generate once when you generate the book
Willow F - if we make it required, then any software would be required to include that feature
Franisco M – what is the purpose for metadata – just internal? Or a way to discover books? The focus will affect what is required
Willow F – really like the idea of a recommended section
Jen G - might be a concern that people would not be taking seriously as optional. Maybe name the name recommended instead of optional
Willow F – probably are safe to change title to recommended. If needed in the future can make an optional section
James B - metadata data useful for libraries, and the actual user. User can make meaningful lists instead of just file name strings are that meaningless
Francisco M - minimum required metadata make it easier to put into different catalogues
Charles LP – if we want ebraille file in bookshare then we need metadata.
Willow F – we will take wiki and turn it into best practices document. The wiki is to help make discussion easier.
James B – suggests grade level is very confusing globally. Maybe use education level
Willow F - that is an easy change
Doug S - potential for confusion with education level. Is it the minimum education level or the appropriate level?
James B – in the UK we have reading age.
Jen G – reading level in Canada
Willow F - education audience? Can update in the wiki and make issues
Jen G - braille code in recommended versus required? Regions where a second language is prevalent?
James B - more than one braille code in a book? Like a dual language dictionary?
Willow F - maybe in the order of which one appears most, then list the others
Charles LP – would make the braille code required
Willow F – compelling reason. Including back translating
Anja Lehmann, Avneesh Singh, Charles LaPierre, Christian Egli, Dan Gardner, Edwin Wong, Francisco Martínez, George Kerscher, James Bowden, Jen Goulden, Jennifer Dunnam, Jmegginson, John Yiloja, Maharshi, Matt Garrish, Nicole, Richard Orme, Robert S. Jaquiss, Sarah Welch, Steve Noble, Susan Osterhaus, Svetlana Vasilyeva, Willow Free
Next – January 23, February 13, in general the 2nd and 4th Tuesday of the month
Willow F – confusion is my fault. Proposing a system of editors and authors. Editors group small. Help prevent errors. Writing style more consistent. Authors will be basically anyone who makes tickets and proposed changes. Tickets will be looked at by editors to implement changes. Authors need to know how to make an issue and how to comment on an issue.
George K – If not familiar with html – the most important thing is to make your comment, and they can do the coding.
Willow F – the thinking is that we don’t need to rewrite the html spec (i.e., p for paragraph). Take the things in html and give guidance on how those can best be used for braille.
George K – want to use the semantics present in html
Matt G – best practices. We are not forcing people to do everything the same way.
James B – do we somewhere to define the minimum html that is supported and any exclusions that are not supported.
Matt G – difference between best practices and specification document
Willow F – we will also have exemplars of this file type.
Avneesh S – similar discussion in epub working group a decade ago. Support for html comes by default from the browser
George K – the epub systems today use the web browser to present information. Not writing code themselves
James B – some braille displays run on bare bones and don’t have a premade web browser
Willow F – future creative solution - software that converts the ebraile file into something they can understand.
Willow F – element, boxed text, div, reserved class values. Choice of the word reserved is helping guide the development and help inform on where to go, how to work with spec
Charles LP – one caveat – freedom to do whatever they want. Problem is file then goes somewhere else and they can’t override the reserved classes.
Matt G – reserved aspect is the class names that are defined by best practices. Can’t reuse names.
James B – initially thought no reserved words, all braille programs use different names. We don’t need reserved class names. Helpful to know why we need or don’t need reserved class names.
Willow F – the Bana template can stay the same with the names used. The user experience is not impacted by reserved names used. The reserved names happen in the background.
Christian E – the ebraille format is also a distribution format. To exchange between different areas. Some of the things are just identified by class name.
James B – don’t need reserved class names to go between countries. Need to work out a list of things to note. Thinking of navigation functions for the user.
George K – if we have a paragraph and paragraphs are normally like “this” then we don’t need a class name for the default paragraph. Do we need a class name for the paragraphs that are different?
James B – yes
George K – so when we are taking a file from a publisher not in braille, we would get the default braille out. task is to apply the styles that are different in this case.
Willow F – nimas accessible file type is great. It is also permissive and the files you get are great mostly. Occasionally get files where things were done a bit differently but still to the specification. What happens is that we now must decide – do we ignore the unusual thing or support it? What to do with the next unusual thing? For braille blasters they had to define what they would use and what they would ignore.
James B – same issue with epub files.
Willow F – initially needed to transform braille files. Make a robust file type and let reading systems do their thing
James B – disagrees. For transcribe note – if not reserved name, then can’t directly navigate to transcriber note.
John Y – value in exploring what elements are unique to braille.
Avneesh S – want to highlight difference between html and ebraille. Html comes with its own CSS. For things like ebraille interoperability becomes very important.
Robert J – on the reserved class names – any thought as to something like picture caption
Willow F – link in agenda takes to best practices document. It is rendered and doesn’t show all the code. For emphasis could have used a span – the problem with doing that is that screen readers may not recognize it. if you have emphasis and put a class on it. we don’t need a perfect spec for the mvp – but we should be thinking of these things as best as we can.
Anja Lehmann, Avneesh Singh, Caryn Navy, Charles LaPierre, Christian Egli, David Holladay, Doug Schepers, Edwin Wong, Francisco Martínez, George Kerscher, James Bowden, Jen Goulden, Jennifer Dunnam, Jmegginson, John Ylioja, Joshua Miele, Ka, Maharshi, Matt Garrish, Michael Ryan Hunsaker, Nicole Gaines, O’Reilly Alice, Peter Brass, Robert S. Jaquiss, Sara Larkin, Sarah Welch, Steve Noble, Susan Osterhaus, Svetlana Vasilyeva, Willow Freeman
We would like you to use these class values when applicable. How to propose changes? If you know how to use git hub – pull down changes, make edits yourself on separate branch, make pool request, edit team reviews, then it is approved or not. Not realistic way for most people.
Alternative method - copy text you want to change. Paste it into a ticket, put what you propose to be changed and why.
GitHub desktop – does a lot of the git hub stuff for you.
How straightforward the change can also change the complexity of using git hub.
Ticket and issue are different things.
Issue is about one thing you want to see changed. Once consensus, then editor makes changes and do pr, merge, then close issue.
Tagging best practices document.
Metadata document.
Can do issue for pull request.
Tracking changes - all changes need an issue.
Willow to make wiki to describe process.
Robert J - result is ebrf format is html document.
George K – all operating systems support html. Building reading system would take advantage of all the stuff that is built in
Willow F – exemplars of ebrf, and validator
Joshua M – likes wiki idea. In addition to tooling, talk about recommended workflow. Also cultural stuff about GitHub. Cli – recommended for screen reader users
Bash is the interface recommended for command line, it is universal, allows cut and paste.
To edit in GH wiki – send email to Avneesh, he will check permissions.
Maybe use markdown instead of html – Matt – says has seen it tried but not seen it successful.
Christian E – thought text only format would be easier to edit.
Charles LP – abandoned because of complete tables. Caused the switch back to html.
James B – one monolithic document or break it down?
Willow F – have a best practices document for tagging, one for CSS, and one for metadata, spine, open to suggestions.
Still questions for CSS group.
Willow F will get wiki going, layout process, and how to work with GitHub.
Next meeting – second Tuesday of January, January 9, 2024