Bug#699950: Festival-doc was orphaned by Kartik - should this be removed from the archive at this point?

Dear all,

I will try to give my two cents, although I'm not an a11y expert :-)

2013/2/10 Peter Drysdale <drysdalepete@gmail.com>

Dear Maintainer/Uploaders of festival and Users of festival-docs,

To clarify the situation. festival-doc currently contains a html and ps (Postscript) version of
the "Festival Manual". The version number is 1.4.2 and dates from 25th July 2001.

CMU (the current employer of Prof. Alan Black - one of the original authors of festival)
has an online version of the manual version number 1.4.3 and dated 27th December 2002.

CSTR at University of Edinburgh - (the University where festival was originally written) has an
online version of the manual version number 1.4.0 and dated 17th July 1999.

No later copies of the main content of "Festival Manual" appear to have been published.

The current Debian festival (not festival-docs) package ships a copy of "Festival Manual"
as part of the festival deb file. It is labelled 1.4.3. It like all the others is old.

It is superior to the CMU online version in one respect the festival Scheme interpreter
function list at the end of this manual is dynamically regenerated from the source
code each time we build the festival package. Thus is reflects the "function comment lines"

of the current Debian version of festival.

Even though the Festival documentation may be old it is still quite accurate, as Festival has not changed much in the past 10 years :-)

Please note the copy of "Festival manual" we ship with the festival deb is in "info" format

and may be accessed using "info festival" command.

I didn't really care which format I use hence my suggestion that we drop festival-doc. BUT...

The format may be important from an a11y perspective for our users !

Based your combined knowledge a11y issues could everyone give an opinion on "info"
vs "html" vs "ps". Please everyone give your opinion on this.

I would say that HTML is better than PS for accessibility. For instance, I am not able to select text using evince from the festival manual included in the festival-doc package. Maybe modern PS or modern PDF formats such as [PDF/UA](http://en.wikipedia.org/wiki/PDF/UA) are good for accessibility purposes, but I have seen many more a11y-ready web pages than a11y-ready PDF files.

Regarding the info format... I don't know much about its a11y... :-S

Should we just choose one of those formats not necessarily the current "info" format
for bundling with festival deb and drop festival-doc or are the additional formats important?

I strongly suggest from now on we build whatever manuals regenerated from the actual
festival source code in our current deb. This suggests festival-doc even if it is decided
to continue to exist should be a binary package built from the common festival source package,

i.e. from the debian/control and debian/rules files of the festival source package.

I agree. The festival-doc source package should be removed and the festival-doc and speech-tools-doc binary packages should be built from festival and speech-tools sources respectively.

Based on this I think it would be appropriate for JP as maintainer of festival to issue a

Debian ITA over the orphaned packages while we decide the formats and then choose

whether we ship a binary festival-doc package built from festival source package or only ship the one format
(as best serves the need of a11y users) inside the festival binary package.

I look forward to hearing your experiences on formats from a a11y perspective. Comments?

I hope you agree that we should regenerate any shipped version of "Festival manual" (even
though the bulk text is old) from our source code as we do for the current "info" format (which
may change based on your input). Comments?

I agree completely.

I have not pursued the speech-tools angle yet, but as a precaution I think JP should Debian ITA in

his capacity as maintainer of speech-tools while we figure out how to integrate its building out
of the common source or drop etc...

with very best regards,
Peter

Best regards,

Sergio