On Fri, 2007-08-31 at 01:46 +0100, Martyn Shaw wrote:
> For me, xhtml is better; I can scale the font (locally, so it wraps),
> copy, paste, print easily (admittedly 'print' may not be as good). I
> believe that accessibility is easier and anybody with a web browser can
> read it.
> It's not that I hate pdfs, if I want to print something out, such as a
> service manual for the washing machine, then they are fine. But on
> screen? At 1024x768? A4 paper must be about 3000xsomething or more.
> Appropriate means for the medium, I say, and people using Audacity are
> on a computer of some sort aren't they?
The problem is that an awful lot of computer illiterate users want to
print out "the manual" rather than read it on their screen (and have no
idea how to open a local file in a web browser anyway).
This was why I started converting the HTML manual for audacity 1.2 into
a PDF using a format converter, so that the people who wanted to print
the lot didn't have to do each page as they went, and they could
download it as a single file (most can't cope with zip archives
The problem with this approach was two-fold. Firstly, you had to write
the manual as HTML, so it was a pain to update (it wasn't very WYSWYG
friendly, and the output of most WYSWYG applications wouldn't convert to
PDF properly). Secondly, the formatting of the PDF often didn't match
the formatting of the HTML, because the converter had lousy style
support and ignored most of the formatting.
These were the main reasons for moving the manual onto the wiki at
This makes editing easier (because you don't need to mess with HTML),
and it outputs nice, reasonably standards compliant XHTML on the
Internet. There is an interface for adding exporters to mediawiki, so
the idea (mostly Dominic's) was to use this interface to export other
formats we wanted the documentation in, mainly (at that point) PDF.
The problem is that PDF export for mediawiki isn't terribly mature
(hence why it's currently broken), and there is no good way to do static
HTML pages other than by spidering the site, which isn't a terribly good
way to do it.
The wxHTML viewer gives us another set of problems, because it doesn't
support XHTML. It doesn't even do all the things in HTML 4.0, but
basically does the cut-down feature set of the Microsoft HTML help
browser. This is a pain, because it doesn't (as far as I know) include
any style support. So creating content for it is messy and non-standard.
This is where the drive to not use the program internal help came from -
creating it was a right pain because it won't take content intended for
modern web browsers.