omniprint-developer Mailing List for OMNI Print Driver Model (Page 9)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

It will be released in a couple of days.  Please test it out.

Thanks,

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/






Hi Rafael,

I have now removed the auto building of the CUPS ppds.  You must now
explictly "make generateBuildPPDs" before "make install".
This way, it can be performed at compile time or at install time.

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/




Hi,

In this bug report:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=87407

it is reported that the HP LaserJet 4000N has a TRAY_2, but the
generated foomatic data doesn't reflect that.

Tim.
*/



> Care to give me a pointer?  Here's the fix I'm using in rawhide:

The IBM Instances were the ones that were fixed, IIRC.  These were:
      IBM Pages Instance.[hc]pp
      IBM 5577 Instance.[hc]pp

Unfortunately, three other global fixes and code clean up occured as well.
So you can't just take the current code.

They are missing translateKeyValue () functions (and listKeyValues () as
well).

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/




On Tue, Mar 25, 2003 at 01:58:56PM -0600, Mark Hamzy wrote:

> There was a problem in the new IBM drivers that didn't translate strings
> properly.
> This has been fixed in the latest CVS code.

Care to give me a pointer?  Here's the fix I'm using in rawhide:

--- Omni/Foomatic/OmniFoomaticGenerator.cpp.ofg	2003-03-24 13:14:44.000000000 +0000
+++ Omni/Foomatic/OmniFoomaticGenerator.cpp	2003-03-24 13:15:11.000000000 +0000
@@ -2112,6 +2112,9 @@
         pszKey  = (char *)next->first.c_str ();
         pDevice = next->second;
 
+        string *pRet = pDevice->translateKeyValue (pszKey, 0);
+        if (!pRet) continue;
+
         cout << argv[0] << ": Extra Options: " << pszKey << endl;
 
         oss.str ("");
@@ -2142,8 +2145,6 @@
 
 ////////cout << "Trying " << pDevice->getDriverName () << "." << pDevice->getDeviceName () << endl;
 
-        string *pRet = pDevice->translateKeyValue (pszKey, 0);
-
         *pofstream << "   <en>" << *pRet << "</en>" << endl;
 
         delete pRet;

Tim.
*/





Hi Tim,

There was a problem in the new IBM drivers that didn't translate strings
properly.
This has been fixed in the latest CVS code.

I just noticed that RH 9.0 is shipping soon.  Is it too late to get a new
package into the CD?  I have realized that the CUPS support was accidently
disabled in the CUPS filter.

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/




Hi,

There seems to be a bug in OmniFoomaticGenerator that causes
omni-EconoMode.xml to get truncated.  This doesn't seem to be
something in my environment, since the Omni-foomatic-0.7.3-1.i386.rpm
package on sourceforge shows the same truncation.  Here's the
backtrace:

[...]
/tmp/twaugh/Omni/Foomatic/.libs/lt-OmniFoomaticGenerator: Generating foomatic-db/db/source/opt/omni-EconoMode.xml

