I'm making a program in C for linux but an important thing i can't find in
my books is how to print from your C program
any hint,link or tutorial is welcome
thaaaaaaaaaaaaaaaaanx Marco
Printing isn't a language issue, it's a system one. Hint: use popen to
open a pipe to the printer submission program, usually lpr or lp. Or if
you want to do it the long way, write to a file, close it and then
invoke the printer submission program to print it.
There are print output generation routines in Gnome, etc, but I don't
think this is what you had in mind.
#include <stdio.h>
...
FILE *printer = popen("lpr", "w");
fprintf(printer, "This text is printed\n");
pclose(printer);
> Hi,
>
> I'm making a program in C for linux but an important thing i can't find in
> my books is how to print from your C program
popen to the lpr command. (man popen, man lpr.) The exact format in
which data is expected depends on the printer and the lpd setup, but
most systems should accept text and PostScript.
--
Nate Eldredge
neld...@hmc.edu
: I'm making a program in C for linux but an important thing i can't find in
: my books is how to print from your C program
You mean "Send data to the printer?".
Basically, there is no way to send data to the printer directly from
user C program. There is some print spooling system, and some system
utility, usially lpr, which is only person in the town, who knows how to
send data to the printer queue.
So, if one wants to print from C program, he does
popen("lpr","w") and writes data to the lpr's stdin.
More clever programmers typically provide some way to configure
printing program, just in case that someone would port their program
to System V Unix (such as Solaris) which use "lp" command to send data
to the printer, or in case that user wants to provide some additional
arguments for lpr, such as specific printer name.
Some people also tends to provide more comprehensive interface to print
spooling system, such as some GUI which lists available printers,
but it is a bit more complicated thing - if there are typically two
commands which send files to queue - lp and lpr, and their interface
is identical - just write to them via pipe calling them with
user-supplied arguments,
there are really various print spooling systems: Berkeley lpd, lprng,
cups etc, which may use same name for command to display list of
printers and their status (lpc status), but output format varies
dramatically.
: any hint,link or tutorial is welcome
: thaaaaaaaaaaaaaaaaanx Marco
--
I think that's easier to read. Pardon me. Less difficult to read.
-- Larry Wall in <1997101202...@wall.org>
I'm also interested in printing in C, but well formatted pages,
such as print a big character and then a small one, add a thin line
and if possible a image. Is there the ability to:
- make a temporarily latex-file
- translate it to .dvi-file
- send this file per lpr to the printer?
Thanks in Advance for any thoughts.
Christian
It's no problem at all. fopen() a file, write whatever TeX commands and
text you need into it, close() it, invoke 'latex' and 'dvips' on it
using popen() and then print the result by invoking 'lpr' via popen().
You also could write a Postscript directly and then send it to the
printer.
Regards, Jens
--
_ _____ _____
| ||_ _||_ _| Jens.T...@physik.fu-berlin.de
_ | | | | | | AG Moebius, Institut fuer Molekuelphysik
| |_| | | | | | Fachbereich Physik, Freie Universitaet Berlin
\___/ens|_|homs|_|oerring Tel: ++49 (0)30 838 - 53394 / FAX: - 56046
Hint: 'man popen'
Less of a hint:
#include <stdio.h>
{
FILE *report;
if ((report = popen("/usr/bin/lpr","w")) != NULL)
{
/* we are ready to print our report */
int count;
fprintf(report,"Hello world\n");
for (count = 0; count < 20; ++count)
fprintf(report,"Line %d of the report\n",count+1);
/* we are done reporting now, let the output go... */
fclose(report); /* could have used pclose() instead */
}
else fprintf(stderr,"Gulp: can't popen() lpr\n");
}
--
Lew Pitcher
Master Codewright and JOAT-in-training
Registered Linux User #112576
Thanks!
I want to run my program under Win32, too. Is there a library to form
the latex-file into a dvi-file, because I cannot run dvips under Win32?
Christian
"The return value from popen() is a normal
standard I/O stream in all respects save that it
must be closed with pclose() rather than
fclose()." popen man page
> }
> else fprintf(stderr,"Gulp: can't popen() lpr\n");
> }
--
Floyd L. Davidson <http://www.ptialaska.net/~floyd>
Ukpeagvik (Barrow, Alaska) fl...@barrow.com
I want to thank everyone for the advice to get me started on printing
thaaaaaaaaaaaaaaaaaaanx Marco
> I want to run my program under Win32, too. Is there a library to form
> the latex-file into a dvi-file, because I cannot run dvips under Win32?
Now that's something I really can't answer because I hardly ever
programmed on a Windows system and I am happily ignorant of how to
spawn other programs from within a program on these systems ;-) But
I have definitely seen collegues using dvips on Windows and I guess
it should be included in MikTeX (see http://www.miktex.org).
LaTeX file is just plain text file with some special commands. You may
write it with just printf statements.
Of course, there are some subtle issues with temporary files - you
have to insure that in no circumstances you'll accidentely rewrite
some user file with important information. "In no circumstanses" means
"Even if some evil local user would try to trick your program, running
on behalf on another local user". But this is quite possible and
technics to deal with temorary files are well-known. You'll find
a lot of information in info libc.
BTW, in your place I'd probably use some other page description language
than LaTeX.
1. You may write PostScript directly. It might be a bit more
complicated, but it is almost standard page description language for
Unix systems, and it is often understood by printers directly.
2. You may use something more lightweight text formatter, like lout
or groff. I perlsonally vote for groff. First, almost every Unix system
has some version of *roff if just for formatting of manual pages.
Second, groff doesn't need temporary files - you feed it with formatting
commands via pipe and get result via pipe. Third, just by altering
value of -T option you can choose between various output formats - ps,
dvi, html and text which would show bold and underline in less.
--
Never trust an operating system you don't have sources for. ;-)
-- Unknown source
: Thanks!
First, you CAN run dvips on Win32. In comp.text.tex there are lot of
people who do exactly that. Second, I've suggested more
lightweight text formatters than LaTeX.
--
Even more amazing was the realization that God has Internet access. I
wonder if He has a full newsfeed?
-- Matt Welsh
<grin visage="sheepish">
Ooops. Gotta stop skimming those man pages.
</grin>
> > }
> > else fprintf(stderr,"Gulp: can't popen() lpr\n");
> > }
>
> --
> Floyd L. Davidson <http://www.ptialaska.net/~floyd>
> Ukpeagvik (Barrow, Alaska) fl...@barrow.com
--
Jens> Christian Lang <Ziege...@web.de> wrote:
>> I'm also interested in printing in C, but well formatted pages,
>> such as print a big character and then a small one, add a thin
>> line and if possible a image. Is there the ability to:
>> - make a latex-file
>> - translate it to .dvi-file
>> - send this file per lpr to the printer?
Why not? Just use mktemp() to create a temp file, use system() to
invoke TeX and 'dvips' and 'lpr'. Anything you can do via the command
line or shell-script can be done in C. (In the most extreme case, you
just resort to system().)
Jens> It's no problem at all. fopen() a file, write whatever TeX
Jens> commands and text you need into it, close() it, invoke
Jens> 'latex' and 'dvips' on it using popen() and then print the
Jens> result by invoking 'lpr' via popen(). You also could write
Jens> a Postscript directly and then send it to the printer.
I would prefer generating Postscript directly if I want fine control
on the appearance. Otherwise, why invent the wheel? Just leave it to
(La)TeX, which has been doing its job so well!
--
Lee Sau Dan 李守敦(Big5) ~{@nJX6X~}(HZ)
.----------------------------------------------------------------------------.
| e-mail: sd...@eti.hku.hk http://www.csis.hku.hk/~sdlee |
`----------------------------------------------------------------------------'
Victor> You mean "Send data to the printer?".
Victor> Basically, there is no way to send data to the printer
Victor> directly from user C program.
Yes, there is: fopen("/dev/lp0", "w") and write the data out. But...
1) Usually, a user program does not have permissions to write to
"/dev/lp0".
2) This is non-portable. On older Linux kernels (2.0 and earlier),
that would be "/dev/lp1" instead. On other UNIX or architectures,
who knows what that device file is named!
Therefore, the standard way is to have a daemon (lpd) manage the
printer via this raw device file, and have clients (i.e. user
programs) submit print jobs to the daemon (using "lpr"). Using lpd
has the advantage of making the printer access mroe
network-transparent. So, opening the raw device is usually only does
when writing such a daemon. (P.S. To test if a printer works, it is
handy to "echo Hello > /dev/lp0" or try something like that, esp. when
the lpd system has not yet been configured properly.)
Victor> So, if one wants to print from C program, he does
Victor> popen("lpr","w") and writes data to the lpr's stdin.
Yeah! That's the recommended way to do that.
Victor> Of course, there are some subtle issues with temporary
Victor> files - you have to insure that in no circumstances you'll
Victor> accidentely rewrite some user file with important
Victor> information. "In no circumstanses" means "Even if some
Victor> evil local user would try to trick your program, running
Victor> on behalf on another local user". But this is quite
Victor> possible and technics to deal with temorary files are
Victor> well-known. You'll find a lot of information in info libc.
Doesn't mkstemp() take care of it already?
Victor> BTW, in your place I'd probably use some other page
Victor> description language than LaTeX.
Victor> 1. You may write PostScript directly. It might be a bit
Victor> more complicated, but it is almost standard page
Victor> description language for Unix systems, and it is often
Victor> understood by printers directly.
But then, you have to implementing your own line-breaking algorithm,
line-justification algorithm, hyphenation algorithm, kerning tables,
ligature substitutions, or even math formula setting! Why reinvent
the wheel, when it is NOT PATENTED?
Victor> 2. You may use something more lightweight text formatter,
Victor> like lout or groff. I perlsonally vote for groff.
I agree.
Victor> First, you CAN run dvips on Win32. In comp.text.tex there
Victor> are lot of people who do exactly that. Second, I've
Victor> suggested more lightweight text formatters than LaTeX.
Is pdf(la)tex available for Win32/DOS? If so, another possibility is
to generate PDF with pdf(la)tex and then convert it to Postscript by
launching Acrobat Reader.
Thank you all!!!!!
:> Now that's something I really can't answer because I hardly ever
:> programmed on a Windows system and I am happily ignorant of how to
:> spawn other programs from within a program on these systems ;-)
You're right, but it's a present that must run under Win32. But when
it must run there it should run at least under Linux, too.
Best regards,
Christian
: Victor> First, you CAN run dvips on Win32. In comp.text.tex there
: Victor> are lot of people who do exactly that. Second, I've
: Victor> suggested more lightweight text formatters than LaTeX.
: Is pdf(la)tex available for Win32/DOS? If so, another possibility is
Of course it is.
: to generate PDF with pdf(la)tex and then convert it to Postscript by
: launching Acrobat Reader.
I don't think that Acrobat Reader for Windows is able to convert pdf to
postscript. It has ability to print pdfs, and thats all. While in Unix
printing means "converting to postscript and feeding to lpr" on Windows
there is another way around - using GDI calls to draw into printer.
So, "Print to file" option in Windows would produce postscript only if
you have postscript printer driver installed.
Otherwise it would produce PCL, ESCP/2 or whatever else your printer
understand. Hmm, interesting thing, how does "Print to file" works
if only printer driver you've installed is Winprinter? Write Windows
metafile?
By the way, launching Acrobat Reader is terrible thing to do something
programmaticaly. It is GUI program.
: --
: Lee Sau Dan ╖У╕u╢╟(Big5) ~{@nJX6X~}(HZ)
: ..----------------------------------------------------------------------------.
: | e-mail: sd...@eti.hku.hk http://www.csis.hku.hk/~sdlee |
: `----------------------------------------------------------------------------'
--
We question most of the mantras around here periodically, in case
you hadn't noticed. :-)
-- Larry Wall in <1997051019...@wall.org>
: Jens> Christian Lang <Ziege...@web.de> wrote:
: >> I'm also interested in printing in C, but well formatted pages,
: >> such as print a big character and then a small one, add a thin
: >> line and if possible a image. Is there the ability to:
: >> - make a latex-file
: >> - translate it to .dvi-file
: >> - send this file per lpr to the printer?
: Why not? Just use mktemp() to create a temp file, use system() to
For example, becouse it is hard to determine programmaticaly whether
you have run latex enough times on the particular file, or extra pass
is needed to get references right.
For example, becouse it creates a lot of extra files (.aux, .log, .toc
and whatever else) along with dvi files. And you have to clean up
after yourself.
Note that same is true for pdflatex.
But main reason against using latex as printing engine for your program
is that it is just too big to carry along with your program, and
consists of thousands of files.
BTW, not all printer spooling systems understand .dvi.
Mine, for instance, does not, becouse dvips is by default configured to
send output to printer, so it doesn't make much difference to type
"dvips file" insted of "lpr file.dvi"
: I would prefer generating Postscript directly if I want fine control
: on the appearance. Otherwise, why invent the wheel? Just leave it to
I rather do it vice versa. If I need thoroughly typesetted text, I'd use
LaTeX, if I want something much simplier, I'd write postscript directly.
Becouse it is quite simple to produce postscript with low-to-medium
output quality, and in-depths knowledge of its internals, and lot of
extra info, such as font metrics and ppd-s are required to produce
really professonally-looking output.
BTW, there is also perl script called html2ps, which can be fed
by pipe and produces reasonable good postscript from HTML
(and there is numerous libraries which help you to write html from
program, mostly intended for CGI programming).
html2ps really writes quite clever postscript program, which justifies
text lines automatically. So it can produce justified paragraphs without
reading afm file.
--
<dark> Turns out that grep returns error code 1 when there are no matches.
I KNEW that. Why did it take me half an hour?
-- Seen on #Debian
: Victor> Of course, there are some subtle issues with temporary
: Victor> files - you have to insure that in no circumstances you'll
: Victor> accidentely rewrite some user file with important
: Victor> information. "In no circumstanses" means "Even if some
: Victor> evil local user would try to trick your program, running
: Victor> on behalf on another local user". But this is quite
: Victor> possible and technics to deal with temorary files are
: Victor> well-known. You'll find a lot of information in info libc.
: Doesn't mkstemp() take care of it already?
Not always. It wouldn't know if you create some file, that tex, which
you'll later invoke on it, would create files with .aux and .log (and
may be .toc added. And evil user might know that (especially after
reading this posting). Moreover, tex would create these files non in the
same dierctory as original file resides, but in current one.
: Victor> BTW, in your place I'd probably use some other page
: Victor> description language than LaTeX.
: Victor> 1. You may write PostScript directly. It might be a bit
: Victor> more complicated, but it is almost standard page
: Victor> description language for Unix systems, and it is often
: Victor> understood by printers directly.
: But then, you have to implementing your own line-breaking algorithm,
: line-justification algorithm, hyphenation algorithm, kerning tables,
: ligature substitutions, or even math formula setting! Why reinvent
: the wheel, when it is NOT PATENTED?
Becouse an existing wheel from a lorry might be just to heavy for your bike.
: Victor> 2. You may use something more lightweight text formatter,
: Victor> like lout or groff. I perlsonally vote for groff.
: I agree.
BTW, I've read somewhere in the news, that one guy have written
all the algorithmes mentioned above in Postscript language. So you just
write out standard prologue, and then something which quite close
resembling TeX source, and getting adequate results.
Of course, I forgot a package name. I thing it was ${something}Script.
May be ClearScript or EasyScript.
:
--
> Tut mir Leid, Jost, aber Du bist ein unertraeglicher Troll.
Was soll das? Du *beleidigst* die Trolle!
-- de.comp.os.unix.linux.misc
: Victor> You mean "Send data to the printer?".
: Victor> Basically, there is no way to send data to the printer
: Victor> directly from user C program.
: Yes, there is: fopen("/dev/lp0", "w") and write the data out. But...
: 1) Usually, a user program does not have permissions to write to
: "/dev/lp0".
: 2) This is non-portable. On older Linux kernels (2.0 and earlier),
: that would be "/dev/lp1" instead. On other UNIX or architectures,
: who knows what that device file is named!
3) If two programs using this approach simulateously, guess what would
be printed.
: Therefore, the standard way is to have a daemon (lpd) manage the
: printer via this raw device file, and have clients (i.e. user
: programs) submit print jobs to the daemon (using "lpr"). Using lpd
: has the advantage of making the printer access mroe
: network-transparent. So, opening the raw device is usually only does
Main reason for the existence of spooling system is not a network
transparency, it is multitasking. Print jobs have to be queued and
executed one by one.
: when writing such a daemon. (P.S. To test if a printer works, it is
: handy to "echo Hello > /dev/lp0" or try something like that, esp. when
: the lpd system has not yet been configured properly.)
Of course, when system administrator tests if printer works (and it has
to be a system administrator due to reason 1 above), no other user
would send data to this printer, becouse they know it is not already in
operation.
--
<sel> need help: my first packet to my provider gets lost :-(
<netgod> sel: dont send the first one, start with #2
* netgod is kidding
> Yes, there is: fopen("/dev/lp0", "w") and write the data
> out. But...
Victor> 3) If two programs using this approach simulateously,
Victor> guess what would be printed.
Wouldn't the second open() be blocked until the first client as
close()d it?
Victor> : Why not? Just use mktemp() to create a temp file, use
Victor> system() to
Victor> For example, becouse it is hard to determine
Victor> programmaticaly whether you have run latex enough times on
Victor> the particular file, or extra pass is needed to get
Victor> references right.
That's not too difficult to determine. Approaches used in Makefiles
include:
1) Run it a fixed number of times. If the text is simple text without
any cross referencing, once should be enough. Run it a second time
if you have used any cross references (such as \ref, \cite, \pageref).
If you're using bibTeX to generate the bibliography list, do:
latex, bibtex, latex, latex. etc.
2) Determine it from the .log file generated by LaTeX. If you find
(use regular expressions!) any "Warning" about possibly incorrect
references, rerun latex.
Victor> Note that same is true for pdflatex.
Sure. The only difference is that a PDF file is generated in the
place of a DVI file.
Victor> But main reason against using latex as printing engine for
Victor> your program is that it is just too big to carry along
Victor> with your program, and consists of thousands of files.
You can trim it down to just what you need. For simple text layout,
TeX alone should be sufficient. Moreover, you should have a good idea
of what LaTeX input your own program is going to generate. So, you
know what features or packages you'll need. It is possible to just
package the files enough for your jobs. (E.g. if you're using
Postscript fonts only, why package CMR .mf files and METAFONT? If
you're using pdfLaTeX, why package 'dvips'?)
Victor> BTW, not all printer spooling systems understand .dvi.
That's why we normally use dvips (or others).
Victor> Mine, for instance, does not, becouse dvips is by default
Victor> configured to send output to printer, so it doesn't make
Victor> much difference to type
Victor> "dvips file" insted of "lpr file.dvi"
Use the "-f" flag to force it to write the result to stdout.
Victor> BTW, there is also perl script called html2ps, which can
Victor> be fed by pipe and produces reasonable good postscript
Victor> from HTML (and there is numerous libraries which help you
Victor> to write html from program, mostly intended for CGI
Victor> programming).
But HTML is not a good language to describe layout. I would consider
troff (groff) first.
Victor> html2ps really writes quite clever postscript program,
Victor> which justifies text lines automatically. So it can
Victor> produce justified paragraphs without reading afm file.
The problem is not in the utility, but the defects of HTML itself.
Victor> I don't think that Acrobat Reader for Windows is able to
Victor> convert pdf to postscript.
Too bad it can't do this simple and (quite) straight-forward thing.
Victor> It has ability to print pdfs, and thats all.
So, install the "Apple Laserwriter" printer driver from your WinXX CD,
and then do print-to-files to this printer.
Victor> So, "Print to file" option in Windows would produce
Victor> postscript only if you have postscript printer driver
Victor> installed.
Windows since 3.1 (?) have such a driver PSCRIPT.DLL. You'll get it
if you pretend that you have an Apple Laserwriter printer and install
it. Of course, many people have complained about the qualitfy of the
output of Microsoft's Postscript driver implementation. Many people
would prefer to download and install Adobe's Windows Postscript
driver. Adobe's driver gives much better quality and capabilities
(such as printing 4 pages on 1 sheet back in the old dates of Win95).
The license allows people who have Postscript printers to use this
driver.
Victor> Otherwise it would produce PCL, ESCP/2 or
Victor> whatever else your printer understand. Hmm, interesting
Victor> thing, how does "Print to file" works if only printer
Victor> driver you've installed is Winprinter? Write Windows
Victor> metafile?
I guess so...
Victor> By the way, launching Acrobat Reader is terrible thing to
Victor> do something programmaticaly. It is GUI program.
So, it's not that "user-friendly", because in your case "user" ==
"programmer". Or is it TOO "user-friendly"?
That's why I like UNIX.
--
Lee Sau Dan 李守敦(Big5) ~{@nJX6X~}(HZ)
.----------------------------------------------------------------------------.
Victor> : Doesn't mkstemp() take care of it already?
Victor> Not always. It wouldn't know if you create some file, that
Victor> tex, which you'll later invoke on it, would create files
Victor> with .aux and .log (and may be .toc added. And evil user
Victor> might know that (especially after reading this
Victor> posting). Moreover, tex would create these files non in
Victor> the same dierctory as original file resides, but in
Victor> current one.
OK. Then,
if (mkdir("/tmp/blahblah/,0700) == 0
&& chdir("/tmp/blahblah/") == 0) {
/* proceed */
} else {
perror("something wrong");
exit(1);
}
where "blahblah" is some randomly generated directory name.
Victor> BTW, I've read somewhere in the news, that one guy have
Victor> written all the algorithmes mentioned above in Postscript
Victor> language. So you just write out standard prologue, and
Victor> then something which quite close resembling TeX source,
Victor> and getting adequate results.
Victor> Of course, I forgot a package name. I thing it was
Victor> ${something}Script. May be ClearScript or EasyScript.
Wow! That's cool! Is that Postscript library very large?
: Victor> So, "Print to file" option in Windows would produce
: Victor> postscript only if you have postscript printer driver
: Victor> installed.
: Windows since 3.1 (?) have such a driver PSCRIPT.DLL. You'll get it
And it produces TERRIBLE postscipt. If you want to get reasonably good
postscript from windows program, which is usable not only for sending
it to printer, you have to install Adobe driver.
: Victor> By the way, launching Acrobat Reader is terrible thing to
: Victor> do something programmaticaly. It is GUI program.
: So, it's not that "user-friendly", because in your case "user" ==
: "programmer". Or is it TOO "user-friendly"?
I think that "user-friendlyness" is totally wrong concept.
Programs shouldn't be so arrogant to think themselves friends of user.
Friendship is relationship between equals. And programs are servants
of user. They should do what they told and be invisible all other time.
--
> Alan Cox wrote:
[..]
No I didnt. Someone else wrote that. Please keep attributions
straight.
-- From linux-kernel
:)
Victor, may I quote you on this in sigcookie?
--
dg
Victor> I think that "user-friendlyness" is totally wrong concept.
Well... it all depends on who the user is and how "friendliness" is
defined. Unfortunately, most people talking about it take "user" ==
"idiot" and "friendliness" == "discourage you to learn anything by
hiding everything behind the scene from you, even if you're curious
enough to learn how the magic works". I hate this approach to
"user-friendliness".
Victor> Programs shouldn't be so arrogant to think themselves
Victor> friends of user. Friendship is relationship between
Victor> equals. And programs are servants of user.
But nowadays, most "user-friendly" programs are not there to serve
people. They're there to make people serve them. They don't have a
way for smart people to do things smartly, but force these potentially
smart people to do things in a rigid, boring, repetitive, error-prone
method. You think you're clever enough to automate the task? No way,
the "user-friendly" program is not intended to be used like that! And
that makes you complain about the stupidness of the designer of the
interface.
Victor> They should do
Victor> what they told and be invisible all other time.
Invisible? Well... are "invisible" things really considered
"programs" in this GUI-overpolluted world? Nowadays, even a simple
"hello world" program would need a GUI, or it'll be considered
something obsolete. That's sick.
: :)
Of course. My ideas usially distributed under GPL.
--
(It is an old Debian tradition to leave at least twice a year ...)
-- Sven Rudolph
: Victor> I think that "user-friendlyness" is totally wrong concept.
: Well... it all depends on who the user is and how "friendliness" is
: defined. Unfortunately, most people talking about it take "user" ==
Nice "user-friendly" explanation of what I've said in four lines.
[skip]
: Victor> They should do
: Victor> what they told and be invisible all other time.
^^^^
You've only forget to commend on this word. And I'm put it in for
purpose. I think that programs should be told to do things rather
then pointed to. Mankind invented speach (and written words) becouse
it is much more efficient way of communication than gesture which apes
use.
--
BTW: I have a better name for the software .... Microsoft Internet
Exploder.
-- George Bonser <gr...@cris.com>