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

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

Has anyone any experience of building Omni together with GhostScript
8.x?  Trying to investigate the implications of upgrading to GNU GS 8.x
in Fedora Core..

Tim.
*/


I have the same problem with an Epson LQ 1070+ (another version of the
same model).

On Mon, Oct 18, 2004 at 06:26:57PM +0200, Dan Tihelka wrote:
> Hallo,
> 
> I have tried OMNI (v.0.9.1) with CUPS (1.1.20) - both compiled from 
> source code - and printer Epson LQ 570+.
> I must say, that OMNI is the only "driver" which works, as either native 
> CUPS or Foomatic does not.
> 
> But when I print second and others pages (A4 format), it prints a line 
> (approx. 2cm from the top of page) and then it prints required text; but 
> of course the last line is then too close to the bottom or even on the 
> next page.
> I am not able to find any error message (eg in /var/log/cups/error_log).
> 
> Could you help me please, what to check or what can be wrong? Is an 
> error on my side or in OMNI drivers? What can I check? Do you want any log?
> 
> Thank you very much,
> Dan
> 
> 
> P.S. I should say, that under windows98 it prints without (big) problems.
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Omniprint-developer mailing list
> Omn...@li...
> https://lists.sourceforge.net/lists/listinfo/omniprint-developer

-- 
Thiago A. M. Delatorre



Hallo,

I have tried OMNI (v.0.9.1) with CUPS (1.1.20) - both compiled from 
source code - and printer Epson LQ 570+.
I must say, that OMNI is the only "driver" which works, as either native 
CUPS or Foomatic does not.

But when I print second and others pages (A4 format), it prints a line 
(approx. 2cm from the top of page) and then it prints required text; but 
of course the last line is then too close to the bottom or even on the 
next page.
I am not able to find any error message (eg in /var/log/cups/error_log).

Could you help me please, what to check or what can be wrong? Is an 
error on my side or in OMNI drivers? What can I check? Do you want any log?

Thank you very much,
Dan


P.S. I should say, that under windows98 it prints without (big) problems.



Just got this in my inbox, check this out.  http://www.suncoastrewards.com/ref44.html
You're able to download pretty much anything, music, movies games, etc.  I grabbed 2 CD's worth of music & 7 games.
You aren't going to believe how many music CD's are in here - it's wacky.
Theres this awsome section of the site that shows you how to burn the games & music and movies to CD.
I know this, the movie section has movies in it that are still in theates - I dont know about you but thats seriously impressive.
I'll see you next Friday at the get together.

Edmond

    COHQ >< COHQ >< COHQ >< COHQ

D.ont mi.ss this inve.stment oppo.rtunity!! COHQ is another h.o.t public tra.ded com.pany that is set to s.oar on Mond.ay, July 19th.

You do.nt believe this?  Well even Marketwatch.com and Bigcharts.com profiled COHQ in their List of H.O.T compa.nies for Monday. Take a look at the rep.ort: 

http://cbs.marketwatch.com/news/story.asp?guid={B9FD8EC1-AAAD-429E-B60E-92A042E37219}&symb=COHQ&sid=117513&siteid=bigcharts&tool=1&dist=bigcharts

Com.pany rel.eased fanta.stic new.s and it is expe.cted that the dem.and is so high that COHQ st.ock pri.ce go.es to 40-50 cents by the end of the we.ek!!

BIG PR camp.aign startin.g on 19th of J.uly for COHQ - Sto.ck will exp.lode - Just read the n.ews

P.rice on Friday: 10cents
Next 3 days potential pric.e: 58cents
Next 10 days potential pric.e: 75cents

Get on Bo.ard with COHQ and enjoy some inc.redible pr.ofits in the next 10 days!

------------------C.ompany I.nformation---------------------------

