The future of typesetting --- LaTeX3, or what?

19 views
Skip to first unread message

Harald Kirsch

unread,
May 31, 1998, 3:00:00 AM5/31/98
to

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

unread,
May 31, 1998, 3:00:00 AM5/31/98
to

[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

unread,
May 31, 1998, 3:00:00 AM5/31/98
to

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

unread,
May 31, 1998, 3:00:00 AM5/31/98
to

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

unread,
May 31, 1998, 3:00:00 AM5/31/98
to

Michael C. Grant wrote:
>
> 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.

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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

"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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

[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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

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.

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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

[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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

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

PostScript might have been PLANNED as device independant, but, as a
matter of fact, is not.

cheers
juergen

Juergen v. Hagen

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

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.
not really.

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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

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.

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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

[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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

[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

unread,
Jun 1, 1998, 3:00:00 AM6/1/98
to

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

unread,
Jun 2, 1998, 3:00:00 AM6/2/98
to

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

unread,
Jun 2, 1998, 3:00:00 AM6/2/98
to

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

unread,
Jun 2, 1998, 3:00:00 AM6/2/98
to

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

unread,
Jun 2, 1998, 3:00:00 AM6/2/98
to

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

unread,
Jun 2, 1998, 3:00:00 AM6/2/98
to

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?
I don't know enough about gs, nor Windowze, nor the network HP printer
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}

unread,
Jun 2, 1998, 3:00:00 AM6/2/98
to

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

unread,
Jun 2, 1998, 3:00:00 AM6/2/98
to

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

unread,
Jun 2, 1998, 3:00:00 AM6/2/98
to

[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

unread,
Jun 2, 1998, 3:00:00 AM6/2/98
to

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

unread,
Jun 2, 1998, 3:00:00 AM6/2/98
to

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

unread,
Jun 2, 1998, 3:00:00 AM6/2/98
to

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

unread,
Jun 3, 1998, 3:00:00 AM6/3/98
to

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

unread,
Jun 3, 1998, 3:00:00 AM6/3/98
to

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

unread,
Jun 3, 1998, 3:00:00 AM6/3/98
to

In article <KIR.98Ju...@Gauss.iitb.fhg.de>,

Harald Kirsch <k...@iitb.fhg.de> wrote:
>and, afaik, PDF is PostScript+DSC+something.

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

unread,
Jun 3, 1998, 3:00:00 AM6/3/98
to

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:
>
>[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

unread,
Jun 3, 1998, 3:00:00 AM6/3/98
to

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

unread,
Jun 3, 1998, 3:00:00 AM6/3/98
to

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

unread,
Jun 3, 1998, 3:00:00 AM6/3/98
to

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

unread,
Jun 3, 1998, 3:00:00 AM6/3/98
to

> 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

unread,
Jun 3, 1998, 3:00:00 AM6/3/98
to

In article <1da0n79.jmp...@p52.nas1.is2.u-net.net>,

Rebecca and Rowland <reb...@astrid.u-net.com> wrote:
>I think the great advantage of PS over dvi is that (assuming the PS
>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

unread,
Jun 3, 1998, 3:00:00 AM6/3/98
to

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

unread,
Jun 3, 1998, 3:00:00 AM6/3/98
to

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

unread,
Jun 4, 1998, 3:00:00 AM6/4/98
to

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

unread,
Jun 4, 1998, 3:00:00 AM6/4/98
to

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

unread,
Jun 4, 1998, 3:00:00 AM6/4/98
to

[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

unread,
Jun 4, 1998, 3:00:00 AM6/4/98
to

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

unread,
Jun 4, 1998, 3:00:00 AM6/4/98
to

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

unread,
Jun 4, 1998, 3:00:00 AM6/4/98
to

[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

unread,
Jun 4, 1998, 3:00:00 AM6/4/98
to

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

unread,
Jun 4, 1998, 3:00:00 AM6/4/98
to

>>>>> "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

unread,
Jun 4, 1998, 3:00:00 AM6/4/98
to

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

unread,
Jun 4, 1998, 3:00:00 AM6/4/98
to

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

unread,
Jun 5, 1998, 3:00:00 AM6/5/98
to

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

unread,
Jun 5, 1998, 3:00:00 AM6/5/98
to

Robin Fairbairns <