ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
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

  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).