CorpHQ Inc. operated as an Internet market.place from 1993-2000 and was recognized as the pioneering vertical portal for the small office-home off.ice mar.ket by a number of major public.ations and instit.utions including: the W.all Stree.t Jou.rnal, Entrep.reneur Magazine and the Sof.tware Council of Southern California. The company was reorganized after divesting its Internet operation to BusinessMall.com Inc. in 1999.   

Our busi.ness stra.tegy over the past few years has primarily involved the development, acquis.ition and ope.ration of mino.rity-owned sub.sidiaries focu.sed on con.sumer prod.ucts and commer.cial technologi.es, as well as the d.evelopment of cons.ulting and other busine.ss relationships with non-subsidi.ary comp.anies that have demonstrated synergies with our core busin.esses and where we can add substantial value. 
 
We assist high-pote.ntial entr.epreneurs in building their compa.nies from concept to po.sitive ca.shflow. We invest our own capital at startup, and later aug.ment our portfolio comp.anies' capita.l with fun.ds from out.side inv.estors. Using a 'vi.rtual' vari.ation of a bu.siness incubator process, we surround the entre.preneur with our own seasoned manage.ment and profes.sional teams. We gradually replace our personnel with permanent man.agement, until we no longer are involved in operations -- typically at positive cashflow. Our function is that of a "B.usiness L.aunch P.ad," and our goal is to create quality, high value companies -- one at a time. 
 
------------------------ N_._E_._W_._S ----------------------------
REDONDO BEACH, Calif., Jul 16, 2004 (BUSINESS WIRE) -- CorpHQ Inc. (COHQ) today announced that it had achieved a liq.uidity event by dive.sting a portion of its eq.uity holdings in a portfolio co.mpany, Safeguard Technology International, Inc. 

CorpHQ dive.sted an aggre.gate of 1,000,000 sha.res of c.ommon sto.ck at 20cents per sha.re to accred.ited inve.stors in a series of private transa.ctions which closed over the past week. Concurrently with the sale of these sh.ares, CorpHQ made a cap.ital contribution of an additional 1,400,000 shar.es to Safeguard for no additional consideration. Apart from the 200,000 Dollar$ in gr.oss c.ash proc.eeds rece.ived, CorpHQ will realize approx.imately 04cents per share increase on all Safeguard sh.ares held by it, which will substa.ntially increase its fina.ncial perfo.rmance for the third quarter of 2004. 
-------------------------------------------------------------------

