Steve Mack has shared a form letter response from Simon Power that has surely been sent to hundreds of other people about the Guilt Upon Accusation law ‘Section 92A’. Hon Simon Power is now responsible for S92A and he could stop it but he is not doing so and now he is trying to distance National from it. This means we’re getting through. Read on to see the letter, and our analysis of how it’s false…

Steve Mack received this letter,

Dear Steve,

Thank you for your email regarding section 92A of the Copyright Act 1994, which comes into force on 28 February 2009. I have read and noted your concerns. I apologise for the time is has taken for me to, but I wanted to ensure you received the most up-to-date information.

The amendment to section 92 of the Copyright Act was passed through the House by the previous government. The new National-led government understands that many people are concerned about the effect of the legislation and we will monitor the implementation of section 92A closely.

This part of the response (which looks like a form letter and was surely sent to many people) is implying that they didn’t make this law.

Section 92A was supported by Judith Tizard (Labour) and Chris Finlayson (National).

Evidence of this can be found in who voted for it (every party aside from Greens and The Maori Party voted for it). Although United Future voted for it at the time they have now declared that they thought they were protecting artists but that they were wrong and that they are seeking to fix it.

When this was voted for it was National’s Chris Finlayson that supported Section 92A. Here’s a quote from parliamentary record by Chris Finlayson (National, Attorney General) saying why he supports S92A: It was due to “approaches by various commercial entities” (I’m not kidding, check the link)

However Simon Power is responsible for this now and he could stop it but he’s not. He’s taking a wait and see approach to S92A. This is irresponsible and poor leadership.

Remember that this letter is surely being sent to many people who will be fooled by it. If you have received this letter I suggest that you reply to these email addresses,

• s.power@ministers.govt.nz (Simon Power)
• s.joyce@ministers.govt.nz (Steven Joyce)
• c.finlayson@ministers.govt.nz (Chris Finlayson)

Please spread the word about this form letter because many people will be falsely convinced by it.

If you’re looking to write a letter you may find ideas here.

UPDATE: Many National MPs are now using this letter. Educate people about this by sending them to the Creative Freedom Foundation’s story on this.

With e-Book technology improving such as the recent announcement of the Amazon Kindle 2 they can now make digital books available to sight-impaired people by having the digital device read aloud, speaking every line of text. It seems like allowing people to have legally purchased digital books read aloud within their homes would be a good idea, however not everyone agrees.

From the news site Slashdot…

“The Author’s Guild claims that the new Kindle’s text-to-speech software is illegal, stating that ‘They don’t have the right to read a book out loud,’ said Paul Aiken, executive director of the Authors Guild. ‘That’s an audio right, which is derivative under copyright law.’ Forget for a moment that text-to-speech doesn’t copy an existing work. And forget the odd notion that the artificial enunciation of plain text is equivalent to a person’s nuanced and emotive reading. The Guild’s claim is that even to read out loud is a production akin to an illegal copy, or a public performance.”

The idea of course is that sight-impaired people should buy an audio copy of a book (if it’s available) or license the additional rights to hear the book. Reading aloud to your friend would be legal but having a device read to you may not be.

The digital age could allow equality (that blind people pay the same as the sighted and have the same range of books) but only through changes to Fair Dealing allowances in copyright law. More than that this could increase sales by making more books available to this community.

We’ve decided to add this as a possible goal for the CFF so discuss this possible goal on our forum and tell us if you agree.

PilferPage is a simple file format and a set of converters that convert PilferPages to HTML 3.2, HTML 4.01, XHTML 1, HTML 5, XHTML 5, XSL-FO 1.1, Flex 2, XUL 1, CSV, and ODF 1.1.

Here’s the PilferPage Website with a demo showing a version with basic table support. It’s not very advanced, infact it’s very primitive, but it should give you an idea of it. If you want to contribute patches to the XSLT then download the code and email me back.

At a bare minimum Tables consist of a flat list of rows containing cells. They don’t necessarily contain headers or footers, or cell spans,  or hierarchical rows. As it turns out however when you add a few more features then Tables become a generalised model for both DataGrids and TreeViews so –for the purposes of comparing tables– we’ll call all three of these Tables.

Hierarchical Rows

In HTML, XSL-FO, CSV, and ODF table rows are a one-dimensional list, whereas in XUL rows can be hierarchical (the Subject column, above). Hierarchical rows are a simple way of supporting multi-column TreeViews. HTML, DocBook, XSL-FO, ODF and CSV do not inherently support row hierarchy but you can fake this through formatting (style padding or indenting characters). In HTML you can make this faux-hierarchy faux-interactive with JavaScript. So hierarchical rows can be represented, and they seem like a useful feature for Pilferpage.

Hierarchical Tables

All of the markup-language-based formats (HTML, XSL-FO, ODF, DocBook) support hierarchical tables; which leaves CSV as the one that doesn’t. For CSV you’d have to render different tables one after another (or, more sensibly, as separate CSV files). Providing there was a way of extracting tables from the page (perhaps with some URL parameters) then CSV could use hierarchical tables, so again this seems like a useful feature for pivot-tables and general data drilling.

