Re: HP 4MP printer driver current?

In article <1iwtj5h.13ku47z13sskufN%dempson@xxxxxxxxxxxxx>,
dempson@xxxxxxxxxxxxx (David Empson) wrote:

RobertB <missinglink@xxxxxxxxxx> wrote:

In article <1iwru9x.1xhrhbo17tyylnN%dempson@xxxxxxxxxxxxx>,
dempson@xxxxxxxxxxxxx (David Empson) wrote:

RobertB <missinglink@xxxxxxxxxx> wrote:

This is interesting. If I save it (Print>Save As PDF) as a PDF in Word,
I can print it successfully from Acrobat Reader but not from Preview
(which seems to use an RTF version of the file), which exhibits the
same
problem as Word. I can print the RTF file from the G4, however (it's
the
only version I tried to print from there).

I don't understand your RTF reference. When you print to a PDF, you have
a PDF file, not an RTF file. Preview or Adobe Reader would be dealing
with a PDF, and converting it back to an RTF would be a rather difficult
task (which would probably lose all structure of the original document).
Preview has no mechanism to do that. It can only save as PDF or various
image formats.

Well, Preview handles RTF files just fine. I'll have to double-check
this because it could have been an artifact of a previous version of the
file (RTF) not printing completely and appearing in the print queue.

Preview has nothing to do with RTF files. It cannot directly open them
or save them.

Hmm. I see it can open PostScript files as well as PDF. Not RTF though.



When Preview is involved in the print process, the original format of
the document (whether it be text, RTF, Word or anything else) doesn't
change anything as far as Preview is concerned. In all cases, the other
application has printed to PDF and Preview is opening a PDF. This
applies whether you explicitly save as PDF and then open the PDF in
Preview, or simply click the Preview button in the print dialog, or use
Preview to examine a document in a print queue.

So, in all cases, it converts to PDF.


The name of the document appearing in the print queue might reference
the original document name (including its extension), but it is not in
the original format. It is a PDF.

That's interesting. Although I specifically saved the file in PDF
format.



But (I'm recollecting here) I recall that after trying to print from Word
without success, I saved the RTF as PDF and opened it in Preview and
printed it from Preview. When I checked the Print Utility, the document
in the queue was an RTF version of the file. So, either it was still
trying to print an earlier version of the file OR well, I don't know
what the hell it was doing.

If you had a document in the print queue which mentioned RTF then it
would have been the print output from an application which had opened
and printed the RTF.

That would be Word.

I expect it was an earlier version, if you had
saved it as Word, renamed it in the process and printed it again.

This problem has never happened before. Word has been pretty reliable
(although flaky from time to time), so has the printer.

The problem is likely to be a subtle one: something specific in that
document and the way in which Word prints it is causing production of a
PDF which the Mac OS X Postscript to PDF renderer can't quite handle (at
least for your printer). It is likely to be triggered by some content in
the doucment and could be very hard to spot.

Well, I'm pretty sure there is corruption in the doc somewhere. It did
crash Word during a spellcheck, right near the end of the endnotes. I
can't say for sure, but that's my suspicion right now.

Seems like a reasonable theory.

I'm guesssing the "EOF" message is something the printer software
identifies in the file at a location where it shouldn't be.

EOF is an abbreviation for "End Of File". The PDF to Postscript renderer
expected there to be more data in the file but it wasn't there. This is
probably due to it misinterpreting some element within the PDF which it
thought was supposed to contain more data than existed in the rest of
the file.

Interesting.

Rather than corruption, it could also be that the PDF output was
incomplete, but the document got sent to the print queue anyway.

Incomplete in what sense? Or rather, how? Wouldn't that imply that the
EOF code may have clipped the document when generating the PDF (so
Preview printed the same abbreviated document as Word)?



Unless I'm mistaken, EOF is not a Word or PostScript code. It's one of
those basic codes used by even the simplest documents, similar to LF
(line
feed), etc.

You're probably thinking of ASCII codes, and none of them are called
"EOF". The most similar ones are ETX (End Of Text, Ctrl-C), EOT (End Of
Transmission, Ctrl-D) and ETB (End Transmission Block, Ctrl-W).

CP/M and MS-DOS text files popularised the use of Ctrl-Z as an "end of
file" character, but its ASCII name is SUB (Substitute, I think).

So what code system uses EOF? Any idea?

None that I know of. It is just a general computing term for "end of
file", which literally means "there is no more data to read", not even a
character to indicate that you are at the end of the file.

Not a postscript code then.


Modern file systems (by which I mean anything after the early 1980s) are
able to record the exact length of a file in bytes, and file formats
designed to work on modern file systems don't need to write special
characters to say there is no more data to follow. Some do anyway, as a
safety precaution in case they are transported via a method which could
cause the length to increase. Old communication protocols like XMODEM
could cause the file size to be rounded up to the nearest multiple of
128 bytes. I doubt original XMODEM was used much after the late 1980s.

Geez, I haven't used XMODEM as a transfer protocol in many, many years.

--
"Never believe anything until it's officially denied."
.