more on web export

pviton's picture

SWP 6.0.20 on MSWin

Here are some problems mostly connected
with exporting SWP6 documents as web files.
(Intended as a supplement to jsmeyer's
recent post, though I think his point has
been mentioned before, possibly during the
beta test).

*** References

The attached refs2_1.gif shows some additional
text added to the Std Latex Article: we have a
label for the section title, a bibtex reference
and an equation with a key. Then we reference
the two labels.

refs2_3.gif shows the exported result. Basically,
all three refs get exported as blank spaces.

*** Is this a bug?

Well, no. Creating Documents (p. 102) says
that these elements are not exported. It gives
as a reason: "Because HTML files are designed
for online use instead of in print". I have
to say that this reason makes no sense to me.
It appears to be saying that you shouldn't be
exporting scholarly work as a web file; but if
so, what's the point of having the option?
This after all is *Scientific* Word, not a
general-purpose web editor.

Be that as it may, the upshot is that, as
far as I can see, the program is presently
useless for generating HTML versions of
serious scholarly work.

The problem may be unfixable for SN (no LaTeX)
but for SW and SWP, it would seem to be possible
to use the contents of the aux and/or blg files
(when they exist, and even to produce them
silently when they don't) to get these elements
exported correctly. That's what most of the
latex-to-html converters now available do.

*** Footnotes

Footnotes are also problematic. While the footnote
markers (ie the superscripted numbers) are always
present, the contents are only usable (ie viewable)
if they're "open" in the SWP6 editor when you export
the document. Note that the *contents* of the
footnote seems to be present in the xhtml file:
it's just that if the footnotes are closed
in the SWP6 editor there's no way of actually
viewing them in the web browser.

Assuming that this isn't a bug, is there a
case that not being able to see the
footnote contents is *ever* a reasonable choice?
Isn't this in effect saying to your readers:
there's something here that I thought important
to mention, but you can't see it, sorry.
It seems to me that you should always make
footnotes viewable in the generated html.

Finally, refs2_4.gif shows what can go wrong
when footnotes are made visible: I added a
footnote to "appendices" in para 1 of the text
and exported it with footnotes open.

*** The zip file.

You have a document and you export it to
a web file; SWP6 creates a zip file. You
then make a few changes in the source and
you want to re-export it to the same zip file.
SWP6 will not allow you to do this: it will
not over-write an existing zip file. It *asks*
you if you want to overwrite the existing file,
but if you say Yes, the result is "Web file
not created".

*** The zip file (2)

In several export attempts, the zip file contained
the xhtml file, but no css files. I don't know
what caused this, and it doesn't seem to
be regular. Once it happens, it seems to be
a persistent feature of the web export; but
restarting the program and re-exporting
often seems to put it right.

*** Direct preview

refs2_2.gif shows what can happen when
you direct-preview the file. Note that
material on the right is cut off; and there
is no horizonal scroll bar that would enable
you to view it. Reducing the Scale doesn't
help: the font gets smaller, but additional
material doesn't become visible.

I believe this doesn't always happen, and
when it does may depend on the way the
user has sized the program's window;
nevertheless, it shouldn't happen at all.

*** css files in the zip archive

As I understand it, the zip archive is meant
to be unzipped when you want to put the document
on the web. The archive includes a bunch of css files
like article.css, which are usually just copies of the
files supplied with the program. One exception is
my.css. If the user has utilized the SWP6 css editor,
this file will be document-specific, so there is the
possibilty of clashes if you want to put several
exported xhtml files in the same web directory.
I think you should try to avoid this. One obvious
way would be to rename my.css to match the xhtml
file name, so that, eg, if the xhtml file is
pav_article.xhtml then my.css would be
included in the zip file as pav_article_my.css
(and of course referenced by that name in the
xhtml file).

refs2_1.gif77.68 KB
refs2_2.gif60.46 KB
refs2_3.gif38.55 KB
refs2_4.gif39.55 KB