Subtables

Subtables however are not useful — these are typically an awkward way of encoding cell-spanning and row-spanning by declaring that multiple nested tables should be treated as a single unified table. I believe that Subtables will be deprecated in ODF 1.2.

Pilferpage won’t support them.

Headers and Footers

As well as providing visual cues table headers and footers allow cell data to be accessible to disabled people. A disabled person navigating a cell that reads “11%” may not be able to easily glance up the column in order to understand that it’s about “Elbow Growth” but by explicitly encoding headers the table can be made practically usable to these people. Another benefit of clearly articulating the table header/footer is that software can reuse the data more easily. Most DataGrids expect explicit column headings, for example.

Column Headers and Footers

HTML, ODF, XSL-FO and Flex all support basic single-level column headers.

HTML, ODF, and XSL-FO support single-level column footers.

HTML and ODF support multi-level column headers and footers.

Flex does not appear to support table footers, multiple column headers, multi-level headers or footers, or cell headers/footers.

CSV doesn’t support table headers or footers. Some software implies headers by assuming that it’s the first row.

HTML uses table headings and footers to allow progressive loading of table data via the <thead> <tbody> and <tfoot> tags. The idea is that a browser may receive the table header, then the footer, and then the table body. The browser keeps filling out the table body as more and more data is streamed in. If browsers support this reliably then it would be useful to rearrange a pilferpage in order to support this in HTML.

Cell Headers and Footers

There’s a difference between column headers and cell headers,

In the screenshot the yellow table cells mark a cross-section from a table that only shows the top-left and bottom-right portions. This technique is already popular, and to make this accessible they couldn’t use column headings — they’d need cell headings. So, by cell headings we mean that each cell references the appropriate cell headings rather than headings being implied by columns or rows.

HTML and ODF support cell headings. XSL-FO, CSV, and Flex do not.

Another example is the periodic table of elements where it’s groupings could be expressed by cell headings. Note the background colours:

Heading Levels

Again, this is perhaps best described by a screenshot,

The ‘System’ heading is a grouping of the ‘Metal Parts‘ and ‘Wood Parts‘ headings. As well as the cells being headings the relationship between these three cells is expressed by encoding heading levels.

HTML and ODF support hierarchical cell headings by way of putting textural headings inside cell headings. XSL-FO, Flex, and CSV do not.

It seems that an ambiguity can occur when the heading levels are encoded using conventional text headings: if in HTML a cell heading contains H1 and H3 and another cell heading contains H2 then in which order should a screen-reader speak the headings? Because of this it seems that it would be better to encode cell headings per-cell, perhaps with a heading-level attribute.

Diagonal Table Headings

Diagonal table headings (or labels) are used to describe columns and rows in a more compact notation. Given a table of,

One would make diagonal table heading of,

They’re popular in Asia, particularly in China and Japan. There seems to be some disagreement as to whether diagonal table headings are headings or labels but in both cases a user navigating cell data may want to access a description while browsing cell data. The distinction between heading or label may only be useful when browsing a table hierarchically, where headings (but not labels) would presumably group cell headings. Personally I’d say that they’re headings and not labels.

These Diagonal Table Headings can also be multi-level. In the following table I’ve coloured the headings,

And sometimes they even cram a title in there…

While in English the letters do appear cramped it’s not the same for the Chinese language,

(source: Diagonal Table Header Specification)

HTML, CSV, Flex, do not support them diagonal table headings. ODF doesn’t yet support it although there is a proposal to support diagonal table headings in OpenOffice.org (and ODF). Unfortunately no one seems to be making much progress here. Chinese versions of Microsoft Office and OpenOffice.org appear to support it (via UOF and .doc) but these aren’t part of ODF. So, how do we want diagonal headings in Pilferpage? Well, as there’s no output format it’s probably not worth the bother.

But it’s worth considering to ensure that it wouldn’t break our assumptions about table data-structures; that it can build upon our existing table heading hierarchies. With some simple rules it looks like Pilferpage could support this,

1. Where there’s an attribute of diagonalHeading=”right down” in the <cell> tag. Values are up/right/down/left.
2. This same cell should be empty (only text nodes of whitespace in the cell).
3. From this cell any cells along the axis (depending on the diagonalHeading) must span in that direction to the edges of the table.

If a Pilferpage table does this then we would have enough information to generate a diagonal table header.

These diagonal table headings can appear in any cell, so you can get diagonal table footers too. Perhaps then it should be an attribute of diagonalTitle or aggregateTitle where you could specify several formatting options.

Spanning Cells

HTML, ODF, and XSL-FO cells can be spanned down or right but not left or up or in arbitrary shapes (for example, ‘L’ shaped spans aren’t possible).

Flex and CSV do not support cell spanning.

Style

For now I’m just going to declare these out of scope. It’s too big of a topic.

Request For Comment

I probably haven’t gotten everything right so please post comments and I’ll update the post accordingly. Cheers!

[1] It’s an old technique there. [2] Just kidding, no one uses CALS.