From: Ville Voipio <ville.voipio@kpatents.com>
Subject: Re: Context, LaTeX, or an XML for academic writing?
Date: Thu, 12 May 2005 16:46:58 +0300 [thread overview]
Message-ID: <42835E52.20802@kpatents.com> (raw)
In-Reply-To: <4281495B.5020200@gmail.com>
> Actually your comment here might suggest how far we have to go then, as
> I'd consider my wishlist a very roughly stated but really quite minimal
> set of requirements for academic writing.
Well, if you drop the RTF part, then your wishlist is not that
difficult. However, there are some requirements which look trivial at
first but are rather difficult to make well. The most important of these
is the difference between HTML and a printed book.
As long as you use only running text (no illustrations, graphs, images,
formulae, tables), there is no problem. By making suitable templates the
text may be typeset well and it works as a web page (or a collection of
web pages). In HTML you have less control over the layout, but as the
user has the control, everything is well.
Some problems arise when you add any special elements to the text.
Formulae are a good example. Even though you might in principle use
MathML or equivalent, the browser support is not built-in, so most users
cannot read the formulae. You'll need to use images, but then the best
resolution is hard to find. The same goes with images, SVG is not ready
yet, so resolution problems are really difficult. Illustrations which
print well at high resolution do not necessarily look good at screen
resolution.
But the real problems start with floats. Where do you put a picture with
its captions on a web page? Or a footnote? One common solution is to put
them behind a link. However, some people (yours truly included) find
that following the links back and forth is clumsy. Another solution
would be to place the figures within the text, but then we have all
sorts of typesetting problems without having a typesetting engine.
Of course, you can make miracles with XHTML/CSS. You can make something
that looks laike pages from a book, for example. But then, why not
really use PDF instead? Because then you can be sure of the layout.
The hyperlink navigation paradigm of HTML is a good one for many
purposes. It is not a good one for a book. If I have a book (or a PDF),
I can easily verify I've read it to the last comma. With a more
complicated (even a simple tree without loops) HTML document trying the
same reminds me of the "Maze all different" in the old "Adventure" game
(Colossal Cave Adventure by Will Growther).
I am not saying HTML is bad and PDF good. HTML is extremely good for
many purposes. Wiki is a good example of this, and so are many web
pages. But as HTML is not necessarily a good form for a book,
concentrating on PDF is probably a better idea.
---
> Since posting I've thought a bit more about why I wanted RTF, and
> realised it wouldn't do what I wanted anyway. The 'inter-operation with
> Word users' I was referring to is primarily this: it's common amongst
> academics I know here in Australia to use some of the collaboration
> features of Word (marginal comments and revision control, particularly).
> RTF wouldn't actually help with those anyway. So there's really no way
> around this without using Word, which I will only do at gunpoint.
Well, if everyone around you is using Word and requires you to
collaborate by using Word, you are up to your lower back in alligators.
On the other hand, there are ways around this. What I use when
commenting on other people's texts, I want to have the texts as PDF.
Then I just simply write a mail with my comments:
"p. 123, paragraph 2: Not so. Dr. Frankenstein proved this to be wrong
in 1974, see Journal of Unlikely Science, 1865, pp. 1456-1505"
p.127, figure 2.13: I don't get it."
Exactly same thing as scribbling things into the margin. This method is
independent of the programs used and does not really take any more time.
I have found only two shortcomings with this method: 1. it is difficult
to combine comments from several reviewers, 2. you cannot edit the text
yourself even if you wanted to. The first one is a problem with Word
documents, as well, and the second one is not always so desirable, anyway.
Really, I hate it when people send me their Word files. I am quite
convinced I am not the only one. The annotation mechanism in Word is
similar to almost everything else in the program: looks easy, feels easy
at first, makes you run circles on the walls in the end.
- Ville
next prev parent reply other threads:[~2005-05-12 13:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-07 2:58 CB
2005-05-09 9:48 ` Ville Voipio
2005-05-10 23:52 ` CB
2005-05-11 6:52 ` Henning Hraban Ramm
2005-05-12 13:46 ` Ville Voipio [this message]
2005-05-13 0:05 ` CB
2005-05-14 12:45 Tobias Wolf
2005-05-16 17:50 ` John R. Culleton
2005-05-17 0:59 ` Tobias Burnus
2005-05-17 12:41 ` Tobias Wolf
2005-05-17 4:03 ` Matthias Weber
[not found] ` <e06bd0fe050517055047c3210b@mail.gmail.com>
2005-05-17 12:52 ` Tobias Wolf
2005-05-17 22:41 Ville Voipio
2005-05-18 2:10 ` Paul Tremblay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42835E52.20802@kpatents.com \
--to=ville.voipio@kpatents.com \
--cc=ntg-context@ntg.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).