[lug] looking for TeX viewer/print

[J. Wayde Allen]

On Fri, 24 Aug 2001, D. Stimits wrote:

> One thing I am frustrated with by plain ascii is lack of color (this
> isn't just for resume's, but includes other printing, e.g., syntax
> highlighted source code).  RTF may have some ability to work with color,
> but I suspect you are right about it just leading to frustration.

Yes, I think that RTF does allow for color specification.  I'm not too
sure, but I think the new ISO 8859-1 may also allow for color?

> I was under the impression that LaTeX macros were there to do something
> similar to this: Take content described logically, such as a heading,
> title, or paragraph, and format it to conform to a style specification.
> Thus, a need for a detailed style specification.

Yes kind of, but you don't have to use all of the macros, and most of them
can be overridden, or modified.  It also is a kind of programming language
that allows you to do conditional branching in the document, and to define
new features in the document source itself.  Also since it is built on top
of TeX you can drop down to the lower level TeX programming if you feel
you need that degree of control.  Few people ever need to do that.

Most people take an existing document class and then tweak that to their
needs by overriding certain built-ins and redefining a few things.  That
usually isn't hard, and once you've done it for a particular type of
document you don't need to reinvent the wheel for he next document.

> It sounds like LaTeX also has an ability to work more in a free-form
> way, is this correct? Can I work without a style specification?

You can work in a fairly free-form way, and I was thinking you could get
away without a document type declaration.  However, the proof is in the
pudding, so I tried it.  There were a number of errors generated when I
left out the document type.  The most critical being that the default font
was not defined.  That resulted in an empty document.

So, I did my usual and used the article document type to create the
following "minimal" LaTeX document:

   \documentclass{article}
   \usepackage{color}
   \definecolor{red}{rgb}{1,0,0}
   \begin{document}

   This is a test to see how little one can get away with when it comes to
   working with \LaTeX.  OK, this seems to be working.  How about some
   \textcolor{red}{red text}?

   Maybe we should create a second paragraph just for grins.  That way you
   can see how that is done.  Mostly you just type what you want to say,
   and put in commands, as needed.  Much like you would do in html.  You
   can for example give your text \emph{emphasis}, or you can make it 
   \large{big} or \bfseries{\large{big and bold}}.

   \end{document}

> I would like to do things like highlight text, then set it to bold or a
> color or a specific font size.

OK, I've demo'd that in the mini-document above.  Save it to a file and
run the following commands:

   latex whateveryoucalledthefile
   dvips -o junk.ps whateveryoucalledthefile.dvi

you can then look at the postscript results using ghostview.

> There is a certain difficulty in viewing
> on one window and then searching for the right spot in another window
> for editing.

Fair enough, that is true.  I've just gotten use to it so it really
doesn't bother me.  Mostly I just read the LaTeX file, I really only use
xdvi if I'm tweaking a document override and want to see the effect.  In
practice you really don't need to "see" what things look like here since
you are working based more on content than layout.  

> LyX is the closest I know of at the moment, and I'm not very good with
> it.

That is my take on it as well.

> Btw, I've never seen color in xdvi, does xdvi support color? Probably
> I simply haven't run into a color case.

Well, it indicates that it does, but it didn't display the red text in my
example.  I got a message saying something about checking color
maps.  That is why I converted to postscript and viewed it in ghostview.

> As far as this sort of scheme goes though, I like the way ghostview can
> monitor a file and auto-update each time the file is edited. Ghostview
> is very nice, it even allows color, and is a nice printing aid.

Yes, works basically the same as xdvi in that regard.  The advantage of
xdvi is that you don't have to convert to postscript between edits.

> If ghostview could allow interactive editing, rather than just
> display, I'd be incredibly thrilled (cheap thrills?).

I think that there are some subtleties here that we are probably
missing.  The only postscript editing program I know of is Xcircuit.  It
seems to read and write postscript directly.  My guess as to why editors
don't read and write postscript directly has to do with at least one of
two possibilities.  One is that the postscript file format may not exactly
be in the public domain, and there may be some licensing issues.  Another
issue has to do with postscript being primarily a printer control
language.  Using higher level representations such as dvi probably makes
for a more efficient symbolic representation of the document that can be
more easily converted to various formats.

> > > Better yet, a WYSIWYG dvi editor (this of course would require some
> > > sort of related setting to display on given hardware...assuming it
> > > really is device independent, WYSIWYG is something of an oxymoron).

