The future of typesetting --- LaTeX3, or what?
Harald Kirsch
Hi there,
recently I had a look at what the LaTeX3 team has released. It reads
like their prime goal is currently to create well defined,
straightforward and understandable _programming language_ on top of
the TeX language, in particular to ease the task of writing document
classes. And of course they want to maintain compatibility with
LaTeX2e.
Out of curiosity I wonder what it would be like, if we start from
scratch and ask for a macro- or scripting-language to typeset
documents. At the back end, I would probably see PostScript instead of
DVI. But the front end?
Personally I like Tcl as a scripting language, in particular because
its evaluation rules almost trivial. The command `man Tcl|wc -l'
results in just 264 lines. To make it easier to type long paragraphs,
I would change just one rule of Tcl: A command ends at a semicolon or
at an empty line, not at the end of the line.
The basic command to typeset a paragraph would probably be `Par'. The
following paragraphs try to use the syntax of Tcl for annotation and
will probably only make sense to the Tcl-literate.
Par The command [texttt Par] collects all its arguments in the
Tcl-sense and typesets them as a paragraph. As described above, its
arguments are all the words up to the next empty line, i.e. this one
ends here.
Par According to Tcl's evaluation rules, [textit words enclosed in
brackets] are evaluated even before [texttt Par] sees them, so the
command [texttt textit] can arrange to have its arguments typeset in
[textit italics].
Par The syntax of environments could look like this:
Itemize;
item The semicolon on the previous line terminates the argument list
of the [texttt Itemize]-command in the same way as an empty line would
do. This way, [texttt item] is a new command.
item The [texttt Itemize]-command would set several global
parameters to allow the [texttt item]-commands to work as expected.
item Finally, the a command like [texttt EndItemize] would reset the
parameters which were changed by [texttt Itemize].
EndItemize
Par Although this looks pretty neat, how would it be to typeset TeX's
logo? Suppose we have a built-in function that arranges a list of
boxes according to kerns and raise-amounts noted in between. Then, in
Tcl-syntax we could define a macro like this:
Verbatim {
proc TeX {} {
[arrange T -.16667em -0.5ex E -0.125em 0pt X] }
}
}
Par Note how I would expect the [texttt arrange]-command to understand
numbers with a unit! And see how the extra braces make sure that the
whole text is passed unevaluated to the [texttt Verbatim]-command.
Par Now [TeX]'s logo is readily available, but of course in a rather
new syntax.
Par -linewidth 10cm
We could use options to change the appearance of a paragraph. The
meaning of the option used for this one should be obvious.
Par All these are very preliminary ideas. Maybe someone out there
knows TeX and Tcl as well and can point out, if the ideas desribed
above are at all possible, or if TeX as a macro-language has features
which would never be possible to formulate in Tcl.
Thank you for your patient reading,
Harald Kirsch.
--
---------------------+------------------+--------------------------
Harald Kirsch (@home)| | Now I rebooted.
k...@iitb.fhg.de | | --- Jerry Pournelle, BYTE
gegen Punktfilitis hilft nur `chmod u-w ~'
Rolf Marvin B|e Lindgren
[Harald Kirsch]
| Personally I like Tcl as a scripting language, in particular because
| its evaluation rules almost trivial. The command `man Tcl|wc -l'
| results in just 264 lines. To make it easier to type long paragraphs,
| I would change just one rule of Tcl: A command ends at a semicolon or
| at an empty line, not at the end of the line.
this has been debated before and little good seems to come out of it.
everybody has their own favorite.
for instance, I can't comprehent why anybody would want anything other
than Lisp, to wit:
- Lisp has the simplest syntax of any programming language, quite unlike
Tcl, which is a mess
- in Lisp, pages, paragraphs, letters would just be objects with
properties
- as opposed to Tcl, Lisp is available for any computer system I've heard
about
- the www has adopted a variant of Lisp known as Scheme for styles and
extension.
all in all, Lisp seems to be the way to go.
and by the way, the output language should not be PostScript, that would
alienate 80% of current TeX users.
--
Rolf Lindgren | "The opinions expressed above are
Sofienberggt. 13b | not necessarily those of anyone"
N-0551 OSLO | ro...@ask.uio.no
Michael C. Grant
Rolf Marvin B|e Lindgren wrote in message ...
>all in all, Lisp seems to be the way to go.
>and by the way, the output language should not be PostScript, that would
>alienate 80% of current TeX users.
I know, let's make the output language _device independent_; hmm, we can
call it DVI, that sounds right. We could make a "previewer" which would let
us see what these documents will look like before we try to print them out.
Then we could make converters that can take these DVI files and turn them
into, say, PS files for PostScript lovers, PCL for HP printer owners, and
throw in a windows driver perhaps.
Yeah, that would do it.
Ernst U. Wallenborn
Rolf Marvin B|e Lindgren <ro...@morgoth.uio.no> writes:
> and by the way, the output language should not be PostScript, that would
> alienate 80% of current TeX users.
i don't understand this. ghostscript is available for any OS i have access
to (ok, that's only three: UNIX/Linux, Windows95, MacOS), and furhter-
more ps is the only format where in my experience the files are really
reliably printed. I mean yap's dvi printroutines (MikTeX package) aren't
very good, on the two machines i installed it on (generic W95, HP
670C and a cheap laser i even forgot the company that made it)
printing dvi frequently resulted in truncated pages. I don't even
consider this a bug since yap is a *previewer*. For printing, ps
conversion and printing with gs is a piece-of-cake.
Personally, i write much on my linux notebook. At home i use
my old mac as a print server, and transfer the files as ps
(i have CMacTeX installed, but it's more convenient not to retypeset
everything). My \texteuro0.02 are that dvi could be abandoned.
--
--
Ernst-Udo Wallenborn
Laboratorium fuer Physikalische Chemie
ETH Zuerich
Aleksandar Bakic
Michael C. Grant wrote:
>
> Rolf Marvin B|e Lindgren wrote in message ...
> >all in all, Lisp seems to be the way to go.
> >alienate 80% of current TeX users.
>
> call it DVI, that sounds right. We could make a "previewer" which would let
> us see what these documents will look like before we try to print them out.
>
> Then we could make converters that can take these DVI files and turn them
> into, say, PS files for PostScript lovers, PCL for HP printer owners, and
> throw in a windows driver perhaps.
>
> Yeah, that would do it.
Could someone list pros and cons of DVI and PDF? Someone in
comp.text.sgml
mentioned that PDF has poorly solved some typesetting and layout issues.
Thanks,
Aleks
Rebecca and Rowland
Ernst U. Wallenborn <wa...@bacon.ethz.ch> wrote:
> Rolf Marvin B|e Lindgren <ro...@morgoth.uio.no> writes:
>
>
> > and by the way, the output language should not be PostScript, that would
> > alienate 80% of current TeX users.
>
>
> i don't understand this. ghostscript is available for any OS i have access
> to (ok, that's only three: UNIX/Linux, Windows95, MacOS), and furhter-
> more ps is the only format where in my experience the files are really
> reliably printed. I mean yap's dvi printroutines (MikTeX package) aren't
> very good, on the two machines i installed it on (generic W95, HP
> 670C and a cheap laser i even forgot the company that made it)
> printing dvi frequently resulted in truncated pages. I don't even
> consider this a bug since yap is a *previewer*. For printing, ps
> conversion and printing with gs is a piece-of-cake.
Nice theory; shame about the practice. I use OzTeX on my Performa 475
and I never print using Ghostscript if there's any alternative. Why?
There are a few problems: I have to convert my dvi file using dvips,
then tell Ghostscript to render the first page, and then I can tell
Ghostscript to print it. If I want to (say) print two-sided, I need to
give dvips a different command line and run it twice to produce two
different ps files, and then run Ghostscript twice.
Another problem is that Ghostscript is *slow* on my old Mac; MacGS View
crashes if I do unreasonable things like move the console window, and
CMacTeX's Ghostscript tends to crash while rendering.
The process is in any case a right pain the backside and often leads to
a crash. Of course, if you've got a fast modern Unix workstation, of
*course* it's easy; the same does not apply to Macs even when
Ghostscript doesn't crash on you and you have a fast processor.
I've had trouble with GS mis-scaling pages and things like that (a bug
in MacGSView, since fixed). On the other hand, OzTeX's dvi driver has
worked perfectly the whole time I've been using it.
> Personally, i write much on my linux notebook. At home i use
> my old mac as a print server,
Have you really got Ghostscript working as a printing device? That is,
just send it the files and watch them print the way you want?
> and transfer the files as ps
> (i have CMacTeX installed, but it's more convenient not to retypeset
> everything). My \texteuro0.02 are that dvi could be abandoned.
I've been known to run OzTeX on my Mac Plus: 8MHz 68000; 4MB RAM. The
thought of attempting to use Ghostscript on that makes my hair curl.
dvi can't be abandoned and still allow people with old compters to use
LaTeX.
Rowland.
--
Remove the animal for my email address: reb...@astrid.dog.u-net.com
Sorry - the spam got to me. PGP pub key A680B89D
UK biker? Join MAG and help keep bureaucracy at bay
http://dredd.meng.ucl.ac.uk/www/mag/mag.html
Harald Kirsch
Rolf Marvin B|e Lindgren writes:
> [Harald Kirsch]
>
> | Personally I like Tcl as a scripting language, in particular because
> | its evaluation rules almost trivial. The command `man Tcl|wc -l'
> | results in just 264 lines. To make it easier to type long paragraphs,
> | I would change just one rule of Tcl: A command ends at a semicolon or
> | at an empty line, not at the end of the line.
>
> this has been debated before and little good seems to come out of it.
> everybody has their own favorite.
Good to hear, can you give me some keywords to look for in DejaNews?
>
> for instance, I can't comprehent why anybody would want anything other
> than Lisp, to wit:
Yeah, Great, lets take lisp. But this does not answer my original
question. Compared to what I know a bit of (Tcl, lisp, csh, sh, M4,
TeX), TeX has for my opinion the strangest evaluation/expansion rules
of all. Think of all this `\expandafter', `\csname' and `\if'-business for
example. What I would like to know is, if this is an accident of
history or if there are some very good reasons why TeX's macro
language facilities are not as simple as lisp's or Tcl's.
> and by the way, the output language should not be PostScript, that would
> alienate 80% of current TeX users.
So 6 out of 11 chapters of `The LaTeX Graphics Companion' address only
20% of current TeX users? And none of the other 80% has ever heard of
ghostscript?
Harald Kirsch
Harald Kirsch
"Michael C. Grant" <mcg...@mindspring.com> writes:
> Rolf Marvin B|e Lindgren wrote in message ...
> >all in all, Lisp seems to be the way to go.
> >and by the way, the output language should not be PostScript, that would
> >alienate 80% of current TeX users.
>
> I know, let's make the output language _device independent_; hmm, we can
> call it DVI, that sounds right. We could make a "previewer" which would let
> us see what these documents will look like before we try to print them out.
>
> Then we could make converters that can take these DVI files and turn them
> into, say, PS files for PostScript lovers, PCL for HP printer owners, and
> throw in a windows driver perhaps.
Since my original post, were I dared to call PostScript device
independent, seems to have initiated all this rhetoric, I feel a bit
stupid, because I don't know the reasons why it is not. Could someone
explain me why or give me some keywords to ask DejaNews for, if it has
been discussed recently.
Thank you,
Harald Kirsch.
Rolf Marvin B|e Lindgren
[Harald Kirsch]
| Since my original post, were I dared to call PostScript device
| independent, seems to have initiated all this rhetoric, I feel a bit
| stupid, because I don't know the reasons why it is not. Could someone
| explain me why or give me some keywords to ask DejaNews for, if it has
| been discussed recently.
DVI is an open standard which is under control of the TeX community
(ideally, that, is). it is not owned by anybody.
PostScript is owned by Adobe. just the fact that the «standard» is
proprietary makes it not an option. PostScript is, furthermore, not a
standard in the canonical sense, PostScript is whatever Adobe wants it
to be.
GhostScript is a clone of PostScript and is, as such, not good enough
for professional typesetting. if you want real typesetting, you need to
purhcase a PostScript printer or a PostScript engine, which is why 80%
of the TeX users either use GhostScript or a DVI to HP/PCL converter.
PostScript has become cheaper and more common, so I don't think the 80%
figure is still true.
I used to work at the computing support center of the University of
Oslo. we had an Imagen printer from DEC, two Xeroxen, a Linotronic,
several HP and Apple printers, and also supported the entire printer
network of the University of Oslo. my experience is that PostScript is
not even compatible with itself, and is far too printer dependent to
build a standard on. the Xerox would crash on anything. an HP III Si
would crash if the file included a drawing made on Macintosh. the Lino
would accept just about anything. all had small peculiarities.
if you have a DVI to PostScript driver, however, you could _support_ all
those cute differences in translating from DVI to PostScript, actually
making PostScript _more_ portable.
Louis Vosloo
Harald Kirsch wrote:
>
> "Michael C. Grant" <mcg...@mindspring.com> writes:
>
> > Rolf Marvin B|e Lindgren wrote in message ...
> > >all in all, Lisp seems to be the way to go.
> > >and by the way, the output language should not be PostScript, that would
> > >alienate 80% of current TeX users.
> >
> > I know, let's make the output language _device independent_; hmm, we can
> > call it DVI, that sounds right. We could make a "previewer" which would let
> > us see what these documents will look like before we try to print them out.
> >
> > Then we could make converters that can take these DVI files and turn them
> > into, say, PS files for PostScript lovers, PCL for HP printer owners, and
> > throw in a windows driver perhaps.
>
> independent, seems to have initiated all this rhetoric, I feel a bit
> stupid, because I don't know the reasons why it is not. Could someone
> explain me why or give me some keywords to ask DejaNews for, if it has
> been discussed recently.
You may be using a TeX system where everything is - or has to be -
done using PostScript. However:
Since there exists support (in fact the best rasterizer) for
Type 1 fonts that does *not* involve PostScript, there are TeX
Systems that do not require PostScript or a PS interpreter.
On screen viewing using Type 1 fonts (so-called `PS' fonts in
the TeX world) does not require a PS interpreter. Printing to
non-PS devices using Type 1 fonts (so-called `PS' fonts in the
TeX world) does not require a PS interpreter.
It's true that PS is wonderful. But it isn't required for
everything. Consequently tying everything in TeX to PS limits
it unneccessarily. Particulalry if you are not on a system
that uses Display PostScript as its imaging model (as NeXT was,
and as Rhapsody was going to be).
--
Y&Y, Inc., Tuttle's Livery, 45 Walden Street, Concord, MA 01742 USA
(800) 742-4059 (North America), (978) 371-3286 Fax: (978) 371-2004
Sales: mailto:sa...@YandY.com Support: mailto:sup...@YandY.com
World Wide Web: http://www.YandY.com
Rebecca and Rowland
Harald Kirsch <k...@iitb.fhg.de> wrote:
[snip]
> What I would like to know is, if this is an accident of
> history or if there are some very good reasons why TeX's macro
> language facilities are not as simple as lisp's or Tcl's.
TeX was written to do one specific job. It wasn't written to be an
elegant, general-purpose programming language (as in the case of Lisp);
nor was it written after lots of people had gained lots of experience
writing macro programming languages to do various different jobs (as
with tcl). Basically, TeX is a product of its time (late 1970s), just
as tcl and Lisp are. TeX has it's form for exactly the same reasons Lisp
and tcl do: mostly historical accident.
> > and by the way, the output language should not be PostScript, that would
> > alienate 80% of current TeX users.
>
> So 6 out of 11 chapters of `The LaTeX Graphics Companion' address only
> 20% of current TeX users?
I think that's an over-estimate myself.
> And none of the other 80% has ever heard of
> ghostscript?
Ghostscript is quite impractical for many TeX users. For example, it's
very awkward to use on a Mac at the moment. You have to render the
first page of a file on screen before you can print it, for example, and
there's no straightforward way of automating the process of printing a
file. And even then, both versions have a nasty habit of crashing on my
Mac; it's the most unreliable software I use. I do have to use it, of
course, but I've never been forced to use it for my own documents.
I also seriously doubt that it's practical for anyone using an 8086 PC,
or indeed any Wintel PC without at least an 80486 processor. Even then,
it's very slow.
Of course, if I were using Unix, I'd have it installed like a shot and
use nothing but dvips->ghostscript for my printed output unless I had a
PS printer.
Rebecca and Rowland
Rolf Marvin B|e Lindgren <ro...@morgoth.uio.no> wrote:
[snip]
> GhostScript is a clone of PostScript and is, as such, not good enough
> for professional typesetting.
What difference is there between Ghostscript's output at high resolution
and output from a `real' Postscript interpreter at high resolution?
I can't see that Ghostscript is necessarily inferior just because it was
written after Adobe wrote the original PostScript; and I was under the
impression that the typesetting was all done by TeX.
Rowland.
[snip]
Rolf Marvin B|e Lindgren
[Rebecca and Rowland]
| What difference is there between Ghostscript's output at high resolution
| and output from a `real' Postscript interpreter at high resolution?
as far as I know, basically the font rendering algorithm. type looks
better with real PostScript. there are some other minor quirks too,
which is documented in the GhostScript distribution.
Louis Vosloo
Rolf Marvin B|e Lindgren wrote:
>
> [Rebecca and Rowland]
>
> | What difference is there between Ghostscript's output at high resolution
> | and output from a `real' Postscript interpreter at high resolution?
>
> as far as I know, basically the font rendering algorithm. type looks
> better with real PostScript. there are some other minor quirks too,
> which is documented in the GhostScript distribution.
Right. the main difference is in the font rendering. No surprise
since Adobe holds their font rasterizer trade secret. Note though
that not all `Adobe' PS rasterizers are equally good. Some printers
apparently have code ported from ATM --- which does the best, of course.
Also note that some so-called `Adobe PS' devices are not really
(like the QMS PS 815 MR sitting on my desk here, despite what QMS says).
Ernst U. Wallenborn
reb...@astrid.u-net.com (Rebecca and Rowland) writes:
> Another problem is that Ghostscript is *slow* on my old Mac; MacGS View
> crashes if I do unreasonable things like move the console window, and
> CMacTeX's Ghostscript tends to crash while rendering.
i have a performa 475, too, and the most recent Cmactex ghostscript
is stable afaict. I is slow, though. But dvi on the other
hand is not truly an alternative: i tried to transfer dvi
files at first, and this did not work because the font setup
was not identical on my machines.
> I've had trouble with GS mis-scaling pages and things like that (a bug
> in MacGSView, since fixed). On the other hand, OzTeX's dvi driver has
> worked perfectly the whole time I've been using it.
OzTeXs dvi driver is known to be very good. But there's no
OzTeX in Windoze, and yap's printing routines are mediocre
at best.
> > Personally, i write much on my linux notebook. At home i use
> > my old mac as a print server,
>
> Have you really got Ghostscript working as a printing device? That is,
> just send it the files and watch them print the way you want?
I put the file on my mac, open ghostscript and say Print.
In earlier versions you could only print one page at a time,
true, and this was a major #$%@@#$! but now this limit is gone,
and i don't care about the speed since i don't have to stand
by the machine.
Harald Kirsch
In article <35728C1A...@YandY.com> Louis Vosloo <sup...@YandY.com> writes:
> Harald Kirsch wrote:
[snip]
> > Could someone
> > explain me why
[insert: PostScript is not considered device independent by some]
> > or give me some keywords to ask DejaNews for, if it has
> > been discussed recently.
>
> You may be using a TeX system where everything is - or has to be -
> done using PostScript. However:
>
> Since there exists support (in fact the best rasterizer) for
> Type 1 fonts that does *not* involve PostScript, there are TeX
> Systems that do not require PostScript or a PS interpreter.
> On screen viewing using Type 1 fonts (so-called `PS' fonts in
> the TeX world) does not require a PS interpreter. Printing to
> non-PS devices using Type 1 fonts (so-called `PS' fonts in the
> TeX world) does not require a PS interpreter.
>
> It's true that PS is wonderful. But it isn't required for
> everything. Consequently tying everything in TeX to PS limits
> it unneccessarily. Particulalry if you are not on a system
> that uses Display PostScript as its imaging model (as NeXT was,
> and as Rhapsody was going to be).
Am I missing something? I cannot find any argument why PostScript is
not device independent? Just because a PostScript interpreter is built
into some printers does not make PostScript a device in itself.
I cannot see the difference between using ghostscript, for example, to
stuff pixelized data into e.g. a HP Deskjet and using dvidj or
something like that.
Harald Kirsch
Juergen v. Hagen
Harald Kirsch wrote:
>
....
> Am I missing something? I cannot find any argument why PostScript is
> not device independent? Just because a PostScript interpreter is built
> into some printers does not make PostScript a device in itself.
file prints fine on one device, but not on some other (as I experienced
a lot with mixed Mac, PX, Unix on mixed Mac and Hp printers), I would
call this "device dependant".
PostScript might have been PLANNED as device independant, but, as a
matter of fact, is not.
cheers
juergen
Juergen v. Hagen
Ernst U. Wallenborn wrote:
>
....
> consider this a bug since yap is a *previewer*. For printing, ps
> conversion and printing with gs is a piece-of-cake.
I can not print gnuplot created color PS (on Unix) files via GhostView
on my PC (on Winow$ 95). For me, ps is definetly NOT a piece of cake.
schoene Gruesse
juergen
Robin Fairbairns
In article <1d9y5kv.1td...@p11.nas1.is2.u-net.net>,
Rebecca and Rowland <reb...@astrid.u-net.com> wrote:
>Harald Kirsch <k...@iitb.fhg.de> wrote:
>
>[snip]
>> What I would like to know is, if this is an accident of
>> history or if there are some very good reasons why TeX's macro
>> language facilities are not as simple as lisp's or Tcl's.
>
>TeX was written to do one specific job. It wasn't written to be an
>elegant, general-purpose programming language (as in the case of Lisp);
>nor was it written after lots of people had gained lots of experience
>writing macro programming languages to do various different jobs (as
>with tcl). Basically, TeX is a product of its time (late 1970s), just
>as tcl and Lisp are. TeX has it's form for exactly the same reasons Lisp
>and tcl do: mostly historical accident.
you jest, of course. i was using general-purpose macro processors for
odd jobs 10 years before tex hit the streets (and 20 years before i
started using tex), and they weren't new then.
at the time, mark you, i concluded that lisp was the most arse-about-
face language i'd ever encountered, and i was't terribly worried that
there was no lisp interpreter on the machine i used.
>I also seriously doubt that [gs is] practical for anyone using an 8086 PC,
>or indeed any Wintel PC without at least an 80486 processor. Even then,
>it's very slow.
it's not fast, but it's not impractical, ime. and its speed seems to
improve with every release.
i only know one person (in this country) who persists in using a 286
(let alone an 8086) -- are such historical relics still a significant
part of tex equipment?
>Of course, if I were using Unix, I'd have it installed like a shot and
>use nothing but dvips->ghostscript for my printed output unless I had a
>PS printer.
why is it different under unix? what if i were to make my machine
dual-boot unix/doze? would it be wrong to run gs in one but not the
other? itwsbt.
--
I live in the crowd of jollity, not so much to enjoy company as to shun
myself. -- Samuel Johnson
Sanat Kumara
Harald Kirsch wrote:
>
> "Michael C. Grant" <mcg...@mindspring.com> writes:
>
> > Rolf Marvin B|e Lindgren wrote in message ...
> > >all in all, Lisp seems to be the way to go.
> > >alienate 80% of current TeX users.
> >
> > call it DVI, that sounds right. We could make a "previewer" which would let
> > us see what these documents will look like before we try to print them out.
> >
> > Then we could make converters that can take these DVI files and turn them
> > into, say, PS files for PostScript lovers, PCL for HP printer owners, and
> > throw in a windows driver perhaps.
>
> Since my original post, were I dared to call PostScript device
> independent, seems to have initiated all this rhetoric, I feel a bit
> explain me why or give me some keywords to ask DejaNews for, if it has
> been discussed recently.
PostScript is indeed device independent.
And, frankly, it is a requirement for anything decent that ends up on a
printing press.
Sure, somebody can prepare a short-run document with TeX, print it out
on a PCL laser printer, then have somebody shoot negatives with a
process camera, then burn plates and print from that...but that end
product is less than decent.
Sanat
Natarajan Krishnaswami
On Mon, 01 Jun 1998 09:54:39 -0800, Sanat Kumara <caps...@sirius.com> wrote:
> PostScript is indeed device independent.
This is not really a meaningful statement. The PostScript language
provides facilities for both device-independent and device-dependent.
PostScript programs can be device-independent, but very often are not.
N.
--
nx...@po.cwru.edu, RFVC Moderation Team
Deorum iniuriae diis curae.
-- Tacitus
Harald Kirsch
In article <lbz90nh...@morgoth.uio.no> Rolf Marvin B|e Lindgren <ro...@morgoth.uio.no> writes:
> [Harald Kirsch]
>
> | Since my original post, were I dared to call PostScript device
> | independent, seems to have initiated all this rhetoric, I feel a bit
> | stupid, because I don't know the reasons why it is not. Could someone
> | explain me why or give me some keywords to ask DejaNews for, if it has
> | been discussed recently.
>
> DVI is an open standard which is under control of the TeX community
> (ideally, that, is). it is not owned by anybody.
Interesting fact, but what does it have to do with `device
independence'. What I understand in your text is `vendor independence'.
> GhostScript is a clone of PostScript and is, as such, not good enough
> for professional typesetting. if you want real typesetting, you need to
> purhcase a PostScript printer or a PostScript engine, which is why 80%
> of the TeX users either use GhostScript or a DVI to HP/PCL converter.
Conclusion: Those part of the 80% which use GhostScript don't do
professional typesetting and HP/PCL is more vendor independent than
PostScript ... or what?
> I used to work at the computing support center of the University of
> Oslo. we had an Imagen printer from DEC, two Xeroxen, a Linotronic,
> several HP and Apple printers, and also supported the entire printer
> network of the University of Oslo. my experience is that PostScript is
> not even compatible with itself, and is far too printer dependent to
> build a standard on. the Xerox would crash on anything. an HP III Si
> would crash if the file included a drawing made on Macintosh. the Lino
> would accept just about anything. all had small peculiarities.
All that you are talking about here is bad implementation of a
PostScript engine, which implies nothing about the device independence
of PostScript as a page description language.
Please don't get me wrong: I am not arguing that PostScript is the
solution to everthing. I was just after arguments explaining if/why
PostScript might be less device independent than DVI. From the answers
I saw until now I conclude that there are no such arguments.
And if we start talking about dismissing PostScript because it is
owned by Adobe: what page description do we use, if we want graphics?
Every graphic as a MetaFont-glyph? Uuuugh.
Rolf Marvin B|e Lindgren
[Robin Fairbairns]
| At the time, mark you, i concluded that lisp was the most arse-about-
| face language i'd ever encountered, and i was't terribly worried that
| there was no lisp interpreter on the machine i used.
Lisp isn't what it used to be. CLOS and ClTl2 are poetry in syntax and
symbols.
Rolf Marvin B|e Lindgren
[Rolf Marvin B|e Lindgren]
| Dvi is an open standard which is under control of the TeX community
| (ideally, that, is). It is not owned by anybody.
[Harald Kirsch]
| Interesting fact, but what does it have to do with `device
| independence'. What I understand in your text is `vendor independence'.
it means that one can be certain that DVI won't change significantly in
the future. It's much easier to change dvips, dvihplj, dvipcl, etc.,
than to change TeX.
| Conclusion: Those part of the 80% which use GhostScript don't do
| professional typesetting and HP/PCL is more vendor independent than
| PostScript ... or what?
and so what? we still need to cater for those who don't use TeX for
professional typesetting. they form a large basis of the most vital
part of the TeX community - those who ensure that universities and
(some) professional organizations support TeX.
| All that you are talking about here is bad implementation of a
| PostScript engine, which implies nothing about the device independence
| of PostScript as a page description language.
yes it does. it's much easier to write for a standardized
least-common-denominator virtual typesetting engine than to write for a
standard which a) isn't fully implementeded everywhere and b) is subject
to change without notice.
| And if we start talking about dismissing PostScript because it is
| owned by Adobe: what page description do we use, if we want graphics?
something that the dvi driver can understand. we live in the
communication age, the trend is towards generalized TeX macros that can
communicate with any DVI driver, calling external programs to translate
to whatever target one is processing for. If all the world were Windows
and PostScript, that would not be necessary, but all the world isn't,
and we've got to have to live with that.
| Every graphic as a MetaFont-glyph? Uuuugh.
don't be silly. every graphic as tpic forms, of course.
Louis Vosloo
Harald Kirsch wrote:
> > It's true that PS is wonderful. But it isn't required for
> > everything. Consequently tying everything in TeX to PS limits
> > it unneccessarily. Particulalry if you are not on a system
> > that uses Display PostScript as its imaging model (as NeXT was,
> > and as Rhapsody was going to be).
> Am I missing something? I cannot find any argument why PostScript is
> not device independent? Just because a PostScript interpreter is built
> into some printers does not make PostScript a device in itself.
> I cannot see the difference between using ghostscript, for example, to
> stuff pixelized data into e.g. a HP Deskjet and using dvidj or
> something like that.
Yes, it is an uphill battle :-) The difference is between converting
first to PS format and then to something else (like bitmaps on screen)
versus generating the final result directly (for example using ATM).
Generally the direct method is faster and more direct, and in the
case of font rendering also higher quality.
Your question also shows some bias towards printing. `Pre'viewing
is also important and can be high quality and need not depend on PS.
Things can look good on screen. It isn't necessary to just accept
`readable' form for on screen display. Of course, it is may be hard
to see this when you are used to working the other way :-)
Rebecca and Rowland
Rolf Marvin B|e Lindgren <ro...@morgoth.uio.no> wrote:
> [Rebecca and Rowland]
>
> | What difference is there between Ghostscript's output at high resolution
> | and output from a `real' Postscript interpreter at high resolution?
>
> as far as I know, basically the font rendering algorithm. type looks
> better with real PostScript. there are some other minor quirks too,
> which is documented in the GhostScript distribution.
I see; so at high resolution, there shouldn't be much of a difference?
(aside from the quirks, that is).
Rowland.
Rebecca and Rowland
Ernst U. Wallenborn <wa...@bacon.ethz.ch> wrote:
> reb...@astrid.u-net.com (Rebecca and Rowland) writes:
>
> > Another problem is that Ghostscript is *slow* on my old Mac; MacGS View
> > crashes if I do unreasonable things like move the console window, and
> > CMacTeX's Ghostscript tends to crash while rendering.
>
> i have a performa 475, too, and the most recent Cmactex ghostscript
> is stable afaict.
Ah! Now for the chance for a meaningful comparison. I'm using System
7.6.1 and RAM Doubler 2.0.2 on a Performa 475 with 20MB RAM; Tom Kiffe
reckons the crashes I've seen are probably down to a collision between
his (apparently nasty in places) code and RAM Doubler. Are you using
RAM Doubler? If not, the problem is probably isolated.
> I is slow, though. But dvi on the other
> hand is not truly an alternative: i tried to transfer dvi
> files at first, and this did not work because the font setup
> was not identical on my machines.
That's the problem with dvi; PostScript has its uses, and I'd certainly
consider using it if I had to print a file elsewhere. I've just not
needed to do that yet (thankfully, since I've not added all my founts to
psfonts.map).
> > I've had trouble with GS mis-scaling pages and things like that (a bug
> > in MacGSView, since fixed). On the other hand, OzTeX's dvi driver has
> > worked perfectly the whole time I've been using it.
>
> OzTeXs dvi driver is known to be very good. But there's no
> OzTeX in Windoze, and yap's printing routines are mediocre
> at best.
Hmm - interesting. I didn't know that.
> > > Personally, i write much on my linux notebook. At home i use
> > > my old mac as a print server,
> >
> > Have you really got Ghostscript working as a printing device? That is,
> > just send it the files and watch them print the way you want?
>
> I put the file on my mac, open ghostscript and say Print.
> In earlier versions you could only print one page at a time,
> true, and this was a major #$%@@#$! but now this limit is gone,
> and i don't care about the speed since i don't have to stand
> by the machine.
Speed of rendering isn't something that bothers me particularly; what I
don't like is the way I'd have to do two dvips runs and then two bits of
work with Ghostscript to get a typical two-sided document printed. It's
too much like hard work to me (yes, I know it's just a minute or so with
the mouse, but that's not the point). Now if I could just drop a dvi
file onto an Applescript that did the whole job, I'd be quite happy
using PostScript even if it did take 2 minutes to render each page.
Rebecca and Rowland
Odd - I'd've thought this would be practical. Have you tried asking in
comp.lang.postscript about this? Or is it something that is certainly
not possible with the current Ghostscript?
Ernst U. Wallenborn
reb...@astrid.u-net.com (Rebecca and Rowland) writes:
> Ernst U. Wallenborn <wa...@bacon.ethz.ch> wrote:
> Ah! Now for the chance for a meaningful comparison. I'm using System
> 7.6.1 and RAM Doubler 2.0.2 on a Performa 475 with 20MB RAM; Tom Kiffe
> reckons the crashes I've seen are probably down to a collision between
> his (apparently nasty in places) code and RAM Doubler. Are you using
> RAM Doubler? If not, the problem is probably isolated.
System 7.0, 20MB RAM, *no* Ram doubler.
> > OzTeX in Windoze, and yap's printing routines are mediocre
> > at best.
>
> Hmm - interesting. I didn't know that.
I can only talk from my experience in setting up MikTeX on
two different W95 machines with different printers over
Christmas last year. On both printers yap frequently
truncated output. gs got the job done.
Juergen v. Hagen
Rebecca and Rowland wrote:
>
> > I can not print gnuplot created color PS (on Unix) files via GhostView
> > on my PC (on Winow$ 95). For me, ps is definetly NOT a piece of cake.
>
> Odd - I'd've thought this would be practical. Have you tried asking in
> comp.lang.postscript about this? Or is it something that is certainly
> not possible with the current Ghostscript?
to
worry about. I now use gnuplot on the PC and print directly the window.
I just wanted to point out that PS is NOT as versatile, device
independant,
easy to use, straightforward, fault insensitive, use-whereever-you-want
as some people might think. If I can get away without PS I do it.
Especially as PS seems to me a bit like a dead end: once you have
something
in PS, you're stuck with it. You can convert DVI to a lot of things as
there are a lot of ("device") drivers, but with PS you're stuck with gs
(which
you {\it could} use to convert into other formats, but this is not 100%
sure - not even 90% in my experience) or native PS interpreters.
cheers
juergen
PROF D. Rogers {EAS FAC}
G'day,
Let me jump into the middle of this discussion.
Recently I ran a TeX job of some 800 pages including
about 500 line art images and a few halftones on a PC.
I use dvips to convert the output to PostScript
and sent the PostScript files to the printer and
with minor problems it worked well. Now this sounds
like an argument for PostScript being device independent
but it is not. The problems had to do with the fact
that the PostScript outline font rasterized is NOT
resolution, and hence device, independent. It is a well
known that when the Computer Modern Type 1 fonts, which
were `optimized' for a resolution of about 300 dpi
are rasterized at higher resolutions say 2400 dpi
that they come out too thin. Hence, the device
independence of PostScript is lost, i.e., I do not
get the same looking page when rendered at 2400 dpi
and 300 dpi.
In addition, a number of individuals that have posted
have simply said that PostScript is not device independent.
I am sure this is just based on experience. Frequently,
a given PostScript file will simply NOT correctly run
on different PostScript printers EVEN IF ALL THE PRINTERS
ARE USING AN ADOBE POSTSCRIPT RASTERIZER AND HAVE BEEN
GENERATED WITH AN ADOBE SOFTWARE PRODUCT! Interesting
that!
Dave Rogers
In article <3572EA...@sirius.com>,
Sanat Kumara <caps...@sirius.com> wrote:
>Harald Kirsch wrote:
>>
>> "Michael C. Grant" <mcg...@mindspring.com> writes:
>>
>> > Rolf Marvin B|e Lindgren wrote in message ...
>> > >all in all, Lisp seems to be the way to go.
>> > >and by the way, the output language should not be PostScript, that would
>> > >alienate 80% of current TeX users.
>> >
>> > I know, let's make the output language _device independent_; hmm, we can
>> > call it DVI, that sounds right. We could make a "previewer" which would let
>> > us see what these documents will look like before we try to print them out.
>> >
>> > Then we could make converters that can take these DVI files and turn them
>> > into, say, PS files for PostScript lovers, PCL for HP printer owners, and
>> > throw in a windows driver perhaps.
>>
>> Since my original post, were I dared to call PostScript device
>> independent, seems to have initiated all this rhetoric, I feel a bit
>> stupid, because I don't know the reasons why it is not. Could someone
>> explain me why or give me some keywords to ask DejaNews for, if it has
>> been discussed recently.
>
>PostScript is indeed device independent.
>
M. Schulter
In comp.lang.postscript Louis Vosloo <sup...@YandY.com> wrote:
: Yes, it is an uphill battle :-) The difference is between converting
: first to PS format and then to something else (like bitmaps on screen)
: versus generating the final result directly (for example using ATM).
: Generally the direct method is faster and more direct, and in the
: case of font rendering also higher quality.
Hello, there.
Before commenting on the above, I would like to emphasize that not all TeX
users may use or need PostScript in any form, so the availability of
alternative display models certainly makes sense.
Please let me say that while I certainly recognize that some TeX users
may get along quite well without either a PostScript output device for
hard copy or PostScript preview capabilities, some of us use PostScript
coding to generate graphics for inclusion in TeX documents. In this case,
PostScript is indeed required for either a page preview on screen or final
output on paper or film.
: Your question also shows some bias towards printing. `Pre'viewing
: is also important and can be high quality and need not depend on PS.
: Things can look good on screen. It isn't necessary to just accept
: `readable' form for on screen display. Of course, it is may be hard
: to see this when you are used to working the other way :-)
Here I would comment that at least for me, being able to preview
PostScript code on screen is indeed just as vital as it is for the user of
a GUI graphics program to be able to view an illustration on screen before
printing. Personally, I find that using a PostScript interpreter to
generate the preview has two advantages: it permits the same imaging model
on screen and paper; and, maybe most importantly, permits seeing
everything on screen, including EPS files and even arbitrary PostScript
code added in "literal PS" mode to a TeX document.
Of course, for people who aren't using PostScript as a design language, I
realize that these issues could be very different. However, it is isn't
only Display PostScript users who are relying on PostScript interpreters
to generate graphics data for on-screen previews.
Most respectfully,
Margo Schulter
msch...@value.net
Petr Prikryl
[discussion about device (in)dependency of PostScript from previous
contributions deleted]
PROF D. Rogers {EAS FAC} (d...@eagle3.usna.navy.mil) wrote:
>[...] It is a well known that when the Computer Modern Type 1 fonts,
>which were `optimized' for a resolution of about 300 dpi are
>rasterized at higher resolutions say 2400 dpi that they come out too
>thin.
My guess is that the opposite is true. As far as I know from
discussions with those who knows more about typesetting than I do,
CM were designed for rather high resolutions (like 2400 DPI) which
were used in print-houses before the era of widely spread laser
printers. The people say, that CM looks much better when printed
with high resolution. They look thin not because of the "high
resolution fault", but because they were designed to look thin. It
is clear that they must look bolder or distorted if you print with
lower resolution.
>Hence, the device independence of PostScript is lost, i.e., I do not
>get the same looking page when rendered at 2400 dpi and 300 dpi.
If you want to argue about Type 1 version of CM, then this is not a
problem of PostScript, but of the font. Simply, rasterized result
from CM Type 1 PostScript font may not be equal to CM font
rasterized by Metafont. But it is not the fault of the PostScript.
I quest that if you were able to design CM Type 1 font so precisely
like the Metafont original was done (with hints and all details
related to different resolution), then results of rasterizing for
different resolutions will be comparable.
>In addition, a number of individuals that have posted
>have simply said that PostScript is not device independent.
>I am sure this is just based on experience.
As somebody mentioned here, PostScript may be device independent.
But it is a programming language. You may always create a bad
program in any programming language. It does not mean that the
programming language is bad. The language would be bad if you were
not be able to create a good program.
P.
--
Petr Prikryl (pri...@dcse.fee.vutbr.cz) http://www.fee.vutbr.cz/~prikryl/
TU of Brno, Dept. of Computer Sci. & Engineering; tel. +420-(0)5-7275 218
Rebecca and Rowland
Ernst U. Wallenborn <wa...@bacon.ethz.ch> wrote:
> reb...@astrid.u-net.com (Rebecca and Rowland) writes:
>
> > Ernst U. Wallenborn <wa...@bacon.ethz.ch> wrote:
>
> > Ah! Now for the chance for a meaningful comparison. I'm using System
> > 7.6.1 and RAM Doubler 2.0.2 on a Performa 475 with 20MB RAM; Tom Kiffe
> > reckons the crashes I've seen are probably down to a collision between
> > his (apparently nasty in places) code and RAM Doubler. Are you using
> > RAM Doubler? If not, the problem is probably isolated.
>
> System 7.0, 20MB RAM, *no* Ram doubler.
7.0? Really? I thought 475s needed 7.1 at least. Why such an old OS?
(being curious here). But I note the lack of RAM Doubler; I really must
try CMacTeX's Ghostscript without.
> > > OzTeX in Windoze, and yap's printing routines are mediocre
> > > at best.
> >
> > Hmm - interesting. I didn't know that.
>
> I can only talk from my experience in setting up MikTeX on
> two different W95 machines with different printers over
> Christmas last year. On both printers yap frequently
> truncated output. gs got the job done.
Hmm - interesting again. Thanks.
Rebecca and Rowland
Juergen v. Hagen <vonh...@engr.psu.edu> wrote:
[snip]
> I just wanted to point out that PS is NOT as versatile, device
> independant, easy to use, straightforward, fault insensitive,
> use-whereever-you-want as some people might think. If I can get away
> without PS I do it.
Likewise.
> Especially as PS seems to me a bit like a dead end: once you have
> something in PS, you're stuck with it. You can convert DVI to a lot of
> things as there are a lot of ("device") drivers, but with PS you're stuck
> with gs (which you {\it could} use to convert into other formats, but this
> is not 100% sure - not even 90% in my experience) or native PS
> interpreters.
I think the great advantage of PS over dvi is that (assuming the PS
interpreter doesn't choke on the file) it produces pretty much the same
output anywhere. The problem with dvi files is that they depend on
founts stored outside the dvi file, so you're dependent on the dvi
driver setup, which normally varies quite radically from computer to
computer. Of course, if you stick with the standard CM founts, you
should be okay.
Rebecca and Rowland
PROF D. Rogers {EAS FAC} <d...@eagle3.usna.navy.mil> wrote:
[snip]
> The problems had to do with the fact
> that the PostScript outline font rasterized is NOT
> resolution, and hence device, independent.
Surely this is one of the strengths of PS? Isn't the difference mainly
due to differences in fitting the output glyhps to the raster of the
printer, which must be varied with resolution to maintain quality?
> It is a well
> known that when the Computer Modern Type 1 fonts, which
> were `optimized' for a resolution of about 300 dpi
> are rasterized at higher resolutions say 2400 dpi
> that they come out too thin.
I'm not sure this is right: the CM/PS Type 1 founts I have look very
poor to my eyes at 300dpi on my HP DW520 inkjet when compared to the pk
version of the `same' fount; 12pt in particular looks far too tall and
thin and *very* different to the appearance of the CM founts that the
designer aimed at (see, for example, `The TeXbook' for a definitive view
of what the designer intended). The same founts printed at 90pt on the
same printer look identical, so I can't see how they could look too thin
at higher resolution unless you're printing on a write-white device or
somesuch. Not that I'm really up on the precise details of the
pathology high-resolution printing myself
[snip]
Harald Kirsch
In article <35735C33...@YandY.com> Louis Vosloo <sup...@YandY.com> writes:
[His older arguments and my new question removed. It was about why or
why not use always PostScript as the output of (La)TeX.]
> Your question also shows some bias towards printing. `Pre'viewing
> is also important and can be high quality and need not depend on PS.
> Things can look good on screen. It isn't necessary to just accept
> `readable' form for on screen display. Of course, it is may be hard
> to see this when you are used to working the other way :-)
Yes really, when using TeX, I am definitely biased towards publishing
on paper. Of course I use TeX also as a base for HTML-documents, but
this is a totally different story involving neither DVI nor
PostScript. But even for on-screen published documents,
i.e. documents for the WWWW, PDF seems to be the wave of the future,
and, afaik, PDF is PostScript+DSC+something.
In addition I must say that I don't see much difference between
(on-screen) output from xdvi and GhostScript.
But I am able to learn, I hope, and I would like to hear about
alternatives to PostScript when it comes to graphics to be included
into TeX-documents. And no, no, no, I don't want to hear `MetaFont'
now --- maybe MetaPost, which is pretty neat, but then ... !-)
Ernst U. Wallenborn
reb...@astrid.u-net.com (Rebecca and Rowland) writes:
> 7.0? Really? I thought 475s needed 7.1 at least. Why such an old OS?
> (being curious here). But I note the lack of RAM Doubler; I really must
> try CMacTeX's Ghostscript without.
it is 7.1, actually, soryyy for the misinformation.
when 7.5 came out, i looked at its add-ons and noted
i already had almost all of the stuff, and decided to
wait and upgrade to 8.0, when it would come out. This
upgrade then never happened.
BTW i failed to install the latest version of CMacTeX
(the one with the fancy install script), mine is -i believe-
2.3 which i mixed with the latest available gs.
Robin Fairbairns
In article <KIR.98Ju...@Gauss.iitb.fhg.de>,
something = (hyper-references + font characterisation -
`programmability') + something-else(?)
i don't know it well enough to know if i'm missing anything. the
important point is that pdf is both more expressive and less
expressive than postscript, but in different areas ;-)
Robin Fairbairns
In article <1da0s7l.mig...@p52.nas1.is2.u-net.net>,
>
>[snip]
>> The problems had to do with the fact
>> that the PostScript outline font rasterized is NOT
>> resolution, and hence device, independent.
>
>Surely this is one of the strengths of PS? Isn't the difference mainly
>due to differences in fitting the output glyhps to the raster of the
>printer, which must be varied with resolution to maintain quality?
indeed. to claim that this makes postscript device dependent is like
claiming that paper isn't: it's a truism, but misses the point of the
discussion.
>> It is a well
>> known that when the Computer Modern Type 1 fonts, which
which cm type1 fonts are you talking of, here?
>> were `optimized' for a resolution of about 300 dpi
>> are rasterized at higher resolutions say 2400 dpi
>> that they come out too thin.
>
>I'm not sure this is right: [...]
me neither, but no doubt someone from y&y or bluesky will put us
right.
i work almost exclusively at 600dpi and find that the type1 outlines
produce a better result (using the print engine's rasteriser) than any
metafont mode i've ever concocted for them. they do look thinner than
the metafont output i get, but cm was *designed* thin. when the
printer's in good nick, the output looks beautifully `crisp', and
remarkably similar to that achieved in the texbook etc.
Louis Vosloo
Harald Kirsch wrote:
> In article <35735C33...@YandY.com> Louis Vosloo <sup...@YandY.com> writes:
> [His older arguments and my new question removed. It was about why or
> why not use always PostScript as the output of (La)TeX.]
> > Your question also shows some bias towards printing. `Pre'viewing
> > is also important and can be high quality and need not depend on PS.
> > Things can look good on screen. It isn't necessary to just accept
> > `readable' form for on screen display. Of course, it is may be hard
> > to see this when you are used to working the other way :-)
> Yes really, when using TeX, I am definitely biased towards publishing
> on paper.
But why? They *can* look good on screen. It isn't always
necessary to use up trees just to read a paper :-)
> Of course I use TeX also as a base for HTML-documents, but
> this is a totally different story involving neither DVI nor
> PostScript. But even for on-screen published documents,
> i.e. documents for the WWWW, PDF seems to be the wave of the future,
Yes, of course.
> and, afaik, PDF is PostScript+DSC+something.
sort of :-) --- minus the programming capabilities of PS and minus DSC
and plus some other PDF stuff.
> In addition I must say that I don't see much difference between
> (on-screen) output from xdvi and GhostScript.
There should be no difference if you are using PK fonts.
Also, I was referring to Adobe Type Manager as the reference
rasterizer for Type 1 fonts.
> But I am able to learn, I hope, and I would like to hear about
> alternatives to PostScript when it comes to graphics to be included
> into TeX-documents. And no, no, no, I don't want to hear `MetaFont'
> now --- maybe MetaPost, which is pretty neat, but then ... !-)
For photographs / images TIFF is a better alternative giving the
enormous size of EPS files for images (particularly PS level I).
Louis Vosloo
Robin Fairbairns wrote:
>
> In article <1da0s7l.mig...@p52.nas1.is2.u-net.net>,
> Rebecca and Rowland <reb...@astrid.u-net.com> wrote:
> >PROF D. Rogers {EAS FAC} <d...@eagle3.usna.navy.mil> wrote:
> >> It is a well
> >> known that when the Computer Modern Type 1 fonts, which
> which cm type1 fonts are you talking of, here?
> >> were `optimized' for a resolution of about 300 dpi
> >> are rasterized at higher resolutions say 2400 dpi
> >> that they come out too thin.
> >I'm not sure this is right: [...]
It isn't :-)
> me neither, but no doubt someone from y&y or bluesky will put us
> right.
A lot has been said on this topic, much of it confusing or wrong,
much of it by R&R. Suffice it to say that the Type 1 outlines
are exactly the shapes designed by Knuth. They will print
slightly differently on different printers as the result of
different adjustments, different resolutions and different
Type 1 font rasterization algorithms. Whether Knuth intended
CM to be as thin and spindley as it is has been debated.
Certainly Monotype Modern 8A on which it is based was thin,
as was the fashion when it is was `modern' about a century ago.
> i work almost exclusively at 600dpi and find that the type1 outlines
> produce a better result (using the print engine's rasteriser) than any
> metafont mode i've ever concocted for them. they do look thinner than
> the metafont output i get, but cm was *designed* thin. when the
> printer's in good nick, the output looks beautifully `crisp', and
> remarkably similar to that achieved in the texbook etc.
--
Ian
In article <3573EA27...@engr.psu.edu>,
"Juergen v. Hagen" <vonh...@engr.psu.edu> writes:
> Especially as PS seems to me a bit like a dead end: once you have
> something in PS, you're stuck with it. You can convert DVI to a lot
> of things as there are a lot of ("device") drivers, but with PS
> you're stuck with gs (which you {\it could} use to convert into
> other formats, but this is not 100% sure - not even 90% in my
> experience) or native PS interpreters.
I've never really seen much more flexibility in dvi conversion than I
have in postscript, if you want real flexibility you process the
original latex source, not the output file.
--
Ian - Edit address before mailing. | Have you got a question you want to ask
Running Linux for Intel in the UK. | Usenet? Search www.dejanews.com first!
Ian
> Have you really got Ghostscript working as a printing device? That
> is, just send it the files and watch them print the way you want?
I have under Linux. I just select postscript output from everything
and just pipe it to lpr, these two are usually the default for most
packages anyway. Having said that, I haven't tried it since my hard
disc crash and 2 backup tape media errors lost me a large chunk of my
system (no data thankfully, just setup) so it might no longer work.
It was working fine, and I'd put psnup and psselect into the command
chain, psselect was set up in front of ghostscript on the default
printer queue to reverse the order of any postscript files to make my
noddy printer print them last-first (it stacks face-up), and psnup was
set up under different printer queues to place more than one page onto
each printed page. I then had 1 cheap inkjet printer and 5 virtual
printers, one straight high-quality queue for final printing, the
default queue for 150DPI fast draft printing, a colour queue for
printing using the colour cartridge, a 2-up queue for printing two
pages per page, and a 4-up queue for printing 4 pages per page. DVI
files were processed automatically by the print filter, which fed them
through dvips, unfortunately this bit didn't work if I was including
external postscript files via epsfig using pathnames relative to the
directory the DVI file was created in, so I didn't use it much.
I've just checked, no printer commands are on my system any more. :-(
I'll have to go through all that setup malarkey again..
If you've got some spare cash and time, you could buy a *really cheap*
PC and network it to your mac, a 486 with 8 megs and a 500Mbyte disc
would do. Use that as a printer server and pass it postscript
files. The packages I used in the above are psutils (for psselect and
psnup), ghostscript (aladdin's, not GNU --- it's free for personal
use), magicfilter (for setting up the command chain and for various
file types), and lprNG (for the application printer interface).
Psutils is available on CTAN, ghostscript is from aladdin's web site
(can't remember the URL, it should be easy to guess), the rest is from
sunsite.unc.edu.
Robin Fairbairns
In article <1da0n79.jmp...@p52.nas1.is2.u-net.net>,
>interpreter doesn't choke on the file)
a pretty big assumption.
>it produces pretty much the same
>output anywhere. The problem with dvi files is that they depend on
>founts stored outside the dvi file, so you're dependent on the dvi
>driver setup, which normally varies quite radically from computer to
>computer. Of course, if you stick with the standard CM founts, you
>should be okay.
we have in this department a fair number of propietary outline fonts
spinning on hard drives on the file servers. they're all pgp-
encrypted. if you specify any one of them to dvips, it merely lists
them in the DocumentFonts command: the despooler then decrypts the
fonts on the fly on the way to the printer and inserts them into the
printer output.
the has the strong advantage that people can't (maliciously or
otherwise) export documents containing entire fonts, thus violating
copyright restrictions. however, .ps files from here have exactly the
same property that .dvi files have, that you may need the fonts in the
document locally to be able to read it.
the *only* remotely satisfactory solution to these problems is to
distill the document without embedding the fonts. if the font isn't
available at the far end, the acrobat viewer will magic an almost
passable look-alike via the multiple master mechanism.
Rebecca and Rowland
Louis Vosloo <sup...@YandY.com> wrote:
[snip]
> A lot has been said on this topic, much of it confusing or wrong,
> much of it by R&R.
Would you care to quote one of my comments on this subject which is
wrong?
> Suffice it to say that the Type 1 outlines
> are exactly the shapes designed by Knuth. They will print
> slightly differently on different printers as the result of
> different adjustments, different resolutions and different
> Type 1 font rasterization algorithms. Whether Knuth intended
> CM to be as thin and spindley as it is has been debated.
Why? Surely all you need to do is look at one of his books to find out
what he intended?
> Certainly Monotype Modern 8A on which it is based was thin,
> as was the fashion when it is was `modern' about a century ago.
It was `modern' nearer 250 years back.
Rebecca and Rowland
Ian <ia...@pobox.DUMPTHISBIT.quza.com> wrote:
> > Have you really got Ghostscript working as a printing device? That
> > is, just send it the files and watch them print the way you want?
>
> I have under Linux. I just select postscript output from everything
> and just pipe it to lpr, these two are usually the default for most
> packages anyway. Having said that, I haven't tried it since my hard
> disc crash and 2 backup tape media errors lost me a large chunk of my
> system (no data thankfully, just setup) so it might no longer work.
Ouch!
> It was working fine, and I'd put psnup and psselect into the command
> chain, psselect was set up in front of ghostscript on the default
> printer queue to reverse the order of any postscript files to make my
> noddy printer print them last-first (it stacks face-up), and psnup was
> set up under different printer queues to place more than one page onto
> each printed page. I then had 1 cheap inkjet printer and 5 virtual
> printers, one straight high-quality queue for final printing, the
> default queue for 150DPI fast draft printing, a colour queue for
> printing using the colour cartridge, a 2-up queue for printing two
> pages per page, and a 4-up queue for printing 4 pages per page. DVI
> files were processed automatically by the print filter, which fed them
> through dvips, unfortunately this bit didn't work if I was including
> external postscript files via epsfig using pathnames relative to the
> directory the DVI file was created in, so I didn't use it much.
Coo!
[snip]
> If you've got some spare cash and time, you could buy a *really cheap*
> PC and network it to your mac, a 486 with 8 megs and a 500Mbyte disc
> would do.
[snip]
Now that's a thought. The only problem is that networking it to my Mac
would probably cost more than the cheap Wintel box. But it's worth a
think, isn't it?
Rebecca and Rowland
Louis Vosloo <sup...@YandY.com> wrote:
> Harald Kirsch wrote:
>
> > In article <35735C33...@YandY.com> Louis Vosloo
<sup...@YandY.com> writes:
>
> > [His older arguments and my new question removed. It was about why or
> > why not use always PostScript as the output of (La)TeX.]
>
> > > Your question also shows some bias towards printing. `Pre'viewing
> > > is also important and can be high quality and need not depend on PS.
> > > Things can look good on screen. It isn't necessary to just accept
> > > `readable' form for on screen display. Of course, it is may be hard
> > > to see this when you are used to working the other way :-)
>
> > Yes really, when using TeX, I am definitely biased towards publishing
> > on paper.
>
> But why? They *can* look good on screen. It isn't always
> necessary to use up trees just to read a paper :-)
At the moment, it's much easier, faster, and more comfortable to read
documents on paper than on screen. I *never* attempt to read any
substantial document on screen if I have the option of printing it out.
I've never met a computer screen with anything like the same resolution,
contrast, and ease-of-use of a paper document. Try holding your place
with a finger while you flick back a few pages in an on-screen document.
If I had a 21 inch monitor and a faster computer, I might read some
substantial documents on screen. I'm not rich enough for that just yet,
and I'd probably need a bigger desk.
[snip]
Franz Kaufmann
On 31 May 1998 07:35:13 GMT, Harald Kirsch says...
>
>
>Hi there,
>
>recently I had a look at what the LaTeX3 team has released. It reads
>like their prime goal is currently to create well defined,
>straightforward and understandable _programming language_ on top of
>the TeX language, in particular to ease the task of writing document
>classes. And of course they want to maintain compatibility with
>LaTeX2e.
>
>Out of curiosity I wonder what it would be like, if we start from
>scratch and ask for a macro- or scripting-language to typeset
>documents. At the back end, I would probably see PostScript instead of
>DVI. But the front end?
>
>Personally I like Tcl as a scripting language, in particular because
>its evaluation rules almost trivial. The command `man Tcl|wc -l'
>results in just 264 lines. To make it easier to type long paragraphs,
>I would change just one rule of Tcl: A command ends at a semicolon or
>at an empty line, not at the end of the line.
>
>The basic command to typeset a paragraph would probably be `Par'. The
>following paragraphs try to use the syntax of Tcl for annotation and
>will probably only make sense to the Tcl-literate.
>
>
>Par The command [texttt Par] collects all its arguments in the
>Tcl-sense and typesets them as a paragraph. As described above, its
>arguments are all the words up to the next empty line, i.e. this one
>ends here.
>
>Par According to Tcl's evaluation rules, [textit words enclosed in
>brackets] are evaluated even before [texttt Par] sees them, so the
>command [texttt textit] can arrange to have its arguments typeset in
>[textit italics].
>
>Par The syntax of environments could look like this:
>
>Itemize;
> item The semicolon on the previous line terminates the argument list
> of the [texttt Itemize]-command in the same way as an empty line would
> do. This way, [texttt item] is a new command.
>
> item The [texttt Itemize]-command would set several global
> parameters to allow the [texttt item]-commands to work as expected.
>
> item Finally, the a command like [texttt EndItemize] would reset the
> parameters which were changed by [texttt Itemize].
>
>EndItemize
>
>Par Although this looks pretty neat, how would it be to typeset TeX's
>logo? Suppose we have a built-in function that arranges a list of
>boxes according to kerns and raise-amounts noted in between. Then, in
>Tcl-syntax we could define a macro like this:
>
>Verbatim {
> proc TeX {} {
> [arrange T -.16667em -0.5ex E -0.125em 0pt X] }
> }
>}
>
>Par Note how I would expect the [texttt arrange]-command to understand
>numbers with a unit! And see how the extra braces make sure that the
>whole text is passed unevaluated to the [texttt Verbatim]-command.
>
>Par Now [TeX]'s logo is readily available, but of course in a rather
>new syntax.
>
>Par -linewidth 10cm
>We could use options to change the appearance of a paragraph. The
>meaning of the option used for this one should be obvious.
>
>Par All these are very preliminary ideas. Maybe someone out there
>knows TeX and Tcl as well and can point out, if the ideas desribed
>above are at all possible, or if TeX as a macro-language has features
>which would never be possible to formulate in Tcl.
>
>Thank you for your patient reading,
>
> Harald Kirsch.
>--
>---------------------+------------------+--------------------------
>Harald Kirsch (@home)| | Now I rebooted.
>k...@iitb.fhg.de | | --- Jerry Pournelle, BYTE
> gegen Punktfilitis hilft nur `chmod u-w ~'
Hello.
I wonder why anyone hasn´t proposed Perl as a language to use with tex.
Perl is available on a lot of platforms (->Portability problem solved).
Perl is more powerful with text than TCL and Lisps such as Scheme and
guile.
Perl can be extended via perl and C.
Perl is linked to TK and other GUI´s and widget sets.
Perl has links to all kinds of DBMSes.
Perl is here and ready,guile is halfbreed.
Perl can be used inside Emacs 20.2 via the Perlmacs patch.
Can anything beat the team Emacs,Perl and TeX/LaTeX?
I think not,so why not help these three to meet?
Rolf Marvin B|e Lindgren
[Franz Kaufmann]
| I wonder why anyone hasn´t proposed Perl as a language to use with tex.
because it's not April Fool's Day yet.
--
Rolf Lindgren | "The opinions expressed above are
Sofienberggt. 13b | not necessarily those of anyone"
N-0551 OSLO | ro...@ask.uio.no
Robin Fairbairns
In article <lbz4sy1...@morgoth.uio.no>,
Rolf Marvin B|e Lindgren <ro...@morgoth.uio.no> wrote:
>[Franz Kaufmann]
>
>| I wonder why anyone hasn´t proposed Perl as a language to use with tex.
>
>because it's not April Fool's Day yet.
i dunno. perl has its (errm) distinctive qualities ... it's
a write-only language with a preposterously arcane syntax. its
practitioners form a jealously-guarded refinement of the class of
programmers. its afficionados aspire to wondrously compact and
complex code.
just like tex, really.
Thorsten Ohl
r...@cl.cam.ac.uk (Robin Fairbairns) writes:
> i dunno. perl has its (errm) distinctive qualities ... it's
> a write-only language with a preposterously arcane syntax. its
> practitioners form a jealously-guarded refinement of the class of
> programmers. its afficionados aspire to wondrously compact and
> complex code.
>
> just like tex, really.
Imagine a \catcode command in perl ...
However, such a feature would make the participation in the annual
Obfuscated Perl Code Contest far too easy!
--
Thorsten Ohl, Physics Department, TU Darmstadt -- o...@hep.tu-darmstadt.de
http://crunch.ikp.physik.tu-darmstadt.de/~ohl/ [<=== PGP public key here]
Rolf Marvin B|e Lindgren
[Robin Fairbairns]
| I dunno. Perl has its (errm) distinctive qualities ... it's a
| write-only language with a preposterously arcane syntax. Its
| practitioners form a jealously-guarded refinement of the class of
| programmers. Its afficionados aspire to wondrously compact and
| complex code.
oh, I've been hacking Perl for years. it's nifty, and powerful as a
filtering language, but nowhere as expressive as Lisp.
| Just like tex, really.
touché.
Rebecca and Rowland
Peter Wyzlic <p...@pwyz.rhein.de> wrote:
> On Wed, 3 Jun 1998 19:55:38 +0100, Rebecca and Rowland
> <reb...@astrid.u-net.com> wrote:
>
> [Some Linux propaganda]
> >> If you've got some spare cash and time, you could buy a *really cheap*
> >> PC and network it to your mac, a 486 with 8 megs and a 500Mbyte disc
> >> would do.
> >[snip]
> >
> >Now that's a thought. The only problem is that networking it to my Mac
> >would probably cost more than the cheap Wintel box. But it's worth a
> >think, isn't it?
>
> No, Linux supports the Apple-Talk protocol, you need a cable, and
> a bit time and patience for the network configuration.
Surely I also need a LocalTalk card for the Wintel box? After all,
LocalTalk runs at 230,400 bit/s over a differential pair. Most Wintel
boxes come with an RS232 port which can't do differential signalling or
run faster than 115,200 bit/s.
It was the extra hardware that made me think it'd be expensive.
> Maybe,
> with an ethernet card the data transfer is faster, but ethernet
> cards are also relatively cheap.
For some computers. They're expensive and virtually unobtainable for my
Performa 475.
Alan Shutko
>>>>> "R" == Rebecca and Rowland <reb...@astrid.u-net.com> writes:
R> For some computers. They're expensive and virtually unobtainable
R> for my Performa 475.
That's the same thing as an LC475, right?
Yeah, they are expensive. However, if you want to pay shipping, we
might be getting rid of some in Residential Computing at WU. You
might (if you want to go this route, probably way too much trouble)
check used groups, because I'm sure we're not the only schools
upgrading from those machines.
--
Alan Shutko <a...@acm.org> - By consent of the corrupted
He who laughs last thinks slowest
Allin Cottrell
Based on some recent experience, I'm feeling bleak. Seems
like the "future of typesetting" is... MS Word!
I've just spent many hours trying to turn perfectly good LaTeX
into RTF plus whatever-might-possibly-work for the graphics,
because a paper of mine has been accepted for publication in a
conference volume, and the editor (this is increasingly common,
for our sins) will accept only Word-compatible stuff. I know
full well the end result will look like sh*t. What can one do?
Should I say, if you can't accept LaTeX, forget publishing my
paper? Perhaps.
The other, even more depressing, experience: One doesn't expect
_everyone_ to be able to deal with LaTeX source, but surely any
computer-literate colleague ought to be able to deal with a
postscript file? Think again. I've recently been dealing with
some colleagues in Computer Science (!) departments in the UK,
who apparently can't make anything of postscript files I have
sent them. They're using NT.
Still hoping this is all a bad dream...
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
Steve Rindsberg
Postscript can be device independent but isn't necessarily device
independent.
However, device independent PS of necessity can't access device-specific
features.
--
Steve Rindsberg, Prez, RDP (a slide imaging service)
Microsoft MVP, Lotus L-Team
http://www.rdpslides.com
Please direct newsgroup replies to the newgroup, where I'm a volunteer
NOT to Email, where I charge for private consultations.
> Am I missing something? I cannot find any argument why PostScript is
> not device independent? Just because a PostScript interpreter is built
> into some printers does not make PostScript a device in itself.
>
> I cannot see the difference between using ghostscript, for example, to
> stuff pixelized data into e.g. a HP Deskjet and using dvidj or
> something like that.
>
> Harald Kirsch
Axel Kielhorn
Juergen v. Hagen <vonh...@engr.psu.edu> wrote:
> Harald Kirsch wrote:
> >
> ....
> > Am I missing something? I cannot find any argument why PostScript is
> > not device independent?
> I'm in no way a Guru of whatsoever, just my .02: if the SAME PostScript-
> file prints fine on one device, but not on some other (as I experienced
> a lot with mixed Mac, PX, Unix on mixed Mac and Hp printers), I would
> call this "device dependant".
Ever wondered what all these PPD files are for?
I can tell a DocuTech to sort the copies and staple them on the long end
with a PostScript command. If I send this command to an HP Laserjet it
doesn't work.
When I print using an HP Laserjet PPD it uses a special halfoning screen
that crashes the QMS.
Axel
Axel Kielhorn
Robin Fairbairns <r...@cl.cam.ac.uk> wrote:
> i only know one person (in this country) who persists in using a 286
> (let alone an 8086) -- are such historical relics still a significant
> part of tex equipment?
You may be right about PCs. But you will still find a lot of Ataris (68k
8 Mhz) or Mac IIs (68020 / 030 16 ... 25 (32?) Mhz) that are used to run
TeX.
Axel,
who now has a 32 Mhz Performa 630 that is still to slow to use GS for
previewing. (About 1/3 of the speed of OzTeX DVI previewing.)
Bonvesin de la Riva [bonvicin@humiliati.ripa]
On Thu, 4 Jun 1998, Allin Cottrell wrote:
> Based on some recent experience, I'm feeling bleak. Seems
> like the "future of typesetting" is... MS Word!
will it be that bad ?
> I've just spent many hours trying to turn perfectly good LaTeX
> into RTF [...]
by hand, or automatically ?
I'm currently working at a bidirectional RTF <-> Latex converter
for the reverse reasons of you ...
> conference volume, and the editor (this is increasingly common,
> for our sins) will accept only Word-compatible stuff. I know
Unfortunately in MY field it looks like it's the opposite. The main
journals accept only Latex. (Fortunately conference proceedings instead
accept also Postscript and supply enough info to produce a valid Word
template).
> Should I say, if you can't accept LaTeX, forget publishing my
> paper? Perhaps.
Or should I say, if you can't accept Word, forget publishing MINE ?
> The other, even more depressing, experience: One doesn't expect
> _everyone_ to be able to deal with LaTeX source, but surely any
Yes indeed.
In the old times one sent typed manuscripts, and the publisher took care
of typesetting. Then I started using processors like VS Script, or
runoff (similar in spirit to TeX), but still sending in printed hardcopies.
Then I had a period in which I was writing much more project documents
then papers, and have been extremely happy with WYSIWYG processors like
Wordstar or MS-Word. I do NOT want now to go back learning Latex.
Conversely I appreciate that my colleagues Latexers won't like to learn
using Word.
Which to me indicates that, more than starting a flame war, the way to
go would be for a co-existence of the two worlds ...
... with PUBLISHERS taking care of conversion and final typesetting
from whatever electronic form you send them the manuscript, or at
least the most common ones
... with PUBLISHERS or some professional surely more skilled than me
providing a working set of bidirectional converters !
----------------------------------------------------------------------
nos...@ifctr.mi.cnr.it is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.
Louis Vosloo
Allin Cottrell wrote:
> The other, even more depressing, experience: One doesn't expect
> _everyone_ to be able to deal with LaTeX source, but surely any
> computer-literate colleague ought to be able to deal with a
> postscript file? Think again. I've recently been dealing with
> some colleagues in Computer Science (!) departments in the UK,
> who apparently can't make anything of postscript files I have
> sent them. They're using NT.
Ask them if they have heard of the COPY command :-)?
Or Acrobat Distiller, or GhostScript, or Transverter Pro.
Maybe they know what to do with PDF files?
Rebecca and Rowland
Bonvesin de la Riva [bonv...@humiliati.ripa] <nos...@ifctr.mi.cnr.it>
wrote:
> On Thu, 4 Jun 1998, Allin Cottrell wrote:
>
> > Based on some recent experience, I'm feeling bleak. Seems
> > like the "future of typesetting" is... MS Word!
>
> will it be that bad ?
Yes, because MS Word is a bad typesetter, bad at doing maths, and is a
proprietary program with a file format that changes very frequently.
But don't despair: the Institute of Physics prefers LaTeX submission for
just about everything.
[snip]
> ... with PUBLISHERS taking care of conversion and final typesetting
> from whatever electronic form you send them the manuscript, or at
> least the most common ones
>
> ... with PUBLISHERS or some professional surely more skilled than me
> providing a working set of bidirectional converters !
Bi-directional converters are unneccessary. If the publishers had the
wit God gave a lemon, they would tell you to submit in LaTeX/Word
(ick)/whatever *OR* PS and PDF. PS and PDF both have great advantages
over pretty much every other format.
Unfortunately, the people who specify the file format required are very
often not the publishers but the conference organisers who are one
evolutionary step above yeast, but with less brain. They often do not
realise that when they decide that the `universal' MS Word format will
be used for conference submissions (after asking the publishers if Word
is okay, rather than asking the publishers what format is preferred),
they are being very stupid. What would they do if *I* supplied a
document in Word format? It'd be useless: the only version of MS Word
that I have is MS Word for Macs version 1, which produces files that
can't be read by any current version of MS Word.
The biggest problem with Word is that it's not a stable file format.
Another big problem is that you can't be sure that formatting won't
change if (for example) the original document was formatted for US
letter paper but the computer at the other end is set up for A4 paper.
This kind of slip is trivial to make.
Rebecca and Rowland
Peter Wyzlic <p...@pwyz.rhein.de> wrote:
> On Thu, 4 Jun 1998 15:45:28 +0100, Rebecca and Rowland
> <reb...@astrid.u-net.com> wrote:
>
> >Peter Wyzlic <p...@pwyz.rhein.de> wrote:
> >
> >> No, Linux supports the Apple-Talk protocol, you need a cable, and
> >> a bit time and patience for the network configuration.
> >
> > Surely I also need a LocalTalk card for the Wintel box? After all,
> > LocalTalk runs at 230,400 bit/s over a differential pair. Most
> > Wintel boxes come with an RS232 port which can't do differential
> > signalling or run faster than 115,200 bit/s.
> >
> > It was the extra hardware that made me think it'd be expensive.
>
> I think you'll need an ethernet card on the other side.
Er, no.
> Because
> Apple's Localtalk technology is somewhat related to ethernet
Not that I've heard. The two are utterly different in every respect as
far as I know.
>it
> is possible to initiate a communication between a especially
> configured ethernet on the PC's side and Apple's Talk interface.
You can run AppleTalk over Ethernet if you want to: it's called
Ethertalk. As far as I know, LocalTalk cannot be wired into Ethernet
without using a bridge: LocalTalk is a two-wire RS422-based transmission
system which depends on the particular abilities of the particular RS422
controller IC used in all Macs. I can't see how a differential
transmission running at 230,400 bit/s normally and 920,000 bit/s maximum
can be wired into a single-ended transmission running at 10 MBit/s.
> Personally, I haven't done it by myself, but I heard from others
> who succeeded.
I suspect you've heard from people who have connected Ethernet equipped
Macs to Ethernet systems, perhaps using Ethertalk.
> But if want you want to know more you should ask
> in a Linux or networking newsgroup. It is really a bit off topic
> here ;)
True enough; I'm responding publically only to avoid mis-conceptions
about LocalTalk being spread further than necessary.
Rebecca and Rowland
Axel Kielhorn <A.Kie...@tu-bs.de> wrote:
> Robin Fairbairns <r...@cl.cam.ac.uk> wrote:
>
> > i only know one person (in this country) who persists in using a 286
> > (let alone an 8086) -- are such historical relics still a significant
> > part of tex equipment?
>
> You may be right about PCs. But you will still find a lot of Ataris (68k
> 8 Mhz) or Mac IIs (68020 / 030 16 ... 25 (32?) Mhz) that are used to run
> TeX.
I've got an 8MHz 68000 Mac that is occasionally used for TeXing. I
normally use my faster 25MHz 68040 Mac. Both are networked to the same
printer (all Macs have networking hardware and software so this is
trivial), and both produce identical output.
These older machines are *not* historical relics: they can use
up-to-date operating systems and run up-to-date software. This is where
they differ from PCs: you can't run Windows 95 on an 8086, but you can
run System 7.5.5 on a 68000. I've even used my Plus for TeXing booting
off a floppy disc and using my faster Mac as a fileserver: text editing,
spelling check, and TeXing all under System 6.0.8 (roughly equivalent to
Windows 3.1 in terms of level of development) and using up-to-date
application software. All in 4MB RAM with the entire OS fitting on an
800K floppy.
I've seen estimates that indicate that 40% of all Macs ever made are
still in use. I can believe it: I've got a Mac 512Ke (an upgraded
version of the second Mac ever) which was in regular use (it belonged to
one of the profs) at a large London teaching hospital until 1993. I
don't use that Mac very often now, but I do use my Mac Plus which is the
third Mac designed (1985 I think).
If you don't believe these old machines are still widely used, take a
look:
http://www.zws.com/classicmacs/
Petter Gustad
A.Kie...@tu-bs.de (Axel Kielhorn) writes:
> Robin Fairbairns <r...@cl.cam.ac.uk> wrote:
>
> > i only know one person (in this country) who persists in using a 286
> > (let alone an 8086) -- are such historical relics still a significant
> > part of tex equipment?
>
> You may be right about PCs. But you will still find a lot of Ataris (68k
> 8 Mhz) or Mac IIs (68020 / 030 16 ... 25 (32?) Mhz) that are used to run
> TeX.
Anybody ported TeX to the Palm Pilot yet? You could typeset your
document on the bus, the beach, ...
Petter
--
________________________________________________________________________
Petter Gustad 8'h2B | (~8'h2B) - Hamlet http://home.sol.no/~pegu
#include <stdio.h>/* compile/run this program to get my email address */
int main(void) {printf ("pegu\100computer\056org\nmy opinions only\n");}
Petter Gustad
"Steve Rindsberg" <Drop...@RatHole.nul> writes:
> Postscript can be device independent but isn't necessarily device
> independent.
>
> However, device independent PS of necessity can't access device-specific
> features.
Well said. However, you can access some device-specific features in a
portable way. E.g. to check if there is a manualfeed feature in the
statusdict which will when set to true cause the printer to use the
manual feed tray:
/manualfeed known {statusdict /manualfeed true put} if
I do like PostScript as a programming language (not as pure as Lisp
though). Ca. 10 years ago I wrote documentation directly in PostScript
(using the vi editor). It didn't look too different from LaTeX
actually. I used a PostScript dictionary to hold variables for current
font, margin settings etc. I had a routine to copy a dictionary and
overload some of the variables (almost as inheritance in an OO based
language). I can't find the source code, but it looked kind of like:
mark (This is text for paragraph one) (This is the text for paragraph
2) Body settext
Body was a dictionary which contained the definitions for that
particular style (which could have been inherited from a base
style/dictionary). settext was the routine which did set the text,
keeping track of end of line, end of page, calling hooks in the
dictionary, etc. I did not implement hyphenation, kerning tables, etc.
It was a quick and simple hack, but the result didn't look that bad,
at least to me, an ASIC designer and programmer. Some of the
typographer out there might have felt quite different...
Chris Maden
reb...@astrid.u-net.com (Rebecca and Rowland) writes:
> Bi-directional converters are unneccessary. If the publishers had
> the wit God gave a lemon, they would tell you to submit in
> LaTeX/Word (ick)/whatever *OR* PS and PDF. PS and PDF both have
> great advantages over pretty much every other format.
Augh! No publisher in his right mind would take PS or PDF from an
author. Authors should be writing, not typesetting; relying on
authors to correctly create exactly the house style, even when using a
template, is not going to be a lot of fun. It also means that the
publisher effectively can't correct typos, bad line breaks, etc.
(La)TeX, yes. Word, yes (though we rescue the text from Word as
quickly as possible). Frame, yes. SGML, yes. XML, yes. PS or PDF,
no. (For publication, yes, of course, but authors should be
submitting text, not pictures of text.)
-Chris
--
<!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN">
<!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN"
"<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487
<USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek>
Aleksandar Bakic
Rebecca and Rowland wrote:
>
> Axel Kielhorn <A.Kie...@tu-bs.de> wrote:
>
> > Robin Fairbairns <r...@cl.cam.ac.uk> wrote:
> >
> > > i only know one person (in this country) who persists in using a 286
> > > (let alone an 8086) -- are such historical relics still a significant
> > > part of tex equipment?
> >
Let me add that until two years ago, I used to TeX files on my
XT (8088 w/ 640KB). EmTeX still runs just fine (OK, not fast) on it.
Aleks
Ian
In article <slrn6nf7...@pwyz.rhein.de>,
p...@pwyz.rhein.de (Peter Wyzlic) writes:
> I think you'll need an ethernet card on the other side. Because
> Apple's Localtalk technology is somewhat related to ethernet it
> is possible to initiate a communication between a especially
> configured ethernet on the PC's side and Apple's Talk interface.
Or a compressing PPP connection over a null modem serial cable. Unless
you're transferring massive postscript files or have a really quick
printer, the PS file would probably make it across before the printer
had finished printing. You can get over 30Kbytes/second across serial
lines if the serial hardware's good and you keep the cogs greased.
Compression helps even more.
Ethernet cards are pretty cheap though, especially "defunct" ones,
i.e. ones that are older than two years but work perfectly! ;-)
Coax-only cards should be cheap.
Of course, if you don't know much about unix or PC hardware, you'd
probably be best off buying a postscript printer! All the guff I set
up took a little time and messing about --- and will again :-( Linux
distributions like RedHat are pretty quick to set up apparently,
they're designed for people in a hurry or beginners, I'm a nuts and
bolts man meself (it's my job).
--
Ian - Edit address before mailing. | Have you got a question you want to ask
Running Linux in the UK. | Usenet? Search www.dejanews.com first!
-- There are no facts, only opinions --
Rebecca and Rowland
Petter Gustad <dev....@dev.null.org> wrote:
> A.Kie...@tu-bs.de (Axel Kielhorn) writes:
>
> > Robin Fairbairns <r...@cl.cam.ac.uk> wrote:
> >
> > > i only know one person (in this country) who persists in using a 286
> > > (let alone an 8086) -- are such historical relics still a significant
> > > part of tex equipment?
> >
> > You may be right about PCs. But you will still find a lot of Ataris (68k
> > 8 Mhz) or Mac IIs (68020 / 030 16 ... 25 (32?) Mhz) that are used to run
> > TeX.
>
> Anybody ported TeX to the Palm Pilot yet? You could typeset your
> document on the bus, the beach, ...
I asked a similar question about Psion 3s a while back; I don't know
what processor the Palm Pilot uses, but apparently Psion 3s are a little
bit too slow for this sort of thing to be particularly sensible all
things considered.
Rebecca and Rowland
Franz Kaufmann <ws97...@wsrz1.wiso.uni-erlangen.de> wrote:
[snip]
> I wonder why anyone hasn´t proposed Perl as a language to use with tex.
> Perl is available on a lot of platforms (->Portability problem solved).
> Perl is more powerful with text than TCL and Lisps such as Scheme and
> guile.
>
> Perl can be extended via perl and C.
> Perl is linked to TK and other GUI´s and widget sets.
> Perl has links to all kinds of DBMSes.
> Perl is here and ready,guile is halfbreed.
> Perl can be used inside Emacs 20.2 via the Perlmacs patch.
>
> Can anything beat the team Emacs,Perl and TeX/LaTeX?
> I think not,so why not help these three to meet?
The problem is that Emacs on Macs is under-developed, and Perl programs
don't work as expected on Macs either.
Personally, I quite like the combination of TeX/LaTeX, Alpha (with TCL)
and AppleScript.
I think the big problem is that virtually *everything* except (La)TeX
has some degree of system dependency.
Robin Fairbairns
In article <1da69c2.1uo...@p34.nas1.is2.u-net.net>,
>> A.Kie...@tu-bs.de (Axel Kielhorn) writes:
>> Anybody ported TeX to the Palm Pilot yet? You could typeset your
>> document on the bus, the beach, ...
>
>I asked a similar question about Psion 3s a while back; I don't know
>what processor the Palm Pilot uses, but apparently Psion 3s are a little
>bit too slow for this sort of thing to be particularly sensible all
>things considered.
one probably could port to such silly machines. i have a friend who
was given an icl perq (this was a badged version of an american
competitor to the original apollo with 2x68000 in it -- both machines
had `unix-like' oses). my friend ported tex to it, and found it only
marginally slower than his toy 8086 running emtex. however, he *was*
able to claim to be the only person running tex on a perq.
personally, if i typeset something i want to be able to view the
result. for many purposes, the vdu of a workstation is adequate for
that: the screen of a psion or palm pilot doesn't really seem to me to
cut it.
so why would one port to such a machine? as a stunt.
would one use it in preference to one's own mac/pc/whatever?
hardly...
Rebecca and Rowland
Ian <ia...@pobox.DUMPTHISBIT.quza.com> wrote:
> In article <slrn6nf7...@pwyz.rhein.de>,
> p...@pwyz.rhein.de (Peter Wyzlic) writes:
>
> > I think you'll need an ethernet card on the other side. Because
> > Apple's Localtalk technology is somewhat related to ethernet it
> > is possible to initiate a communication between a especially
> > configured ethernet on the PC's side and Apple's Talk interface.
>
> Or a compressing PPP connection over a null modem serial cable. Unless
> you're transferring massive postscript files or have a really quick
> printer, the PS file would probably make it across before the printer
> had finished printing. You can get over 30Kbytes/second across serial
> lines if the serial hardware's good and you keep the cogs greased.
You can get gigabytes per second across serial lines if you chose the
right serial transmission standard. The average Wintel PC can manage
14400 bytes/s over short distances out of the RS232 serial ports they
usually have. Macs can manage double that under normal circumstances
over distances up to 1500m (IIRC; the maximum distance is about a mile,
but I've not got the data to hand) out of their RS422 ports, and 115000
bytes/s if externally clocked out of the same port.
If you're using USB at the higher speed, you can get 1,500,000 bytes/s
at distances up to 5m.
The serial transmission standards used for things like transatlantic
fibre optic links are something else entirely.
> Compression helps even more.
>
> Ethernet cards are pretty cheap though, especially "defunct" ones,
> i.e. ones that are older than two years but work perfectly! ;-)
> Coax-only cards should be cheap.
This might be the case for Wintel PCs, but it's not the case for Macs.
[snip]
Rebecca and Rowland
Robin Fairbairns <r...@cl.cam.ac.uk> wrote:
These palmtop computers do have the advantage of being able to fit in
your pocket, so I can see that it wouldn't be completely insane to
prepare a tex file and process it while the machine was just sat in your
pocket.
But... Given that you can't very well preview on one of these gadgets,
and given that you have to find yourself a printer (perhaps going via a
desktop computer) to print out, it does seem a bit daft: any tex file a
Psion 3 could process in less than a few hours would probably take less
than a minute on a typical desktop machine[1], so what's the point?
Especially since the storage needed for even a minimal TeX system is
rather big.
But... Wouldn't it be nice?
Rowland.
(who keeps meaning to unearth his ZX81 one of these days)
[1] A tex file that my 25MHz 68LC040 Mac (\sim 40MHz 80486SX) can
process in about 3.5 minutes takes my 8MHz 68000 Mac about 1.5 hours.
I'm told that Psion 3s have a variant on the 8086 theme inside them, and
are slower than my 8MHz 68000 Mac, while typical modern desktop
computers are *much* faster than my 25MHz 68LC040 Mac.
Kevin O. Lepard
> Another problem is that Ghostscript is *slow* on my old Mac; MacGS View
> crashes if I do unreasonable things like move the console window
For previewing PostScript, check out Tailor (http://www.enfocus.com). You
can download a free (non-time limited demo) that is an excellent
previewer. It can't print, but you can use Bare Bones Software's Drop*PS
for that. I don't have an especially speedy Mac (120 MHz 604), but Tailor
performs adequately (and did on my 75 MHz 601, too).
Of course, I don't know that Tailor would run on a 68000.... Still it
works as a good solution elsewhere.
Just thought you might be interested.
Kevin
--
Kevin O. Lepard Diplomacy is saying "nice doggy"
Internet: lepard...@usa.net until you can find a rock.
Timothy Murphy
Allin Cottrell <cott...@ricardo.ecn.wfu.edu> writes:
>I've just spent many hours trying to turn perfectly good LaTeX
>into RTF plus whatever-might-possibly-work for the graphics,
>because a paper of mine has been accepted for publication in a
>conference volume, and the editor (this is increasingly common,
>for our sins) will accept only Word-compatible stuff. I know
>full well the end result will look like sh*t. What can one do?
Perhaps the best thing to do,
if you know in advance that you want output in various formats,
is to write in SGML and use sgmldoc, linuxdoc, or similar,
to translate to LaTeX, HTML, etc ?
--
Timothy Murphy
e-mail: t...@maths.tcd.ie
tel: +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
Rolf Marvin B|e Lindgren
[Timothy Murphy]
| Perhaps the best thing to do, if you know in advance that you want
| output in various formats, is to write in SGML and use sgmldoc,
| linuxdoc, or similar, to translate to LaTeX, HTML, etc ?
if Microsoft Office 2000 will in fact be XML-based, then creating DTDs
which can be read by Word and converted to LaTeX should have the utmost
priority in the LaTeX community.
unless Microsoft introduces incompatible extensions to XML which current
SGML converters can't cope with, which is their wont.
Soren Dayton
t...@maths.tcd.ie (Timothy Murphy) writes:
> Perhaps the best thing to do,
> if you know in advance that you want output in various formats,
> is to write in SGML and use sgmldoc, linuxdoc, or similar,
> to translate to LaTeX, HTML, etc ?
This is, in fact, something that I'm thinking about. Do people have
horror stories or success stories or anything like that that they'd like
to share?
Thanks
Soren
Steve Rindsberg
> > Postscript can be device independent but isn't necessarily device
> > independent.
> >
> > However, device independent PS of necessity can't access
device-specific
> > features.
>
> Well said. However, you can access some device-specific features in a
> portable way. E.g. to check if there is a manualfeed feature in the
> statusdict which will when set to true cause the printer to use the
> manual feed tray:
Thanks ... and I *knew* somebody'd come back to point that out <g>.
>
> /manualfeed known {statusdict /manualfeed true put} if
>
Then the problem becomes one of "What do we do now?? No manual feed, the
user's coming over thinking that he can stick in his own paper and
meanwhile we're churning out hundreds of expensive transparencies because
some fool left them in the paper tray and boy is *everybody* gonna be mad
at one another now!"
Policies is one answer, albeit a partial one.
Ian
In article <1da7yxm.3l...@p5.nas1.is2.u-net.net>,
reb...@astrid.u-net.com (Rebecca and Rowland) writes:
> These palmtop computers do have the advantage of being able to fit
> in your pocket, so I can see that it wouldn't be completely insane
> to prepare a tex file and process it while the machine was just sat
> in your pocket.
Just get a text editor and prepare your file with that.
> But... Given that you can't very well preview on one of these
> gadgets,
I was quite surprised by the usefulness of the fax software on my
Psion 5, the fax display was pretty useable. It's not a 3 I'll grant
you, but don't discount the potential value for previewing on the
thing. Given the storage space required for any halfway worthwhile tex
system, I'd advise anyone interested to just stick to editing, not
previewing! One of the beauties of tex/latex is that you can typeset a
document with nothing more than a simple text editor.
> [1] A tex file that my 25MHz 68LC040 Mac (\sim 40MHz 80486SX) can
> process in about 3.5 minutes takes my 8MHz 68000 Mac about 1.5
> hours. I'm told that Psion 3s have a variant on the 8086 theme
> inside them, and are slower than my 8MHz 68000 Mac, while typical
> modern desktop computers are *much* faster than my 25MHz 68LC040
> Mac.
The Psion 5's got something about as quick as your mac in it but no
hardware floating point (if that's relevant), it's the screen that's
the main issue. Something like 640x200 in 16 greys.
Boris Veytsman
reb...@astrid.u-net.com (Rebecca and Rowland) writes:
> Ian <ia...@pobox.DUMPTHISBIT.quza.com> wrote:
>
> [snip]
> > If you've got some spare cash and time, you could buy a *really cheap*
> > PC and network it to your mac, a 486 with 8 megs and a 500Mbyte disc
> > would do.
> [snip]
>
> Now that's a thought. The only problem is that networking it to my Mac
> would probably cost more than the cheap Wintel box. But it's worth a
> think, isn't it?
>
Why? Modern Linux understands Appletalk. So the only thing you'll need
is Apple-to-serial cable. In Appletalk HOWTO on
sunsite.unc.edu/pub/Linux/doc... it is discussed in detail.
Of course if your Mac has Ethernet card, it might be simoler to
connect it through ethetr cabvle...
Good luck
-Boris
http://www.plmsc.psu.edu/~boris/
Rebecca and Rowland
Ian <ia...@pobox.DUMPTHISBIT.quza.com> wrote:
> In article <1da7yxm.3l...@p5.nas1.is2.u-net.net>,
> reb...@astrid.u-net.com (Rebecca and Rowland) writes:
>
> > These palmtop computers do have the advantage of being able to fit
> > in your pocket, so I can see that it wouldn't be completely insane
> > to prepare a tex file and process it while the machine was just sat
> > in your pocket.
>
> Just get a text editor and prepare your file with that.
Yes, but the point under discussion is running TeX, not using a text
editor.
[snip]
> > [1] A tex file that my 25MHz 68LC040 Mac (\sim 40MHz 80486SX) can
> > process in about 3.5 minutes takes my 8MHz 68000 Mac about 1.5
> > hours. I'm told that Psion 3s have a variant on the 8086 theme
> > inside them, and are slower than my 8MHz 68000 Mac, while typical
> > modern desktop computers are *much* faster than my 25MHz 68LC040
> > Mac.
>
> The Psion 5's got something about as quick as your mac
Which Mac? I mentioned two above. What processor does the Psion 5 use?
>in it but no
> hardware floating point (if that's relevant),
Not for TeX: it uses integer arithmetic exclusively.
> it's the screen that's
> the main issue. Something like 640x200 in 16 greys.
Hmm. Half the resolution and 1/16 the colour depth of what I'm used to.
It's probably good enough.
Rowland.
Rebecca and Rowland
Boris Veytsman <bo...@plmsc.psu.edu> wrote:
> reb...@astrid.u-net.com (Rebecca and Rowland) writes:
>
> > Ian <ia...@pobox.DUMPTHISBIT.quza.com> wrote:
> >
>
> > [snip]
> > > If you've got some spare cash and time, you could buy a *really cheap*
> > > PC and network it to your mac, a 486 with 8 megs and a 500Mbyte disc
> > > would do.
> > [snip]
> >
> > Now that's a thought. The only problem is that networking it to my Mac
> > would probably cost more than the cheap Wintel box. But it's worth a
> > think, isn't it?
> >
>
> Why? Modern Linux understands Appletalk. So the only thing you'll need
> is Apple-to-serial cable. In Appletalk HOWTO on
> sunsite.unc.edu/pub/Linux/doc... it is discussed in detail.
I've looked at that ftp server, and it appears to have nothing on
AppleTalk at all.
AppleTalk comes in many varieties. The version I use, and the one
that's supported by all Macs, is LocalTalk. The way it works is this:
the RS422 port on each networked device has its signal lines transformer
coupled to a pair of conductors: these two conductors carry the data
between network devices. RS422 uses differential transmission: the Rx+
and Tx+ RS422 lines are coupled to *that* network line; and the Rx- and
Tx- RS422 lines are coupled to the other one. The great advantage of
differential transmission is that you can transmit data at high speed
over long distances: I can't find the data sheets at the moment, but
memory tells me that LocalTalk works at 230,400 bit/s at distances up to
about 1 mile (1500m) assuming you've got twisted pair cable.
The data rate used on LocalTalk is 230,400 bit/s or faster (again,
supported by all Macs). The networking depends on the ability of the
RS422 controller IC to process packet address information.
I can't see any way in which a two-wire differential transmission
running at 230,400 bit/s can be connected to a normal RS232 port which
can't manage anything above 115200 bit/s, is stuck with single-ended
transmission, and doesn't have the ability to process packet address
information.
btw, there's no such thing as an `Apple-to-serial cable'. Some Apple
computers (Apple I and II if fitted with the appropriate board) have
old-fashioned RS232 serial ports as fitted to Wintel PCs. Macs use
RS422 with one of three different connection schemes (9 pin D-sub, 8 pin
mini-DIN, 9 pin mini-DIN). So all Apple computers can have serial
ports, but there's no one cable which will allow all Apple computers to
use that serial port. I think what you mean is an RS422-RS232 cable.
In any event, a straight conversion like that *might* allow you to
connect a single Mac to a single Intel-based Linux box using LocalTalk
(assuming Linux has software that takes over the job of processing the
packet address information that's done by Mac hardware - this is of
course entirely possible), but it would certainly not allow you to
connect a Linux box to a proper LocalTalk network. For that, you need
some means of coupling the RS232 port to the two network wires.
[snip]
Thanks for the thought
Rowland.
P.S. Posted to comp.text.tex to try and avoid the perpetuation of
mis-conceptions.
Petter Gustad
reb...@astrid.u-net.com (Rebecca and Rowland) writes:
> Petter Gustad <dev....@dev.null.org> wrote:
>
> > A.Kie...@tu-bs.de (Axel Kielhorn) writes:
> >
> > > Robin Fairbairns <r...@cl.cam.ac.uk> wrote:
> > >
> > > > i only know one person (in this country) who persists in using a 286
> > > > (let alone an 8086) -- are such historical relics still a significant
> > > > part of tex equipment?
> > >
> > > You may be right about PCs. But you will still find a lot of Ataris (68k
> > > 8 Mhz) or Mac IIs (68020 / 030 16 ... 25 (32?) Mhz) that are used to run
> > > TeX.
> >
> > Anybody ported TeX to the Palm Pilot yet? You could typeset your
> > document on the bus, the beach, ...
>
> I asked a similar question about Psion 3s a while back; I don't know
> what processor the Palm Pilot uses, but apparently Psion 3s are a little
> bit too slow for this sort of thing to be particularly sensible all
> things considered.
The Palm Pilot has a 16MHz Motorola MC68328 CPU. The Palm Pilot III
comes with 2MB RAM. Should easily outperform the 128KB Mac that I
bought in 1984...
Ian
In article <1da7ncw.4v...@p5.nas1.is2.u-net.net>,
>
>> You can get over 30Kbytes/second across serial lines if the serial
>> hardware's good and you keep the cogs greased.
>
> You can get gigabytes per second across serial lines if you chose the
> right serial transmission standard.
Okokokok.. I meant standard motherboard-fitted RS232 ports at commonly
found speeds...
Alan G. Isaac
I heard Lotus Millenium Suite (which has a TeX
based math editor) will also be doing this.
My question: how are they handling footnotes?
Does XML have footnotemark and footnotetext
tags? Without this, how is translation possible?
--Alan G. Isaac
Rolf Marvin B|e Lindgren wrote:
> [Timothy Murphy]
>
> | Perhaps the best thing to do, if you know in advance that you want
> | output in various formats, is to write in SGML and use sgmldoc,
> | linuxdoc, or similar, to translate to LaTeX, HTML, etc ?
>
David Kastrup
real-addr...@flur.bltigibbet (Rebecca and Rowland) writes:
>
> >in it but no
> > hardware floating point (if that's relevant),
>
> Not for TeX: it uses integer arithmetic exclusively.
Wrong. It uses real variables and arithmetic for glue_ratios. Which
makes up only a small fraction of TeX's total operation, but a
fraction which causes TeX output to be implementation dependent to
some degree (such as the number of repeated items in leaders).
As contrasted to METAFONT which only uses integer arithmetic and
produces results not depending on the implementation.
--
David Kastrup Phone: +49-234-700-5570
Email: d...@neuroinformatik.ruhr-uni-bochum.de Fax: +49-234-709-4209
Institut für Neuroinformatik, Universitätsstr. 150, 44780 Bochum, Germany
Timothy Murphy
Soren Dayton <csdayto...@cs.uchicago.edu> writes:
>> Perhaps the best thing to do,
>> if you know in advance that you want output in various formats,
>> is to write in SGML and use sgmldoc, linuxdoc, or similar,
>> to translate to LaTeX, HTML, etc ?
>This is, in fact, something that I'm thinking about. Do people have
>horror stories or success stories or anything like that that they'd like
>to share?
The Linux "HOWTO"s (a couple of hundred of them)
are written in this way,
and generally print out quite well in LaTeX.
(I'd give them 8 out of 10.)
Peter Kerr
Allin Cottrell <cott...@ricardo.ecn.wfu.edu> wrote:
>
> The other, even more depressing, experience: One doesn't expect
> _everyone_ to be able to deal with LaTeX source, but surely any
> computer-literate colleague ought to be able to deal with a
> postscript file? Think again. I've recently been dealing with
> some colleagues in Computer Science (!) departments in the UK,
> who apparently can't make anything of postscript files I have
> sent them. They're using NT.
>
> Still hoping this is all a bad dream...
>
Unfortunately it's not just a bad dream...
We are not Latex literate (nor thoroughly ashamed of that)
and in preparing conference papers for publication last year
we asked for contributions, if possible, in RTF or .ps format
so as to keep formatting to the author's preferences, not ours.
We were suitably chastened at the failure rate of contributors
unable or unwilling to comply...
--
Peter Kerr bodger
School of Music chandler
University of Auckland NZ neo-Luddite
Rebecca and Rowland
David Kastrup <d...@mailhost.neuroinformatik.ruhr-uni-bochum.de> wrote:
> real-addr...@flur.bltigibbet (Rebecca and Rowland) writes:
>
> >
> > >in it but no
> > > hardware floating point (if that's relevant),
> >
> > Not for TeX: it uses integer arithmetic exclusively.
>
> Wrong. It uses real variables and arithmetic for glue_ratios. Which
> makes up only a small fraction of TeX's total operation, but a
> fraction which causes TeX output to be implementation dependent to
> some degree (such as the number of repeated items in leaders).
Well I never - I didn't know that. Thanks. I wonder where I got this
wrong idea from?
> As contrasted to METAFONT which only uses integer arithmetic and
> produces results not depending on the implementation.
Righto.
Rowland.
Rebecca and Rowland
Ian <ia...@pobox.DUMPTHISBIT.quza.com> wrote:
> In article <1da7ncw.4v...@p5.nas1.is2.u-net.net>,
> reb...@astrid.u-net.com (Rebecca and Rowland) writes:
> > Ian <ia...@pobox.DUMPTHISBIT.quza.com> wrote:
> >
> >> You can get over 30Kbytes/second across serial lines if the serial
> >> hardware's good and you keep the cogs greased.
> >
> > You can get gigabytes per second across serial lines if you chose the
> > right serial transmission standard.
>
> Okokokok.. I meant standard motherboard-fitted RS232 ports at commonly
> found speeds...
Just for the record: commonly-found serial port speeds in *this* house
are 230400 bit/s, twice what the industrial archeology fitted to the
average Wintel PC can manage.
And this is a serious point: does anyone have any idea *why* Wintel PCs
have RS232 ports? After all, there were *much* better serial
transmission standards available at the time, many of them able to talk
to RS232 with no bother at all (for example, RS422 as fitted to Macs or
RS423 as fitted to BBC Micros)
Ian
In article <1dacm8e.1dv...@p12.nas1.is2.u-net.net>,
real-addr...@flur.bltigibbet (Rebecca and Rowland) writes:
> And this is a serious point: does anyone have any idea *why* Wintel PCs
> have RS232 ports? After all, there were *much* better serial
> transmission standards available at the time, many of them able to talk
> to RS232 with no bother at all (for example, RS422 as fitted to Macs or
> RS423 as fitted to BBC Micros)
I would imagine that it's similar to the situation we have where
Wintel machines are the top of the stack. Throughout computing history
there's been much better solutions from the technical standpoint, but
this isn't relevant, it's who buys them and who makes things that work
for them that counts. This can be influenced by simplicity, provided
tools, similarity to what went before etc..
Chris Maden
"Alan G. Isaac" <ais...@american.edu> writes:
> My question: how are they handling footnotes? Does XML have
> footnotemark and footnotetext tags?
If you want them. This is XML:
<foo>blah blah <bar><baz>poodlefoo</baz></bar> blort farble</foo>
but so is this:
<para>Then Alan <footnote><para>Isaac.</para></footnote> spoke.</para>
Note redirected followups.
-Chris
--
<!NOTATION SGML.Geek PUBLIC "-//Anonymous//NOTATION SGML Geek//EN">
<!ENTITY crism PUBLIC "-//O'Reilly//NONSGML Christopher R. Maden//EN"
"<URL>http://www.oreilly.com/people/staff/crism/ <TEL>+1.617.499.7487
<USMAIL>90 Sherman Street, Cambridge, MA 02140 USA" NDATA SGML.Geek>
Donald Arseneau
In article <m2wwar4...@mailhost.neuroinformatik.ruhr-uni-bochum.de>, David Kastrup <d...@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes...
>real-addr...@flur.bltigibbet (Rebecca and Rowland) writes:
>
>Wrong. It uses real variables and arithmetic for glue_ratios.
True.
>fraction which causes TeX output to be implementation dependent to
>some degree (such as the number of repeated items in leaders).
Are you really sure? As I recall, both badness and leaders count
are implementation-independent.
Donald Arseneau as...@triumf.ca
Rebecca and Rowland
Ian <ia...@pobox.DUMPTHISBIT.quza.com> wrote:
> In article <1dacm8e.1dv...@p12.nas1.is2.u-net.net>,
> real-addr...@flur.bltigibbet (Rebecca and Rowland) writes:
>
> > And this is a serious point: does anyone have any idea *why* Wintel PCs
> > have RS232 ports? After all, there were *much* better serial
> > transmission standards available at the time, many of them able to talk
> > to RS232 with no bother at all (for example, RS422 as fitted to Macs or
> > RS423 as fitted to BBC Micros)
>
> I would imagine that it's similar to the situation we have where
> Wintel machines are the top of the stack. Throughout computing history
> there's been much better solutions from the technical standpoint, but
> this isn't relevant, it's who buys them and who makes things that work
> for them that counts. This can be influenced by simplicity, provided
> tools, similarity to what went before etc..
That's *precisely* the point: fitting an RS422 or RS423 port is no
harder than fitting an RS232 port, lets you talk to existing RS232
devices, and also lets you transmit at higher speeds with greater
reliability over longer distances if you happen to have an RS422/423
device on the other end.
The point being this: any sane design decision would have abandoned
RS232 as soon as the better replaceements were available, because the
replacements have no downside. I *suspect* RS232 ports were used
unthinkingly: that is, the designers used RS232 just because that's what
you use, without bothering to engage brain.
Rolf Marvin B|e Lindgren
[Donald Arseneau]
| Are you really sure? As I recall, both badness and leaders count are
| implementation-independent.
as far as I can recall, TeX the progam has its own definitions of the
needed math functions (trig, log, exp, etc.) for exactly this reason,
rather than relying on using library functions.
David Kastrup
as...@erich.triumf.ca (Donald Arseneau) writes:
> In article <m2wwar4...@mailhost.neuroinformatik.ruhr-uni-bochum.de>, David Kastrup <d...@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes...
> >real-addr...@flur.bltigibbet (Rebecca and Rowland) writes:
> >> Not for TeX: it uses integer arithmetic exclusively.
> >
> >Wrong. It uses real variables and arithmetic for glue_ratios.
>
> True.
>
> >fraction which causes TeX output to be implementation dependent to
> >some degree (such as the number of repeated items in leaders).
>
> Are you really sure? As I recall, both badness and leaders count
> are implementation-independent.
Nope. That the repetition of items is implementation dependent has
caused Knuth to prohibit \write in leaders. Nobody is supposed to
find out about those dependencies except by looking in the dvi file.
Petr Prikryl
Bonvesin de la Riva [bonv...@humiliati.ripa] (nos...@ifctr.mi.cnr.it) wrote:
>On Thu, 4 Jun 1998, Allin Cottrell wrote:
>> Based on some recent experience, I'm feeling bleak. Seems
>> like the "future of typesetting" is... MS Word!
>
> will it be that bad ?
Yes, it would be very bad. Using the Word you can produce the identical
output only when you run the identical version of Word with identical
printer driver, on almost identical OS, and on a computer from very
restricted set of computers. You can be never sure to obtain the result
which was observed by the author.
[...]
>> Should I say, if you can't accept LaTeX, forget publishing my
>> paper? Perhaps.
>
> Or should I say, if you can't accept Word, forget publishing MINE ?
If you want to print something from LaTeX source, then you can
obtain all the software for free (talking about money). If you
decide to use Word, you may be forced to start with purchase of
a different computer. And you will be forced to BUY new versions of
MS Windows, of MS Word, and possibly also a new computer in
future. Why? Because the old one would not be powerful enough
to run the new OS and/or new applications fast enough.
[...]
> Then I had a period in which I was writing much more project documents
> then papers, and have been extremely happy with WYSIWYG processors like
> Wordstar or MS-Word. I do NOT want now to go back learning Latex.
It may work if you want to produce paper, not the electronic form of
documents. The problem is that using Word the WYSIWYG does not mean
that everyone see the same result.
> Conversely I appreciate that my colleagues Latexers won't like to learn
> using Word.
I have used Word only when I was forced to. But I know at least
two colleagues who defended Word very hard... until they had to reuse
some older documents written in older Word. Even to print them is
very difficult after some years.
> Which to me indicates that, more than starting a flame war, the way to
> go would be for a co-existence of the two worlds ...
The worlds are called "the world of money" and "the world of typesetting".
P.
--
Petr Prikryl (pri...@dcse.fee.vutbr.cz) http://www.fee.vutbr.cz/~prikryl/
TU of Brno, Dept. of Computer Sci. & Engineering; tel. +420-(0)5-7275 218
Andreas Schwab
David Kastrup <d...@mailhost.neuroinformatik.ruhr-uni-bochum.de> writes:
|> real-addr...@flur.bltigibbet (Rebecca and Rowland) writes:
|>
|> >
|> > >in it but no
|> > > hardware floating point (if that's relevant),
|> >
|> > Not for TeX: it uses integer arithmetic exclusively.
|>
|> Wrong. It uses real variables and arithmetic for glue_ratios.
But that can easily be changed to use fixed point arithmetics, see
<CTAN:systems/knuth/tex/glue.web>.
--
Andreas Schwab "And now for something
sch...@issan.informatik.uni-dortmund.de completely different"
sch...@gnu.org
Eric Lindsay
In <s6790nb...@dev.null.org> Petter Gustad <dev....@dev.null.org> writes:
>I do like PostScript as a programming language (not as pure as Lisp
>though). Ca. 10 years ago I wrote documentation directly in PostScript
>(using the vi editor). It didn't look too different from LaTeX
I use a neat little (free) package called QuikScript, which comes
from www.adfa.edu.au (Australian Defence Forces Academy). It is just
a 35k header to your text files, all done in Postscript so you can
change it. Your text files just have markers like %P% for paragraph,
%NC, 2% for two column output, etc. I find it very easy to use, and
much more powerful for its size than any other system I've tried.
Device independent, of course, and really slow or old machines can
use it, provided they have an ascii editor, can handle a 35k + file
(or can prepend a 35k file to another text file), and can get it
to a Postscript printer or to a copy of Ghostview/Ghostscript.
Limitations include only using the printer resident fonts (or a set
you download), not being able to handle complex equations (subscript,
superscript and symbols are fine, albeit tedious to do). It does do
headers, footers, centering, justifying right or left, multiple
columns, any font size, embedded Postscript, vertical tabbing,
hanging indents, lists, etc.
--
er...@maths.uts.edu.au Eric Lindsay, School of Mathematical Sciences
http://www.maths.uts.edu.au Room 1618, Tower Building, 1-73 Broadway
Don't take life too seriously. University of Technology, Sydney, Australia.
It is only temporary. +61 2 9514 2254 office +61 2 9514 2248 fax