The Python Papers Edition One
tennessee at tennessee.id.au
Thu Nov 23 06:28:57 CET 2006
On 11/23/06, Stephen Hansen <shansen at advpubtech.com> wrote:
> > 3.) Can I have an HTML version?
> > A) No, we like it pretty.
> The interesting thing is, there's nothing in your layout or format that you can't do with some nice standards-compliant HTML and CSS. It could look identical as HTML-- and be significantly more "reachable" by people, easier for them to use and read, link to, and so on and so forth.
> Plus you could stick some Google adwords ads on it :)
> But, really... if you're eventually wanting this to be a printed/published/mailed sort of thing, I can understand why you'd want to do it as a PDF... but you will be limiting your audience in the meantime. A lot of people just find it too tedious and difficult, and if your goal is to reach people and communicate....
> Why not do both? Might take a bit more work-- but the layout you have isn't that hard to do in HTML, and there's gotta be a way to html2pdf... I've never wanted to, but there has to be. =)
Thanks v. much for the comments. Not a week goes by that this
limitation doesn't irk me. All I can say is that I feel your pain, and
also I really appreciate the response, because the project succeeds
only according to the enthusiasm that can be generated.
So, why aren't we publishing in HTML and not worrying about PDF?
* Document lodgement in online archives. PDFs are a nice bundled
format which preserves formatting, paging etc, isn't resolution
* Page numbers and tables of contents
* Lack of a WYSIWYG gui for advance HTML layouts fully supporting
all browser differences.
* Source application is currently OpenOffice, which *definitely*
doesn't support good enough HTML output.
* If you say LaTex, I'll eat your brain. Or my hat. Unless I'm
seriously underrating it, but I don't think so.
* Scribus crashed multiple times when I was testing it out using on
our first version. I think it's too big.
In my explorations, I have found:
* pdf2html is a lame duck
* html2pdf can't be done
The only possibility is going from something like odt to both PDF and
html, but you seriously lose out in using OpenOffice to generate the
HTML. I haven't been able to identify a truly working upstream
application from which both HTML and PDF can be derived.
PDF2ASCII works okay, but you lose your images.
Docbook format appears to be a possibility, but it lacks a good GUI
for editing in, so you're talking raw XML. OpenOffice claims to
support it, but I couldn't get it to work properly.
Article submissions need to be handled in a variety of formats,
usually word or OpenOffice are used, for example.
It might be possible using Python and ReportLabs to *write* something
which would support a layout which could be translated into HTML and
PDF without a major loss of quality, but this is a major project in
its own right. It would also require that authors make proper use of
sections and heading options rather than just fiddling with the font
Trust me, I thought about it. It still bugs me. It will probably bug
me forever. At this stage, the only viable options I can see are to go
to HTML as the primary format, increase the workload involved in
typesetting and layout, and abandon the idea of a print-friendly
layout, or to continue with the current situation despite its
If anyone has any good ideas for how to cope as a publisher with these
difficulties, I'm all ears. I want something that Just Works. If
there's a Good Way to Do Things, I'll happily adopt it.
More information about the Python-list