Try at printing under linux

[badidea]

Triggered by this topic, I was trying print to a printer under linux (Ubuntu).
Now, I do not have an actual printer, so I installed "cups-pdf". Instead of using "lp" I tried "lpr" (/usr/bin/lpr) via "popen()" and "pclose()". Code:

Code: Select all

#Include Once "crt/stdio.bi"

dim as zstring ptr psPtr = callocate(1000)

#print typeof(psPtr)
#print typeof(*psPtr)

*psPtr = !"%!PS\n"
*psPtr += !"/inch {72 mul} def\n"
*psPtr += !"/Times-Roman findfont 50 scalefont setfont\n"
*psPtr += !"2.5 inch 5 inch moveto\n"
*psPtr += !"(Hello, World!) show\n"
*psPtr += !"showpage\n"

print *psPtr

dim as FILE ptr filePtr

filePtr = popen("/usr/bin/lpr", "w")
If filePtr <> 0 Then
	fprintf(filePtr, psPtr)
Else
	Print "Pipe open fail"
	pclose(filePtr)
End If

deallocate(psPtr)

It actually works. Unfortunately, the 'best' internet provider in the Netherlands seems to block pdf's, so here a small screenshot.

There are however some problems (besides the need to learn postscript):

Problem1:
"popen()" and "pclose()" exist, but not documented here: https://freebasic.net/wiki/wikka.php?wa ... PgCruntime

Problem2:
It does not work with 64-bit fbc.

Code: Select all

printer.c: In function ‘main’:
printer.c:62:3: warning: format not a string literal and no format arguments [-Wformat-security]
   fprintf( FILEPTR$0, PSPTR$0 );

Problem3:
(Probably the cause of problem2)
#print typeof(psPtr) gives:
ZSTRING * 4 PTR with fbc 32-bit
ZSTRING * 8 PTR with fbc 64-bit
I don't even know what ZSTRING * 4/8 PTR means. Should I convert to byte-array? Or am I taking a too complex approach?

[caseih]

The fprintf problem could be that your string has a "%" code in it. Try this instead:

fprintf(filePtr, "%s", psPtr)

[caseih]

Also, is there a reason you can't use LPrint? According to the docs, when you're done you can just issue a "Close -1" and that should terminate the job. The next LPrint will re-open a pipe to the printer.

EDIT: actually, Open Lpt is probably the way to go, rather than Lprint or popening LPR.

[badidea]

LPrint seems to have been replaced with Open "LPT:..." indeed.

The wiki says:
A printer spooler available through lp must be installed to access printers by name or a default printer. Spooler access was tested only with CUPS, but other spoolers may work that are invoked through lp. Port are zero-based on Linux. "LPT1:" corresponds with "/dev/lp0".

My system does not have a "/dev/lp0", so I have to figure out how to solve that.
Currently however, I have no real need to print something, so I will leave it at this for now.

Topic tittle changed. Less negative :-)

[caseih]

Hmm, not sure about /dev/lp. I think that refers to the actual printer port, bypassing cups maybe? I have /dev/lp entries, but I'm not sure if they correspond to cups printers or to the actual parallel ports (or USB equivalents). There's a package called cups-lpr that provides the older lpr spooler interface, but I think you already have that.

So maybe popen'ing the spooler binary directly is actually what you want. I don't know! It is a can of worms, and a bit complicated.

A nice feature that could be added to the runtime would be an interface directly to cups (all done via http protocol). could be wrapped up in open lpt. something like:

open lpt "cups:printer@server" for output as lp

EDIT: or maybe not. The cups api allows specifying of document type, such as pdf or postscript, or plain text, so there'd need to be a way of specifying this when sending a job. The cups API isn't that complicated, but it hasn't been ported to a FB .bi file yet.

[coderJeff]

Syntax:
Open Lpt ["[LPT[x]:][Printer_Name][,TITLE=Doc_Title][,EMU=TTY]"] [For Input Output] as #filenumber

Parameters:
x
- Specifies a port number. If omitted, output is sent to the system print spooler.
Printer_Name
- Name of printer to open. This parameter is ignored on DOS.
TITLE=Doc_Title
- Title of the print job as seen by the printer spooler.

'lp' the command versus '/dev/lp#' the device.

"lpt:..." uses spooler and installed commands 'lpstat' and 'lp'

"lptX:...." uses device port directly '/dev/lp{X-1}'

It worked when I wrote it ... but that was really long ago now. :)