puzzle: print control character between DOS and HP-UX

[Fred Martin_1]

I maintain a text file on our unix server, which is always two pages long. As a page seperator there is a control-L in there, which nicely goes to TOF when printed with the 'lp' command, from HP-UX.

Now I have to also make this file available to users in a public folder on an NT server. I wrote a script that renames a copy of the file to a '.txt' name, and ftp's it over to the NT box. (tried same with a rename to '.rtf')

The problem is that TOF crontrol-L.

When users on the NT side print the file, it doesn't recognize the ^L at all.

I've tried reverse-engeering - tried to insert a TOF in an NT .txt and/or .rtf file, but can't figure out anything that works.

Any ideas?

[Massimo Bianchi]

Hi,
here is my idea:
- create a printer that spools to file, using the dumb printer.
- over that file, issue a

ux2dos

command, to convert LF/CR properly, and move the spooled file wherever you need.

So you have the output already formatted on two pages.

HTH,
Massimo

[Pete Randall]

I would think that just using ux2dos to create your .txt file would suffice. Give it a try.


Pete

[Fred Martin_1]

Using ux2dos doesn't work.

Before: ^L
After: ^L^M

The ^L is ignored when printing in DOS; it prints as a little white box character.

I'll try the other thing.

[Pete Randall]

Oh well! Hopefully Massimo's idea will prove more fruitful.

Good luck!


Pete

[Fred Martin_1]

Nope. The problem is ux2dos doesn't do anything with ^L ... it adds a ^M to end of lines and a ^Z to end of file. I think that's about it.

I guess my question should be:

How do you put a TOF in a .txt or .rtf file? Once I know that I'll ftp the file back to unix and look at the control sequence.

[Massimo Bianchi]

Hi,
another shot:

cat yourUNIXfile | col -b | ux2dos > yourDOSfile

I'm looking at a way to insert the TOF in NT but till now i have not found anything...

Another thought: what kind of printer are you using on the NT side ?


I recall to use control chars in DOS mode (5.x, 6.x). May be it's the window driver that is working badly.

What about (in WINDOWS):
type yourDOSfile_wih_cnrlt_l > lpt1

Massimo

[Fred Martin_1]

Interesting...your suggestion that it's the MS OS is correct.

I'm running Windows ME on my PC. I ftp'd the file containing the ^L to my PC, renamed the file to end in .rtf, brought it up in Wordpad, and there was a pagebreak! Printed fine.

So I ftp'd the file from unix to the NT server. Renamed it to .rtf - while on the NT server I opened it in Wordpad and ... no good.

Then, back on my PC, opened it in Wordpad from across the shared folder ... and it's OK.

It figures this would be a Microsoft thing.

So, it's not reliable because it's the OS version or the version of Wordpad/Notepad or whatever text editor they happen to be using, that controls whether or not it works.

Well I can't control what they use, unfortunately....am I out of luck?

[Gavin Clarke]

So would I be way out asking whether it's being ftp'd as binary or ascii?

Hmmm wouldn't there be ^M's after every line. I don't think this helps much. Please confirm that it doesn't.

[Massimo Bianchi · Accepted solution]

End of friday evening ideas: get a pdf_converter driver, or a pcl to pdf converter.

create a printer that, finally, prints to pdf.

share the pdf.

HTH,
Massimo

[Gavin Clarke]

Or there's samba for a share that's accessible to Windows.

[Fred Martin_1]

Both really good ideas.

In the short term, I split the document into two documents, named them 'page 1' and 'page 2' ... yeah it's stupid but anyway.

Oh and yeah I tried both binary and ascii formats for the ftp. Same result.

Thanks folks,
Fred

[Massimo Bianchi]

Hi,
in this link how to create a pdf:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xfb2731ec5e34d711abdc0090277a778c,00.html


if not work.... i give up, it's friday, out the sun shines and i'm waiting to exit...

Massimo

[Bill Hassell]

The formfeed character is defined by the ASCII standard as a newpage of formfeed character. It is meaningless to the operating system, whether HP-UX or Windows. It does have meaning to ASCII printers but meaningless to non-ASCII printers such as Postscript. And application programs like Wordpad and Word will interpret the FF character according to whatever rules are applied during the file open and in some cases, the file's type extension.

So the problem is how to get all the 'friendly' features of WIndows out of the way so the plain text file can be sent to a printer without filtering. This was trivial in the days of 'real' DOS systems but as you probably know, DOS is no longer an underlying operating system but is now a quaint little program on the side. And to make it friendly to modern versions of Windows, the printing subsystem now gets involved. Unlike HP-UX where almost nothing is done to the print job, Windows processes every character through a giant print subsystem consisting of a meta-data processor (the program-to-spooler interface), then a printer driver where the meta-data is transformed into the best fit for the language of the printer.

Thus, it is quite difficult to control the behavior of a simple print file. What is needed is a 'raw' option in Windows which allows data to be sent as-is to the printer. Of course, a Postscript printer will just print error messages for a plain ASCII file.