OK

> As someone mentioned, there is a need to recompile from TeX to produce
> the dvi format; the dvi is the binary form, not useful for human eyes,
> but it could be used directly by an editor. Or an interpreter would be
> nice, to allow updates to occur simultaneously with edits (this is why
> ghostview works so nicely...it has an interpreter and the postscript
> itself is not compiled to an intermediate form that would possibly take
> multiple passes).

That an editor "could" work directly on dvi files is certainly true.  
What isn't so clear to me is what this gains you?  In a sense, what you
are asking for is nothing more than a word processor that works on dvi
files.  If that is all you need then by all means use a word processor.  
I'm not a big LyX fan, but at least what they are doing seems to make some
sense.

Also, right now LaTeX is a multi-path compiler.  If you have a bibliography
for instance, you have to run bibtex, latex, latex in order for the system
to locate all the citations, build the bibliography from the citation
database (another very cool feature), and then go back number the
citations and references accordingly.  Making a real-time interpreted
version of this would probably mean a code re-write.  There are some newer
document processing systems that may be working in this direction, but I
don't know anything about them.

> Monitoring through xdvi, and editing elsewhere, is a lot of work when
> just maintaining and altering a document (one that might have minor
> changes on a daily basis).

This is where you are thinking like a word processor user though.  There
really isn't much of a reason to monitor the document through xdvi.  I
only do this as a sanity check if I'm tweaking the formating commands and
want to see how it would print.  If you are talking about working on the
document and making minor changes this is really no different than typing
e-mail.

> It seems I'm going to have to learn to do this though.

It really isn't as hard as it seems.  Actually, my experience is that the
guys hung up on the word processor have many more problems.

> I already have some TeX references, but they are primarily mathematics
> references, and don't cover topics like color.

That is because LaTeX/TeX is the tried and true way to get good
equations.  This is the Achilles heel of the standard word
processor.  Creating equations in a word processor is a pain, and there is
essentially no compatibility between any of them on this front.  You can
always share StarOffice, WordPerfect, ApplixWord, and MSword files if they
are basic plain text, but if you have equations you just found yourself in
document conversion hell.

Color is part of the LaTeX graphics package.

> Yes, I'm hoping to do some basic editing, and have high quality output
> for printing. The document typesetting abilities go beyond what I need,
> but the solutions that don't use TeX or PostScript on Linux seem to fall
> short in a lot of ways, most often when printing.

Doesn't matter what platform.

> So the next step up, to get good printing, is a major leap beyond what
> I need, and nothing in between exists.

It may not be as big of a jump as you think.  It does mean you have to get
away from the simulated typewriter paradigm though.  You've already kind
of done that with html.

> In a way similar to how XML was designed as a simpler substitute to
> SGML, while still being convenient in ways of HTML, I wish there was
> an intermediate TeX and intermediate PostScript...designed to actually
> provide good printing control, but not designed to be a publishing
> tool with control to a ten-thousandth of an inch.

That middle ground tool is called - LaTeX.

> This is actually not too bad for many of the things I want to do (not
> all). I currently need a free form editing device that allows color and
> polished look, and then actually prints the same as it looks on the
> monitor (to some degree I consider that a "quality" issue). The second
> thing I need is a format that I can send electronically, and expect the
> other end to also be able to print a reasonable facsimile.

Yes, and it is partly why the computerized typewriter model is still so
well entrenched.  But contrary to the typewriterized philosophy it isn't
the only way ...

> HTML fails because the viewers being used (probably IE or Netscape)
> are inconsistent at printing, even when they display the same. It can
> come close though in terms of being able to send things to other
> people and at least have the display on the monitor look nice, over a
> variety of o/s (there are some things that one has to be careful with,
> but display gotchas are far fewer than print gotchas). If html tools
> that are in general use would actually print the same as they display,
> I'd be satisfied with that for now.

That is a different topic in and of itself.  HTML originally started with
many of the same concepts as the document processing systems.  However the
typewriter/word processor folks didn't like that they didn't really need
to worry about style so much.  After all, who needs content if it looks
pretty <sorry my cynical side>.  Mix into that the battle between Netscape
and Microsoft, and well ... you know the story.

> This is good when writing a book or thesis or other paper that will be
> processed by someone who is knowledgeable in the area.

