xprint - Xwindows

This is a discussion on xprint - Xwindows ; I sent the following to the Debian X specific mailing list, so far without a reply. If there is a better fitting newsgroup, I'll appreciate it if you redirect me there. Begin quote: Hi, those who run up-to-date Debian know ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: xprint

  1. xprint


    I sent the following to the Debian X specific mailing list, so far
    without a reply. If there is a better fitting newsgroup, I'll
    appreciate it if you redirect me there.

    Begin quote:

    Hi, those who run up-to-date Debian know that Mozilla and Firefox don't
    have built-in PostScript printing enabled anymore (and other X programs
    will probably follow the same path sooner or later). Instead, printing
    from Mozilla now requires the Xprint server.

    But I only need to print quite rarely; in fact I don't even have a dead
    tree printer, all I want to do is occassionally "print to file", upload
    the output to my work machine and print it there the next day. So
    running Xprint all the time seems quite wasteful, especially because it
    appears to be just a hacked copy of the regular X server, the worst hog
    among daemons.

    I'd like to set up Xprint to be started on demand through inetd. The
    README.Debian file hints that it is possible but it doesn't give any
    specific advice or examples. I could simply charge ahead but I am
    the worrying type, so these questions come to mind:

    1/ how does the client (Mozilla) know on which X display to contact
    the Xprint daemon? It seems when Xprint is started the "official" way,
    from an initscript, the initscript sets up a file in /var/run or /tmp
    listing the available displays. But if it's started on demand, that
    list obviously won't exist.

    2/ how does the Xprint daemon itself know it is being run through inetd,
    and thus that it should run the protocol on stdin/stdout rather than
    listen on a socket? There's no _documented_ option to tell it so (the
    whole manpage for the daemon seems to be just a customized copy of the
    Xserver manpage).

    TIA for answers, hints, or pointers.

    --
    "It's not true or not." A reality show producer (real quote)

  2. Re: xprint

    Ian Zimmerman wrote:
    >
    > Hi, those who run up-to-date Debian know that Mozilla and Firefox don't
    > have built-in PostScript printing enabled anymore (and other X programs
    > will probably follow the same path sooner or later). Instead, printing
    > from Mozilla now requires the Xprint server.
    >
    > But I only need to print quite rarely; in fact I don't even have a dead
    > tree printer, all I want to do is occassionally "print to file", upload
    > the output to my work machine and print it there the next day. So
    > running Xprint all the time seems quite wasteful, especially because it
    > appears to be just a hacked copy of the regular X server,


    Erm... Xprt isn't a "hack". Xprint is a X Consortium standard (see
    xc/doc/specs/XPRINT/) and provides a fully-featured print API for X11
    applications.
    Why do you think it's a "hack" ?!

    > the worst hog among daemons.


    Xprt can help _saving_ memory since all resource-intensive stuff (fonts,
    images, OpenGL textures etc.) isn't handled at the application side. The
    resource usage which would happen within the application is MOVED to the
    Xprint server side. You do NOT waste resources with that, you only MOVE
    it. And if multiple applications or multiple users (think about large
    multiuser systems) are using Xprt then even memory gets saved. LOTS of
    memory (for the same reason things like "xfs" (X11 font server) were
    invented...).
    BTW: The same argumentation applies to "cupsd" or "lpd", they hog
    memory, too.

    > I'd like to set up Xprint to be started on demand through inetd. The
    > README.Debian file hints that it is possible but it doesn't give any
    > specific advice or examples. I could simply charge ahead but I am
    > the worrying type, so these questions come to mind:
    >
    > 1/ how does the client (Mozilla) know on which X display to contact
    > the Xprint daemon? It seems when Xprint is started the "official" way,
    > from an initscript, the initscript sets up a file in /var/run or /tmp
    > listing the available displays. But if it's started on demand, that
    > list obviously won't exist.


    No, the specifiation defines that the Xprint clients find the Xprint
    server using the XPSERVERLIST environment variable or via the
    "XpServerList" resource. Running it via inetd would require that there
    is a well-known port where Xprt sits...

    > 2/ how does the Xprint daemon itself know it is being run through
    > inetd, and so it should run the protocol on stdin/stdout rather than
    > listen on a socket? There's no _documented_ option to tell it so
    > (the whole manpage for the daemon seems to be just a customized copy
    > of the Xserver manpage).


    AFAIK noone tried to run Xprt throught inetd yet. it isn't that easy
    since the transport code needs to be changed to work with that. If I
    remember it correctly Sun (either Alan or Jay) did some investigation
    with Xprt+inetd but I don't know the results.
    I see at least the following problems:
    - Xprt enumerates all available print queues at startup - which may be
    _SLOW_ in the case when there are remote printers which are OFFLINE. The
    spooler may try to contact them and wait for an timeout. Xprt solves
    that problem via caching the list and only updates them either on a
    server reset or when the XpExtension API hook
    - The XPSERVERLIST environment variable and the XpServerlist resource
    must be distributed somehow... but how ?
    - Multiple Xprint clients can share one surface (or better: "print
    context") for printing (this is needed since an application may call
    |fork()| to run the print process - and CDE's "dtpdm" uses that to have
    the print dialog in a seperate process ("dtpdm" and "dtpdmd") which
    prepares the "print context" and then passes it to the application). So
    Xprt would need to be started in a way that multiple processes can reach
    the same Xprt instance...

    ----

    Bye,
    Roland

    P.S.: Just looking at the memory usage of Xprt: At startup it uses only
    twice the memory of one "bash" session ("top" shows more but that are
    memory mappings done via mmap() and no HEAP usage) - so running Xprt
    only "on demand" doesn't save much (if you want to complain about
    resource usage: "bash" consumes more than three times the memory of
    "ksh93" - so why does Linux still use "bash" and not "ksh93" ? ) ...

    --
    __ . . __
    (o.\ \/ /.o) roland.mainz@nrubsig.org
    \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
    /O /==\ O\ TEL +49 641 7950090
    (;O/ \/ \O

+ Reply to Thread