Program received signal SIGSEGV, Segmentation fault.
0x40262d25 in std::basic_ostream<char, std::char_traits<char> >& std::operator<< <char, std::char_traits<char>, std::allocator<char> >(std::basic_ostream<char,
std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /usr/lib/libstdc++.so.5
(gdb) bt
#0  0x40262d25 in std::basic_ostream<char, std::char_traits<char> >& std::operator<< <char, std::char_traits<char>, std::allocator<char> >(std::basic_ostream<char, std::char_traits<char> >&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /usr/lib/libstdc++.so.5
#1  0x0805364c in main (argc=-1073755008, argv=0xbfffdaa4)
    at OmniFoomaticGenerator.cpp:2147
#2  0x42015574 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) up
#1  0x0805364c in main (argc=-1073755008, argv=0xbfffdaa4)
    at OmniFoomaticGenerator.cpp:2147
2147            *pofstream << "   <en>" << *pRet << "</en>" << endl;

Tim.
*/

I have notice that the CUPS/Makefile.am now defines the environment variable OMNI_XML_ROOT_PATH. This has a problem when building packages.
A deb package is configured with prefix set to /usr, but wen building prefix is redefined to a temporary directory. For example:

./configure --prefix=/usr ....
make install prefix=/home/rafael/cvs/Omni/debian/tmp ....


It is done this way so that the compile time options are set correctly
(i.e they point to /usr). 

If the generation of the ppds would happen when compiling the package (i.e when make is executed) there would be no problem. But if they are generated when installing (make install) then the ppds will refer to 
/home/rafael/cvs/Omni/debian/tmp.

Is it possible to change when the generation of the ppds happens?

Another solution is to don't change the OMNI_XML_ROOT_PATH. This way I can make it be a empty string and the paths will be non-qualified.


The ppd files are generated with hard-coded paths for the .xml files. For example, the  PPDs/Epson/Epson-Epson_LQ_570_-omni-cups.ppd.gz file has the following line:
*ShortNickName: "libXMLOmniDevice.so%20XMLMasterFile=%22/home/rafael/cvs/Omni/Epson/Epson%20LQ-570+.xml%22"


This prevents the driver from working if the compilation directory is moved. I have defined the export OMNI_XML_ROOT_PATH to be the empty string and add this items tho Omni.cpp:

char *vapszDataPaths[] = {
   "",                 // allow for a fully qualified filename to work
   "/opt/Omni/share/",
   "../Brother/",
   "../Canon/",
   "../Epson/",
   "../HP_LaserJet/",
   "../IBM/",
   "../KS/",
   "../Kyocera/",
   "../Okidata/",
   "../Panasonic/",
   "../Star/",
   NULL
};


Now the ppd are usually correct, but some times they don't build at all. I am trying to find why.

Is this the correct way of doing? 
I know that the device list should not be hard-coded in Omni.cpp, but this can be improved by using some #define.


Thanks.



Hey All,

Just a quick note giving everyone a heads up incase they have code that
they need to check in before the release...

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/




Regards

Rajen Ramsammy
Business Development Consultant
CS IT Solutions

Telephone 011 205 7000
Fax          011 205 8586
Cell          082 349 0629

Making Business Sense of IT




Hi,
I'm so sorry to bother you. But I met a critical issue when using Omni
0.7.0 Epson_Generic_ESC_P_24_J84 driver with ghostscript 6.51. No metter
what are printed, there are always several lines (about 40) at the top
of the paper lost.
The source ps file, output data and debug output are attached. The
command is :

DUMP_OUTGOING_BITMAPS=1 gs.debug -sDEVICE=omni
-sDeviceName=Epson_Generic_ESC_P_24_J84 -r180x180 -dNOPAUSE -dBATCH
-dSAFER -sOutputFile=x.prn -sproperties="form=iso_a3_2970.00x4200.00mm
tray=TRAY_SINGLE_SHEET resolution=180x180 dither=DITHER_DITHER_4x4" x.ps
2> debug

x.ps is the source file to be printed. And x.prn is the outputed raw
data. x.png is converted from x.prn and *.bmp is generated by Omni driver.

And I tried different dither options, no help.
Could you please help me resolve this problem as soon as possible? It's
so urgent. If I cannot get the correct result within two days, I will
probably lost my job :-(

Thank you very much.

Regards
James Su



Hi,
I'm so sorry to bother you. But I met a critical issue when using Omni
0.7.0 Epson_Generic_ESC_P_24_J84 driver with ghostscript 6.51. No metter
what are printed, there are always several lines (about 40) at the top
of the paper lost.
The source ps file, output data and debug output are attached. The
command is :

DUMP_OUTGOING_BITMAPS=1 gs.debug -sDEVICE=omni
-sDeviceName=Epson_Generic_ESC_P_24_J84 -r180x180 -dNOPAUSE -dBATCH
-dSAFER -sOutputFile=x.prn -sproperties="form=iso_a3_2970.00x4200.00mm
tray=TRAY_SINGLE_SHEET resolution=180x180 dither=DITHER_DITHER_4x4" x.ps
2> debug

x.ps is the source file to be printed. And x.prn is the outputed raw
data. x.png is converted from x.prn and *.bmp is generated by Omni driver.

And I tried different dither options, no help.
Could you please help me resolve this problem as soon as possible? It's
so urgent. If I cannot get the correct result within two days, I will
probably lost my job :-(

Thank you very much.

Regards
James Su


On Tuesday, October 29, 2002, at 10:36  pm, Mark Hamzy wrote:

> I am glad that the ghostscript team would like to omni included into 
> the
> default build.  We certinaly want that.
> I am confused about your statement "cleaner build patch."  It sounds 
> like
> you do not want gmodule or C++ included
> by omni.  However, omni requires both of these.

Yes, it's the same old problem. We aren't willing to switch to the C++ 
compiler for the default build (at least not for a single driver's 
sake). Do you know a way around this? I experimented some with trying 
to compile just gomni (and possibly link) as C++, but wasn't 
successful. Can you think of a way around this? One possibility is to 
use g++ iff --enable-omni (which wouldn't be the default). I'd consider 
this for the 7.0x (GNU) branch, but not for 8.0.

Also, we'd like the other changes to unixlink.mak (LIBDLOPEN and 
LIBCPP) to be conditional on omni.dev, but that's really part of 
resoving the above.

> What do you suggest?

So I guess I don't have a good suggestion at this point. :( I just 
wanted to advise you we have a major release coming up, and see if you 
had any ideas.

Have you thought about an ijs bridge at all?

FWIW,
  -r




Hi Ralph,

I am glad that the ghostscript team would like to omni included into the
default build.  We certinaly want that.
I am confused about your statement "cleaner build patch."  It sounds like
you do not want gmodule or C++ included
by omni.  However, omni requires both of these.

What do you suggest?

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/





We're releasing Ghostscript 8.0 in the next couple of of weeks, and I 
wanted to ping you to see if there's anything you'd like to go in with 
regard to the Omni driver suite.

I took a look at the current patches against 7.05. Moving to autoconf 
has simplified the configuration issues a great deal, but it's still 
too invasive for mainline Ghostscript. In particular, we still don't 
have a good solution for the gmodule and C++ issues.

If someone can come up with a cleaner build patch, we'd be happy to 
include it. Also I understand we have copyright assignment on gomni.c, 
so we'd be happy to include it in the AFPL release if that's helpful or 
interesting to Omni.

Cheers,
  -r




I received this bug report:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=74811

This is with Omni 0.7.0.

"When Using the lasterjet III printer drivers, either the regular one
 for Laserjet III, or the IIIsi one (I have a IIIsi) the postscript
 test page prints out broken in half from just underneath the redhat
 logo when the driver is configured to 300dpi, as a JetDirect
 printer."

Is it something that might be caused by an Omni bug?

Thanks,
Tim.
*/

Hi Stuart,

You do not need Ghostscript in order to interface with omni.  In fact,
gomni.c in Ghostscript
uses an API to talk with omni.  Take a look at DeviceTester.cpp.  It
implements this API to
print a .bmp file.  It should do every thing that you need.
Please feel free to ask any questions.

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/





Whats involved in using OMNI without ghostscript ??

I have an embedded handheld device running linux. I
need to do screen dumps to various flavors of USB
attached printers. 

Ghostscript seems like overkill if all I ever want to
do is print a 640x480 bitmap. 

Thanks,
  Stuart
  sj...@br...



> What will be the major changes from 0.6.1?  In other words, what makes
> it 0.7.x instead of 0.6.x?

Well we have switched our build environment from Makefiles to autotools and
I think that that is enough of a change to warrant a big number increment.
I hope that we can get omni building on more OSes with this.

We are working towards a 1.0 release.
Some of the features that I want to work on are
      - versioning.  I think that autotools helps us with this.
      - memory leaks.
      - standards compliance?  UPDF and PDC are candidates.

Are there any other things that we should include?

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/





On Wed, May 29, 2002 at 01:49:02PM -0500, Mark Hamzy wrote:

> I will be releasing 0.7.0 soon.  Please notify me if you want to add
> something to the release before it ships.

What will be the major changes from 0.6.1?  In other words, what makes
it 0.7.x instead of 0.6.x?

Tim.
*/

Hey all,

I will be releasing 0.7.0 soon.  Please notify me if you want to add
something to the release before it ships.

Thanks,

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/





Download it at http://sourceforge.net/project/showfiles.php?group_id=18713

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/





I don't know if anyone had been able to take a look at Omni's
7.04 patches.  We removed a bunch of stuff that wasn't really
needed but I am not sure what else you were looking for in them.
We still have the glib-config and gmodule stuff in the make files
though.

Please let me know if there are any more suggestions about what
else should be removed from the makefiles.  I will make sure Omni
will run after any additional changes are made.


Thanks,


Peter Zannucci

IBM Linux Technology Center
Open Source Software Development
Omni Print Project http://sourceforge.net/projects/omniprint
Austin, TX - Tel. 512-838-4687 (t/l 678) pz...@us...


rillian <ri...@te...>@ghostscript.com on 04/18/2002 01:15:46 AM

Sent by:    gs-...@gh...


To:    Pete Zannucci/Austin/IBM@IBMUS, Mark Hamzy/Austin/IBM@IBMUS
cc:    omn...@li..., gs-...@gh...
Subject:    Re: [Gs-devel] Omni and makefile changes



On Wednesday, February 6, 2002, at 02:54 PM, Ralph Giles wrote:

> I've almost finished a counter patch. I'll forward when it has fewer
> issues than yours. :)
> Given the extra dependencies, I'd suggest we only support the omni
> driver with the autoconf makefile.

Unfortunately I never finished this patch in time for the release, and
let it drop in the meantime. However, I'm preparing the first GPL
release of the 7.0x series and wanted to ping you to see if you'd come
up with anything. We'd like to get that out asap, so I don't want to
hold the release for it, but if you come up with something clean I'd be
happy to include it.

The current source is on the GS_7_0X branch of gs on
cvs.ghostscript.com, or you could try the early release candidate at
http://casper.ghostscript.com/~giles/ghostscript-7.05rc1.tar.gz.

Cheers,
  -r

--
ri...@te...
gi...@gh...
GNU Ghostscript maintainer

_______________________________________________
gs-devel mailing list
gs-...@gh...
http://www.ghostscript.com/mailman/listinfo/gs-devel







On Wednesday, February 6, 2002, at 02:54 PM, Ralph Giles wrote:

> I've almost finished a counter patch. I'll forward when it has fewer 
> issues than yours. :)
> Given the extra dependencies, I'd suggest we only support the omni 
> driver with the autoconf makefile.

Unfortunately I never finished this patch in time for the release, and 
let it drop in the meantime. However, I'm preparing the first GPL 
release of the 7.0x series and wanted to ping you to see if you'd come 
up with anything. We'd like to get that out asap, so I don't want to 
hold the release for it, but if you come up with something clean I'd be 
happy to include it.

The current source is on the GS_7_0X branch of gs on 
cvs.ghostscript.com, or you could try the early release candidate at 
http://casper.ghostscript.com/~giles/ghostscript-7.05rc1.tar.gz.

Cheers,
  -r

--
ri...@te...
gi...@gh...
GNU Ghostscript maintainer





2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (24)	Nov (8)	Dec (16)
2002	Jan (21)	Feb (3)	Mar	Apr (3)	May (3)	Jun	Jul (2)	Aug	Sep	Oct (4)	Nov (2)	Dec
2003	Jan	Feb (2)	Mar (9)	Apr (9)	May	Jun	Jul	Aug (3)	Sep	Oct (1)	Nov (1)	Dec (1)
2004	Jan (3)	Feb	Mar (1)	Apr (2)	May	Jun	Jul (1)	Aug (1)	Sep	Oct (1)	Nov (4)	Dec
2005	Jan	Feb	Mar	Apr	May (2)	Jun (2)	Jul (4)	Aug (3)	Sep (6)	Oct (6)	Nov (2)	Dec
2006	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (1)	Dec (6)
2007	Jan (6)	Feb (6)	Mar	Apr (2)	May (2)	Jun (6)	Jul (8)	Aug (2)	Sep (2)	Oct (1)	Nov (1)	Dec (4)
2008	Jan (5)	Feb (5)	Mar (26)	Apr (17)	May (17)	Jun (6)	Jul (26)	Aug (7)	Sep (16)	Oct (15)	Nov (30)	Dec (30)
2009	Jan (8)	Feb (16)	Mar (11)	Apr (17)	May (35)	Jun (24)	Jul (28)	Aug (5)	Sep (3)	Oct	Nov	Dec (13)
2010	Jan (8)	Feb (3)	Mar (1)	Apr (1)	May (1)	Jun (1)	Jul (1)	Aug (2)	Sep (3)	Oct (2)	Nov	Dec
2011	Jan	Feb	Mar	Apr	May	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec

omniprint-developer Mailing List for OMNI Print Driver Model (Page 9)

omniprint-developer — Discussion of the Omni driver by developers