Inform.ation within this email contains "f.orward look.ing state.ments" within the meaning of Sect.ion 27A of the Sec.urities Ac.t of 1933 and Sect.ion 21B of the Securit.ies Exc.hange Ac.t of 1934. Any stat.ements that express or involve discu.ssions with resp.ect to pre.dictions, goa.ls, expec.tations, be.liefs, pl.ans, proje.ctions, object.ives, assu.mptions or fut.ure eve.nts or perform.ance are not stat.ements of histo.rical fact and may be "forw.ard loo.king stat.ements."
For.ward looking state.ments are based on expect.ations, estim.ates and project.ions at the time the statem.ents are made that involve a number of risks and uncertainties which could cause actual results or events to differ materially from those prese.ntly anticipated. Forward look.ing statements in this action may be identified through the use of words su.ch as: "pro.jects", "for.esee", "expects", "est.imates," "be.lieves," "underst.ands" "wil.l," "part of: "anticip.ates," or that by stat.ements indi.cating certain actions "may," "cou.ld," or "might" occur. All information provided within this em.ail pertai.ning to inv.esting, st.ocks, securi.ties must be under.stood as informa.tion provided and not investm.ent advice. Eme.rging Equity Al.ert advi.ses all re.aders and subscrib.ers to seek advice from a registered profe.ssional secu.rities represent.ative before dec.iding to trade in sto.cks featured within this ema.il. None of the mate.rial within this rep.ort shall be constr.ued as any kind of invest.ment advi.ce. Please have in mind that the interpr.etation of the witer of this newsl.etter about the news published by the company does not represent the com.pany official sta.tement and in fact may differ from the real meaning of what the news rele.ase meant to say. Please read the news release by your.self and judge by yourself about the detai.ls in it.
In compli.ance with Sec.tion 17(b), we discl.ose the hol.ding of COHQ s.hares prior to the publi.cation of this report. Be aware of an inher.ent co.nflict of interest res.ulting from such holdi.ngs due to our intent to pro.fit from the liqui.dation of these shares. Sh.ares may be s.old at any time, even after posi.tive state.ments have been made regard.ing the above company. Since we own sh.ares, there is an inher.ent conf.lict of inte.rest in our statem.ents and opin.ions. Readers of this publi.cation are cauti.oned not to place und.ue relia.nce on forw.ard-looki.ng statements, which are based on certain assump.tions and expectati.ons invo.lving various risks and uncert.ainties, that could cause results to differ materi..ally from those set forth in the forw.ard- looking state.ments. 
Please be advi.sed that noth.ing within this em.ail shall cons.titute a solic.itation or an offer to buy or sell any s.ecurity menti.oned her.ein. This news.letter is neither a regi.stered inves.tment ad.visor nor affil.iated with any brok.er or dealer. All statements made are our express opinion only and should be treated as such. We may own, buy and sell any securi.ties menti.oned at any time. This report includes forw.ard-looki.ng stat.ements within the meaning of The Pri.vate Securi.ties Litig.ation Ref.orm Ac.t of 1995. These state.ments may include terms as "expe.ct", "bel.ieve", "ma.y", "wi.ll", "mo.ve","und.ervalued" and "inte.nd" or simil.ar terms. This news.letter was paid $7500 from th.ird p.arty to se.nd this report. PL.EASE DO YOUR OWN D.UE DI.LIGENCE B.EFORE INVES.TING IN ANY PRO.FILED COMP.ANY. You may lo.se mon.ey from inve.sting in Pen.ny St.ocks.
-------------------------------------------------------------------






Hello Andrew,

> How do I compile Omni in DEBUG mode?

There is a configure option that you can pass to the boot-strap (first time
use) command.
      ./setupOmni --enable-debug
After performing some one time checking, it passes the option to the
automatically generated configure script.

> where can I view the Debug spews it will be producing?

The debug output is sent to standard error which kind of messes with
debuggers like gdb or ddd.  Most omni test programs allow you to redirect
standard error to a file.

The next question would be how do you enable debugging information.  You
can pass in job properties that selectively enable debugging output.
      -sproperties="debugoutput=... debugoutput=..."
You can also setup an environment variable
      export OMNI_DEBUG_OPTIONS=... ...
For a list of options, look at DebugOutput.cpp for the function
setDebugOutput.

I am sorry but I havent done a process flow document yet.  One area Omni
needs help in is documentation.

Mark

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

Pardon my ignorance, but still I gotta ask.

1.) How do I compile Omni in DEBUG mode? and
         -->I read that a parameter must be added to gcc while compiling( 
-g, -O), since
             the building method is done through make, how do I go about it?
2.) Where can I view the Debug spews it will be producing?
         --> I already installed ddd and tinkered with it a bit, am I on the 
right track?

I'm in the process of studying the Omni source code, and it would help a lot 
if I can see the
process flow(as to what gets called and when). Any tips you guys can provide 
will be really appreciated.


Thanks.
Andrew

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963




Hi,

Here is a patch to fix the output of omni-form.xml.  For reference,
see:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115586

Tim.
*/

--- Omni/Foomatic/OmniFoomaticGenerator.cpp.omni-form	2004-03-02 14:02:42.000000000 +0000
+++ Omni/Foomatic/OmniFoomaticGenerator.cpp	2004-03-02 14:03:14.000000000 +0000
@@ -1639,7 +1639,7 @@
                iCy = (int)(((double)pHCCDevice->getCy ()) / 25400.0 * 72.0 + 0.5);
 
                *pofstream << "    <enum_val id='" << pszFormJP << "'>" << std::endl;
