Re: The Problems of TeX

Jim Diamond <Jim.Diamond@xxxxxxxxxxxxxxxxx> wrote:

Rowland McDonnell <real-address-in-sig@xxxxxxxxxxxxxxx> wrote:
Jim Diamond <Jim.Diamond@xxxxxxxxxxxxxxxxx> wrote:

Rowland McDonnell <real-address-in-sig@xxxxxxxxxxxxxxx> wrote:

<snip>

I don't see that many people are in a position to install a TeX
installation from scratch these days in any case - every one that I've
looked at has needed a stone-cold TeX+computer expert to set up.

I used to be a tetex user, until TE stopped maintaining it. I found
it straightforward to install texlive 2007 on a Linux system. It was
certainly more effort than installing the tetex packages for my
distribution of choice (Slackware), but it wasn't too hard. Note that
I had never done any non-trivial configuration of TeX distributions
before, so I didn't fall into the "tex installation/configuration
wizard" category. And I still don't.

<shrug> But you do fall into the category of `Unix expert', at a guess?

Humility prevents me from responding. :-)
And please, the word is "wizard". :-)

I use `Unix expert' rather than following your dialect.

I come from a land where multiple dialects of English are in use, and
often run in to each other. The rule is `you use your own dialect,
unless the other bugger can't understand you, in which case you aim for
something a bit more standard unless you really do want to be awkward'.

A Scotsman would view me with suspicion if I said `polis' instead of
`p'leece' (approx rendition of my usual pronunciation) - we each stick
to our own way of using the lingo and don't force our dialects on anyone
else (well, unless they're actual foreigners and `we' are BNP scum or
similar).

But seriously, I didn't think my Unix expertise (or lack thereof)
really came into the picture here,

I think it does, because you have learnt how to use the documentation.
I have not.

although I suppose someone who
knows almost nothing about Unix/Linux (as opposed to someone who has
reached "basic user" status) could have had to think a bit to install
it.

The point about `basic user' status with a free Unix is that you need to
learn a lot to get there. That means you've got to get the hang of the
documentation. Those who cannot do so never reach that level and don't
use Linux, do they?

Seriously, if you have a Linux system at hand, why not give it a
try and let me know?

I don't have Linux to hand. Two Macs by way of modern computers, and
we're not installing Linux on either. Really. Maybe one day, if other
computers become available, I might try a free Unix. But it wouldn't be
Linux. FreeBSB or NetBSD looked more up my street last time I peeked.
I really don't like the Linux approach at all.

I realize that it might be a bit time consuming,
but I would be interested to know if you find that as difficult as
your trials and tribulations with your Mac.

I've looked at Linux stuff, and it would take huge sums of money or very
serious threats to get me to go anywhere near it in use.

I've read Linux help forums. No way am I walking into one of those bear
pits, no fucking way!

As I recall, the only confusing issue was when I had a choice about
installing the whole thing or a subset. And I agree with your theme
there... it was not at all clear to me exactly what pieces I needed,
and how I would suffer later if I didn't install everything. So I
installed it all, which does take a fair bit of disk space.

That sort of thing is not related to the problems that I face.
Admittedly, it's very common problem and *is* a problem when you start
trying to use i-installer. Total disaster, is i-installer. You have to
decide what you need without knowing what's what, and also configure the
installation without having a clue what's what about anything at all.
Impossible to use intelligently. The documentation for i-installer is
some of the worst that I've ever met; the author is pretty bad at
documentation, being someone who rambles on verbosely without actually
achieving completeness or a structure that can be accessed by any method
other than `read it all through from start to finish'.

Yes, I've read recent documentation by him. Every time, I get an urge
to take the author by the throat and scream at him until he does better.
He can, I'm sure of it - bright enough, and good enough at writing
English. (if I didn't think he could do better, I wouldn't have the urge
to bully him into doing so)