In almost all cases this is a good thing.  Especially these days, when so
few people have ever studied typography. 

> It doesn't work very well for general information interchange to the
> average user.

I don't see why this is a problem?

> On the other hand, the means on Linux which work for general
> interchange with other o/s's and non-technical users don't print
> right.

This doesn't work right on any platform, it isn't limited to Linux.

> My main interaction attempts with LaTeX have so far been through LyX,
> which probably places more constraints that pure TeX or LaTeX.

I don't have enough experience with LyX to help there.

> I probably need to give up on LyX and look into actually learning TeX
> (I wonder if windows understands any of the TeX output formats without
> installing special software?).

The crux of your troubles has to do with standards.  HTML is fairly
standard as long as you stick to strict HTML.  Postscript is pretty
standard, but you can get font substitution that can cause troubles, and
you have to convince what you've called "non-technical people" to print
this without using a word processor.  The format that seems to work about
the best is the pdf file.  It does mean you need to have the reader
software installed, but it is pretty ubiquitous these days.

Finally, when push comes to shove, the good old paper copy is always
pretty darn acceptable, and you don't even need a computer to read it!

> What format would you suggest which: (a) is readable by non-technical
> windows users (e.g., IE or Word can import it and the imported version
> looks like what I see from Linux...PostScript fails here), (b) prints
> correctly from default viewing tools of windows (html fails here), and
> (c) has at least some application available on Linux which will allow me
> to print it correctly (PostScript works if the PostScript output
> actually looks like the screen view) without rebooting to windows? It is
> a tall order, and I don't think there is a solution that is completely
> satisfactory.

The "best" solution I can think of is pdf.

> Applix and StarOffice can't be exchanged with windows users; even when
> they claim to export or import word, they don't do it correctly, and
> every export needs a reboot to win to see if it exported properly.

I've not had such extreme problems.  It is an issue though.  This is why I
always prefer working with plain ASCII text.  Never had a compatibility
issue there.

> Any "polished" business paper (versus technical documents) requires
> attention to appearance. I need a polished look in both printed form and
> electronic form, with the expectation that if I send an electronic
> format, it might be printed. There are many people that make a decision
> to drop further consideration of a document the moment it looks sloppy,
> has spelling errors, so on...they don't have time to deal with
> frustrations of fixing someone else's carelessness, and I have no
> influence whatsoever on changing their way of thinking (nor do I have
> the power to ignore these people).

This is true, and is where most people would be better off leaving the
typography to the typographers.  This is where LaTeX shines since you get
a professional typographer doing the layout for you.  One thing that you
can see in a lot of so-called polished business documents these days is
poor if not wrong typography, and LOTS of inconsistencies.

By the way, technical papers also have to be specially formated with
careful attention to look.  I've got the ITS publications manual right
here on the desk next to my computer.

> If windows and standard applications of all the platforms and users that
> I must communicate with all understood TeX, and had the ability to both
> view and print it, I'd snap it up in an instant and become a guru in the
> field. The strengths that are mentioned above about the ability to
> create a consistent format and enforce a style are good for professional
> documentation and academic publishing...but within the area of casual
> exchange among unskilled computer users it breaks down, and becomes a
> road block. I suspect that if someone at MS suggested creating TeX
> import and export abilities in Word, they'd be fired.

I think you are looking at this from a slightly skewed point of
view.  I believe you can create documents that can be viewed on any
platform using the tool of your choice.  If that be with a word processor,
then by all means do so.  

> I'm overly pessimistic in this area because it has been a major
> frustration that I can't do anything about. I'm tied by what is
> available to the common windows user, and by what I can print from
> linux. Even if I can ignore windows users, I can't seem to get easier
> word processing documents to print right, so I'm forced to learn TeX or
> PostScript and write code to print a nice document...

Yes, well I'm pretty frustrated here too.  That is why I've taken the time
to type this long message.  I'm not so frustrated with the tools.  There
are some really useful and powerful tools.  What frustrates me is the
narrow mindedness and blatant disregard for what a little bit of
standardization in the Windows world could do for computing in
general.  That you are having problems getting your word processor to
print correctly sounds a bit fishy.  I've never seen that problem.

The only consolation I can think of is that you are not alone.  This is a
major problem in every organization I know of, and it doesn't go away even
if everyone runs Windows and MSWord.

- Wayde
  (wallen at lug.boulder.co.us)