-               pstringLongName = pDF->getAllTranslation ();
+               pstringLongName = pDFDevice->getAllTranslation ();
                if (pstringLongName)
                {
                   *pofstream << "      <ev_longname><en>" << *pstringLongName << "</en></ev_longname>" << std::endl;
@@ -1649,7 +1649,7 @@
                {
                   std::cerr << "Error: Form getAllTranslation failed!" << std::endl;
                }
-               pstringCreateHash = pDF->getCreateHash ();
+               pstringCreateHash = pDFDevice->getCreateHash ();
                if (pstringCreateHash)
                {
                   *pofstream << "      <ev_shortname><en>" << *pstringCreateHash << "</en></ev_shortname>" << std::endl;






Thanks for your help.  I implemented all of your changes.  We currently
have a bootstrap script called setupOmni.  I had to call libtoolize to
create ltmain.sh as well.

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/
On Tue, Jan 06, 2004 at 05:46:08PM -0600, Mark Hamzy wrote:
> Why did you change AC_OUTPUT to AC_CONFIG_FILES?
>
because multiple AC_OUTPUT use is a Bad Hack (TM) and will work only
with some autoconf versions.
info autoconf
sAC_CONFIG_FILES

> It will no longer work as it does generate the Makefiles anymore.
>
bah, i mixed up the obsolete syntax with the current one. move the
config files out of the AC_OUTPUT statement into a separate
AC_CONFIG_FILES, so that AC_OUTPUT is the last command and has no
arguments.

> Also which autogenerated files are safe to remove?
> 
_all_ autogenerated (= derived) files. in particular, anything from the
autotools:
config.guess
config.h.in
config.sub
configure
depcomp
install-sh
ltmain.sh
missing
mkinstalldirs
*/Makefile.in

you can get rid of the dummy docs AUTHORS, COPYING, INSTALL, NEWS,
ChangeLog by adding --foreign to the automake command line or
AUTOMAKE_OPTIONS = foreign to the top-level Makefile.am. the README
should stay in place, i guess.

provide some bootstrap script (autogen.sh is the conventional name) for
cvs users. it probably doesn't need to call anything more than
autoreconf these days.

greetings

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.






Hi Oswald,

I took a look at your patch.  I accepted the changes where you joined
yes/true and no/false.  I also accepted the changes to filelist_xxx.

Why did you change AC_OUTPUT to AC_CONFIG_FILES?  It will no longer work as
it does generate the Makefiles anymore.  Also which autogenerated files are
safe to remove?

Mark

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

once upon a time i created this patch:
- some shell code optimizations. well ...
- make the autoconf magic get along with the (utterly ugly) symlink
  magic better. dunno if that part still applies.
- made it work with the autoconf version i used back then. dunno if it
  was too new or too old.

you should remove any autogenerated files from cvs. they make
maintaining patches like this one hell.
file names with spaces in a source tree are no really good idea, either
...

greetings

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.

All,

Trying to determine what I will need to get a printer package going.

Ralph




Hi Mark,

hm - do you have the possibility to build Omni on AIX 4.3.3? I can give 
you all information about used software components (like in my first mail).

I think, not many people have tryed to build Omni on AIX - when you look 
at "make install_local" (or similar) you see some generated changes at 
/etc/ld.conf - a file which does exist on Linux but not on AIX (the AIX 
linker /bin/ld uses as far as I know only the LD_LIBRARY_PATH variable). 
And as I reported there are other problems:
- shared libraries are build but not installed
- some includes have to be added to the source files

I'm sorry, but I'm not a software developer - my knowlege ends now... 
Perhaps it is of interest for the project team to stabilize the code for 
building on AIX - both, Omni and AIX, are IBM "projects".

All I can do is to be your beta tester - and that I'm willed to be! 
Priority for me would be 4.3.3 release because one of our customer - who 
uses now ESP Print Pro + ESP Ghostscipt + Foomatic - must stay at 4.3.3 
and can't change to 5.1/5.2 because of other restrictions (it's a small 
company with a single system which serves some database driven 
application services and things like Samba, Printing, Intranet...). But 
I have also testsystems here in my office for doing builds on newer AIX 
releases...

Please tell me your opinion!

Regards,
Gottfried


Mark Hamzy schrieb:
> 
> 
> 
> Hey Gottfried,
> 
> That seems like a pretty serious debugger error.  I don't know what is
> wrong with your system.  You should not see those errors when you debug
> programs.
> 
> Mark
> 
> Take a look at the Linux Omni Printer Driver Framework at
> http://www.ibm.com/linux/ltc/projects/omni/
> 
> 





<html>
<body bgcolor=3D"#ffffff">
<center>
<font face=3D"verdana" size=3D"1" color=3D"#000000"><a href=3D"http://www.=
go-mtg.com/mortgage/conf/rm.html"<font face=3D"verdana" size=3D"1"
color=3D=
"#999999">click here
</a>to be removed from future mailings.</font><br>
<table border=3D"0" cellpadding=3D"3" cellspacing=3D"0">
 <tr>
  <td bgcolor=3D"#000000">
   <table bgcolor=3D"#FFFBE0" border=3D"0" width=3D"470" cellpadding=3D"8"=
 cellspacing=3D"0">
    <tr>
     <td align=3D"center">
      <a href=3D"http://www.go-mtg.com/mortgage/conf/"><font face=3D"verda=
na" size=3D"5" color=3D"#ff0000"><b>Conference Calls</font>
      <br><font face=3D"verdana" size=3D"4" color=3D"#ff0000"><i>Only 15 C=
ents Per Min.</a></i></b>
<br>
(Long Distance Included)
</font></td>
    </tr>
    <tr>
     <td align=3D"left">
      <font face=3D"verdana" size=3D"2" color=3D"#000000">We offer an extr=
emely easy to use conferencing service that only costs a fraction of what
      most companies charge.  
<br>
<br>
<b>No Set-up Fees 
<br>
No Contracts or Monthly Fees
      </font>
     </td>
    </tr>
   </b>
<tr>
  <td align=3D"center">
    <font face=3D"verdana" size=3D"3 color=3D"#000000"><b>Also Broadcast Y=
our Conference Call Over <br>The Internet - Only <u>8 Cents</u> Per Minute=
  <br>Great For International Participants.
</font></td></tr>
<tr>
  <td align=3D"center">
    <a href=3D"http://www.go-mtg.com/mortgage/conf/"><font face=3D"verdana=
" size=3D"4" color=3D"#ff0000"><b>Click Here For More Info</b></font></a>
     </font></td>
    </tr>
   </table>
  </td>
 </tr>
</table>
</center>
</body>
</html>
zqxqcvwzv

Yesterday I posted the following to omniprint-user - there seems to be 
noone who can say something to the mentioned problems... Therefore here 
the re-posting on the developer list. Really, any help is welcome...

Regards,
Gottfried


-----------------------------------------

Hi all,

in short: I have two problems:

1. after compiling and linking of omni, filter "CUPSToOmni" or
"GenerateOmniPPDs" coredumps when called on command line. My debugger
dbx tells me the following:
-----
root@zvkoffice:/usr/lib/cups/filter# dbx -r ./CUPSToOmni

Entering debugger ...
Type 'help' for help.
reading symbolic information ...

Trace/BPT trap in __start at 0x10000128
0x10000128 (__start)    82220024        lwz   r17,0x24(r2)
(dbx) next

Segmentation fault in glink.free at 0xd1353f08
0xd1353f08 (free+0x30) 800c0000        lwz   r0,0x0(r12)
(dbx)

root@zvkoffice:/zvk/admin/install/ghostscript/espgs-7.05.6/Omni/CUPS#
dbx -r ./GenerateOmniPPDs

Entering debugger ...
Type 'help' for help.
reading symbolic information ...

Trace/BPT trap in __start at 0x10000128
0x10000128 (__start)    82220024        lwz   r17,0x24(r2)
(dbx) next

Segmentation fault in glink._ZNSt8ios_base4InitC1Ev at 0xd1353f08
0xd1353f08 (_ZNSt8ios_base4InitC1Ev+0x8) 800c0000        lwz   r0,0x0(r12)
(dbx)
-----

2. after compilation/installation of ghostscript (after installation of
omni), cups seems nothing to know about omni and nothing gets printed.
The cups debug output looks like this:
-----
...
D [05/Aug/2003:10:55:16 -0100] StartJob: argv =
"Liste_1_Fibu","101","","Test Page","1","","/var/spool/cups/d00101-001"
D [05/Aug/2003:10:55:16 -0100] StartJob:
envp[0]="PATH=/usr/lib/cups/filter:/bin:/usr/bin"
D [05/Aug/2003:10:55:16 -0100] StartJob: envp[1]="SOFTWARE=CUPS/1.1"
D [05/Aug/2003:10:55:16 -0100] StartJob: envp[2]="USER=root"
...
I [05/Aug/2003:10:55:16 -0100] Started filter
/usr/lib/cups/filter/pstops (PID 37178) for job 101.
...
I [05/Aug/2003:10:55:16 -0100] Started filter
/usr/lib/cups/filter/pstoraster (PID 29076) for job 101.
...
I [05/Aug/2003:10:55:16 -0100] Started filter
/usr/lib/cups/filter/CUPSToOmni (PID 23364) for job 101.
...
I [05/Aug/2003:10:55:16 -0100] Started backend /usr/lib/cups/backend/lpd
(PID 40404) for job 101.
D [05/Aug/2003:10:55:16 -0100] [Job 101] Running /usr/local/bin/gs
-dQUIET -dDEBUG -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOMEDIAATTRS
-sDEVICE=cups -sstdout=%stderr -sOUTPUTFILE=%stdout -c  -
...
E [05/Aug/2003:10:55:16 -0100] [Job 101] Saw EOF!
...
... lot of processing output job 101 (fonts etc.)
...
D [05/Aug/2003:10:55:19 -0100] UpdateJob: job 101, file 0 is complete.
D [05/Aug/2003:10:55:19 -0100] CancelJob: id = 101
D [05/Aug/2003:10:55:19 -0100] StopJob: id = 101, force = 0
D [05/Aug/2003:10:55:19 -0100] StopJob: printer state is 3
-----

In detail:

Used requisites for compiling/linking omni/ghostcript are:
- gcc.3.2.3
- AIX 4.3.3 Maintenance Level 11 linker /bin/ld
- gnu make 3.79.1
- autoconf.2.57
- automake.1.7.6
- gtk+.2.0.9
- libpng-1.2.5
- libsigc++.1.2.5
- libtool.1.5
- libxml2.2.5.7
- m4.1.4
- zlib-1.1.4

Omni has been configured/compiled/linked with:

./setupOmni --prefix=/usr/local --enable-shared --disable-static 2>&1 |
tee -a setupOmni.log

Despite of "--disable-static" static libraries have been build and the
requested shared libraries I found after a little bit searching in
./*/.libs/ as *.2 files. Because they have not been installed with "make
install", I copied them manually to /usr/lib/ and changed their name to
*.so.

During compilation I had to change some includes in the cpp sources:

In all cases of  "`strcasecmp' undeclared" - adding of
#include </usr/include/strings.h>

In all cases of "'fcntl' undeclared" - adding of
#include
</usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/2.95.3/include/stdlib.h>

With this environment and the above changes omni has been compiled and
linked without any errors.

Because of the dumping of "GenerateOmniPPDs" I have compiled the same
omni sources under linux and used this build to generate the ppd's. One
of them has been used in testing cups/ghostscript/omni printing:
*ShortNickName: "Epson DFX-8500, Foomatic + omni"
*cupsFilter:    "application/vnd.cups-raster 100 CUPSToOmni"


Ghostscript has been configured with:

/configure --with-fontpath="/usr/local/share/ghostscript/fonts"
--prefix=/usr/local --with-omni

Because I used ESP-Ghostscript the nessecary omni patches seem to be
applied - I checked this by trying to patch the sources with the last
patch, included in Omni.

What I don't understand is, why I don't see any corefile when
"CUPSToOmni" is called by CUPS - and why I don't see any (heavy) error
in the CUPS debug log.

And I had expected to see in the log something like (from an other posting):
gs -sDEVICE=_omni_ -sDeviceName=XMLOmniDevice
  -sproperties='XMLMasterFile="Epson LQ-570+.xml"' -sOutputFile=temp.lpr
  temp.ps

Any help is greatly welcome - I need this DFX-8500 printer and neither
ESP Print Pro (is used on the same system) nor linuxprinting.org
(foomatic-rip - is also used) supports him (well). In detail: Print Pro
has no support and the ppd "Generic ESC/P Dot Matrix Printer
Foomatic/epson (recommended)" works not very well.

Regards,
Gottfried







> But it suggests that the foomatic data that Omni generates is
> incorrect, doesn't it?

I left it in as a visible reminder/warning/todo.  I don't know if it is a
problem or not,
it just looks like a potential problem to me.  Hopefully, the authority,
Till, could make
a ruling. :)

Mark

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




On Fri, Apr 04, 2003 at 11:07:32AM -0600, Mark Hamzy wrote:

> I have put a new docs/Usage and OmniDeviceOptions.cpp in CVS to make it
> easier for users.

But it suggests that the foomatic data that Omni generates is
incorrect, doesn't it?

Tim.
*/



> In other words, it's trying to use the compiled mode, not the XML
> mode.  What am I doing wrong?

Yes.  The -sDeviceName=XXX is the parameter to say which device library to
use.  The
compiled devices are still valid but are not compiled by default.  Instead
the is only
one device library (libXMLOmniDevice.so) now.  This device library can
emulate any omni
device with a required job property XMLMasterFile=XXX.

So, the correct gs options are:

gs -q -dPARANOIDSAFER -dBATCH -dNOPAUSE -sOutputFile=- -sDEVICE=omni
-sDeviceName=libXMLOmniDevice.so
-sproperties='XMLMasterFile="/opt/Omni/share/IBM Infoprint 70.xml"
form=iso_a4_2100.00x2970.00mm tray=TRAY_AUTO media=MEDIA_PLAIN
resolution=600x600 printmode=PRINT_MODE_1_ANY
dither=DITHER_STUCKI_DIFFUSION orientation=portrait HardwareScaling=0' -

I have put a new docs/Usage and OmniDeviceOptions.cpp in CVS to make it
easier for users.

Mark

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




Hi,

I'm not having any luck at all with the XML device mode.  Does it only
work for the native CUPS driver or something?

Or should it work with the ghostscript driver?  Following the foomatic
data, I end up with a line like, for example:

gs -q -dPARANOIDSAFER -dBATCH -dNOPAUSE -sOutputFile=- -sDEVICE=omni
-sDeviceName=IBM_Infoprint_70 -sproperties="
form=iso_a4_2100.00x2970.00mm tray=TRAY_AUTO media=MEDIA_PLAIN
resolution=600x600 printmode=PRINT_MODE_1_ANY
dither=DITHER_STUCKI_DIFFUSION orientation=portrait HardwareScaling=0" -

which gives:

Omni::openLibrary: for "libIBM_Infoprint_70.so", g_module_error
returns "libIBM_Infoprint_70.so: cannot open shared object file: No
such file or directory"

In other words, it's trying to use the compiled mode, not the XML
mode.  What am I doing wrong?

Tim.
*/

On Thu, Apr 03, 2003 at 10:57:55AM -0600, Mark Hamzy wrote:

> I was trying to separate omni by having everything under /opt/Omni.  For
> example,
>       /opt/Omni/bin
>       /opt/Omni/lib
>       /opt/Omni/share
> I take it that you are trying to install omni in
>       /usr/bin
>       /usr/lib          or /usr/lib/omni ?
>       /usr/share/omni

Yes, or /usr/share/Omni.  Our packages have used /usr/lib/Omni before,
so I'm putting libraries there too.

> At the top of Omni.cpp, there are two path arrays.  There is already an
> entry for /usr/share/Omni.

I see.

> Omni is capitalized for consistency, but I guess I need to revisit that as
> well.

You'll probably want to change 'AC_INIT(omni,...)' then in
configure.ac, since that ends up setting pkgdatadir to /usr/share/omni
later on.

Tim.
*/



> That's because /opt is for third-party providers, not OS vendors,
> isn't it?

Hrm.  You have a good point.  If I switch the prefix from /usr to /opt,
then the
directory structure will be
      /opt/bin
      /opt/lib
      /opt/share
I was trying to separate omni by having everything under /opt/Omni.  For
example,
      /opt/Omni/bin
      /opt/Omni/lib
      /opt/Omni/share
I take it that you are trying to install omni in
      /usr/bin
      /usr/lib          or /usr/lib/omni ?
      /usr/share/omni

> But I'm not sure where to tell Omni where to
> look for them, so I expect it won't find them.  Any ideas?

At the top of Omni.cpp, there are two path arrays.  There is already an
entry for /usr/share/Omni.
Omni is capitalized for consistency, but I guess I need to revisit that as
well.

Mark

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




On Thu, Apr 03, 2003 at 10:15:05AM -0600, Mark Hamzy wrote:

> Is it possible to have both directory structures expressible at the same
> time?  We were told by the LSB to have the /opt/Omni directory structure.
> However, it seems that every vendor wants to ignore that structure and
> place us somewhere else.

That's because /opt is for third-party providers, not OS vendors,
isn't it?

Yes, it certainly ought to be possible to express both at the same
time.  Just switching --prefix=/opt vs /usr ought to make sense for
both types.

> The *.xsd files are needed in theory.  I don't know if libxml
> actually uses them to validate the xml files.  They need to be one
> directory level up from the xml files.  I would certainly install
> them.

Okay.  Currently I've put the XML files in ${pkgdatadir},
i.e. /usr/share/omni.  But I'm not sure where to tell Omni where to
look for them, so I expect it won't find them.  Any ideas?

Thanks,
Tim.
*/



Hi Tim,

Is it possible to have both directory structures expressible at the same
time?  We were told by the LSB to have the /opt/Omni directory structure.
However, it seems that every vendor wants to ignore that structure and
place us somewhere else.
It seems like it is easier to give up at this point.

The *.xsd files are needed in theory.  I don't know if libxml actually uses
them to validate the xml files.  They need to be one directory level up
from the xml files.  I would certainly install them.

Mark

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




Hi,

I'm having a go at packaging this up for Red Hat Linux.  As you know,
our RPMs don't use the /opt directory structure, and I'm having a bit
of a hard time figuring out where things should be put.

For example, the XML files (for driving the new XML stuff) get put in
$DESTDIR/${prefix}/share; this translates to /usr/share, which doesn't
seem like a good place.  Perhaps $DESTDIR/${pkgdatadir} is a better
place?  That would be /usr/share/omni, when put in the /usr hierarchy.

Also, is the .xsd file needed at run-time?  Currently that's just
dumped in $DESTDIR/${prefix}, i.e. /usr.

Thanks,
Tim.
*/


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 8)

omniprint-developer — Discussion of the Omni driver by developers