I'm not a TeX installation/configuration wizard and never have been -
but I could install and configure OzTeX and CMacTeX without bother (or
without much bother in the case of CMacTeX, which is closer to the Unix
world than OzTeX0.
I did the basic configuration (setting my paper size) without any
hassle,

I've read some stuff about that with MacTeX. The supplied documentation
does not explain very much about what that setting means, and it's
explanation of `what to do if the automatic system doesn't work' is
seriously incomplete. I think I'd be able work it out if I wanted to (I
really haven't a clue what the hell that setting might be /for/ - page
sizes get specified in your LaTeX source document as far as I'm
concerned, although I'll admit I recall something about dvips needing to
be told paper size separately but I've not used dvips for a very long
time and even then it was only one job IIRC)

That's the problem with all the MacTeX documentation: very little of it
does the job properly, and it all leads to a need to do more research,
ask questions, and make my own notes on how to do what I need to do.

It's severely incomplete - but does the job for people who either know
what's what or don't care what's what and are happy to `just follow
instructions until something appears to break'.

and I suspect most people would easily be able to do the same
with a quick web search, as soon as they realized the paper size
wasn't what they want.

<shrug> I have no idea what the MacTeX paper size setting is for off
the top of my head. If I do a LaTeX run and the paper size is wrong, I
put the right paper size spec in the source document thus:

\documentclass[a4paper]{<blah>}

<shrug> What else is one supposed to do? There's something needs
entering into the dvips configuration file (whatever it is) to tell it
about your paper size if you're using dvips, but that's it. And okay,
dvi previewers need to know that sort of thing too but I don't think
I've got one with MacTeX.

If there's anything else regarding paper size settings in a TeX system,
I've no idea at all what it is. I've used OzTeX which had paper size
settings for the dvi viewer and dvips. Two different settings - that
made sense. Before that, I used emTeX and TeX on Unix. Same sort of
thing with them (not that I ever looked after TeX on Unix in those
days). What is going on with TeXLive's paper size setting, I have yet
to find out.

I could not do the same with MacTeX - it was impossible to do without
lots of expert assistance, much of it very grudgingly given because the
experts clearly didn't want me to learn how to subvert their ideas for
what I should be doing...
Sorry to hear that. I find the process of installing software on a
Mac very mysterious, but that is possibly because I've only tried to
do it once.

The usual Mac installation procedure involves dragging an application
icon from one place to another. I.e., the user thinks it's a process of
`There's the file, stick it where you want, job done'.

How is that mysterious?

(okay, a typical Mac app is actually a `bundle', being MacOS X jargon
for `a folder/directory containing all the code and resources for the
application with a new flag set so the OS displays it as a file icon
rather than a folder icon'. Bundles were something else on Macs before
MacOS X came out so old tymers like me get confused. Anyway, Apple's
doing a bit of `lying to the user' in this case, but it works out well)

(GW? What do those letters mean? I have no idea)
Who said "GW"?

I did. If the letters mean nothing to you, all to the good - 'twas a
mean-spirited comment on my part.

So: I would say that the selection and installation of the TeX system
depends on having a TeX expert who's also an expert in the host computer
system to hand. The normal user cannot exercise a choice in this area.
Maybe that is the case in the MacOS world, I dunno. But honestly I
don't think it is for Linux.
If you're a Unix expert (and it sounds like you are), then you'll have
no trouble.
I'm going to disagree with you there, and by doing so will agree with
some of the points you have made throughout this thread... Really, I
don't think that one needs much Unix expertise to install (the
complete) texlive 2007 on a Linux system. However, I will agree that
knowing how to add some things to the system (which I presume is your
issue) is a bit of a black art.

Add, and remove. I don't want Babel in my LaTeX, thanks. Finding out
how to create new formats was a major problem. The first documentation
I read that came with MacTeX told me how to do that job - except that it
was 100% wrong.

<shrug>

I managed to find out what to do eventually, I think... Well, I've got
a procedure and an incantation.

sudo -sudo -H fmtutil-sys --all --cnffile
/Users/Shared/texmf.rjmm/web2c/fmtutil.cnf

(although I'm currently not at all sure what it does - need to
investigate *again* and then write it up for myself so I don't forget
again. I used to know what it did, but I didn't make clear enough notes
for myself. Like, where the hell are the new formats put? Argh... Oh,
I'll find 'em when I get round to looking and all that, but still.)

