From ssebastien at gmail.com Sat Oct 2 05:42:22 2004 From: ssebastien at gmail.com (Sebastien) Date: Fri Oct 1 23:00:41 2004 Subject: [Xprint] Re: Forwarding XPrint server connections via ssh? In-Reply-To: <415E108A.6000800@zip.com.au> References: <9e76f7fe04100117277f12dfc2@mail.gmail.com> <415DFFE0.6070900@zip.com.au> <9e76f7fe04100118185b24d896@mail.gmail.com> <415E04E9.8090708@zip.com.au> <9e76f7fe0410011850592bd4c7@mail.gmail.com> <415E108A.6000800@zip.com.au> Message-ID: <9e76f7fe041001194276a81dee@mail.gmail.com> On Sat, 02 Oct 2004 12:20:58 +1000, Darren Tucker wrote: > Sebastien wrote: > > Do you mean http://xprint.mozdev.org/docs/Xprint_FAQ.html#manual_xprint_forwarding_via_ssh? > > Thats ugly manual hackery ;-( > > So set "AcceptEnv XPSERVERLIST" in sshd_config, set XPSERVERLIST to > "localhost:whatever" and put "SendEnv XPSERVERLIST" into $HOME/.ssh_config. That requires access to the remote systems sshd which I do not always have. > >>I doubt it. It's more a matter of whether or not it belongs. > > > > You have X11 forwarding. And XPrint is X11, too. > > From what I can tell (from a brief read, I didn't investigate > thoroughly) there's significant differences in the way they work. > > * DISPLAY can only point to one port whereas xprint can point to many Why is that a problem? You forward multiple channels then - or not? > * xprint has no equivalent mechanism to xauth (which is crucial in the > way ssh's X forwarding works). I doubt that - the XPrint documentation says that 'Xprt is just another Xserver'. I CC.ed the XPrint list - maybe the gurus there can help with that. -- sebastien From roland.mainz at nrubsig.org Sun Oct 3 02:12:41 2004 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sat Oct 2 19:31:20 2004 Subject: [Xprint] Re: X Strike Force XOrg SVN commit: r19 - in xorg/trunk/debian: . scripts References: <20041002204713.7392C5C005@necrotic.deadbeast.net> Message-ID: <415F35E9.9F902F5A@nrubsig.org> X Strike Force SVN Repository Admin wrote: > > Author: fabbione > +* Import and adapt debian/scripts/prune-non-free: > + + update and review debian/copyright file. > + (note xc/programs/Xserver/XpConfig/C/print/models/SPSPARC2/ disappeared from > + upstream) > + 19 > + The SPSPARC2 model wasn't removed in the Xorg repository and is still there in DESTDIR after a % make install # ... > + 6) The Compugraphic and Adobe fonts distributed as part of the XPrint > + server are not licensed at all, and some of the fonts bear no > + copyright information whatsoever. > + > + All Rights Reserved. > + > + These font files therefore do not satisfy DFSG 1 ("Free > + Redistribution"), DFSG 2 ("Source Code"), or DFSG 3 ("Derived Works"). > + > + xc/programs/Xserver/XpConfig/C/print/models/HPDJ1600C/fonts/9nb00051.pmf These files are no fonts, they are font metrics information (and the copyright notice was just copied over from the original font from the converter and does NOT apply to the font metrics files. The converter just preserved all context attributes of the font regardless of their content). The PMF fonts shipped with Xprint _conform_ 100% to the DFSG 1/2/3 specs. This has extensively been discussed in the past. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From fabbione at fabbione.net Sun Oct 3 07:15:41 2004 From: fabbione at fabbione.net (Fabio Massimo Di Nitto) Date: Sun Oct 3 00:55:52 2004 Subject: [Xprint] Re: X Strike Force XOrg SVN commit: r19 - in xorg/trunk/debian: . scripts In-Reply-To: <415F35E9.9F902F5A@nrubsig.org> References: <20041002204713.7392C5C005@necrotic.deadbeast.net> <415F35E9.9F902F5A@nrubsig.org> Message-ID: <415F7CED.6060302@fabbione.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Roland, Roland Mainz wrote: | X Strike Force SVN Repository Admin wrote: | |>Author: fabbione | | |>+* Import and adapt debian/scripts/prune-non-free: |>+ + update and review debian/copyright file. |>+ (note xc/programs/Xserver/XpConfig/C/print/models/SPSPARC2/ disappeared from |>+ upstream) |>+ 19 |>+ | | | The SPSPARC2 model wasn't removed in the Xorg repository and is still | there in DESTDIR after a % make install # ... This file was not removed from our Xfree86 tree either, but SPSPARC2/fonts is now empty. I will correct the note in the CHANGESET to reflect the correct path. | | |>+ 6) The Compugraphic and Adobe fonts distributed as part of the XPrint |>+ server are not licensed at all, and some of the fonts bear no |>+ copyright information whatsoever. |>+ |>+ All Rights Reserved. |>+ |>+ These font files therefore do not satisfy DFSG 1 ("Free |>+ Redistribution"), DFSG 2 ("Source Code"), or DFSG 3 ("Derived Works"). |>+ |>+ xc/programs/Xserver/XpConfig/C/print/models/HPDJ1600C/fonts/9nb00051.pmf | | | These files are no fonts, they are font metrics information (and the | copyright notice was just copied over from the original font from the | converter and does NOT apply to the font metrics files. The converter | just preserved all context attributes of the font regardless of their | content). The PMF fonts shipped with Xprint _conform_ 100% to the DFSG | 1/2/3 specs. This has extensively been discussed in the past. Do you have any reference I can lookup please? Thanks Fabio - -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBX3zrhCzbekR3nhgRAkTEAJ41EKaYiPdvzpQfgCtFgbsZuwDZuwCeO2B1 A8z0bHJm8NojQIHwDbprzrI= =Ri1j -----END PGP SIGNATURE----- From roland.mainz at nrubsig.org Sun Oct 3 08:15:12 2004 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sun Oct 3 01:33:55 2004 Subject: [Xprint] Re: X Strike Force XOrg SVN commit: r19 - inxorg/trunk/debian: . scripts References: <20041002204713.7392C5C005@necrotic.deadbeast.net> <415F35E9.9F902F5A@nrubsig.org> <415F7CED.6060302@fabbione.net> Message-ID: <415F8AE0.413298F7@nrubsig.org> Fabio Massimo Di Nitto wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Roland, > > Roland Mainz wrote: > | X Strike Force SVN Repository Admin wrote: > | > |>Author: fabbione > | > |>+* Import and adapt debian/scripts/prune-non-free: > |>+ + update and review debian/copyright file. > |>+ (note xc/programs/Xserver/XpConfig/C/print/models/SPSPARC2/ > disappeared from > |>+ upstream) > |>+ 19 > |>+ > | > | The SPSPARC2 model wasn't removed in the Xorg repository and is still > | there in DESTDIR after a % make install # ... > > This file was not removed from our Xfree86 tree either, but > SPSPARC2/fonts is now empty. I will correct the note in the CHANGESET to > reflect the correct path. .../SPSPARC2/fonts/ should not be empty. It should contain soft links to the ../../PSdefault/fonts/ directory where now the font metrics files (*.pmf) for the 30 default Postscript fonts are stored (the "PSdefault" printer model-config was added to have one "generic" configuration which should work for all Postscript printers >= PS Level 2). Note that the install procedure for these files has changed - previously (X11 < release X11R6.8.0 and Xfree86) the xc/programs/Xserver/XpConfig/ directory was simply copied to the destination directory, now (X11 >= release X11R6.8.0) the information and links are generated at % make install # time - maybe that's the problem... > |>+ 6) The Compugraphic and Adobe fonts distributed as part of the XPrint s/XPrint/Xprint/ , please :) > |>+ server are not licensed at all, and some of the fonts bear no > |>+ copyright information whatsoever. > |>+ > |>+ All Rights Reserved. > |>+ > |>+ These font files therefore do not satisfy DFSG 1 ("Free > |>+ Redistribution"), DFSG 2 ("Source Code"), or DFSG 3 ("Derived > Works"). > |>+ > |>+ > xc/programs/Xserver/XpConfig/C/print/models/HPDJ1600C/fonts/9nb00051.pmf > | > | > | These files are no fonts, they are font metrics information (and the > | copyright notice was just copied over from the original font from the > | converter and does NOT apply to the font metrics files. The converter > | just preserved all context attributes of the font regardless of their > | content). The PMF fonts shipped with Xprint _conform_ 100% to the DFSG > | 1/2/3 specs. This has extensively been discussed in the past. > > Do you have any reference I can lookup please? It should be archived either in the Debian-X mailinglist or in one of the xprt-xprintorg package bugs. Drew Parsons may remember the bugid... my email archive doesn't go that far into the past (I guess that issue was debated around 2002 or earlier). The point is that we are talking about the files which contain only width/height data (=metrics information) for each glphy and _no_ bitmap or outline data (the PMF files are pretty small - if they would contain bitmaps rasterizes at 2560DPI you would see GIANT files). The font data itself, e.g. outlines or bitmaps are copyrightable but the width and height information does not fall into the category - it would be silly as everyone who would want to write an application which generates Postscript code would need an explicit license from Adobe. _If_ Adobe would have copyrighted the metrics information no opensource application (Mozilla, Ghostscript, Openoffice, JAVA, etc.) would be able to use one of the 30 default Postscript fonts defined by Postscript Level 2 as there would be no way to measure&layout the glyphs (the same applies to applications which generate PDF files). For example Mozilla ships the same information stored in the PMF files as part of it's Postscript print module (see http://lxr.mozilla.org/mozilla/source/gfx/src/ps/Courier-Bold.h , note that this source code is under MPL(=Mozilla Public License), the PMF files in the XOrg tree were donated by HP and Sun under the MIT license) and noone complained about that since many years (the same data were used in Netscape 4.x, too). ----- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From fabbione at fabbione.net Sun Oct 3 08:24:25 2004 From: fabbione at fabbione.net (Fabio Massimo Di Nitto) Date: Sun Oct 3 01:44:46 2004 Subject: [Xprint] Re: X Strike Force XOrg SVN commit: r19 - inxorg/trunk/debian: . scripts In-Reply-To: <415F8AE0.413298F7@nrubsig.org> References: <20041002204713.7392C5C005@necrotic.deadbeast.net> <415F35E9.9F902F5A@nrubsig.org> <415F7CED.6060302@fabbione.net> <415F8AE0.413298F7@nrubsig.org> Message-ID: <415F8D09.7000909@fabbione.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roland Mainz wrote: |>| |>| The SPSPARC2 model wasn't removed in the Xorg repository and is still |>| there in DESTDIR after a % make install # ... |> |>This file was not removed from our Xfree86 tree either, but |>SPSPARC2/fonts is now empty. I will correct the note in the CHANGESET to |>reflect the correct path. | | | .../SPSPARC2/fonts/ should not be empty. It should contain soft links to | the ../../PSdefault/fonts/ directory where now the font metrics files | (*.pmf) for the 30 default Postscript fonts are stored (the "PSdefault" | printer model-config was added to have one "generic" configuration which | should work for all Postscript printers >= PS Level 2). | Note that the install procedure for these files has changed - previously | (X11 < release X11R6.8.0 and Xfree86) the xc/programs/Xserver/XpConfig/ | directory was simply copied to the destination directory, now (X11 >= | release X11R6.8.0) the information and links are generated at % make | install # time - maybe that's the problem... Ok this make sense to me now. |>|>+ 6) The Compugraphic and Adobe fonts distributed as part of the XPrint | | | s/XPrint/Xprint/ , please :) Sure no problem :-) | |>|>+ server are not licensed at all, and some of the fonts bear no |>|>+ copyright information whatsoever. |>|>+ |>|>+ All Rights Reserved. |>|>+ |>|>+ These font files therefore do not satisfy DFSG 1 ("Free |>|>+ Redistribution"), DFSG 2 ("Source Code"), or DFSG 3 ("Derived |>Works"). |>|>+ |>|>+ |>xc/programs/Xserver/XpConfig/C/print/models/HPDJ1600C/fonts/9nb00051.pmf |>| |>| |>| These files are no fonts, they are font metrics information (and the |>| copyright notice was just copied over from the original font from the |>| converter and does NOT apply to the font metrics files. The converter |>| just preserved all context attributes of the font regardless of their |>| content). The PMF fonts shipped with Xprint _conform_ 100% to the DFSG |>| 1/2/3 specs. This has extensively been discussed in the past. |> |>Do you have any reference I can lookup please? | | | It should be archived either in the Debian-X mailinglist or in one of | the xprt-xprintorg package bugs. Drew Parsons may remember the bugid... | my email archive doesn't go that far into the past (I guess that issue | was debated around 2002 or earlier). | | The point is that we are talking about the files which contain only | width/height data (=metrics information) for each glphy and _no_ bitmap | or outline data (the PMF files are pretty small - if they would contain | bitmaps rasterizes at 2560DPI you would see GIANT files). The font data | itself, e.g. outlines or bitmaps are copyrightable but the width and | height information does not fall into the category - it would be silly | as everyone who would want to write an application which generates | Postscript code would need an explicit license from Adobe. _If_ Adobe | would have copyrighted the metrics information no opensource application | (Mozilla, Ghostscript, Openoffice, JAVA, etc.) would be able to use one | of the 30 default Postscript fonts defined by Postscript Level 2 as | there would be no way to measure&layout the glyphs (the same applies to | applications which generate PDF files). For example Mozilla ships the | same information stored in the PMF files as part of it's Postscript | print module (see | http://lxr.mozilla.org/mozilla/source/gfx/src/ps/Courier-Bold.h , note | that this source code is under MPL(=Mozilla Public License), the PMF | files in the XOrg tree were donated by HP and Sun under the MIT license) | and noone complained about that since many years (the same data were | used in Netscape 4.x, too). Ok. I think you conviced me. I want to wait for Branden's opinion too since he was the one creating these copyright notes and scripts for removal of these files in the first place. Thanks Fabio - -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBX40HhCzbekR3nhgRAk2FAJ9PoNp6j3bevR1j54hIAliI5ji+EwCfb8nd EOTgyjJZO13CziJE4A1hrIc= =YhbN -----END PGP SIGNATURE----- From roland.mainz at nrubsig.org Sun Oct 3 08:44:30 2004 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sun Oct 3 02:03:12 2004 Subject: [Xprint] Re: X Strike Force XOrg SVN commit: r19 -inxorg/trunk/debian: . scripts References: <20041002204713.7392C5C005@necrotic.deadbeast.net> <415F35E9.9F902F5A@nrubsig.org> <415F7CED.6060302@fabbione.net> <415F8AE0.413298F7@nrubsig.org> <415F8D09.7000909@fabbione.net> Message-ID: <415F91BE.8D09A092@nrubsig.org> Fabio Massimo Di Nitto wrote: > |>| The SPSPARC2 model wasn't removed in the Xorg repository and is still > |>| there in DESTDIR after a % make install # ... > |> > |>This file was not removed from our Xfree86 tree either, but > |>SPSPARC2/fonts is now empty. I will correct the note in the CHANGESET to > |>reflect the correct path. > | > | .../SPSPARC2/fonts/ should not be empty. It should contain soft links to > | the ../../PSdefault/fonts/ directory where now the font metrics files > | (*.pmf) for the 30 default Postscript fonts are stored (the "PSdefault" > | printer model-config was added to have one "generic" configuration which > | should work for all Postscript printers >= PS Level 2). > | Note that the install procedure for these files has changed - previously > | (X11 < release X11R6.8.0 and Xfree86) the xc/programs/Xserver/XpConfig/ > | directory was simply copied to the destination directory, now (X11 >= > | release X11R6.8.0) the information and links are generated at % make > | install # time - maybe that's the problem... > > Ok this make sense to me now. Please check whether the fonts.dir of the "PSdefault" model is populated (30 entries, the "SPSPARC2" model-config only links a subset of these fonts into the SPSPARC2/fonts/ dir as the printer has fewer fonts in it's ROM) in the Debian package. If the PMF files are missing the Xprint server is likely going amok and all printers which use this model won't work as expected. And since "PSdefault" is the "generic"(=default) model-config really worse this can happen then... ;-( BTW: Please sync with Drew Parsons about the Xprint configuration - the xprint.mozdev.org and Xorg trees have been merged in X11R6.8.0 so both versions of the Xprint server and server maintaince tools ("xplsprinters", "xphelloworld", etc.) are now the same... > |>|>+ 6) The Compugraphic and Adobe fonts distributed as part of the XPrint > | > | > | s/XPrint/Xprint/ , please :) > > Sure no problem :-) Thanks! :) > |>|>+ server are not licensed at all, and some of the fonts bear no > |>|>+ copyright information whatsoever. > |>|>+ > |>|>+ All Rights Reserved. > |>|>+ > |>|>+ These font files therefore do not satisfy DFSG 1 ("Free > |>|>+ Redistribution"), DFSG 2 ("Source Code"), or DFSG 3 ("Derived > |>Works"). > |>|>+ > |>|>+ > |>xc/programs/Xserver/XpConfig/C/print/models/HPDJ1600C/fonts/9nb00051.pmf > |>| > |>| > |>| These files are no fonts, they are font metrics information (and the > |>| copyright notice was just copied over from the original font from the > |>| converter and does NOT apply to the font metrics files. The converter > |>| just preserved all context attributes of the font regardless of their > |>| content). The PMF fonts shipped with Xprint _conform_ 100% to the DFSG > |>| 1/2/3 specs. This has extensively been discussed in the past. > |> > |>Do you have any reference I can lookup please? > | > | It should be archived either in the Debian-X mailinglist or in one of > | the xprt-xprintorg package bugs. Drew Parsons may remember the bugid... > | my email archive doesn't go that far into the past (I guess that issue > | was debated around 2002 or earlier). > | > | The point is that we are talking about the files which contain only > | width/height data (=metrics information) for each glphy and _no_ bitmap > | or outline data (the PMF files are pretty small - if they would contain > | bitmaps rasterizes at 2560DPI you would see GIANT files). The font data > | itself, e.g. outlines or bitmaps are copyrightable but the width and > | height information does not fall into the category - it would be silly > | as everyone who would want to write an application which generates > | Postscript code would need an explicit license from Adobe. _If_ Adobe > | would have copyrighted the metrics information no opensource application > | (Mozilla, Ghostscript, Openoffice, JAVA, etc.) would be able to use one > | of the 30 default Postscript fonts defined by Postscript Level 2 as > | there would be no way to measure&layout the glyphs (the same applies to > | applications which generate PDF files). For example Mozilla ships the > | same information stored in the PMF files as part of it's Postscript > | print module (see > | http://lxr.mozilla.org/mozilla/source/gfx/src/ps/Courier-Bold.h , note > | that this source code is under MPL(=Mozilla Public License), the PMF > | files in the XOrg tree were donated by HP and Sun under the MIT license) > | and noone complained about that since many years (the same data were > | used in Netscape 4.x, too). > > Ok. I think you conviced me. I want to wait for Branden's opinion too > since he was the one creating these copyright notes and scripts for > removal of these files in the first place. OK. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From pac at fortuitous.com Sun Oct 3 18:21:20 2004 From: pac at fortuitous.com (Phil Carinhas) Date: Sun Oct 3 18:39:44 2004 Subject: [Xprint] Re: Monospaced font in Thunderbird/Mozilla mail In-Reply-To: <414E4CE4.5070405@JaySmith.com> References: <414D5ABD.2040809@my.home> <414E4CE4.5070405@JaySmith.com> Message-ID: <20041003222120.GA13563@mail.fortuitous.com> On Sun, Sep 19, 2004 at 11:22:12PM -0400, Jay Smith wrote: > THANK YOU! > > I have now done this and tested.... and it works! > > The funny thing is that I thought I would combine it with the CSS content > at http://www.jw-stumpel.nl/stestu.html (Section 9 - printing) but then I > realized that this was YOU and that you apparently had since updated that > page with this new information. > > Anyway, I used your entire CSS "@media print" chunk and everything works. Will this work in a global Xprint file? I usually have to set up Firefox for all users. Thanks, -Phil Carinhas -- .--------------------------------------------------------. | Dr. Philip A. Carinhas | pac(at)fortuitous.com | | Fortuitous Technologies Inc. | http://fortuitous.com | | Linux Consulting & Training | Tel : 1-512-218-9561 | `--------------------------------------------------------' From DonziGuy at sbcglobal.net Sun Oct 3 19:45:38 2004 From: DonziGuy at sbcglobal.net (Donzi Guy) Date: Sun Oct 3 19:07:42 2004 Subject: [Xprint] GISWxprint-sparc-2004-07-07-release_009_001 Prints too large Message-ID: <41608112.6080805@sbcglobal.net> Hi All, I'm running Solaris 9 1001 with gnome desktop 2.0 and xprint GISWxprint sparc package 0901. I have a cups printer installed and can print to it using lp -d print-server:printer. Printing from mozilla using xprint works, except that only about 1/4 of the page is printed on a us-letter size page. By that I mean that the page is too large and only about 1/4 fits on a printer page. With the previous version, the pages were printed extremely small! What do I need to change in the configuration for the page to be printed correctly? How does one debug this? Thanks! From ssebastien at gmail.com Mon Oct 4 02:13:26 2004 From: ssebastien at gmail.com (Sebastien) Date: Sun Oct 3 19:31:55 2004 Subject: [Xprint] GISWxprint-sparc-2004-07-07-release_009_001 Prints too large In-Reply-To: <41608112.6080805@sbcglobal.net> References: <41608112.6080805@sbcglobal.net> Message-ID: <9e76f7fe041003161313596faa@mail.gmail.com> On Sun, 03 Oct 2004 18:45:38 -0400, Donzi Guy wrote: > Hi All, > > I'm running Solaris 9 1001 with gnome desktop 2.0 and xprint GISWxprint > sparc package 0901. I have a cups printer installed and can print to > it using lp -d print-server:printer. Printing from mozilla using xprint > works, except that only about 1/4 of the page is printed on a us-letter > size page. By that I mean that the page is too large and only about 1/4 > fits on a printer page. With the previous version, the pages were > printed extremely small! > > What do I need to change in the configuration for the page to be printed > correctly? Read http://xprint.mozdev.org/docs/Xprint_FAQ.html#printout_only_covers_1_4_of_the_paper and http://xprint.freedesktop.org/bugzilla/show_bug.cgi?id=772 > How does one debug this? Check the output of xplsprinters for the default-printer-resolution and adjust that in the server config. Common values are 300, 600 and 1200 dpi, less common values are 150, 360, 720 dpi. -- sebastien From DonziGuy at cocoanet.us Sun Oct 3 20:45:04 2004 From: DonziGuy at cocoanet.us (Dante Bell) Date: Sun Oct 3 20:03:17 2004 Subject: [Xprint] GISWxprint-sparc-2004-07-07-release_009_001 Prints too large In-Reply-To: <9e76f7fe041003161313596faa@mail.gmail.com> References: <41608112.6080805@sbcglobal.net> <9e76f7fe041003161313596faa@mail.gmail.com> Message-ID: <41608F00.4020204@cocoanet.us> An HTML attachment was scrubbed... URL: http://mozdev.org/pipermail/xprint/attachments/20041003/d5c31dd1/attachment.htm From aleksander.adamowski.xprint at altkom.pl Mon Oct 4 10:46:22 2004 From: aleksander.adamowski.xprint at altkom.pl (Aleksander Adamowski) Date: Mon Oct 4 04:05:19 2004 Subject: [Xprint] GISWxprint-sparc-2004-07-07-release_009_001 Prints too large In-Reply-To: <9e76f7fe041003161313596faa@mail.gmail.com> References: <41608112.6080805@sbcglobal.net> <9e76f7fe041003161313596faa@mail.gmail.com> Message-ID: <4160FFCE.3060309@altkom.pl> Sebastien wrote: >On Sun, 03 Oct 2004 18:45:38 -0400, Donzi Guy wrote: > > >>it using lp -d print-server:printer. Printing from mozilla using xprint >>works, except that only about 1/4 of the page is printed on a us-letter >>size page. By that I mean that the page is too large and only about 1/4 >> >> >> >Read http://xprint.mozdev.org/docs/Xprint_FAQ.html#printout_only_covers_1_4_of_the_paper >and http://xprint.freedesktop.org/bugzilla/show_bug.cgi?id=772 > > This problem will return again and again regardless of the FAQ, because most users will never even know the existence of the FAQ (especially when Xprint starts to be shipped with Linux distros by default). This guy's printing system (CUPS) already supplies the needed info about the printer's parameters (the cupsGetPPD() function), and Xprint _could_ extract that information in addition to model configs. I can see in practice that almost all Xprint users use the deafult, one-size-fits-all model-config, and even though I know how to change mine, I don't do that because it: * printer -> model-config map sits in a very strange location as for a config file (/usr/X11R6/lib/X11/xserver/C/print/attributes/printer in my case) and is likely to be wiped out with next system upgrade * i already have the needed information on my system (in the CUPS) and I believe that I shouldn't have to create redundant information WRT printers on my system The only proper solution is to make Xprint use CUPS information if it is available to supplement the model-config info. The CUPS information should override any model-config settings as it is most probably always more accurate. The bug about this is in Bugzilla: http://bugzilla.mozdev.org/show_bug.cgi?id=5355 If I just had the skill and internal knowledge of Xprint needed to fix it... Which unfortunately I don't. -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.ab.altkom.pl From roland.mainz at nrubsig.org Tue Oct 5 03:19:19 2004 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Mon Oct 4 20:37:57 2004 Subject: [Xprint] Re: /etc/init.d/xprint should be in /etc/rc.d/init.d/xprint on ourdistribution build kit References: <41619B82.4080107@obster.org> Message-ID: <4161E887.B0FD6E60@nrubsig.org> Michael Obster wrote: > I need some help from one of the imake people. I have seen, that X.Org > installs the xprint init script in /etc/init.d. What I need is to > install this one in /etc/rc.d/init.d. Which kind of Linux is that ? Could you file a bug under https://xprint.freedesktop.org/bugzilla/enter_bug.cgi?product=xprint for that, please ? > Can anyone give me a hint which makefile I need to change? I looked into > the makefile directory but haven't seen any option to change the init-dir. See xc/programs/Xserver/Xprint/etc/init.d/Imakefile ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From kissg at cdata.hu Tue Oct 5 13:58:25 2004 From: kissg at cdata.hu (Kiss Gabor) Date: Tue Oct 5 12:31:32 2004 Subject: [Xprint] HTML hint Message-ID: <41627E51.F4450797@cdata.hu> Dear folks, Could you break somehow the long fixed font lines on page http://xprint.mozdev.org/docs/Xprint_FAQ.html? Long unbreakable lines forces my browser to set line lengths of normal text much wider than the window intself. I cannot read text unless I continously scroll right-left-right-left... See attached screenshot. Thanks. Gabor -------------- next part -------------- A non-text attachment was scrubbed... Name: screenshot.png Type: image/png Size: 54390 bytes Desc: not available Url : http://mozdev.org/pipermail/xprint/attachments/20041005/31088e6d/screenshot-0001.png From ted at cypress.com Wed Oct 6 10:32:45 2004 From: ted at cypress.com (Thomas Dodd) Date: Wed Oct 6 10:52:15 2004 Subject: [Xprint] Re: /etc/init.d/xprint should be in /etc/rc.d/init.d/xprint on ourdistribution build kit In-Reply-To: <4161E887.B0FD6E60@nrubsig.org> References: <41619B82.4080107@obster.org> <4161E887.B0FD6E60@nrubsig.org> Message-ID: <4164020D.3080006@cypress.com> Roland Mainz wrote: > Michael Obster wrote: > >>I need some help from one of the imake people. I have seen, that X.Org >>installs the xprint init script in /etc/init.d. What I need is to >>install this one in /etc/rc.d/init.d. > > > Which kind of Linux is that ? Pre RH-7.3 comes to mind. In RHL-7.3 they created a symlink /etc/init.d -> /et/rc.d/init.d preparing for the full switch. That's my suggestiong for a fix too. create that symlink if the system doesn't have/use /etc/init.d -Thomas From roland.mainz at nrubsig.org Wed Oct 6 17:55:39 2004 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Wed Oct 6 11:14:18 2004 Subject: [Xprint] HTML hint References: <41627E51.F4450797@cdata.hu> Message-ID: <4164076B.8FB218DA@nrubsig.org> Kiss Gabor wrote: > Could you break somehow the long fixed font lines on page > http://xprint.mozdev.org/docs/Xprint_FAQ.html? > > Long unbreakable lines forces my browser to set line lengths > of normal text much wider than the window intself. > I cannot read text unless I continously scroll > right-left-right-left... That's a known problem, but I am not sure where this issue comes from. The HTML code is generated from an DocBook/XML file (the source can be found under https://xprint.freedesktop.org/cgi-bin/viewcvs.cgi/xorg/xc/doc/hardcopy/XPRINT/Xprint_FAQ.xml) - either the DocBook/XML-->HTML conversion stylesheet, the converter (unlikely) or the XML source has a bug. The quiz is: Which part is responsible... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From roland.mainz at nrubsig.org Fri Oct 8 00:06:17 2004 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Thu Oct 7 17:25:10 2004 Subject: [Xprint] Re: [Fwd: [Bug 1496] Xorg Xprt does not support "*xp-listfonts-mode: xp-list-internal-printer-fonts" to toggle the usage of printer-builtin fonts] References: <415B6FF5.9C5BA190@nrubsig.org> Message-ID: <4165AFC9.34F04E51@nrubsig.org> Roland Mainz wrote: > The patch raises the question whether "xp-listfonts-mode" (unlikely) or > "xp-listfonts-modes" (likely) is correct. Can anyone please check which > attribute is being used by libDtPrint ? > > -------- Original Message -------- > Subject: [Bug 1496] Xorg Xprt does not support "*xp-listfonts-mode: > xp-list-internal-printer-fonts" to toggle the usage of printer-builtin > fonts > Date: Wed, 29 Sep 2004 19:05:47 -0700 (PDT) > From: bugzilla-daemon@freedesktop.org > To: roland.mainz@nrubsig.org > > Please do not reply to this email: if you want to comment on the bug, go > to > the URL shown below and enter yourcomments there. > > https://freedesktop.org/bugzilla/show_bug.cgi?id=1496 For the log: I have checked-in the patch in the hope that this is the correct solution. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From roland.mainz at nrubsig.org Fri Oct 8 00:53:02 2004 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Thu Oct 7 18:12:00 2004 Subject: [Xprint] IDEA: A tool which prints an application window References: <9e76f7fe04091721532214e139@mail.gmail.com> Message-ID: <4165BABE.7FFFED11@nrubsig.org> Sebastien wrote: > I spend some time with reading the XPrint documentation today - and > after some time I was thinking myself 'hey, wouldn't it be cool if I > can make snapshots from any application using XPrint? Its a Xserver > after all, kind of, so any X application runs on it, right?'. Is that > feasible - a tool which redirects an application window to the print > server and prints that? I thought a little bit about the issue. The primary problems are: 1. How to display the application on the Xprint server that it appears within the paper surface (in Xprint the X11 windows usually represent surfaces on paper) ? 2. How can it be detected that the application finished content loading (for example a browser), layout, rendering etc. ? 3. How should pagination be implemented ? 4. How should the launched application be terminated ? There is no window manager running on Xprt so another way is needed to send a "window close" message to the application. [1] can be realised quite easy using the APPGROUP extension which allows an application to specify a window as display area. Then a special MIT-MAGIC-COOKIE-1 gets generated using the SECURITY extension - all applications which use this cookie will automagically apper within the appgroup display area. [2] is much harder to realise [3] could be done using XawPrintShell, however the limitation is than the total height of pages cannot exceed 2^15-1 pixels due a limitation in the XawPrintShell code. [4] I remember that somewhere was some example code whoch showed how to send a "window close" message to an application using it's window id. Alternatively |XKillClient()| could be used, however I don't like that idea... Finally: We need a name for the tool. Suggested names: - "xpappsnapshot" - "xpsnapshot" - "xpappwindump" Better suggestions welcome... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From roland.mainz at nrubsig.org Sat Oct 9 10:33:58 2004 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sat Oct 9 03:52:51 2004 Subject: PMF license / was: Re: [Xprint] Re: X Strike Force XOrg SVN commit: r19 -inxorg/trunk/debian: . scripts References: <20041002204713.7392C5C005@necrotic.deadbeast.net> <415F35E9.9F902F5A@nrubsig.org> <415F7CED.6060302@fabbione.net> <415F8AE0.413298F7@nrubsig.org> <415F8D09.7000909@fabbione.net> <415F91BE.8D09A092@nrubsig.org> <20041009060745.GS19131@redwald.deadbeast.net> Message-ID: <41679466.B52AF08@nrubsig.org> Branden Robinson wrote: > > On Sun, Oct 03, 2004 at 07:44:30AM +0200, Roland Mainz wrote: > > > |>|>+ server are not licensed at all, and some of the fonts bear no > > > |>|>+ copyright information whatsoever. > > > |>|>+ > > > |>|>+ All Rights Reserved. > > > |>|>+ > > > |>|>+ These font files therefore do not satisfy DFSG 1 ("Free > > > |>|>+ Redistribution"), DFSG 2 ("Source Code"), or DFSG 3 ("Derived > > > |>Works"). > > > |>|>+ > > > |>|>+ > > > |>xc/programs/Xserver/XpConfig/C/print/models/HPDJ1600C/fonts/9nb00051.pmf > > > |>| > > > |>| > > > |>| These files are no fonts, they are font metrics information (and the > > > |>| copyright notice was just copied over from the original font from the > > > |>| converter and does NOT apply to the font metrics files. The converter > > > |>| just preserved all context attributes of the font regardless of their > > > |>| content). The PMF fonts shipped with Xprint _conform_ 100% to the DFSG > > > |>| 1/2/3 specs. This has extensively been discussed in the past. > > > |> > > > |>Do you have any reference I can lookup please? > > > | > > > | It should be archived either in the Debian-X mailinglist or in one of > > > | the xprt-xprintorg package bugs. Drew Parsons may remember the bugid... > > > | my email archive doesn't go that far into the past (I guess that issue > > > | was debated around 2002 or earlier). > > > | > > > | The point is that we are talking about the files which contain only > > > | width/height data (=metrics information) for each glphy and _no_ bitmap > > > | or outline data (the PMF files are pretty small - if they would contain > > > | bitmaps rasterizes at 2560DPI you would see GIANT files). The font data > > > | itself, e.g. outlines or bitmaps are copyrightable but the width and > > > | height information does not fall into the category - it would be silly > > > | as everyone who would want to write an application which generates > > > | Postscript code would need an explicit license from Adobe. _If_ Adobe > > > | would have copyrighted the metrics information no opensource application > > > | (Mozilla, Ghostscript, Openoffice, JAVA, etc.) would be able to use one > > > | of the 30 default Postscript fonts defined by Postscript Level 2 as > > > | there would be no way to measure&layout the glyphs (the same applies to > > > | applications which generate PDF files). For example Mozilla ships the > > > | same information stored in the PMF files as part of it's Postscript > > > | print module (see > > > | http://lxr.mozilla.org/mozilla/source/gfx/src/ps/Courier-Bold.h , note > > > | that this source code is under MPL(=Mozilla Public License), the PMF > > > | files in the XOrg tree were donated by HP and Sun under the MIT license) > > > | and noone complained about that since many years (the same data were > > > | used in Netscape 4.x, too). > > > > > > Ok. I think you conviced me. I want to wait for Branden's opinion too > > > since he was the one creating these copyright notes and scripts for > > > removal of these files in the first place. > > > > OK. > > I'd appreciate some precise references, please. I don't remember this > issue being discussed on debian-x. > > Your reasoning seems to be grounded on a couple of problematic premises: > * That font metric information isn't copyrightable. This may be true in > the United States, but one of the big reasons Debian still has a non-free > section is because Adobe in Japan asserts copyright over just this sort > of thing. Again, this does not cover the PMF files. The original files have been commited by Hewlett-Packard under the MIT/X Consortium license many many years ago (and the files for the Postscript DDX were later refreshed by me to fix a minor bug - and I committed them under the same license: MIT/X.org). The so-called "copyright" notice in these files is just an attribute which informs the application that the attribute "COPYRIGHT" has a value. But this value does not relicense the file itself away from the MIT/X.org license. That would be the same as "relicesing" this email just because it references the string. References or index data of this kind cannot be copyrighted, neither in the US nor in Japan nor elsewhere in the world. > I will try to find this discussion in Debian's list archives > if you're interested. Sure. It may be possible that Adobe Japan did some tricky stuff with CID fonts, but again this doesn't apply to something which has been explicitly commited under the MIT/X.org license by the authors. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From mblinn at peopleplaces.org Fri Oct 8 15:12:03 2004 From: mblinn at peopleplaces.org (Michael Blinn) Date: Sat Oct 9 16:41:17 2004 Subject: [Xprint] HTML to PostScript to PDF Message-ID: <017a01c4ad62$4fe7ad40$0ea8a8c0@peopleplaces.org> New to the list but didn't see much like this in the archives; probably because I'm asking the wrong list. Odd question - I'm trying to on-the-fly convert server-side HTML to a PostScript or (preferably) PDF. - Something as simple as html2ps doesn't work for me because I need to support CSS. Someone suggested scripting Gecko to render PS and my research into this method led me to Xprint, though I am not in an X11 environment. As I'm writing this I feel as I'm in the wrong place ;) Any ideas? I wouldn't be adverse to writing a C interface if that is what is necessary. Anyone point me in the right place? Cheers, Michael Blinn -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mozdev.org/pipermail/xprint/attachments/20041008/97b0d366/attachment.htm From Matthew.Hooper at flinders.edu.au Mon Oct 11 10:30:26 2004 From: Matthew.Hooper at flinders.edu.au (Matthew Hooper) Date: Sun Oct 10 20:20:17 2004 Subject: [Xprint] HTML to PostScript to PDF In-Reply-To: <017a01c4ad62$4fe7ad40$0ea8a8c0@peopleplaces.org> References: <017a01c4ad62$4fe7ad40$0ea8a8c0@peopleplaces.org> Message-ID: <4169CD1A.6090405@flinders.edu.au> Probably the easiest way would be to use PHP with the PDF functions enabled, and just pass the URL as a parameter to the script in the URL, so that the script opens the URL and reads it like a file including all your CSS, and then creates a PDF document based on the URL. Hope this helps, Matt. Michael Blinn wrote: > New to the list but didn't see much like this in the archives; > probably because I'm asking the wrong list. > > Odd question - I'm trying to on-the-fly convert server-side HTML to a > PostScript or (preferably) PDF. - Something as simple as html2ps > doesn't work for me because I need to support CSS. Someone suggested > scripting Gecko to render PS and my research into this method led me > to Xprint, though I am not in an X11 environment. As I'm writing this > I feel as I'm in the wrong place ;) Any ideas? > > I wouldn't be adverse to writing a C interface if that is what is > necessary. Anyone point me in the right place? > > Cheers, > Michael Blinn > >------------------------------------------------------------------------ > >_______________________________________________ >Xprint mailing list >Xprint@mozdev.org >http://mozdev.org/mailman/listinfo/xprint > > -- Matthew Hooper Library Systems Officer Flinders University Library G.P.O. Box 2100 ADELAIDE, South Australia 5001 t +618 8201 2068 f +618 8201 2508 http://www.lib.flinders.edu.au/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mozdev.org/pipermail/xprint/attachments/20041011/7b44fa71/attachment.htm From felix.schulte at gmail.com Mon Oct 11 12:35:05 2004 From: felix.schulte at gmail.com (Felix Schulte) Date: Mon Oct 11 05:54:19 2004 Subject: [Xprint] Adding Xprint to LSB Message-ID: <74f15d5f04101102355e78d60c@mail.gmail.com> While browsing http://www.linuxbase.org/spec//booksets/LSB-Graphics/LSB-Graphics/set1.html + http://refspecs.freestandards.org/LSB_2.0.0/LSB-Graphics/LSB-Graphics/generic-graphics.html I realised that the Xprint extension API is missing/omitted, leaving the whole printing side of X11 unspecified by the LSB. Tier1 (java, Mozilla, ...) and legacy applications (Motif) depend on the Xprint extension library and therefore I see a demand in adding this to the LSB specs. Any comments, opinions on this? Thanks... Felix Schulte From fabbione at debian.org Mon Oct 11 10:02:45 2004 From: fabbione at debian.org (Fabio Massimo Di Nitto) Date: Mon Oct 11 06:23:17 2004 Subject: PMF license / was: Re: [Xprint] Re: X Strike Force XOrg SVN commit: r19 -inxorg/trunk/debian: . scripts In-Reply-To: <41679466.B52AF08@nrubsig.org> References: <20041002204713.7392C5C005@necrotic.deadbeast.net> <415F35E9.9F902F5A@nrubsig.org> <415F7CED.6060302@fabbione.net> <415F8AE0.413298F7@nrubsig.org> <415F8D09.7000909@fabbione.net> <415F91BE.8D09A092@nrubsig.org> <20041009060745.GS19131@redwald.deadbeast.net> <41679466.B52AF08@nrubsig.org> Message-ID: <416A3015.7070704@debian.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roland Mainz wrote: | Again, this does not cover the PMF files. The original files have been | commited by Hewlett-Packard under the MIT/X Consortium license many many | years ago (and the files for the Postscript DDX were later refreshed by | me to fix a minor bug - and I committed them under the same license: | MIT/X.org). The so-called "copyright" notice in these files is just an | attribute which informs the application that the attribute "COPYRIGHT" | has a value. But this value does not relicense the file itself away from | the MIT/X.org license. That would be the same as "relicesing" this email | just because it references the string. References or index data of this | kind cannot be copyrighted, neither in the US nor in Japan nor elsewhere | in the world. | | |>I will try to find this discussion in Debian's list archives |>if you're interested. | | | Sure. It may be possible that Adobe Japan did some tricky stuff with CID | fonts, but again this doesn't apply to something which has been | explicitly commited under the MIT/X.org license by the authors. Since the xprint-org package is anyway maintained outside the xfree86 tree AND considering that the whole purpose of these new X.org packages is to split the tree as much as possible, I suggest that we can just stop shipping the xprint code from x.org tree, since there is absolutely no point in shipping it twice and maintaing it twice. I am pretty sure that the knowledge that Drew has on this package is far more deep than the one I have (possibly of other XSF maintainers). Meaning that his package is imho better qualified to stay where it is. Also resolving the issue of shipping two conflicting packages that are supposed to provide and do the same thing. Merging/re-building the package again from X.org means extra work needs to be done/redone/reviewed/etc. If nobody disagree with me i will start removing it within the next 2 or 3 days. Fabio - -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBajAShCzbekR3nhgRAuJgAJ4rdrxPpJoQDWZA3ru4sF+McZHaDACfVGxX Zv5g5OK+fMRDpe9MRaR8X9U= =do20 -----END PGP SIGNATURE----- From dfp110 at rsphysse.anu.edu.au Mon Oct 11 18:30:41 2004 From: dfp110 at rsphysse.anu.edu.au (Drew Parsons) Date: Mon Oct 11 06:23:18 2004 Subject: PMF license / was: Re: [Xprint] Re: X Strike Force XOrg SVN commit: r19 -inxorg/trunk/debian: . scripts In-Reply-To: <416A3015.7070704@debian.org> References: <20041002204713.7392C5C005@necrotic.deadbeast.net> <415F35E9.9F902F5A@nrubsig.org> <415F7CED.6060302@fabbione.net> <415F8AE0.413298F7@nrubsig.org> <415F8D09.7000909@fabbione.net> <415F91BE.8D09A092@nrubsig.org> <20041009060745.GS19131@redwald.deadbeast.net> <41679466.B52AF08@nrubsig.org> <416A3015.7070704@debian.org> Message-ID: <4602.150.203.177.114.1097479841.squirrel@rsphyweb.anu.edu.au> > > Since the xprint-org package is anyway maintained outside the xfree86 > tree AND considering that the whole purpose of these new X.org packages > is to split the tree as much as possible, I suggest that we can just > stop shipping the xprint code from x.org tree, since there is > absolutely no point in shipping it twice and maintaing it twice. ... > If nobody disagree with me i will start removing it within the next 2 > or 3 days. > I've got no particular problems with this, but give it a week or so to let Roland or anyone else raise any objections. The only reason we'd want to X.Org's xprt is if it's perceived as a kind of "stable" version, where the xprint.[mozdev.]org version would be the "bleeding edge" version. But on the other hand, I've been careful in general to only upload the official ("stable") versions from xprint.mozdev.org into debian, not the development versions, so this would be a false perception, really. The official versions from xprint.mozdev.org should, by definition as it were, be superior (if not identical) to the latest one in X.org. I think if we'll agree to remove xprt (X.org) altogether, then it would make best sense to rename my version as xprt, and turn xprt-xprintorg into a dummy package which depends on the new xprt. Drew From fabbione at debian.org Mon Oct 11 10:41:34 2004 From: fabbione at debian.org (Fabio Massimo Di Nitto) Date: Mon Oct 11 06:23:18 2004 Subject: PMF license / was: Re: [Xprint] Re: X Strike Force XOrg SVN commit: r19 -inxorg/trunk/debian: . scripts In-Reply-To: <4602.150.203.177.114.1097479841.squirrel@rsphyweb.anu.edu.au> References: <20041002204713.7392C5C005@necrotic.deadbeast.net> <415F35E9.9F902F5A@nrubsig.org> <415F7CED.6060302@fabbione.net> <415F8AE0.413298F7@nrubsig.org> <415F8D09.7000909@fabbione.net> <415F91BE.8D09A092@nrubsig.org> <20041009060745.GS19131@redwald.deadbeast.net> <41679466.B52AF08@nrubsig.org> <416A3015.7070704@debian.org> <4602.150.203.177.114.1097479841.squirrel@rsphyweb.anu.edu.au> Message-ID: <416A392E.1000303@debian.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Drew Parsons wrote: |>Since the xprint-org package is anyway maintained outside the xfree86 |>tree AND considering that the whole purpose of these new X.org packages |>is to split the tree as much as possible, I suggest that we can just |>stop shipping the xprint code from x.org tree, since there is |>absolutely no point in shipping it twice and maintaing it twice. | | ... | |>If nobody disagree with me i will start removing it within the next 2 |>or 3 days. |> | | | I've got no particular problems with this, but give it a week or so to let | Roland or anyone else raise any objections. Sure, I have no objections. | I think if we'll agree to remove xprt (X.org) altogether, then it would | make best sense to rename my version as xprt, and turn xprt-xprintorg into | a dummy package which depends on the new xprt. Yes, i agree and i have no objections here either. Fabio - -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBajkrhCzbekR3nhgRAmtHAJ0UgfF3oiooB9PiSD81XopstJ3IyQCgoNj2 NxyFr9geG4O9SNFJo2K4Id0= =QfJ2 -----END PGP SIGNATURE----- From jstumpel at planet.nl Mon Oct 11 21:33:48 2004 From: jstumpel at planet.nl (Jan Willem Stumpel) Date: Mon Oct 11 14:53:01 2004 Subject: [Xprint] Monospaced font in Thunderbird/Mozilla mail (episode 2) In-Reply-To: <414D5ABD.2040809@my.home> References: <414D5ABD.2040809@my.home> Message-ID: <416AD20C.8080709@my.home> In my message of September 19th I wrote: > It seems that the file userContent.css can also be used to > obtain monospaced printout of mail messages from Mozilla and > derivatives, making the print preview agree with the actual > printout. > > Inside the @media print selector you just add > > .moz-text-plain { font-family: 'Courier New',courier,monospace > !important; } But this is not /quite/ the solution yet. At least not with the Debian version of xprint which I have now: ii xprt-common 0.0.9.final.001-6 ii xprt-xprintorg 0.0.9.final.001-6 I get a monospaced, Courier-like print-out alright (and I also get other UTF-8 characters, like Japanese characters), but the problem is that some accented *Western* letters do not get printed at all. E.g. ????? is printed as ???. No more ?, ?. And the ?, ?, and ? are printed somewhat bold, unlike the un-accented letters. This is in a UTF-8 locale. Question 1: can anyone confirm/reproduce this? (NOTE: this should be tested with the userContent.css modification. If userContent.css does not contain the .moz-text-plain entry, all accented letters are printed OK -- but in a proportional font, and the whole object of the exercise was to get monospaced print-out). From perusal of mozilla.ps (when I choose to "print to file")?? it appears that that the "normal" letters are printed in a font called /CourierNewPSMT_iso8859-7 (why iso8859-7 is used is a mystery in itself), while accented letters (in so far as they are printed at all) are printed using /Courier10PitchBT-Roman_iso8859-1. So even the above entry in the userConfig.css has not quite succeeded in taming xprint's errant font selection mechanism. After some experiments I found that things improve when you specify a font (in userContent.css) which makes it impossible for xprint to confuse Courier New with any of the other Couriers around. E.g. the following both work (restore printing of ?, ?, and leave accented letters in the same font as non-accented ones): .moz-text-plain { font-family: 'Bitstream Vera Sans Mono' !important; } and .moz-text-plain { font-family: 'FreeMono' !important; } (of course, you must have the mentioned fonts installed). Question 2: can anyone confirm/reproduce *this*? A last point: it seems that the latest versions of xprint no longer contain .pfm files in /usr/share/Xprint/xserver/C/print/models/PSdefault/fonts (so it is no longer necessary to remove them, in order to have headers & footers printed properly). Was this an intended change, as far as anyone knows? Regards, Jan From dfp110 at rsphysse.anu.edu.au Tue Oct 12 11:22:19 2004 From: dfp110 at rsphysse.anu.edu.au (Drew Parsons) Date: Mon Oct 11 20:41:40 2004 Subject: [Xprint] Re: Monospaced font in Thunderbird/Mozilla mail (episode 2) In-Reply-To: <200410111433.57622.jgoerzen@complete.org> References: <20041008091443.GA2295@mars.ephaone.org> <20041008151851.GA19749@mars.ephaone.org> <20041008151956.GS16153@parcelfarce.linux.theplanet.co.uk> <200410111433.57622.jgoerzen@complete.org> Message-ID: <4962.150.203.177.114.1097540539.squirrel@rsphyweb.anu.edu.au> > In my message of September 19th I wrote: > > > So even the above entry in the userConfig.css has not quite > succeeded in taming xprint's errant font selection mechanism. You'll be glad to hear upstream is now on to the problem. Incidentally, he reports the bug is in fact in mozilla, not in Xprint. He's heavily involved with mozilla's development as far as Xprint goes, so I'm confident of a "proper" solution before too long. > > A last point: it seems that the latest versions of xprint no > longer contain .pfm files in > > /usr/share/Xprint/xserver/C/print/models/PSdefault/fonts > > (so it is no longer necessary to remove them, in order to have > headers & footers printed properly). Was this an intended change, > as far as anyone knows? > Hmm, -6 should be no different to -5. The only change is a comment in the docs saying you might find it helpful to remove the directory yourself, but I haven't otherwise removed it or the fonts. Purging xprt-common to remove it utterly, then reinstalling, might be worth trying. Again, upstream says the fonts should stay, the bug is mainly in mozilla and will be fixed there. Drew From roland.mainz at nrubsig.org Wed Oct 13 02:00:12 2004 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Wed Oct 13 07:58:24 2004 Subject: Keeping the Debian Xprint sources seperate from the Debian Xorg sources ? / was: Re: PMF license / was: Re: [Xprint] Re: X Strike Force XOrg SVN commit: r19 -inxorg/trunk/debian: . scripts References: <20041002204713.7392C5C005@necrotic.deadbeast.net> <415F35E9.9F902F5A@nrubsig.org> <415F7CED.6060302@fabbione.net> <415F8AE0.413298F7@nrubsig.org> <415F8D09.7000909@fabbione.net> <415F91BE.8D09A092@nrubsig.org> <20041009060745.GS19131@redwald.deadbeast.net> <41679466.B52AF08@nrubsig.org> <416A3015.7070704@debian.org> Message-ID: <416C61FC.B1A6E19B@nrubsig.org> Felix Schulte wrote: [snip] > > Since the xprint-org package is anyway maintained outside the xfree86 > > tree AND considering that the whole purpose of these new X.org packages > > is to split the tree as much as possible, I suggest that we can just > > stop shipping the xprint code from x.org tree, since there is absolutely > > no point in shipping it twice and maintaing it twice. > Urgh. > The X.org tree and the xprint-org are now coming from the same CVS > repository as annouced on the xprint.mozdev.org front page. However I > assume that both will continue to have different functionality, X.org > version being the normal version, xprint-org being the development > version or something like that. > > Fabio: What about making Drew Parsons the maintainer of both versions > just for the case that you can't handle it? :) One version may be less confusing. Unless urgend bugfixing happened the "normal" release cycles between two major Xprint releases was more or less six months - the same amount of time Xorg is planning for their major version release cycle. But I agree... it sounds a nice idea to make Drew Parsons the maintainer of the Debian Xorg Xprint server package if he wants to do that (and Fabio and Branden agree with that). Maintaining the Xprint server as seperate package may or may not be slightly more difficult as it now supports the GLX extension (=OpenGL) which added more or less the whole Mesa codebase to the source. Having more than one person looking at the Mesa code may help a lot and lower the pain (at the beginning Drew had to work hard to get the Xprint server working on all platforms Debian supports and doing the same in two locations (Mesa in the Debian/Xorg tree and Mesa in the Debian/Xorg-Xprint) is twice the work where it wouldn't be neccesary) for Drew... :) > > I am pretty sure that the knowledge that Drew has on this package is far > > more deep than the one I have (possibly of other XSF maintainers). > > Meaning that his package is imho better qualified to stay where it is. > > Also resolving the issue of shipping two conflicting packages that are > > supposed to provide and do the same thing. > > Merging/re-building the package again from X.org means extra work needs > > to be done/redone/reviewed/etc. > > > > If nobody disagree with me i will start removing it within the next 2 or > > 3 days. > I disagree :) I disagree, too. See my comments above. ---- Bye, Roland P.S.: Please keep the Xprint mailinglist in the CC: that other people get the emails, too - not everyone is subscribed to the debian-x lists... -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From mats.d.wichmann at intel.com Tue Oct 12 14:43:35 2004 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Wed Oct 13 08:07:18 2004 Subject: [Xprint] FW: Adding Xprint to LSB Message-ID: Forwarded from private email. [ note to Felix and the xprint list: lsb-futures is where we track new features, please send further info to that list -- mats ] Original message: While browsing http://www.linuxbase.org/spec//booksets/LSB-Graphics/LSB-Graphics/set1.h tml + http://refspecs.freestandards.org/LSB_2.0.0/LSB-Graphics/LSB-Graphics/ge neric-graphics.html I realised that the Xprint extension API is missing/omitted, leaving the whole printing side of X11 unspecified by the LSB. Tier1 (java, Mozilla, ...) and legacy applications (Motif) depend on the Xprint extension library and therefore I see a demand in adding this to the LSB specs. Any comments, opinions on this? Added comment from Stuart: I think there is even a spec already in place. Still need tests. There is some debate over wether it is really best practice or not. From roland.mainz at nrubsig.org Wed Oct 13 02:00:26 2004 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Wed Oct 13 08:18:53 2004 Subject: [Xprint] Re: x.org packages roadmap ? References: <20041012210343.GS19131@redwald.deadbeast.net> Message-ID: <416C620A.A14A3296@nrubsig.org> Branden Robinson wrote: > > On Sun, Sep 12, 2004 at 12:10:10AM +0000, ROBERTOJIMENOCA wrote: > > I saw this post on slashdot.org: > > http://developers.slashdot.org/comments.pl?sid=121015&cid=10187780 > > This isn't funny. > > > > Do you have any roadmap to have x.org Debian packages? > > How may I help? > > You may be interested in the latest addition to the Debian X FAQ. > > What are Debian's plans with respect to X.Org and XFree86? > > Thanks to Fabio Massimo Di Nitto for contributing much of this entry. [snip] > While moving from XFree86's monolithic tree to X.Org's is a relatively > simple technical transition of itself, the transition to a > fully-modularized set of packages will take longer ??? indeed, an unknown > amount of time which depends on the speed of upstream's progress ??? but we > expect the process will bring the packages' quality to a higher level, > thanks to the introduction of a fast release cycle for each single > component. We expect to "modularize" two parts of the X.Org distribution > immediately: XTerm and Xprt (the XPRINT server). Both of these are > independently maintained by entities external to (but working in > cooperation with) freedesktop.org. Uhm... correction: Xprint is part of the Xorg release, starting with X11R6.8.0 both trees are identical (before that Xprint was already part of X11 (since X11R6.4) but the plain X.org version was pretty much unuseable since the single vendors worked on their own implementations without contributing patches back). Xprint is no longer "externally" maintained. Just the documentation and mailinglist is still hosted at mozdev.org since too many links point to that site and we didn't had time to fight with Wiki (which seems to be mandatory for the freedesktop.org site... ;-/) ... ---- Bye, Roland P.S.: Please keep the Xprint mailinglist in the CC: that other people get the emails, too - not everyone is subscribed to the debian-x lists... -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) From jstumpel at planet.nl Tue Oct 12 20:11:07 2004 From: jstumpel at planet.nl (Jan Willem Stumpel) Date: Wed Oct 13 10:24:28 2004 Subject: [Xprint] GISWxprint-sparc-2004-07-07-release_009_001 Prints too large In-Reply-To: <4160FFCE.3060309@altkom.pl> References: <41608112.6080805@sbcglobal.net> <9e76f7fe041003161313596faa@mail.gmail.com> <4160FFCE.3060309@altkom.pl> Message-ID: <416C102B.3040209@my.home> Aleksander Adamowski wrote: > This problem will return again and again regardless of the FAQ, > because most users will never even know the existence of the > FAQ (especially when Xprint starts to be shipped with Linux > distros by default). Well, yes, xprint's documentation is bad and also not easy to find. But I've always wondered why this problem has to occur at all. xprint generates PostScript, doesn't it? PostScript is a universal language which is understood by all printers on Linux systems, either natively or through ghostscript. And according to what little I know about PostScript, there are commands like moveto, scalefont, etc., which refer to sizes and distances in absolute measures (like centimeters or typographical points) and not to printer-specific "pixels" at all. Why can't xprint use these exclusively? If it did, characters printed at 12 point size would be 12 points, whatever printer happened to be used. Enlightenment on this would be much appreciated. Regards, Jan. From branden at debian.org Fri Oct 15 15:06:10 2004 From: branden at debian.org (Branden Robinson) Date: Fri Oct 15 15:46:12 2004 Subject: [Xprint] Re: x.org packages roadmap ? In-Reply-To: <416C620A.A14A3296@nrubsig.org> References: <20041012210343.GS19131@redwald.deadbeast.net> <416C620A.A14A3296@nrubsig.org> Message-ID: <20041015190610.GW27607@redwald.deadbeast.net> On Wed, Oct 13, 2004 at 01:00:26AM +0200, Roland Mainz wrote: > Uhm... correction: Xprint is part of the Xorg release, starting with > X11R6.8.0 both trees are identical (before that Xprint was already part > of X11 (since X11R6.4) but the plain X.org version was pretty much > unuseable since the single vendors worked on their own implementations > without contributing patches back). > Xprint is no longer "externally" maintained. Just the documentation and > mailinglist is still hosted at mozdev.org since too many links point to > that site and we didn't had time to fight with Wiki (which seems to be > mandatory for the freedesktop.org site... ;-/) ... Ah. Fixed in revision 1955. Thanks! -- G. Branden Robinson | The more ridiculous a belief Debian GNU/Linux | system, the higher the probability branden@debian.org | of its success. http://people.debian.org/~branden/ | -- Wayne R. Bartz -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://mozdev.org/pipermail/xprint/attachments/20041015/4e965017/attachment.bin From roland.mainz at nrubsig.org Sun Oct 17 03:07:04 2004 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Sat Oct 16 20:26:13 2004 Subject: [Xprint] Unified video/print Xserver... Message-ID: <4171B7A8.F0CF9865@nrubsig.org> Hi! ---- We are currently investigating whether it's usefull to make an unified video+print Xserver (HP-UX has such a unified Xserver since a long time). Attached is a small patch which demonstrates how such a unified video/print server would look like... * Known bugs: - DAMAGE needs to be turned off (otherwise a SIGSEGV follows) - Spooling print jobs seems to be broken somehow, e.g. only print-to-file works - Xprint-specific options are not listed in the usage output * Known limitations (these limitations only apply when both vdeio and print screens are acive at the same time. If video and print server are seperate processes on seperate display ids then there is no problem...): - Xinerama won't be usefull (and won't work as the visuals of the print DDX are likely very different from the video DDX) unless Xinerama starts to support the combining of multiple physical screens to multiple logical screens - RENDER disables itself as the print DDX do not have the prerequirements (available depths etc.) and do not implement RENDER - RANDR is useless (unless there is a way to select only a single screen in RANDR, I didn't check that) * Usage (on SuSE Linux 8.2): 1. Checkout tree 2. Create xc/config/cf/host.def with the following lines: -- snip -- #define HasFreetype2 NO #undef OptimizedCDebugFlags #define OptimizedCDebugFlags -g -DDEBUG_$(LOGNAME) #define DoLoadableServer NO #define PrintOnlyServer NO #define BuildServersOnly YES -- snip -- 3. Apply the patch 4. % make World 2>&1 | tee -a buildlog.log 5. Run Xorg server with % (XPCONFIGDIR=/tmp/xptestinstall001/usr/X11R6/lib/X11/xserver gdb --args ./Xorg -dumbSched -dpms -audit 4 -pn -extension DAMAGE :2) # (you need a Xprint config in /tmp/xptestinstall001/usr/X11R6/lib/X11/xserver/). Comments/suggestions/etc. welcome... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) -------------- next part -------------- Index: xc/programs/Xserver/dix/main.c =================================================================== RCS file: /cvs/xorg/xc/programs/Xserver/dix/main.c,v retrieving revision 1.4 diff -u -2 -0 -r1.4 main.c --- xc/programs/Xserver/dix/main.c 18 Sep 2004 23:18:35 -0000 1.4 +++ xc/programs/Xserver/dix/main.c 16 Oct 2004 23:40:19 -0000 @@ -234,41 +234,46 @@ ~0, ~0, ~0, ~0, ~0, ~0, ~0, ~0, ~0, ~0, ~0, ~0, ~0, ~0, ~0, ~0, 3 /* 64 bits per scanline pad unit */ }; #ifndef MIN #define MIN(a,b) (((a) < (b)) ? (a) : (b)) #endif int main(int argc, char *argv[], char *envp[]) { int i, j, k, error; char *xauthfile; HWEventQueueType alwaysCheckForInput[2]; display = "0"; +#define UNIFIED_XPRINT_SERVER 1 InitGlobals(); +#ifdef UNIFIED_XPRINT_SERVER + XprintInitGlobals(); +#endif + /* Quartz support on Mac OS X requires that the Cocoa event loop be in * the main thread. This allows the X server main to be called again * from another thread. */ #if defined(__DARWIN__) && defined(DARWIN_WITH_QUARTZ) DarwinHandleGUI(argc, argv, envp); #endif /* Notice if we're restarted. Probably this is because we jumped through * an uninitialized pointer */ if (restart) FatalError("server restarted. Jumped through uninitialized pointer?\n"); else restart = 1; CheckUserParameters(argc, argv, envp); CheckUserAuthorization(); #ifdef COMMANDLINE_CHALLENGED_OPERATING_SYSTEMS From julien.lafon at gmail.com Wed Oct 20 08:48:33 2004 From: julien.lafon at gmail.com (Julien Lafon) Date: Wed Oct 20 02:07:34 2004 Subject: [Xprint] Unified video/print Xserver... In-Reply-To: <4171B7A8.F0CF9865@nrubsig.org> References: <4171B7A8.F0CF9865@nrubsig.org> Message-ID: On Sun, 17 Oct 2004 02:07:04 +0200, Roland Mainz wrote: > > Hi! > > ---- > > We are currently investigating whether it's usefull to make an unified > video+print Xserver (HP-UX has such a unified Xserver since a long > time). > > Attached is a small patch which demonstrates how such a unified > video/print server would look like... > > * Known bugs: > - DAMAGE needs to be turned off (otherwise a SIGSEGV follows) > - Spooling print jobs seems to be broken somehow, e.g. only > print-to-file works Maybe it is related to the following two messages I found in my system log: ./messages:Oct 19 08:11:21 minou kernel: request_module[char-major-10-134]: fork failed, errno 1 ./messages:Oct 19 08:11:21 minou kernel: request_module[char-major-81-0]: fork failed, errno 1 > - Xprint-specific options are not listed in the usage output > > * Known limitations (these limitations only apply when both vdeio and > print screens are acive at the same time. If video and print server are > seperate processes on seperate display ids then there is no problem...): > - Xinerama won't be usefull (and won't work as the visuals of the print > DDX are likely very different from the video DDX) unless Xinerama starts > to support the combining of multiple physical screens to multiple > logical screens Did you file a bug against Xinerama into the fdo bugzilla yet? > - RENDER disables itself as the print DDX do not have the > prerequirements (available depths etc.) and do not implement RENDER > - RANDR is useless (unless there is a way to select only a single screen > in RANDR, I didn't check that) What about implementing RANDR support for Xprt that users can change the geometry of the print screens on the fly? > > * Usage (on SuSE Linux 8.2): > 1. Checkout tree > 2. Create xc/config/cf/host.def with the following lines: > -- snip -- > #define HasFreetype2 NO > #undef OptimizedCDebugFlags > #define OptimizedCDebugFlags -g -DDEBUG_$(LOGNAME) > > #define DoLoadableServer NO > #define PrintOnlyServer NO > > #define BuildServersOnly YES > -- snip -- > 3. Apply the patch > 4. % make World 2>&1 | tee -a buildlog.log > 5. Run Xorg server with > % (XPCONFIGDIR=/tmp/xptestinstall001/usr/X11R6/lib/X11/xserver gdb > --args ./Xorg -dumbSched -dpms -audit 4 -pn -extension DAMAGE :2) # (you > need a Xprint config in > /tmp/xptestinstall001/usr/X11R6/lib/X11/xserver/). > > Comments/suggestions/etc. welcome... Roland: Three words: This is wicked! :) Do you intend to work on that in te near future or is that something for later? -- Julien Lafon Consultant Software Engineer From julien.lafon at gmail.com Wed Oct 20 09:13:08 2004 From: julien.lafon at gmail.com (Julien Lafon) Date: Wed Oct 20 02:32:08 2004 Subject: [Xprint] GISWxprint-sparc-2004-07-07-release_009_001 Prints too large In-Reply-To: <416C102B.3040209@my.home> References: <41608112.6080805@sbcglobal.net> <9e76f7fe041003161313596faa@mail.gmail.com> <4160FFCE.3060309@altkom.pl> <416C102B.3040209@my.home> Message-ID: On Tue, 12 Oct 2004 19:11:07 +0200, Jan Willem Stumpel wrote: > Why can't xprint use > these exclusively? If it did, characters printed at 12 point size > would be 12 points, whatever printer happened to be used. > Enlightenment on this would be much appreciated. I just checked this on our HP box: The Postscript driver in HP/UX does not show this issue, this problem is limited to the mozdev.org/XOrg versions. Its likely a driver bug then unless HP/UX has something smart in the print spooler which scales nonfitting print jobs to match the paper size. btw: You may be interested in https://bugzilla.mozilla.org/show_bug.cgi?id=262287 which will help avoiding this kind of problem in the future. -- Julien Lafon Consultant Software Engineer From julien.lafon at gmail.com Wed Oct 20 09:24:44 2004 From: julien.lafon at gmail.com (Julien Lafon) Date: Wed Oct 20 02:43:43 2004 Subject: [Xprint] FW: Adding Xprint to LSB In-Reply-To: References: Message-ID: On Tue, 12 Oct 2004 13:43:35 -0700, Wichmann, Mats D wrote: > > Forwarded from private email. > > [ note to Felix and the xprint list: lsb-futures is where we > track new features, please send further info to that list -- mats ] > > Original message: > > While browsing > http://www.linuxbase.org/spec//booksets/LSB-Graphics/LSB-Graphics/set1.h > tml > + > http://refspecs.freestandards.org/LSB_2.0.0/LSB-Graphics/LSB-Graphics/ge > neric-graphics.html > I realised that the Xprint extension API is missing/omitted, leaving > the whole printing side of X11 unspecified by the LSB. Tier1 (java, > Mozilla, ...) and legacy applications (Motif) depend on the Xprint > extension library and therefore I see a demand in adding this to the > LSB specs. > Any comments, opinions on this? I like the idea and I think we are very interested in supporting an addition of Xprint to the LSB graphics specification. What are the steps to begin with the standardisation process? > Added comment from Stuart: > > I think there is even a spec already in place. Still > need tests. > > There is some debate over wether it is really best practice or not. What does Stuart mean with `it' in this case? -- Julien Lafon Consultant Software Engineer From anderson at freestandards.org Wed Oct 20 09:30:16 2004 From: anderson at freestandards.org (anderson@freestandards.org) Date: Wed Oct 20 13:24:32 2004 Subject: [Xprint] FW: Adding Xprint to LSB In-Reply-To: References: Message-ID: On Wed, 20 Oct 2004, Julien Lafon wrote: > > Added comment from Stuart: > > > > I think there is even a spec already in place. Still > > need tests. > > > > There is some debate over wether it is really best practice or not. > What does Stuart mean with `it' in this case? 'It' is refering to Xprint. I was raising the question as to wether Xprint is really used as the de facto printing model everywhere. I know a couple of things like Mozilla use it, but I'm not sure if the majority of the desktop applications are using it or not. Ideally, what the LSB would like to adopt is the one de facto printing model that is used by just about everything, wether that is Xprint or not. First thing to do, is to decide if such a thing like this even exists yet. Xprint also has the characteristic that it is a part of the X Window System, and as such could be brought into the Desktop module anyway. Stuart anderson@freestandards.org Free Standards Group Lead Developer, Written Specification Linux Standard Base 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149 From aleksander.adamowski at altkom.pl Wed Oct 20 15:36:10 2004 From: aleksander.adamowski at altkom.pl (Aleksander Adamowski) Date: Wed Oct 20 13:24:33 2004 Subject: [Xprint] GISWxprint-sparc-2004-07-07-release_009_001 Prints too large In-Reply-To: <416C102B.3040209@my.home> References: <41608112.6080805@sbcglobal.net> <9e76f7fe041003161313596faa@mail.gmail.com> <4160FFCE.3060309@altkom.pl> <416C102B.3040209@my.home> Message-ID: <41765BBA.5020000@altkom.pl> Jan Willem Stumpel wrote: >But I've always wondered why this problem has to occur at >all. xprint generates PostScript, doesn't it? PostScript is a >universal language which is understood by all printers on Linux >systems, either natively or through ghostscript. And according to >what little I know about PostScript, there are commands like >moveto, scalefont, etc., which refer to sizes and distances in >absolute measures (like centimeters or typographical points) and >not to printer-specific "pixels" at all. Why can't xprint use >these exclusively? If it did, characters printed at 12 point size >would be 12 points, whatever printer happened to be used. > > Yet still XPrint requires some information about printers (resolution among others) for some reasons. And I see it strange that XPrint is so much about generating standard Postscript and sending it to a printer, but it understands only a non-standard printer model description format, while a standard, Postscript-based (PPD) format is available and widely used. Many printer vendors publish PPDs for their devices. And the currently most popular printing system (CUPS) makes that PPD printer model data easily available. So lack of PPD support in XPrint looks strange, you'd think that XPrint would be one of the first candidates to support that standard. -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.ab.altkom.pl From ted at cypress.com Wed Oct 20 14:52:13 2004 From: ted at cypress.com (Thomas Dodd) Date: Wed Oct 20 15:12:24 2004 Subject: [Xprint] FW: Adding Xprint to LSB In-Reply-To: References: Message-ID: <4176B3DD.7010003@cypress.com> anderson@freestandards.org wrote: > I was raising the question as to wether Xprint is really used as the de facto > printing model everywhere. I know a couple of things like Mozilla use it, > but I'm not sure if the majority of the desktop applications are using it > or not. > > Ideally, what the LSB would like to adopt is the one de facto printing > model that is used by just about everything, wether that is Xprint or > not. First thing to do, is to decide if such a thing like this even > exists yet. There really is no defacto standard. Everyone does it their own way it seams. At least all the big apps do it their own way. KDE/QT apps have access to a library that is similar to xprint. for printer setup and for the drawing commands. GNOME has a print library, but it basicall a postscript interface to the developer. It can create output other than postscript, including a preview, but the API is still postscript-like. Xprint would be great, if it supported better font management systems now common. Support for PPD configuration would be nice. A configuration sialog like KDEprint and CUPS, with resolution, plex, page, and such is needed too, but probably better left to the desktop/library guys so it fits the uses setup. PPDs use would help there, so the same options and values are available to xprint and the dialogs. -Thomas From ted at cypress.com Wed Oct 20 14:57:42 2004 From: ted at cypress.com (Thomas Dodd) Date: Wed Oct 20 15:17:23 2004 Subject: [Xprint] GISWxprint-sparc-2004-07-07-release_009_001 Prints too large In-Reply-To: <41765BBA.5020000@altkom.pl> References: <41608112.6080805@sbcglobal.net> <9e76f7fe041003161313596faa@mail.gmail.com> <4160FFCE.3060309@altkom.pl> <416C102B.3040209@my.home> <41765BBA.5020000@altkom.pl> Message-ID: <4176B526.3060306@cypress.com> Aleksander Adamowski wrote: > Yet still XPrint requires some information about printers (resolution > among others) for some reasons. That's for converting X11 to the page. X is device independent and printing isn't. > And I see it strange that XPrint is so much about generating standard > Postscript and sending it to a printer, but it understands only a > non-standard printer model description format, while a standard, > Postscript-based (PPD) format is available and widely used. > Many printer vendors publish PPDs for their devices. When Xprint started PPD wasn't so big. And the configuration makes sense, and the syntax is standard Xdefaults style. Support for PPDs would be a nice addition though. -Thomas From aleksander.adamowski.xprint at altkom.pl Thu Oct 21 13:46:31 2004 From: aleksander.adamowski.xprint at altkom.pl (Aleksander Adamowski) Date: Thu Oct 21 07:06:02 2004 Subject: [Xprint] GISWxprint-sparc-2004-07-07-release_009_001 Prints too large In-Reply-To: <4176B526.3060306@cypress.com> References: <41608112.6080805@sbcglobal.net> <9e76f7fe041003161313596faa@mail.gmail.com> <4160FFCE.3060309@altkom.pl> <416C102B.3040209@my.home> <41765BBA.5020000@altkom.pl> <4176B526.3060306@cypress.com> Message-ID: <41779387.5010706@altkom.pl> Thomas Dodd wrote: > > When Xprint started PPD wasn't so big. And the configuration makes > sense, and the syntax is standard Xdefaults style. Well, yes, this starts to make sense when you conisder that this is rather X-side of things. > Support for PPDs would be a nice addition though. Exactly. Even more: it would solve lots of problems. The Xdefaults style model configs will probably never be properly maintained by anyone (Xprint packagers, printer vendors, end users...) They currently contain configs for only a miniscule amount of printers. Using them at all requires manual printer->model mapping on each client system. That mapping requires changes in a config file located in /usr. At the same time, PPD info is already there, reachable through the CUPS API, and it's always current. It is fully centralisable, that is, there can be a single organization-wide CUPS server, and all CUPS clients get the current PPD descriptors from that server along with printer lists. And the jobs will be submitted to that server's central spool. It's just so much a pity that Xprint cannot use all those easily accessible goodies... -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.ab.altkom.pl From ted at cypress.com Thu Oct 21 09:34:45 2004 From: ted at cypress.com (Thomas Dodd) Date: Thu Oct 21 09:54:29 2004 Subject: [Xprint] GISWxprint-sparc-2004-07-07-release_009_001 Prints too large In-Reply-To: <41779387.5010706@altkom.pl> References: <41608112.6080805@sbcglobal.net> <9e76f7fe041003161313596faa@mail.gmail.com> <4160FFCE.3060309@altkom.pl> <416C102B.3040209@my.home> <41765BBA.5020000@altkom.pl> <4176B526.3060306@cypress.com> <41779387.5010706@altkom.pl> Message-ID: <4177BAF5.5010405@cypress.com> Aleksander Adamowski wrote: > They currently contain configs for only a miniscule amount of printers. > Using them at all requires manual printer->model mapping on each client > system. > That mapping requires changes in a config file located in /usr. It is rather simple to use a config file from anywhere. My xprint is in $HOME now. On Solaris It used config files from $HOME while Xprt was from Sun in /usr. > At the same time, PPD info is already there, reachable through the CUPS > API, and it's always current. Xprint cannot use the CUPS API though. Not everyone uses cups. PPDs ar OK, but Xprint needs to read them directly, not through come random API that could be gone in a few years. A default and user location for the PPDs for Xprint (and anyone else) to read and use as needed. Xprint would be (is) a central server, not running on every machine if there is a central CUPS server in use. Everyone would use the same XPSERVERLIST setting. Is the a way for the CUPS clients to create a local copy of the PPDs it gets from the server? Currently Xprint is print spooler independent. Changing that would not be a wise choice. Some of us have no choice but to use other spoolers. -Thomas From aleksander.adamowski.xprint at altkom.pl Thu Oct 21 18:02:28 2004 From: aleksander.adamowski.xprint at altkom.pl (Aleksander Adamowski) Date: Thu Oct 21 11:21:58 2004 Subject: [Xprint] GISWxprint-sparc-2004-07-07-release_009_001 Prints too large In-Reply-To: <4177BAF5.5010405@cypress.com> References: <41608112.6080805@sbcglobal.net> <9e76f7fe041003161313596faa@mail.gmail.com> <4160FFCE.3060309@altkom.pl> <416C102B.3040209@my.home> <41765BBA.5020000@altkom.pl> <4176B526.3060306@cypress.com> <41779387.5010706@altkom.pl> <4177BAF5.5010405@cypress.com> Message-ID: <4177CF84.5000905@altkom.pl> Thomas Dodd wrote: >> At the same time, PPD info is already there, reachable through the >> CUPS API, and it's always current. > > > Xprint cannot use the CUPS API though. Not everyone uses cups. I'm not saying that model configs be replaced by PPD's form CUPS, I'm saying that they should work in parallel. Ideally, Xprint would be refactored so that various sources of printer model information are supported and coexist on one Xprint installation, with various priorities when it comes to overriding other ones' settings. E.g. a default installation of Xprint would use model configs, and if CUPS is detected, Xprint would read the PPD from the CUPS system using its API, and any CUPS PPD settings would override settings provided earlier by model-configs. Another sources of model info should be possible to implement as plug-ins, e.g. in future, one would possibly like to get model information from an LDAP directory. > PPDs ar OK, but Xprint needs to read them directly, not through come > random API that could be gone in a few years. Well, it seems that the CUPS API has been here for a couple of years and it isn't going away in a few years, especially since it now ships with all major Linux distributions, Apple MacOS, and works well on other *NIX-es. In fact, it is steadily replacing older spoolers everywhere. And why should Xprint server assume that some information necessarily has to be accessed thrhogh its local filesystem? What is the rationale behind setting such a limitation? In a large organisation, one may want to provide centralised configuration data over network through the LDAP protocol, or some other means, for example. > A default and user location for the PPDs for Xprint (and anyone else) > to read and use as needed. That's based on unnecessary assumption, that the information must come in the form of filesystem objects (files), available in the local filesystem tree. This quickly becomes unmaintainable in large environments (e.g. couple thousands of machines, distributed around a country or whole world, since it would require tunnelling NFS over some VPNs, etc...). > Xprint would be (is) a central server, not running on every machine if > there is a central CUPS server in use. That's fine, but it adds unnecessary additional work for the admins, who have to configure each printer twice: once for CUPS server, once for Xprint server. And this could be avoided, if only Xprint could get model configuration from CUPS. > Everyone would use the same XPSERVERLIST setting. Is the a way for the > CUPS clients to create a local copy of the PPDs it gets from the server? > > Currently Xprint is print spooler independent. Changing that would not > be a wise choice. Some of us have no choice but to use other spoolers. > Well, it supports CUPS as a spooler currently. I think Xprint can be modified to get the model information from CUPS if available, yet still work as previously will all the other spoolers? -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.ab.altkom.pl From ted at cypress.com Thu Oct 21 11:31:28 2004 From: ted at cypress.com (Thomas Dodd) Date: Thu Oct 21 11:51:10 2004 Subject: [Xprint] GISWxprint-sparc-2004-07-07-release_009_001 Prints too large In-Reply-To: <4177CF84.5000905@altkom.pl> References: <41608112.6080805@sbcglobal.net> <9e76f7fe041003161313596faa@mail.gmail.com> <4160FFCE.3060309@altkom.pl> <416C102B.3040209@my.home> <41765BBA.5020000@altkom.pl> <4176B526.3060306@cypress.com> <41779387.5010706@altkom.pl> <4177BAF5.5010405@cypress.com> <4177CF84.5000905@altkom.pl> Message-ID: <4177D650.7030802@cypress.com> Aleksander Adamowski wrote: > I'm not saying that model configs be replaced by PPD's form CUPS, I'm > saying that they should work in parallel. Ideally, Xprint would be > refactored so that various sources of printer model information are > supported and coexist on one Xprint installation, with various > priorities when it comes to overriding other ones' settings. > > E.g. a default installation of Xprint would use model configs, and if > CUPS is detected, Xprint would read the PPD from the CUPS system using > its API, and any CUPS PPD settings would override settings provided > earlier by model-configs. So if I use LPRng and want xprint to use PPDs? Write another config option so Xprint can get the PPDs from a directory? >> PPDs ar OK, but Xprint needs to read them directly, not through come >> random API that could be gone in a few years. > > > > Well, it seems that the CUPS API has been here for a couple of years and > it isn't going away in a few years, especially since it now ships with > all major Linux distributions, Apple MacOS, and works well on other > *NIX-es. > In fact, it is steadily replacing older spoolers everywhere. Slowly. And 3 years ago people said LPD wouldn't be replaced. Something will happen and CUPS will no longer be the hot spooler. It could be next year, or it could be 5 years. I just don't think that API should be used when other, long term methods are available instead. > That's based on unnecessary assumption, that the information must come > in the form of filesystem objects (files), available in the local > filesystem tree. This quickly becomes unmaintainable in large > environments (e.g. couple thousands of machines, distributed around a > country or whole world, since it would require tunnelling NFS over some > VPNs, etc...). That's Unix. Everything is a file. It doesn't have to be local, it could be NFS, SMB, or som other networked filesystem easily. It the a simple way to get info from CUPS, and LDAP, and NIS, using file commands? There is no reason for Xprint to know CUPS, LDAP, NIS, NFS, HTTP, ... when all could be abstracted to a file which is what Xprint needs. That a Windows/Microsoft mentality, all apps speak all protocols. Look at the problems caused but not abstraction these already. Every mail tool has to have extra, often buggy, support for LDAP and IMAP. If they were abstracted to a file model, all mail tools coul use them without (major) changes. >> Xprint would be (is) a central server, not running on every machine if >> there is a central CUPS server in use. > > > That's fine, but it adds unnecessary additional work for the admins, who > have to configure each printer twice: once for CUPS server, once for > Xprint server. If the Xprint server and cups serve are colocated, Xprint can query the spooler as it currently does, and load the same PPDs as CUPS did. Only "extra" step is installing/starting Xprint. -Thomas From aleksander.adamowski.xprint at altkom.pl Fri Oct 22 11:48:14 2004 From: aleksander.adamowski.xprint at altkom.pl (Aleksander Adamowski) Date: Fri Oct 22 05:07:46 2004 Subject: [Xprint] GISWxprint-sparc-2004-07-07-release_009_001 Prints too large In-Reply-To: <4177D650.7030802@cypress.com> References: <41608112.6080805@sbcglobal.net> <9e76f7fe041003161313596faa@mail.gmail.com> <4160FFCE.3060309@altkom.pl> <416C102B.3040209@my.home> <41765BBA.5020000@altkom.pl> <4176B526.3060306@cypress.com> <41779387.5010706@altkom.pl> <4177BAF5.5010405@cypress.com> <4177CF84.5000905@altkom.pl> <4177D650.7030802@cypress.com> Message-ID: <4178C94E.1040002@altkom.pl> Thomas Dodd wrote: > So if I use LPRng and want xprint to use PPDs? > Write another config option so Xprint can get the PPDs from a directory? Exactly. That would be a third model-config source mechanism plug-in (in addition to classic model configs and CUPS PPDs). Then for example, if in the future you'd switch to CUPS, the 2nd plugin (PPDs from CUPS) should detect CUPS availability, and provide additional model information form CUPS. All info should be merged with configurable priorities (you should be able to decide what overrides what, with the default being "model-configs <- CUPS PPDs <- local manually installed PPDs"). If some other network mechanism was added in addition to CUPS PPD (e.g. LDAP), it should probably sit between CUPS PPDs and local PPDs (that is, your local PPD's should override everything else). >> Well, it seems that the CUPS API has been here for a couple of years >> and it isn't going away in a few years, especially since it now ships >> with all major Linux distributions, Apple MacOS, and works well on >> other *NIX-es. >> In fact, it is steadily replacing older spoolers everywhere. > > > Slowly. And 3 years ago people said LPD wouldn't be replaced. > Something will happen and CUPS will no longer be the hot spooler. It > could be next year, or it could be 5 years. I just don't think that > API should be used when other, long term methods are available instead. Well, this is the point where I do disagree with you. The CUPS is young, that's true, but look: * It is based on IPP (Internet Printing Protocol), which is an Internet standard, documented by RFC, thus is interoperable with systems outside the POSIX world (Mac, Windows...) * It uses a widely adopted printer description format (PPD), which is: 1) Supported by largest amount of printer vendors 2) Based on a standard, mature Postscript language that has been here for almost thirty years, and PPD has been a stable standard for 15 years * It's so superior that it has replaced other spoolers in all major Linux distros just 2 years ago and since then it shows no signs of weakening Maybe I'm wrong, maybe I don't know something you do know. What are those long term methods that you have mentioned? > That's Unix. Everything is a file. It doesn't have to be local, it > could be NFS, SMB, or som other networked filesystem easily. It the a > simple way to get info from CUPS, and LDAP, and NIS, using file commands? Well, you can write shell and Perl scripts. That's moderately complex and I for example do some of this stuff. But there's no standard covering filesystem representation of LDAP of NIS data, so those would be purely ad-hoc solutions. Most probably they would end up as some "NFS-accessible structure synchronised through rsync-over-SSH by a Python script getting a pipe from a Perl sub, launched as a CORBA method from a shell script from crontab", being a nightmare to support by any admin. Besides, LDAP or CUPS are used mainly there, where ordinary filesystem stops to scale well; LDAP offers high performance access by queries to a hierarchical database by various keys, something you don't have with NFS (NFS doesn't offer indexing by various file properties, you just have directory structure and symlinks). CUPS's value is mainly in the standardization, so it can be used directly through IPP from UNIX clients, Windows clients and MacOS clients. It's a heterogenous environment godsend. The UNIX "everything is a file" paradigm just doesn't fit well to all possible problems, and it's is the case here too. > There is no reason for Xprint to know CUPS, LDAP, NIS, NFS, HTTP, ... > when all could be abstracted to a file which is what Xprint needs. > That a Windows/Microsoft mentality, all apps speak all protocols. Look > at the problems caused but not abstraction these already. Every mail > tool has to have extra, often buggy, support for LDAP and IMAP. If > they were abstracted to a file model, all mail tools coul use them > without (major) changes. Ok, comparing with LDAP, how do you abstract a query for a telephone number as an attribute of a person to a filesystem? Note that telephone number queries are specifig, since telephone numbers have to be compared in a special way (e.g brackets would be ignored etc.). What filesystems implementation currently offer built-in indexing of such data in order to speed up searches? You just can't use the UNIX filesystem for everything. Now you could imagine some mapping of CUPS printers for filesystem (e.g. a single printer queue is a file, and printer with its various queues is a directory, and properly named symlinks pointing to those queues denote current settings, e.g. currently set default paper orientation and resolution and ReT settings) which could be shared through NFS. But there's no standard on that. And probably never will be. And you have not only standardize on directory structure, but also on all data formats. E.G. "to submit a job with a non-default resolution of 600 DPI you open the file spool/printername/queuename, and write 'Resolution: 600 DPI\n\nPOSTSCRIPT_DATA'". That's just too much work that has to be done fighting inertial; even if a strong community started today, it would take more than 10 years to get this widely adopted. > Xprint would be (is) a central server, not running on every machine if > there is a central CUPS server in use. > > If the Xprint server and cups serve are colocated, Xprint can query > the spooler as it currently does, and load the same PPDs as CUPS did. > Only "extra" step is installing/starting Xprint. Plus synchronisinhg the ever-changing printer data from CUPS to Xprint. The helpdesk guys replace broken printers, relocate them to different offices, rename them, change default printout settings, and they do it using CUPS's web interface. There are currently no tools to populate that data to Xprint, so each deployment requires writing them by hand. And they'd have to be launched periodically from crontab (the changes wouldn't be instant), or modyfying the CUPS source so that it launches a synchronisation script after each change in printers configuration. BTW, I couldn't find this information in the docs: does Xprint server require a after a change in model configs? If yes, then when you have a couple dozen's of printers, either users would be denied printing access for a couple of seconds a number of times a day, or in the case of replacing a broken printer the users would have to wait with their printouts till next day. Both solutions are unacceptable. -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.ab.altkom.pl From ted at cypress.com Fri Oct 22 10:23:16 2004 From: ted at cypress.com (Thomas Dodd) Date: Fri Oct 22 10:43:01 2004 Subject: [Xprint] GISWxprint-sparc-2004-07-07-release_009_001 Prints too large In-Reply-To: <4178C94E.1040002@altkom.pl> References: <41608112.6080805@sbcglobal.net> <9e76f7fe041003161313596faa@mail.gmail.com> <4160FFCE.3060309@altkom.pl> <416C102B.3040209@my.home> <41765BBA.5020000@altkom.pl> <4176B526.3060306@cypress.com> <41779387.5010706@altkom.pl> <4177BAF5.5010405@cypress.com> <4177CF84.5000905@altkom.pl> <4177D650.7030802@cypress.com> <4178C94E.1040002@altkom.pl> Message-ID: <417917D4.6060400@cypress.com> Aleksander Adamowski wrote: > Thomas Dodd wrote: > >> So if I use LPRng and want xprint to use PPDs? >> Write another config option so Xprint can get the PPDs from a directory? > > > Exactly. > That would be a third model-config source mechanism plug-in (in addition > to classic model configs and CUPS PPDs). Adding multiple ways of getting the configuration data sound trouble prone. I cannot think of any cases where more than one configuration type is used. System wide (/etc) and local ($HOME) happens, but the format is the same. NIS and LDAP attempt to add LAN wide, but still tend to be roughly the same. > The CUPS is young, that's true, but look: > * It is based on IPP (Internet Printing Protocol), which is an > Internet standard, documented by RFC, thus is interoperable with systems > outside the POSIX world (Mac, Windows...) Never seen IPP outside of CUPS. How do I configure Win98 to automatically get the pinter info from a CUPS server? > * It uses a widely adopted printer description format (PPD), which is: I agreed with using PPDs for the info they provide. Paper sizes and trays, plex, resolution and such. Notice one of the things that allowed CUPS to move in was compatibility of the user tools. Having lpr/lpq/lprm commands. It met resistance when it used the solaris lp/lpstat/lpcancel scommands only. > Maybe I'm wrong, maybe I don't know something you do know. What are > those long term methods that you have mentioned? Networked filesystems and file acess. > But there's no standard covering filesystem representation of LDAP of > NIS data, so those would be purely ad-hoc solutions. That's unfortunate. What about the libc functions that get data from files, NIS, LDAP and other sources? The apps that uses that info don't know or care if the data is a file or NIS. > The UNIX "everything is a file" paradigm just doesn't fit well to all > possible problems, and it's is the case here too. That's been claimed for 20 years, yet it still works well. Look at the linux /proc and nor /sys psudoe filesystems. It uses "files" for thing others said a file wouldn't work for. > Ok, comparing with LDAP, how do you abstract a query for a telephone > number as an attribute of a person to a filesystem? Not a clue.I don't use LDAP much. I do know I've had problems wil mail tools not working with LDAP and IMAP. So the current interfaces ar not great. > What filesystems implementation currently offer built-in indexing of > such data in order to speed up searches? > > You just can't use the UNIX filesystem for everything. You don't have to have full access for PPDs. You just populate a CUPS directory, with print queue directories, which has a PPD file. Maybe some other info, but we don't need it. > formats. E.G. "to submit a job with a non-default resolution of 600 DPI > you open the file spool/printername/queuename, and write 'Resolution: > 600 DPI\n\nPOSTSCRIPT_DATA'". Or write to the 600DPI subqueue. CUPS/ lp1/ 600dpi 300dpi lp2/ 600dpi 1200dpi You only need the different queues for info that won't fit in the postscript data. Not sure what postscript supports, but I know plex mode and paper tray selection are. > There are currently no tools to populate that data to Xprint, so each > deployment requires writing them by hand. And they'd have to be launched > periodically from crontab (the changes wouldn't be instant), or > modyfying the CUPS source so that it launches a synchronisation script > after each change in printers configuration. If the PPDs are being used, you don't have to write it by hand. > If yes, then when you have a couple dozen's of printers, either users > would be denied printing access for a couple of seconds a number of > times a day, or in the case of replacing a broken printer the users > would have to wait with their printouts till next day. Both solutions > are unacceptable. And restarting CUPS is instant? All changes are immediately available on all clients? And xprint doesn't take that long to start. I do think that Xprint need a way to reload config data other than a complete restart. With X getting RandR most reasons for an X restart are going away. Then again, for a long time, lpr has required a restart to get config changes. We've all survived that so far. From aleksander.adamowski.xprint at altkom.pl Mon Oct 25 13:16:17 2004 From: aleksander.adamowski.xprint at altkom.pl (Aleksander Adamowski) Date: Mon Oct 25 06:35:57 2004 Subject: [Xprint] GISWxprint-sparc-2004-07-07-release_009_001 Prints too large In-Reply-To: <417917D4.6060400@cypress.com> References: <41608112.6080805@sbcglobal.net> <9e76f7fe041003161313596faa@mail.gmail.com> <4160FFCE.3060309@altkom.pl> <416C102B.3040209@my.home> <41765BBA.5020000@altkom.pl> <4176B526.3060306@cypress.com> <41779387.5010706@altkom.pl> <4177BAF5.5010405@cypress.com> <4177CF84.5000905@altkom.pl> <4177D650.7030802@cypress.com> <4178C94E.1040002@altkom.pl> <417917D4.6060400@cypress.com> Message-ID: <417CD271.1050409@altkom.pl> Thomas Dodd wrote: > Never seen IPP outside of CUPS. How do I configure Win98 to > automatically get the pinter info from a CUPS server? It's in Windows since version 2000. Win98 isn't supported by MS anyway for some time, it's too old. In Win 2000, when adding a printer, you select adding by URL, and you can paste a IPP URL there (from CUPS it would be http://cupsserver/printers/printer_name). > >> Maybe I'm wrong, maybe I don't know something you do know. What are >> those long term methods that you have mentioned? > > > Networked filesystems and file acess. I know that, but as I've said it's not enough. The UNIX filesystem model is too limited. For a rationale, read my next reply. > >> But there's no standard covering filesystem representation of LDAP of >> NIS data, so those would be purely ad-hoc solutions. > > That's unfortunate. What about the libc functions that get data from > files, NIS, LDAP and other sources? The apps that uses that info don't > know or care if the data is a file or NIS. But that's using getent(), not the filesystem-related functions. Which only illustrates that the filesystem model is not perfect for solving all thge problems. We have a key->value database problem, with a need for efficient searching based on various object attributes, and traditional UNIX filesystem model is weak at this task. > That's been claimed for 20 years, yet it still works well. Look at the > linux /proc and nor /sys psudoe filesystems. It uses "files" for thing > others said a file wouldn't work for. It works only, if you know precisely the name and location of the object which you want to get. This is indeed good for storing system settings, and printer model configs. But when you want to centralise organization-wide information, this is not enough, hence the popularity of LDAP and directory services in general these days. CUPS could be thought of as a "directory service for printers", and it will probably integrated with LDAP some time in the future. > > You don't have to have full access for PPDs. You just populate a CUPS > directory, with print queue directories, which has a PPD file. Maybe > some other info, but we don't need it. That would be nice, but there's no implementation nor a standard covering this. If XPrint were accepting a directory of PPDs with printer names as filenames, one could simply NFS mount the directory /etc/cups/ppd from the CUPS server at a proper mount point- that would be a nice filesystem-based standard for the start. But this layout is internal to the CUPS server, it can change in the future and the CUPS API is the most proper way of extracting model information. > > Or write to the 600DPI subqueue. > > CUPS/ > lp1/ > 600dpi > 300dpi > lp2/ > 600dpi > 1200dpi Then you'd need: CUPS/ lp1/ 600dpi/ A4 doublesidedlongedge doublesidedshortedge singlesided A3 doublesidedlongedge doublesidedshortedge singlesided Letter doublesidedlongedge doublesidedshortedge singlesided 300dpi A4 doublesidedlongedge ... You get the idea? Now imagine you want to add support for e.g. media source (envelope feeder, manual feeder, tray 1, tray 2...). Or economy mode. This directory structure becomes exponentially complex, because the information is multidimensional. There are multiple orthogonal attributes (paper sizes; possible plexes; resolution). You end up with thousands of symlinks for a few printers. At some point your filesystem will run out of inodes. Earlier it will become very slow. > You only need the different queues for info that won't fit in the > postscript data. Not sure what postscript supports, but I know plex > mode and paper tray selection are. The structure is not only for submitting, but also for discovering information about supported printer input, e.g. so you can see whether a printer can print 600DPI duplex on the Letter format paper. This is what we are discussing: a way to specify model config information to Xprint in a functional way. >> There are currently no tools to populate that data to Xprint, so each >> deployment requires writing them by hand. And they'd have to be >> launched periodically from crontab (the changes wouldn't be instant), >> or modyfying the CUPS source so that it launches a synchronisation >> script after each change in printers configuration. > > > If the PPDs are being used, you don't have to write it by hand. I know, I were talking about distribution of those PPDs in large corporate environments. > >> If yes, then when you have a couple dozen's of printers, either users >> would be denied printing access for a couple of seconds a number of >> times a day, or in the case of replacing a broken printer the users >> would have to wait with their printouts till next day. Both solutions >> are unacceptable. > > > And restarting CUPS is instant? No, but it's not needed. > All changes are immediately available on all clients? Exactly. CUPS is designed as a heavy duty multi-user, multi-workstation, multi-printer system. > And xprint doesn't take that long to start. For environments where there are thousands of user, a restart taking a couple of seconds is unacceptable. Of course, one could cluster Xprint servers and provide dynamic failover, but it would be better if it could just run continuosly and not be restarted when a trivial thing such as a change of a printer somewhere on the network occurs. > I do think that Xprint need a way to reload config data other than a > complete restart. With X getting RandR most reasons for an X restart > are going away. Agreed. > Then again, for a long time, lpr has required a restart to get config > changes. We've all survived that so far. Some have got fed up with that. And CUPS is the result. It was designed to eliminate that problem (among others). -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.ab.altkom.pl From theimrot at gmx.de Fri Oct 29 13:29:19 2004 From: theimrot at gmx.de (Thomas Heimroth) Date: Mon Nov 1 06:06:05 2004 Subject: [Xprint] Probleme beim Drucken mit XPrint beim Browser Firefox unter Debian Sarge Message-ID: <20041029102919.GA832@sensenstein.kassel.de> Ich wende mich mal an Sie bei Problemen mit Xprint. Ich habe diese Adresse aus den Newsgroups von Mozilla bekommen und hoffe sie k?nnen mir weiterhelfen. Ich habe Probleme unter Firefox zu drucken. Ich habe einen HP-Deskjet 980 CXI und habe ihn ?ber Cups konfiguriert. Wenn ich unter Firefox etwas drucken m?chte, habe ich folgende Auswahlen: lp@:64 hp980cxi@:64 xp_ps_spooldir_HOME_Xprintjobs@:64 xp_pdf_spooldir_HOME_Xprintjobs@:64 PostScript/hp:980_cxi Mein Drucker-Name ist: hp_980_cxi Was bedeuten die oberen 5 Auswahlen? Und wenn ich eine von denen ausw?hle und drucken ausw?hle wird eine Seite mit einer Zeile gedruckt z.B. mit folgendem Inhalt: %!PS-Adobe-3.0 %%BoundingBox: 18 18 541 769 %%Creator: Mozilla PostScript module (...... oder: %!PS-Adobe-3.0 %%Creator: The X Print Server's PostScript DDX %xprint.mozdev.org,...... Die Zeile druckt nicht zu Ende, oder ?ber das Baltt hinaus. Was fehlt dem Firefox Version 1.0, hat er ?brigens auch beim vorigen Mozilla Version 1.5 gemacht. Bei anderen Anwendungen: xemacs, konqueror funktioniert das Drucken. Beim Konqueror muss ich nur den richtigen unter cups eingerichteten Drucker ausw?hlen. Was ist nicht in Ordnung unter Firfox? Thomas -- +----------------------------------------------+ | Deshalb k?nnen Pinguine nicht fliegen: | | Was nicht fliegt, kann auch nicht abst?rzen. | | www.linux.de | +----------------------------------------------+ +----------------------------------------------+ | Thomas Heimroth | | email: theimrot@gmx.de | +----------------------------------------------+