-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Captain's log. We received a signal from you on StarDate 23/10/05 00:53.
Translated to English it stated:
> Hello,
>
> I lost your reply. I found something more explicit than my
> vague recollection of accumulating files in one directory.
I have just re-sent the reply (forwarded it) in case it helps.
> "One has to keep in mind that, as opposed to TEX with its dvi output,
> the pdfTEX program does not require a separate postprocessing stage
> to transform the TEX input into a pdf file. As a consequence, all
> data needed for building a ready pdf page must be available during
> the pdfTEX run, in particular information on media dimensions and
> offsets, graphics files for embedding, and font information
> (font files, encodings)."
>
> http://www.cs.ubc.ca/~van/GI2005/giformat.htm
> pdfLaTeX
> "The last way to generate a PDF file from LaTeX sources is to use the
> free tool pdflatex, which we highly recommend. This system is built
> upon pdftex, an enhancement of TeX which can generate resolution-
> independent, searchable PDF directly. If you also include the standard
> hyperref LaTeX package when compiling your document, the resulting PDF
> will automatically have a hierarchical table of contents and citations,
> footnotes and cross-references will be hyperlinked. You can also reference
> Web URLs and have a web browser automatically come up when a hyperlink
> is clicked in the Acrobat reader. This is all demonstrated in the source
> for the example file available in the GI author's kit. See the TeX
> User's Group's web site for documentation on hyperref and pdflatex."
Interesting. Very interesting as I was never able to get hyperlinks to
work, let alone tables of contents. I spent quite a bit of time on that
too and assumed that something in my build was just incomplete or
out-of-date. I'll try again and soon as I dispatch this message.
> SH: Did you know that if one uses two formal languages such as
> C++ and Lisp which are not identical, that there is always some
> program p, which cannot have its logical function implemented
> identically in the other language? I am not sure that the next idea
> is a consequence of that theorem, but I would suspect that a
> program like xpdf would not identically produce pdf output compared
> to Adobe Writer Pro. You had mentioned about pdf printed output
> appearing differently on printers, but I don't think you specified they
> were all connected to the same OS and pdf generation program.
Well, I recently indeed found out (and can confirm) that different
routes to generating the PDF's led to different outcomes. This was quite
worrying, to me at least. Now I have to fiddle and experiments with
outputs, just to ensure all is fine.
> Perhaps I am mistaken, but I have the impression that you didn't
> take into account that in principle, there is no software program
> which is going to convert dvi (TeX) to doc (Word) or doc to dvi
> in a complex document with equations involved, perfectly, although
> the translation will be very much improved if the same underlying engine
> has generated two documents such as with postscript/ghostscript.
I have never explored that area really. I consider any conversion
between TeX and Word to be poor. Word is about splicing bits onto A4
paper whereas TeX is more restrictive and contains document structure.
> Some contexts can be approximated so closely as to appear
> indistinguishable, but usually a conversion needs to be proofread.
> My intention is not to defend Word but to mention mechanical or
> algorithmic program limitations and I much admire Donald Knuth.
Same here. Donald inspired me at times and I seemed to have taken some
of his oddities too.
Word is excellent for people to whom documents need to be build with
merely 0 experience. Even my 9 year-old sister can use it as it is
intuitive and requires few skills. Having said that, if you want to race
in Formula 1, you would better master the stick shift!
Roy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
iD8DBQFDWwN1U4xAY3RXLo4RAvR5AJ9APdoMbvzm8Ed9Z9m1XaEa26ADYQCgjf9D
9XdV9EGOmQbK/ds9QrAgMgA=
=pdFu
-----END PGP SIGNATURE-----
|
|