Being a plain tex user, I don't need
to add/update latex packages, and the one time I added fonts they came
with explicit directions on exactly what to do. To me, the process of
updating things in one's tex distribution seems gratuitously complex,
but I say that from my position of "tex user", not "tex system/tool
implementer" or "tex package implementer".

Properly speaking, it should be perfectly possible to just put the
required files on the appropriate search paths. A `system wide
additions' texmf tree and a `this user additions' texmf tree should be
supplied for local additions in all TeX systems so all you have to do is
just bung the files where they're needed in a very straightforward
fashion.

The texmf structure on its own makes life a bit of a pain, insisting
(for example) that the different files for a LaTeX package are kept in
different places (font definition files there, tfms here, documentation
somewhere else, and so on). This might have made sense in the 1970s,
but it's not so sensible these days if you ask me...

But... installing (the entire) texlive2007 was pretty straightforward.

Installing MacTeX 2007 was a process of `telling the installer to do its
thing, and it did'. What I got was a mostly working TeX installation -
which needed a bit of mild tweaking to sort out some minor irritations
and then some major surgery so I could add on my local additions.

Local additions which I've been using for a very long time, I might
add... With OzTeX and later CMacTeX, no less - then I tried to get
things working with MacTeX 2006 and ended up an unhappy bunny.
Documentation for that was and is hopeless, not to mention getting a lot
of personal abuse on the TeX on MacOS X mailing list.

Personal abuse is explictly forbidden on that mailing list, but the
owner doesn't seem to mind just so long as its directed at someone he
doesn't like either. Apparently, it's okay to hurl personal abuse at
someone if he's just critised a software distribution.

Most people /can't/ learn to use Emacs, AUCTeX, and so on -
I've tried to learn how to use Emacs+AUCTeX from the supplied
documentation, and I have failed. Emacs documentation is, on its own,
impossible for a normal person to get anywhere with as far as I can
tell. This is the big problem with a lot of Unix-side software:
documentation that is designed to exclude.
I think that is harsh to the point of inaccuracy.
Yes, it's inaccurate, but only because I'm being far too polite and
gentle.
:-)

The *raw* opinion I have on the subject of `typical Unix-style
documentation' is - umm, different. You've got the toned-down,
filtered opinion - my public lie on the subject.

Look, it's perfectly obvious that Unix documentation is written on the
basis of `If you don't understand this stuff, you shouldn't be fiddling
with it'. It's also obvious that Unix documentation is mostly written
by heavy, heavy hackers who have no idea how to communicate with normal
human beings, no idea what learning requirements normal human beings
have, no idea how to assess the quality of their documentation, and
generally no interest at all in making their documentation *useful*.

Possibly you are familiar with research results which indicate that
different people like different types of reading material? Some
people prefer documentation or descriptions that go on in great detail
with many examples, and other people like documentation that is terse.
I don't think you should categorize one group as "normal".

<puzzled> What are you on about?

Look, I'm trying to distinguish `useful from the point of view of a
heavy hacker' and `useful from the point of view of someone else' -
calling `all that set normal human beings'.

And perhaps you are aware that regardless of what research says about
what people reading, documentation is useless unless it teaches people
what they need to know. And no-one enjoys reading documentation that
does not perform the function they require from it.

Typical Unix documentation is useful to people who are looking for
tersely-written material.

You are distorting and misrepresenting the matter as if it were purely
down to aesthetics and battle between a desire to keep things short and
sweet and a desire to waffle. It is not: it's all about function, and
the distinction between `concise' and `concise' rather than `terse' and
`verbose'. No, I've not gone mad - read on.

