Reformat tables from spatial to linear as needed

[wfree-aph]

As a multiline braille display user, I want the reading software I am using to use the markup of tables to reformat them from a spatial layout to a linear one at my command.

Detail: Tables in print can be very large. They typically become even larger when transcribed into braille. On a multiline braille display, you could theoretically view a table of almost any horizontal or vertical size in a spatial layout. However, the viewing process could be unenjoyable because of the need to pan left, right, up, and down. Additionally, users may find that information can sometimes be more easily processed in a linear format.

Additionally, a spatial table may not fit on all devices and so it may be preferable to automatically switch a spatial table to a linear one upon opening the file.

Currently tables have no markup in traditional braille files and there are no instructions included with print files to allow for this kind of reformatting.

The terms spatial and linear are meant to be braille code agnostic, so that the ideas can be applied regardless of a braille region's formatting rules. Spatial just means laid out to resemble the print table, while linear means laid out in more of a listed format.

Proposal: The creator of braille documents should use markup to identify the column and row headings and all cell contents of a table. They should also specify whether a table would be better viewed in a spatial or linear format.

Instructions for displaying tables in spatial and linear formats should be included in the electronic braille file so that reading software can accurately reproduce these formats and switch between them as the user or the hardware requires. An example here would be using CSS.

[jrbowden]

I agree that tables should be well marked up. We may need information in addition to standard HTML tags and attributes to allow a rendering device to choose the most appropriate method for the table.

Note also that there are many more ways to display a table: BANA has at least four methods and there may well be others internationally.

Note also that trnsposing columns and rows is also used to make tables more usable in braille. Consider for example a rainfall table, 12 columns and two rows. In braille, much better 12 rows by two columns. We probably need to carefully consider what is needed for tables.

[mattgarrish]

I'm not sure how to assess this issue against the existing publishing formats. They all allow table markup, and usually reformatting at the user request isn't part of the format. CSS media queries don't sound like a fit, as they would trigger reformatting based on characteristics of the device, for example, not a user request.

If additional information is needed on how to optimally reformat, then the extensibility comment I made in https://github.com/daisy/ebraille/issues/28#issuecomment-1271774574 probably applies here, too.

[bertfrees]

Media queries can also be based on user preferences. See the Media Queries Level 5 specification. So if we're only talking about switching the style of tables based on user preference, I see possibilities.

Note however that if we're also talking about switching content (which would be needed in case of pre-formatted tables), another mechanism is needed.

[mattgarrish]

So if we're only talking about switching the style of tables based on user preference, I see possibilities.

Ya, I guess I'm wondering if we want to push this onto publishers to add to every file with tables. There's an opportunity here for the reading system to provide this functionality by changing the display to, for example, list layouts. But this is becoming a technical detail and not something that should present a barrier to the existing formats.

[bertfrees]

As is the case with a lot of these use cases, it is not defined how much control the publisher should have over the exact layout and how much control the reading device should have, so I assume the most general case i.e. is that both need control.

Edit: Well I guess the description of this issue clearly mentions "the reading software [...] to reformat [tables]". But I'm not sure that is the only requirement 😊

[wfree-aph]

The markup required for this feature is available in xHTML and is mentioned in the Tagging Best Practices and CSS Best Practices documents. Other than that, this is a reading system feature that is outside of our control. Closing this issue as resolved.

[bertfrees]

I'm not sure if this is resolved.

The required markup is available, so if this is purely a reading system requirement, we can consider it resolved.

However if we want the eBraille creator to have some control over the content and style as well, more things are needed:

• use media queries to switch style based on characteristics of the device: OK
• use media queries to switch style based on user preferences: not covered (might be possible with media queries 5)
• use media queries to switch content (for pre-formatted tables) based on characteristics of the device and user preferences: not covered (might be possible if we consider using the picture + source elements for preformatted content)
• use CSS to format a table as a list or a spatial table: will be covered to some extend in styling best practices (soon but not yet)
• use CSS + JavaScript to do more complex formatting, such as transposing columns and rows, repeating headers, handling tables with complex axes, ...: not covered

@wfree-aph

[wfree-aph]

That's a fair assessment. Thank you @bertfrees. I will reopen this ticket.