Making the terse/verbose distinction is wrong. Unix documentation is as
minimalist as it can get by intent. That is bad for most people. Most
people need more filling in of gaps. But documentation should always be
`concise' - meaning `short but complete'. But what's complete? From a
Unix hacker's point of view, `standard man pages'. From the point of
view of a normal human being, `complete' means rather more is needed.

The solution is to write suitably concise documentation for a particular
audience - but that human way of looking at things doesn't seem to exist
in Unixland, does it?

Typical Unix documentation is not useful for anyone who is not already a
stone cold Unix expert.

It is useful for people who are looking for documentation that is
accessible only to stone cold experts like themselves, and excludes all
normal people who do not have the right expert background.

It's like old fashioned class discrimination - `You're not one of us, go
away!'. It's just a normal human behaviour pattern that you can observe
almost anywhere you have human groupings, and even more commonly where
you have a group of people that possesses privileges. Access to
information and power to control are privileges. Have a think about it.

However, IMHO it is too terse for someone
starting from square one, and such people would really want some
verbose material or a helping hand.

`Terse' and `verbose' is missing the point entirely: `documentation
written for a different audience' is what is needed. No-one who is not
a salted Unix expert can make proper use of most Unix documentation -
it's designed to exclude because it is not concise from the point of
view of a non-Unix expert. It is incomplete - and therefore cannot be
concise.

One needs to write all documentation to be *concise* - meaning
`complete, but short'. `Terse' and `verbose' puts you in a wrong-headed
position when considering the matter - and if it's a typical outlook, no
wonder we've got bloody awful documentation. Thinking about whether the
docs should be `terse' or `verbose' is clearly what sombunall[1] Unix
heads do - rather than doing the functionally correct thing, which is
knowing that concise is what is essential, and then working out how to
produce something that'll do the job with the intended audience.

You seem to be ignoring the human end of things - docs need to be
/useful/.

I would not be surprised that if you take any group of people (e.g.,
Unix hackers) they might tend toward similarity in some personality
traits. And perhaps the preference for terse documentation is such a
trait common to Unix hackers.

It's not like that at all. Unix hackers are Unix hackers because they
can work with the available documentation. Those of us who find it hard
to learn how to use Unix are in the position we are in because we cannot
work with the available documentation.

It has nothing to do with personal likes and dislikes, as you falsely
imply. Purely functional, and to do with knowledge and information
rather than anything much else that I can think of.

But I don't think that writing for
people with similar learning styles is "no interest at all in making
their documentation *useful*.". I'd say it is "no interest in making
their documentation useful for people who like verbosity".

I'm not talking about people who like verbose documentation. Verbose
and terse documentation are both bad styles. All documentation should
be concise - none of it should be either terse or verbose.

Those are
two different puppies.

`No interest in making their documentation useful for people who like
documentation to be useful to people who can't cope with normal Unix
documentation'. Or `No interest in trying to understand the needs of
another human being'.

What I'm arguing for is concise documentation. The problem is that Unix
hackers don't write for normal human beings: they usually only write for
each other. The idea that verbose documentation is a good thing is one
that I reject - I have come across verbose documentation on the Unix
side, and it's almost as useless as the terse stuff.

I've got verbose documentation for other things, and I hate it with a
passion. Chapter after chaper of waffle, low information density,
incredibly hard to find out what you want, and so on. No more use than
the usual terse stuff, really.

Clearly quite a lot of Unix documentation is written with great care
and attention to detail - so the authors do care about *something*,
but it's not `making the documentation useful for others', whatever
they're playing at.
I really don't think that is the case.

<shrug> And I really do, based on my observations.

I would say that a lot of Unix docs are designed to be terse and
not beginner-friendly. (And yes, I agree that is a problem.) But
I seriously doubt that many (or any) documentation writers actually
design their docs to exclude people.
<puzzled> But `terse and not beginner friendly' is equivalent to
`designed to exclude'.
No it isn't. It is "not designed to include everyone", which is
considerably different.

`Designed to exclude some people' is what you claim it is - which is
equivalent to `designed to exclude people' which is what I claim it is.

But you've madly claimed otherwise. I'm not sure what to do about that
- am I really trying to have a debate with a lunatic?

You're not making any sense here, I'm afraid.
Well, perhaps not to you on my first try. Is my second try more
lucid?

What seem to be saying is that I'm wrong and you're right regardless, so
I'm afraid I have to say that you're not making any more sense this
time.

If not, perhaps I am not writing well, but perhaps my writing
is poorly matched to your reading/learning style.

You can of course make as many insulting personal insinuations as you
like. Each one that I read lowers my opinion of you.

I believe they just don't make the effort to make the
documentation more inclusive.
The documentation is written so that only existing Unix experts who
already `know it all' (more or less) can use it.
An exaggeration,

I would say not - not based on my experience.

but valid nonetheless for much documentation. But
then you can see how it would be well-suited to such people, who might
not like to wade through chapters of excessive verbiage hunting for
the few facts they are not already in possession of.

But no-one likes to wade through verbiage. What I am suggesting is that
documentation should be concise in all cases. You are creating a false
dichotomy here. Everyone likes concise documentation. I'm in favour of
dropping the terse and verbose styles and moving to concise for all of
it - because concise is most useful.

I do not refer to `personal preferences', but `what's most useful'.
Function, not emotions.

Admittedly, what's `concise' from the point of view of different people
is different, so I'm not trying to suggest that `one style fits all'.
But the principle does.

That's a policy which excludes almost everything - and it's deliberate.
Well, maybe, but as someone who has been using Unix and Unix-like
systems for most of the last 28 years, I've never seen any evidence
that there is any deliberate exclusion policy. Maybe I didn't get the
memo :-)

<sigh> One does not need to have a formal, written conspiracy to have
human behaviour running as human behaviour normally does. It's how
people behave - I can assure you that I have seen evidence as I state.

Which is not, as you imply, me claiming that there is a formal exclusion
policy so please do drop that bit of insulting nonsense.

(Yeah, I've looked at the AUCTeX docs, and I must admit I didn't see a
whole lot there for plain TeX users, notwithstanding the advertising
that says it is useful for plain TeX. Intentional exclusion for plain
TeX users? I doubt it, just not a major interest for people
contributing to AUCTeX. Or maybe I didn't spend enough time looking.)

I've looked at the AUCTeX docs. They're one reason I've never tried
to use Emacs seriously in recent years.
You can happily edit TeX files with emacs without auctex, I do it
almost every day.

<sigh> But what on *EARTH* would cause me to use a text editor for
editing text files that didn't have some sort of TeX mode?

The only reason is `lack of anything else' and I've got text editors
that are a lot more convenient to use than Emacs. If I were to use
Emacs for TeXing, I wouldn't dream of not using a TeX-aware mode of some
sort.

I've only ever been able to learn how to use a specific mode in
Emacs by following instructions from a human being - Emacs `help'
has never helped me learn how to use the features of a mode (the
standard Unix `documentation written for experts only' problem
again).

When I lost access to a live-in Unix sysadmin (long time ago, when a
student), that was `it' for me and Emacs, really. Its documentation
makes it very hard for someone to learn to use who doesn't have a
human expert to hand.
I agree. But since you can use emacs on a wide variety of platforms,
I don't think you should tie "unix" and "emacs" too closely together.

<pained> What are you on about?

Tell you what, why not re-read what I wrote and try to understand it
this time?

A lot of unix sysadmins belong to the church of vi, and see emacs as
something very unholy.

Indeed so, as I knew long before said Unix sysadmin and me parted
company when we moved out of that particular student house.

Your point being?

I've never been able to learn anything about `Unix-related issues'
from the documentation alone - always, always, always in the case of
Unix-related anything, I need to ask questions of people because
Unix documentation is - pretty much universally - *meant* to be
incomprehensible to non-initiates. I stand by my claim that is
quite deliberate.
I'd be interested in non-speculatory proof of that :-)

There is no such thing. All it takes is a little bit of observation and
a little understanding of what is laughably called `human nature'.

The world is as I claim[2].

Rowland.

[1] RAW is dead. So I've stolen his word. `Some but not all'.
<http://www.rawilson.com/about.shtml>. His book `Quantum psychology'
explains something about `somebunall'

[2] Just call me God.

--
Remove the animal for email address: rowland.mcdonnell@xxxxxxxxxxxxxxx
Sorry - the spam got to me
http://www.mag-uk.org http://www.bmf.co.uk
UK biker? Join MAG and the BMF and stop the Eurocrats banning biking
.