From pete at advertiger.com  Thu Jan  9 19:36:32 2003
From: pete at advertiger.com (Advertiger)
Date: Fri, 10 Jan 2003 04:36:32 +0100
Subject: [printing-driver] Cheap Cigarettes
Message-ID: <E18WpyM-0002LZ-00@base.freestandards.org>

Dear Sir or Madam

If you are a smoker in the UK, or in the ROI, then we have something for you.

You are probably fed up with paying high prices for your cigarettes and tobacco.  Take a look at what we can do for you at
http://www.advertiger.com/bs/index.php?E=06fe9d33f17d55936c8a833ef8dab991

We can send you, legally, by registered air mail, direct to your door, 4 cartons of cigarettes or 30 fifty gram pouches of rolling tobacco (all brands are available) from only 170 Euros - about 105 pounds - fully inclusive of postage and packing.  Why pay more?

If you would rather not hear from us any more, this link will ensure that you are not bothered again.
http://www.advertiger.com/bs/off.php?E=06fe9d33f17d55936c8a833ef8dab991

Yours faithfully.
British Smokers

http://www.advertiger.com/bs/index.php?E=06fe9d33f17d55936c8a833ef8dab991

w2yy2692334ald



From ndsub at mail.internetseer.com  Thu Jan  9 19:31:05 2003
From: ndsub at mail.internetseer.com (Mike Dever)
Date: Thu, 9 Jan 2003 22:31:05 -0500 (EST)
Subject: [printing-driver] InternetSeer Free Activation Confirmation
Message-ID: <19933930.1042169465919.JavaMail.root@sunrays>

Dear InternetSeer,

Starting today, your site's connectivity will be tested every hour, seven days 
a week. You will begin to receive the following benefits from InternetSeer:

- A weekly performance report on your monitored Web page. 
  - Featuring valuable services to help you grow your business. 
- Alerts when your Web page is not available. 

Click here to automatically login to your account. You can easily add more 
URL's to monitor or make changes to your account.
http://www.internetseer.com/ep/my_internetseer.jsp?7g7j5YM42gX6v76OwPGwJxPD7671ExzT=e3
 
For your records, your login name and password are below: 

Login Name:	printing-driver at freestandards.org
Password:	473qhp22
 
-------------------------------------------------------------------------------
Your FREE Web site monitoring service is now activated.<br>
<br>
InternetSeer has arranged to offer you the following FREE Rewards. This is our way of saying thank you for doing business with us. Please take advantage of one or more of these great Registration Rewards.<br>
<br>
<img src="http://redir.internetseer.com/tr.jsp?79785YzAyD7j7lEPR7g7jQicpxX6v76OwPGwJxPD7671ExzTX7879OPP=e3"><b>300 FREE minutes of Business Long Distance<br>
How much do you pay for Business Long Distance?</b> Long Distance Rates as Low as 3.4 cents... 
Exclusively for InternetSeer Subscribers.  Reduce costs while you take control of long distance 
service.  Get the lowest rates and best customer service available in Business Long Distance. 
Plus get Online Account Management Tools, Toll-Free Numbers, and Virtual Calling Cards with 
just a few clicks.  <a href="http://redir.internetseer.com/tr.jsp?79785YWWTD7j7lEWR7g7jQigpxX6v76OwPGwJxPD7671ExzTX7879OPP=e3" target="_blank">Register Today and Receive 300 Free 
Minutes - Click Here!</a><br>
<br>
<b>Do-It-Yourself Email Marketing Solution! - 60-Day Free Trial</b><br>
Capture more sales with Constant Contact's email list builder, newsletter 
builder, and campaign manager.  Create explosive email campaigns in minutes... 
you have nothing to lose.  Try the leader in "Do-It-Yourself Email Marketing" 
FREE for 60 days! <a href="http://redir.internetseer.com/tr.jsp?79785YWWUD7j7lEWR7g7jQihpxX6v76OwPGwJxPD7671ExzTX7879OPP=e3" target="_blank">Sign-up Now!</a><br>
<br>
<b>Network & Web Site Security Service - No Risk Security Audit</b><br>
Is your Web site secure? Security Space's Web-based vulnerability assessment 
system will validate the security of critical network infrastructure, including 
routers, firewalls, web servers and mail servers. Over 1,500 vulnerabilities in 
all are checked in less than 24 hours.  <a href="http://redir.internetseer.com/tr.jsp?79785YWzTD7j7lEWR7g7jQidpxX6v76OwPGwJxPD7671ExzTX7879OPP=e3" target="_blank">
Get your NO RISK Audit now!</a><br>
<br>
<b>Web Traffic Analysis - 14 day Free Trial</b><br>
What Do You Know About Your Web Site Visitors?  Get more out of your marketing 
dollars by learning about your Web site visitors. EnterURL's Traffic Analysis 
offers the most comprehensive and lowest cost Web traffic statistics package.  
<a href="http://redir.internetseer.com/tr.jsp?79785YPUPD7j7lEWR7g7jQifpxX6v76OwPGwJxPD7671ExzTX7879OPP=e3" target="_blank">Sign up today for a 14 day FREE Trial and 
start collect information!</a><br>
<br>
Thank you and welcome to InternetSeer. Please let others know about our Service.<br>
<br>
Mike Dever<br>
CEO<br>
<br>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030109/24fb3488/attachment.htm 

From Bottamossboy at aol.com  Thu Jan 16 22:37:42 2003
From: Bottamossboy at aol.com (Bottamossboy at aol.com)
Date: Fri, 17 Jan 2003 01:37:42 EST
Subject: [printing-driver] brothers hp-630
Message-ID: <4a.16ad96aa.2b58feb6@aol.com>

 



From telesurcom at msn.com  Thu Jan 30 03:55:22 2003
From: telesurcom at msn.com (Vacations Tours)
Date: Thu, 30 Jan 2003 03:55:22
Subject: [printing-driver] gano sus vacaciones gratis en un crucero!!!
Message-ID: <E18eAUR-0005fN-00@base.freestandards.org>

Usted y su familia ganaron sus vacaciones "GRATIS"

8 dias y 7 noches en un crucero por el caribe!!!!!!!!!!!!!!!!

Reclame su premio, su numero de confirmacion es 055

LLAME YA!!!!

Llame gratis desde los Estados Unidos y Puerto Rico 1800-806-3646

Desde del exterior 001-305-379-8877



From IMC at mail.internetseer.com  Thu Mar 13 11:38:13 2003
From: IMC at mail.internetseer.com (Kane at InternetSeer)
Date: Thu, 13 Mar 2003 14:38:13 -0500 (EST)
Subject: [printing-driver] your course will arrive in 5-7 days
Message-ID: <11563404.1047584293742.JavaMail.promon@pm65>

An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030313/a5a56adb/attachment.htm 

From hamzy at us.ibm.com  Tue Mar 18 08:34:44 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Tue, 18 Mar 2003 10:34:44 -0600
Subject: [printing-driver] FSG Printer Working Group conference call 03/19/03
Message-ID: <OF0A61CB18.4C5A0FFB-ON86256CED.005880EA-86256CED.005B1247@us.ibm.com>




Wednesday, March 19

GMT 19:00
EST 14:00
CST 13:00
MST 12:00
PST 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Topics
      - should printer drivers use a common set of job properties
      - should job properties be passed all at once
      - should we use a named pipe (or similiar) to communicate to a driver
or can we use an API
      - should there be different pipes for each print job
      - should there be application presentation information that can be
queried
      - should there be different job properties for each page

Mark

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




From rlk at alum.mit.edu  Tue Mar 18 16:21:47 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Tue, 18 Mar 2003 19:21:47 -0500
Subject: [printing-driver] FSG Printer Working Group conference call 03/19/03
In-Reply-To: 
	<OF0A61CB18.4C5A0FFB-ON86256CED.005880EA-86256CED.005B1247@us.ibm.com>
	(hamzy@us.ibm.com)
References: <OF0A61CB18.4C5A0FFB-ON86256CED.005880EA-86256CED.005B1247@us.ibm.com>
Message-ID: <200303190021.h2J0LloL007457@dsl092-065-009.bos1.dsl.speakeasy.net>

   From: Mark Hamzy <hamzy at us.ibm.com>
   Date: Tue, 18 Mar 2003 10:34:44 -0600

   Wednesday, March 19

   GMT 19:00
   EST 14:00
   CST 13:00
   MST 12:00
   PST 11:00

   Tie Line:    650-3239
   Toll Free:   1-800-497-2024
   Toll Number: 1-719-457-3821
   Passcode:     160458

   Topics
	 - should printer drivers use a common set of job properties
	 - should job properties be passed all at once
	 - should we use a named pipe (or similiar) to communicate to a driver
   or can we use an API
	 - should there be different pipes for each print job
	 - should there be application presentation information that can be
   queried
	 - should there be different job properties for each page

Please make sure that the minutes from this get posted promptly.  I
can't attend this call (this little thing called work gets in the
way), but I have real interest in a number of these issues.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From hamzy at us.ibm.com  Wed Mar 19 13:57:13 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Wed, 19 Mar 2003 15:57:13 -0600
Subject: [printing-driver] FSG Printer Working Group meeting notes 03/19/03
Message-ID: <OFDA21D6CF.99A834A7-ON86256CEE.007023AF-86256CEE.0078986A@us.ibm.com>




Attendees:
  Ira
  Norm
  Claudia
  Till

We originally cancelled the meeting.  However, there was some
clarification of the proposed architectural points for the driver group.

* should printer drivers implement a required set of common job properties
(JP)?
  Examples of keys would be: orientation, form, tray, media, duplex,
resolution.

  + Should we use
       - one existing standard
          PWG well known values
(http://www.pwg.org/schemas/sm/latest/MediaWellKnownValues.xsd)
       - two or more existing standards
          PWG and/or JDF
       - a new standard

  + is support of the FSG's Job Ticket standard a requirement?

* should all JPs be passed in one call or only one JP for each call
  (requiring multiple calls to a driver)?

* can there be default job properties or must every property be set?

* should we use a named pipe (or similar) to communicate to a driver or
  can we use an API?

  + If an API, should that API implement a pipe under the covers?

* should there be different pipes for each print job or should the driver
  be required to multiplex between the jobs in one pipe?

* should there be application presentation information that can be
  queried?  Some examples are:
     printable page size
     resolution
     current color depth
     font metrics

* can there be different job properties for each page?

  + Can this can be optional?

* should we allow for future extensibility to support optional components
of
  a printer driver?

  + vector graphics

    - should we use existing vector language? (SVG, PDF)

    - can it be multiple languages?

    - should we require simulation?
      That is if a driver only accepts bitmaps, then create a raster image
      of the vector commands.  If a driver doesn't support rounded boxes
      but does support arcs and lines, then break a round box into
      multiple arc and line calls.

  + device fonts

* should we have an interface to query the printer's job dialog?
  This will allow for programmatic support of setting/querying the JPs.

     + grouping/structuring

     + constraints

     + type of data (boolean, int, float, string, password, etc)

* should we require a standard install path?
  /usr/lib/print/driver/drivername
  /usr/share/print/font/drivername/

Mark

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




From mike at easysw.com  Fri Mar 21 07:07:48 2003
From: mike at easysw.com (Michael Sweet)
Date: Fri, 21 Mar 2003 10:07:48 -0500
Subject: [printing-driver] FSG Printer Working Group meeting notes 03/19/03
In-Reply-To: <OFDA21D6CF.99A834A7-ON86256CEE.007023AF-86256CEE.0078986A@us.ibm.com>
References: <OFDA21D6CF.99A834A7-ON86256CEE.007023AF-86256CEE.0078986A@us.ibm.com>
Message-ID: <3E7B2AC4.3030401@easysw.com>

[My comments in-line...]

Mark Hamzy wrote:
 > ...
> * should printer drivers implement a required set of common job properties
> (JP)?
>   Examples of keys would be: orientation, form, tray, media, duplex,
> resolution.

We definitely need to refine this list, however from a PWG/IPP
perspective only the following attributes (and their -supported,
-default, and -actual counterparts) are probably applicable to
drivers themselves:

     copies
     finishings
     media or media-col
     orientation-requested
     print-quality
     printer-resolution
     sides

The notion of a form requires printing system support (or you
have to do it individually for each driver, which sucks), and
there are printing system implications as well (if a user asks
for a print on a form that isn't "mounted", then the job gets
held until the form is available or rejected; the driver might
only be involved to query the printer for the forms that are
installed...)

Trays (in IPP) are part of the media or media-col attribute,
as applicable.

>   + Should we use
>        - one existing standard
>           PWG well known values
> (http://www.pwg.org/schemas/sm/latest/MediaWellKnownValues.xsd)
>        - two or more existing standards
>           PWG and/or JDF
>        - a new standard

Stick with one standard.  If you have two standards, you don't
really have a standard unless you force compliance with both
(which may not be possible... :)

>   + is support of the FSG's Job Ticket standard a requirement?

I would say that the job ticket is a separate entity that the
printing system needs to digest and pass only the attributes
that the driver is interested in.

> * should all JPs be passed in one call or only one JP for each call
>   (requiring multiple calls to a driver)?

 From the CUPS standpoint, we pass them all in at once.  IJS does
them one-at-a-time for their interface, but when wrapped by CUPS
we just break them up and feed them ourselves, so passing them
all at once doesn't prevent the use of internal interfaces that
only take one option at a time (or have separate calls for each
option, like GIMP-print).  However, if you only pass them one at
a time you'll need to provide a start/end interface so that the
receiver can know when it is OK to start printing.

> * can there be default job properties or must every property be set?

Allow defaults.  If you don't, then it is impossible to target a
job to multiple printers which may not have exactly the same
attribute support.

> * should we use a named pipe (or similar) to communicate to a driver or
>   can we use an API?

My advice - stick to simple interfaces that don't require special
software or OS support to implement.  Doing so in CUPS has allowed
us to run on multiple platforms with multiple driver implementations,
each with their own architectures.  APIs are nice, but the underlying
interface needs to be implementable on multiple architectures.

Most definitely do NOT provide any direct interface between an
application and the driver.  Doing so opens up numerous security
holes and will kill any notion of multi-user printing.

> * should there be different pipes for each print job or should the driver
>   be required to multiplex between the jobs in one pipe?

Don't assume that the driver is a standalone process that will be
accessed for printing each job.  That sort of implementation has
its place for specialized devices, but does not scale and is a
nightmare for code maintenance, etc.

One of the "mistakes" we made in our original printing software
(ESP Print, before CUPS) was that each driver had its IO code
compiled in, so it was possible for some drivers to support only
the parallel port, some only network, etc.  Eventually we made
a common port API that allowed us to support the same interfaces
from all drivers, but we couldn't add new interfaces without
recompiling.

The printing system manages print jobs.  The print driver prints
them when the printing system tells it to.  If you implement a
persistent driver process, it can determine when to start a job
and should be allowed to tell the caller that it is busy.  That
will allow ANY kind of implementation, whether the driver is
running in-line or as an external server that the in-line stub
(in the case of CUPS) calls.

> * should there be application presentation information that can be
>   queried?  Some examples are:
>      printable page size
>      resolution
>      current color depth
>      font metrics

Yes, and this will be part of PAPI's capabilities API.

> * can there be different job properties for each page?

Yes, there often are.

>   + Can this can be optional?

No.  Documents often contain pages of different sizes or
orientations, and a driver MUST be able to handle this.
For some (old) devices, this may involve ending the current
job on the printer itself and starting a new one with the
new attributes - the driver MUST handle this itself.

> * should we allow for future extensibility to support optional components
> of
>   a printer driver?

Yes, of course.

>   + vector graphics
> 
>     - should we use existing vector language? (SVG, PDF)

SVG and PDF are excellent formats, but are too high-level for most
vector devices.

>     - can it be multiple languages?

Not at the same time, unless the format supports it.  For example,
PDF files can contain embedded PostScript objects.

>     - should we require simulation?
>       That is if a driver only accepts bitmaps, then create a raster image
>       of the vector commands.  If a driver doesn't support rounded boxes
>       but does support arcs and lines, then break a round box into
>       multiple arc and line calls.

Yes, all supported formats should be supported on all printers.
(and this is actually easy to do with a good filter framework...)

>   + device fonts

Device fonts are a tricky issue - in general, we don't trust device
fonts for anything other than plain ASCII text, and there are limits
to the support provided by printers.  For example, only specific
sizes or orientations may be supported, so some text may be rendered
by the device, and some by the driver/RIP (and that assumes that
your device font matches the font you have on the system... :)

In our internal development testing (ah, if we only had more time!)
we found that rendering system fonts as vectors offered similar
speed/quality gains and made the interface simpler when printing
a mix of text and graphics.

> * should we have an interface to query the printer's job dialog?
>   This will allow for programmatic support of setting/querying the JPs.
> 
>      + grouping/structuring
> 
>      + constraints
> 
>      + type of data (boolean, int, float, string, password, etc)

I'm not sure I understand this question, but assuming that you
are looking for an API to populate a print dialog, the PAPI
capabilities API is what you are looking for.

The printing system should cache the cap data that the driver
supplies; in CUPS this data is stored in a PPD file, but you
could just as easily use UPDF or some other text-based format.
The advantage of using a cached version is performance (the
data is only updated when things change) and simplicity; apps
can read the cap data locally or over the network if the
printing system supports it, e.g.:

     http://cupsserver:631/printers/name.ppd

> * should we require a standard install path?
>   /usr/lib/print/driver/drivername
>   /usr/share/print/font/drivername/

This is highly printing-system dependent, and you have no guarantee
that a print driver will be a single executable, DSO, etc.

That said, it might be more productive to define a standard
command that is used to install a printer driver and its data
files (probably using a .inf or similar file that lists the
files to be installed...)  That way each printing system can
support "FSG" printer drivers in the best way possible for
that system.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com






From hamzy at us.ibm.com  Mon Mar 24 11:30:36 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 24 Mar 2003 13:30:36 -0600
Subject: [printing-driver] FSG Printer Working Group conference call 03/26/03
Message-ID: <OFC5111351.DFB34EDB-ON86256CF3.006ACF5B-86256CF3.006B2C0C@us.ibm.com>




Wednesday, March 26

GMT 19:00
EST 14:00
CST 13:00
MST 12:00
PST 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:    160458

Topics

* should printer drivers implement a required set of common job properties
(JP)?
  Examples of keys would be: orientation, form, tray, media, duplex,
resolution.

  + Should we use
       - one existing standard
          PWG well known values (
http://www.pwg.org/schemas/sm/latest/MediaWellKnownValues.xsd)
       - two or more existing standards
          PWG and/or JDF
       - a new standard

  + is support of the FSG's Job Ticket standard a requirement?

* should all JPs be passed in one call or only one JP for each call
  (requiring multiple calls to a driver)?

* can there be default job properties or must every property be set?

* should we use a named pipe (or similar) to communicate to a driver or
  can we use an API?

  + If an API, should that API implement a pipe under the covers?

* should there be different pipes for each print job or should the driver
  be required to multiplex between the jobs in one pipe?

* should there be application presentation information that can be
  queried?  Some examples are:
     printable page size
     resolution
     current color depth
     font metrics

* can there be different job properties for each page?

  + Can this can be optional?

* should we allow for future extensibility to support optional components
of
  a printer driver?

  + vector graphics

    - should we use existing vector language? (SVG, PDF)

    - can it be multiple languages?

    - should we require simulation?
      That is if a driver only accepts bitmaps, then create a raster image
      of the vector commands.  If a driver doesn't support rounded boxes
      but does support arcs and lines, then break a round box into
      multiple arc and line calls.

  + device fonts

* should we have an interface to query the printer's job dialog?
  This will allow for programmatic support of setting/querying the JPs.

     + grouping/structuring

     + constraints

     + type of data (boolean, int, float, string, password, etc)

* should we require a standard install path?
  /usr/lib/print/driver/drivername
  /usr/share/print/font/drivername/

Mark

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




From rlk at alum.mit.edu  Mon Mar 24 17:16:35 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Mon, 24 Mar 2003 20:16:35 -0500
Subject: [printing-driver] FSG Printer Working Group conference call 03/26/03
In-Reply-To: 
	<OFC5111351.DFB34EDB-ON86256CF3.006ACF5B-86256CF3.006B2C0C@us.ibm.com>
	(hamzy@us.ibm.com)
References: <OFC5111351.DFB34EDB-ON86256CF3.006ACF5B-86256CF3.006B2C0C@us.ibm.com>
Message-ID: <200303250116.h2P1GZVc009025@dsl092-065-009.bos1.dsl.speakeasy.net>

   From: Mark Hamzy <hamzy at us.ibm.com>
   Date: Mon, 24 Mar 2003 13:30:36 -0600

   * should printer drivers implement a required set of common job properties
   (JP)?
     Examples of keys would be: orientation, form, tray, media, duplex,
   resolution.

These certainly don't apply to all printers; most inkjets don't
support duplex, and many also don't have selectable input sources.
I'd prefer to see a list of standard job properties that could be
amended, and standards (and/or a registry) for drivers to support
non-standard properties (such as the whole mess of things Gimp-print
supports).

     + Should we use
	  - one existing standard
	     PWG well known values (
   http://www.pwg.org/schemas/sm/latest/MediaWellKnownValues.xsd)
	  - two or more existing standards
	     PWG and/or JDF
	  - a new standard

I don't like the fixed values at all; they basically try to force all
papers into specific niches.  For example, Epson offers a number of
different photographic papers (Photo Paper, Premium Glossy Photo
Paper, Premium Semiglosss, etc.), and each one has different
characteristics.  There are a lot of third party papers as well, and
these also have different characteristics.  Having the
MediaTypeExtensionPattern is fine, but on Epson (and other inkjet)
printers, "photographic-glossy" simply isn't a very useful
description; there are enormous differences between different
photographic-glossy papers, and it's important for the user to specify
the precise paper by name.  Subtle differences in the coating (which
users generally can't distinguish except by name) require great
differences; for example, when printing to Premium Glossy on the
Stylus C80, it's important to not use black ink, which is formulated
differently and doesn't adhere correctly to the paper.  Other glossy
photo papers should be printed with black ink, however.

   * should all JPs be passed in one call or only one JP for each call
     (requiring multiple calls to a driver)?

I'd vote for all at once.  It doesn't enormously matter for
Gimp-print, but it may make it easier for drivers to sanity check
early.

   * can there be default job properties or must every property be set?

Defaults should be allowed.  For example (using a Gimp-print
property), a user should not have to specify the ink type; the driver
should pick it automatically.

   * should we use a named pipe (or similar) to communicate to a driver or
     can we use an API?

stdin/stdout/stderr

   * should there be application presentation information that can be
     queried?  Some examples are:
	printable page size
	resolution
	current color depth
	font metrics

Yes.  It should be possible for the application to determine
e. g. what the current settings are.

   * can there be different job properties for each page?

     + Can this can be optional?

I don't much like it, but Mike presents a good case, and anyway
Gimp-print is really page-oriented anyway.

   * should we allow for future extensibility to support optional components
   of
     a printer driver?

       - should we require simulation?
	 That is if a driver only accepts bitmaps, then create a raster image
	 of the vector commands.  If a driver doesn't support rounded boxes
	 but does support arcs and lines, then break a round box into
	 multiple arc and line calls.

Yes.  The higher level software should break these things down as
appropriate.  Otherwise drivers have to duplicate code.

   * should we have an interface to query the printer's job dialog?
     This will allow for programmatic support of setting/querying the JPs.

Yes.  This actually maps very well to Gimp-print, particularly in
4.3.  It's a lot more flexible than a static file; expressing
constraints using boolean logic can get extremely complex.

	+ grouping/structuring

	+ constraints

	+ type of data (boolean, int, float, string, password, etc)

Add curve, vector, and raw to that, and I'll be happy.  Gimp-print
also supports file, but neither the Ghostscript nor the CUPS driver
supports this for security reasons (the only thing that uses it is the
GIMP plugin, so the Postscript family driver can find a PPD file).

   * should we require a standard install path?
     /usr/lib/print/driver/drivername
     /usr/share/print/font/drivername/

This is much too system-specific.  Obviously Windows will have
different conventions from UNIX (what, me defend Windows?), and
different UNIX versions/Linux distributions have different
conventions.  The printing system should manage that.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From mike at easysw.com  Mon Mar 24 18:13:35 2003
From: mike at easysw.com (Mike Sweet)
Date: Mon, 24 Mar 2003 21:13:35 -0500
Subject: [Printing-architecture] Re: [printing-driver] FSG Printer Working
 Group conference call 03/26/03
In-Reply-To: <200303250116.h2P1GZVc009025@dsl092-065-009.bos1.dsl.speakeasy.net>
References: <OFC5111351.DFB34EDB-ON86256CF3.006ACF5B-86256CF3.006B2C0C@us.ibm.com> <200303250116.h2P1GZVc009025@dsl092-065-009.bos1.dsl.speakeasy.net>
Message-ID: <3E7FBB4F.4040503@easysw.com>

Robert L Krawitz wrote:
>    From: Mark Hamzy <hamzy at us.ibm.com>
>    Date: Mon, 24 Mar 2003 13:30:36 -0600
> 
>    * should printer drivers implement a required set of common job properties
>    (JP)?
>      Examples of keys would be: orientation, form, tray, media, duplex,
>    resolution.
> 
> These certainly don't apply to all printers; most inkjets don't
> support duplex, and many also don't have selectable input sources.
> I'd prefer to see a list of standard job properties that could be
> amended, and standards (and/or a registry) for drivers to support
> non-standard properties (such as the whole mess of things Gimp-print
> supports).

WRT the sides (duplex) attribute, the related sides-supported
attribute lists the supported values.  For a printer that does
not support duplexing, the only supported value will be
"one-sided".

As for the property "registry", that is one topic for the
capabilities API that will be part of PAPI 2.0 (or 1.1, or
whatever).  At present, it looks like we'll have an attribute
that lists the available job template attributes, additional
attributes to handle simple constraints, and finally an API
for doing round-trip constraint checks.

> ...
>    * should we have an interface to query the printer's job dialog?
>      This will allow for programmatic support of setting/querying the JPs.
> 
> Yes.  This actually maps very well to Gimp-print, particularly in
> 4.3.  It's a lot more flexible than a static file; expressing
> constraints using boolean logic can get extremely complex.

First, we need static files (or the equivalent attributes) for
the UI; there cannot be a direct interface between app and driver,
otherwise we're repeating the same old errors that have been
cursed on Windows.

Second, all constraints can be expressed using boolean logic;
putting them in code or in a file doesn't matter much - the
same amount of complexity is required either way.  Keep in mind
that we are planning on providing a constraint mechanism that
is a superset of that supported by PPD and that there will still
be a way to do full round-trip constraint checks through the
printing system (if supported); the latter checks are meant for
sanity checks when submitting options/jobs and not for on-the-fly
constraint checking when a user changes an option.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike at easysw.com
Printing Software for UNIX                       http://www.easysw.com




From rlk at alum.mit.edu  Mon Mar 24 18:42:14 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Mon, 24 Mar 2003 21:42:14 -0500
Subject: [Printing-architecture] Re: [printing-driver] FSG Printer Working
 Group conference call 03/26/03
In-Reply-To: <3E7FBB4F.4040503@easysw.com> (mike@easysw.com)
References: <OFC5111351.DFB34EDB-ON86256CF3.006ACF5B-86256CF3.006B2C0C@us.ibm.com> <200303250116.h2P1GZVc009025@dsl092-065-009.bos1.dsl.speakeasy.net> <3E7FBB4F.4040503@easysw.com>
Message-ID: <200303250242.h2P2gEia009925@dsl092-065-009.bos1.dsl.speakeasy.net>

   Date: Mon, 24 Mar 2003 21:13:35 -0500
   From: Mike Sweet <mike at easysw.com>

   >    * should we have an interface to query the printer's job dialog?
   >      This will allow for programmatic support of setting/querying the JPs.
   > 
   > Yes.  This actually maps very well to Gimp-print, particularly in
   > 4.3.  It's a lot more flexible than a static file; expressing
   > constraints using boolean logic can get extremely complex.

   First, we need static files (or the equivalent attributes) for the
   UI; there cannot be a direct interface between app and driver,
   otherwise we're repeating the same old errors that have been cursed
   on Windows.

True; I guess I glossed over the "job dialog" part.  However, I don't
think that there actually need to be static files; an API to the
printing system (whereby the printing system acts as an abstraction
barrier between the application and the driver) would also accomplish
this end.  The back end of this could be whatever the driver and the
printing system agree on: it could be a PPD file for some drivers and
an interface module (like rastertoprinter or ijsgimpprint) between the
driver and the printing system for others.

   Second, all constraints can be expressed using boolean logic;
   putting them in code or in a file doesn't matter much - the same
   amount of complexity is required either way.

Not necessarily; the internal logic might be dynamic, based on the
printer state (e. g. the driver might want to offer only options that
are actually installed on the printer), or it might reference internal
driver logic that's unwieldly to express via logic or simply doesn't
need to be exposed to the application.  To illustrate what I mean, the
compressed Gimp-print PPD files for the Epson Stylus printers total
1440 KB (each one totals about 12 KB; the entire compressed source
code for the Epson family driver totals 48 KB, even though Gimp-print
doesn't query printer status (it does offer dynamic options based on
the state of other options).
						 
						 Keep in mind that we
   are planning on providing a constraint mechanism that is a superset
   of that supported by PPD and that there will still be a way to do
   full round-trip constraint checks through the printing system (if
   supported); the latter checks are meant for sanity checks when
   submitting options/jobs and not for on-the-fly constraint checking
   when a user changes an option.

Can it express certain options being entirely unavailable in some
circumstances (e. g. when the user chooses to print in black and
white, color controls should be disabled)?

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From pzaan at us.ibm.com  Tue Mar 25 06:06:22 2003
From: pzaan at us.ibm.com (Pete Zannucci)
Date: Tue, 25 Mar 2003 08:06:22 -0600
Subject: [Printing-architecture] Re: [printing-driver] FSG Printer Working Group
 conference call 03/26/03
Message-ID: <OF4F5F0FA3.10E5FF1A-ON85256CF4.004B44C5@pok.ibm.com>




From: Robert L Krawitz <rlk at alum.mit.edu>

> True; I guess I glossed over the "job dialog" part.  However, I don't
> think that there actually need to be static files; an API to the
> printing system (whereby the printing system acts as an abstraction
> barrier between the application and the driver) would also accomplish
> this end.  The back end of this could be whatever the driver and the
> printing system agree on: it could be a PPD file for some drivers and
> an interface module (like rastertoprinter or ijsgimpprint) between the
> driver and the printing system for others.


The goal should be to abstract away the ugliness of the system and
provide a clean simple API for the application.  Applications should
not be concerned about the underlying architecture or implementation.

Secondly it would be nice if we could agree upon a single format for
storage of the properties based on the current printer configuration.
The driver/backend could use whatever mechanism it wants to use for
generating or using information internally but if properties could
be stored by the print system/driver when settings change or at
install/config time in a common database, that will ease the burden of
having to put translation layers in for each of the formats going to
the application interface.  This would allow consistent information be
returned to the app.  It would also solve a lot of portability issues
between systems and make the interface consistent and less error prone.




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) pzaan at us.ibm.com







From mike at easysw.com  Tue Mar 25 07:22:09 2003
From: mike at easysw.com (Michael Sweet)
Date: Tue, 25 Mar 2003 10:22:09 -0500
Subject: [Printing-architecture] Re: [printing-driver] FSG Printer Working
 Group conference call 03/26/03
In-Reply-To: <200303250242.h2P2gEia009925@dsl092-065-009.bos1.dsl.speakeasy.net>
References: <OFC5111351.DFB34EDB-ON86256CF3.006ACF5B-86256CF3.006B2C0C@us.ibm.com> <200303250116.h2P1GZVc009025@dsl092-065-009.bos1.dsl.speakeasy.net> <3E7FBB4F.4040503@easysw.com> <200303250242.h2P2gEia009925@dsl092-065-009.bos1.dsl.speakeasy.net>
Message-ID: <3E807421.9050508@easysw.com>

Robert L Krawitz wrote:
> ...
>    First, we need static files (or the equivalent attributes) for the
>    UI; there cannot be a direct interface between app and driver,
>    otherwise we're repeating the same old errors that have been cursed
>    on Windows.
> 
> True; I guess I glossed over the "job dialog" part.  However, I don't
> think that there actually need to be static files; an API to the
> printing system (whereby the printing system acts as an abstraction
> barrier between the application and the driver) would also accomplish
> this end.  The back end of this could be whatever the driver and the
> printing system agree on: it could be a PPD file for some drivers and
> an interface module (like rastertoprinter or ijsgimpprint) between the
> driver and the printing system for others.

Right, but from the application/PAPI standpoint, that interface
is hidden.

(and from the CUPS standpoint, we *will not* be supporting a
direct scheduler<->driver interface, as that opens up serious
security and performance issues...)

>    Second, all constraints can be expressed using boolean logic;
>    putting them in code or in a file doesn't matter much - the same
>    amount of complexity is required either way.
> 
> Not necessarily; the internal logic might be dynamic, based on the
> printer state (e. g. the driver might want to offer only options that
> are actually installed on the printer), or it might reference internal
> driver logic that's unwieldly to express via logic or simply doesn't
> need to be exposed to the application.  To illustrate what I mean, the

First, "dynamic" logic based upon the current printer state is not
dynamic - it is static logic based upon dynamic information,
something that the current design allows for and is already
implemented with some drivers in PPD files for CUPS.

> compressed Gimp-print PPD files for the Epson Stylus printers total
> 1440 KB (each one totals about 12 KB; the entire compressed source
> code for the Epson family driver totals 48 KB, even though Gimp-print
> doesn't query printer status (it does offer dynamic options based on
> the state of other options).

That's not a valid comparison - you'd need to compare the size of
the constraints in PPD files to the constraints in code.  IIRC,
there are *no* constraints in the current GIMP-print PPD files...

Any textual representation of attributes, constraints, etc. will
generally be larger than the compiled code that uses them - it
doesn't matter whether this data is in a static file (PPD, UPDF,
etc.) or is passed via a direct interface.

That said, using a separate data store (file and/or attributes in
memory) to hold this information has several pleasant effects:

     1. Apps can locally resolve constraints in real-time
        (for the user: things work faster) vs. round-trip
        delays and resending of every selected attribute.

     2. Drivers can be totally data-based, allowing new devices
        to be added relatively easily (barring major format/
        protocol changes requiring new support code)

     3. Printer/driver state and capability information can be
        provided locally and over the network to multiple
        platforms, and can be converted to any designed format
        or interface.

 > ...
> Can it express certain options being entirely unavailable in some
> circumstances (e. g. when the user chooses to print in black and
> white, color controls should be disabled)?

Certainly, as can PPD files...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com






From rlk at alum.mit.edu  Tue Mar 25 17:37:33 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Tue, 25 Mar 2003 20:37:33 -0500
Subject: [Printing-architecture] Re: [printing-driver] FSG Printer Wor
	king Group conference call 03/26/03
In-Reply-To: <A134E2426B46D711BB4B000347AE6E7CAA532D@xvan02.vcd.hp.com>
	(bobt@hp.com)
References: <A134E2426B46D711BB4B000347AE6E7CAA532D@xvan02.vcd.hp.com>
Message-ID: <200303260137.h2Q1bX19023295@dsl092-065-009.bos1.dsl.speakeasy.net>

   From: "TAYLOR,BOB (HP-Vancouver,ex1)" <bobt at hp.com>
   Date: Tue, 25 Mar 2003 14:14:33 -0500

   <bt>
   Agreed - and note that this is a good example of why we need to be able
   to pass localized UI strings through the capabilities interface as well.
   I don't think it's a reasonable expectation that all of these
   rapidly-evolving
   vendor-specific media types will be registered, much less actually supported
   with localized strings in most clients.
   </bt>

Right.

   >    * should we have an interface to query the printer's job dialog?
   >      This will allow for programmatic support of 
   > setting/querying the JPs.
   > 
   > Yes.  This actually maps very well to Gimp-print, 
   > particularly in 4.3.  It's a lot more flexible than a static 
   > file; expressing constraints using boolean logic can get 
   > extremely complex.

   Note that you end up defining these constraints someplace anyway -
   the question is whether you do it in code that's bound to an
   implementation or in a data structure that can be evaluated in many
   implementations.

The flat file's already bound to the implementation; a Gimp-print PPD
file won't work with the HPIJS driver and vice versa.  IMHO, an
application should neither know nor care whether the back end is a PPD
file, an XML file of some kind, a driver, or even a relational
database of some kind.  There should be an API by which it can get
this information from the core printing system.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From rlk at alum.mit.edu  Tue Mar 25 17:56:39 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Tue, 25 Mar 2003 20:56:39 -0500
Subject: [Printing-architecture] Re: [printing-driver] FSG Printer Working
 Group conference call 03/26/03
In-Reply-To: <3E807421.9050508@easysw.com> (mike@easysw.com)
References: <OFC5111351.DFB34EDB-ON86256CF3.006ACF5B-86256CF3.006B2C0C@us.ibm.com> <200303250116.h2P1GZVc009025@dsl092-065-009.bos1.dsl.speakeasy.net> <3E7FBB4F.4040503@easysw.com> <200303250242.h2P2gEia009925@dsl092-065-009.bos1.dsl.speakeasy.net> <3E807421.9050508@easysw.com>
Message-ID: <200303260156.h2Q1udkt023508@dsl092-065-009.bos1.dsl.speakeasy.net>

   From: Michael Sweet <mike at easysw.com>
   Date: Tue, 25 Mar 2003 10:22:09 -0500

   Robert L Krawitz wrote:
   > ...
   >    First, we need static files (or the equivalent attributes) for the
   >    UI; there cannot be a direct interface between app and driver,
   >    otherwise we're repeating the same old errors that have been cursed
   >    on Windows.
   > 
   > True; I guess I glossed over the "job dialog" part.  However, I
   > don't think that there actually need to be static files; an API
   > to the printing system (whereby the printing system acts as an
   > abstraction barrier between the application and the driver) would
   > also accomplish this end.  The back end of this could be whatever
   > the driver and the printing system agree on: it could be a PPD
   > file for some drivers and an interface module (like
   > rastertoprinter or ijsgimpprint) between the driver and the
   > printing system for others.

   Right, but from the application/PAPI standpoint, that interface is
   hidden.

Agreed; the application shouldn't know where the data comes from.

BTW, whatever the driver interface looks like, I could see a use for
a back end other than a file -- suppose a large company wants to have
a common set of printing options for all of its printers; it could use
a network service to distribute the printing information, rather than
having to copy flat files to every single workstation in the company.

   (and from the CUPS standpoint, we *will not* be supporting a
   direct scheduler<->driver interface, as that opens up serious
   security and performance issues...)

What's the security issue?

   > Not necessarily; the internal logic might be dynamic, based on the
   > printer state (e. g. the driver might want to offer only options that
   > are actually installed on the printer), or it might reference internal
   > driver logic that's unwieldly to express via logic or simply doesn't
   > need to be exposed to the application.  To illustrate what I mean, the

   First, "dynamic" logic based upon the current printer state is not
   dynamic - it is static logic based upon dynamic information,
   something that the current design allows for and is already
   implemented with some drivers in PPD files for CUPS.

True enough.

   > compressed Gimp-print PPD files for the Epson Stylus printers total
   > 1440 KB (each one totals about 12 KB; the entire compressed source
   > code for the Epson family driver totals 48 KB, even though Gimp-print
   > doesn't query printer status (it does offer dynamic options based on
   > the state of other options).

   That's not a valid comparison - you'd need to compare the size of
   the constraints in PPD files to the constraints in code.  IIRC,
   there are *no* constraints in the current GIMP-print PPD files...

All right, that's fair enough.

Another issue that didn't occur to me last night is that actually
going through and computing the constraints (to generate PPD
constraints) is expensive; in principle, genppd would have to set all
of the option to all of the possible values to determine the legal
combinations.  While in practice it's not that bad, it's much easier
to determine the legal values for a given option in the context of all
other current settings.

(Ironically, the reason it's not actually "all that bad" is because
Gimp-print's very permissive -- it's perfectly happy to let you set
2880x1440 with 7-color inks printing line art to plain paper, and it's
also willing to let you print full bleed on all paper sizes, not just
those where there's a pad under the carriage to catch the ink that
bleeds over.  It's also very happy to let you set arbitrary options
that aren't used by the current driver, and simply ignores them.)

   Any textual representation of attributes, constraints, etc. will
   generally be larger than the compiled code that uses them - it
   doesn't matter whether this data is in a static file (PPD, UPDF,
   etc.) or is passed via a direct interface.

I was comparing it to the source code, not the compiled code.

   That said, using a separate data store (file and/or attributes in
   memory) to hold this information has several pleasant effects:

	2. Drivers can be totally data-based, allowing new devices
	   to be added relatively easily (barring major format/
	   protocol changes requiring new support code)

I have no objection to this at all; I'd just like to see other options
available for drivers that are more complicated.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From rlk at alum.mit.edu  Tue Mar 25 18:01:05 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Tue, 25 Mar 2003 21:01:05 -0500
Subject: [Printing-architecture] Re: [printing-driver] FSG Printer Working Group
 conference call 03/26/03
In-Reply-To: <OF4F5F0FA3.10E5FF1A-ON85256CF4.004B44C5@pok.ibm.com>
	(pzaan@us.ibm.com)
References: <OF4F5F0FA3.10E5FF1A-ON85256CF4.004B44C5@pok.ibm.com>
Message-ID: <200303260201.h2Q2155Z023588@dsl092-065-009.bos1.dsl.speakeasy.net>

   From: "Pete Zannucci" <pzaan at us.ibm.com>
   Date: Tue, 25 Mar 2003 08:06:22 -0600

   From: Robert L Krawitz <rlk at alum.mit.edu>

   > True; I guess I glossed over the "job dialog" part.  However, I
   > don't think that there actually need to be static files; an API
   > to the printing system (whereby the printing system acts as an
   > abstraction barrier between the application and the driver) would
   > also accomplish this end.  The back end of this could be whatever
   > the driver and the printing system agree on: it could be a PPD
   > file for some drivers and an interface module (like
   > rastertoprinter or ijsgimpprint) between the driver and the
   > printing system for others.

   The goal should be to abstract away the ugliness of the system and
   provide a clean simple API for the application.  Applications
   should not be concerned about the underlying architecture or
   implementation.

Agreed.  It's the back end (from the printing system on down) I'm
talking about.

   Secondly it would be nice if we could agree upon a single format
   for storage of the properties based on the current printer
   configuration.  The driver/backend could use whatever mechanism it
   wants to use for generating or using information internally but if
   properties could be stored by the print system/driver when settings
   change or at install/config time in a common database, that will
   ease the burden of having to put translation layers in for each of
   the formats going to the application interface.  This would allow
   consistent information be returned to the app.  It would also solve
   a lot of portability issues between systems and make the interface
   consistent and less error prone.

BTW, how would we represent ICC profiles (for example)?

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From mike at easysw.com  Tue Mar 25 20:31:44 2003
From: mike at easysw.com (Mike Sweet)
Date: Tue, 25 Mar 2003 23:31:44 -0500
Subject: [Printing-architecture] Re: [printing-driver] FSG Printer Working
 Group conference call 03/26/03
In-Reply-To: <200303260156.h2Q1udkt023508@dsl092-065-009.bos1.dsl.speakeasy.net>
References: <OFC5111351.DFB34EDB-ON86256CF3.006ACF5B-86256CF3.006B2C0C@us.ibm.com> <200303250116.h2P1GZVc009025@dsl092-065-009.bos1.dsl.speakeasy.net> <3E7FBB4F.4040503@easysw.com> <200303250242.h2P2gEia009925@dsl092-065-009.bos1.dsl.speakeasy.net> <3E807421.9050508@easysw.com> <200303260156.h2Q1udkt023508@dsl092-065-009.bos1.dsl.speakeasy.net>
Message-ID: <3E812D30.40701@easysw.com>

Robert L Krawitz wrote:
 > ...
>    (and from the CUPS standpoint, we *will not* be supporting a
>    direct scheduler<->driver interface, as that opens up serious
>    security and performance issues...)
> 
> What's the security issue?

The two main ones are:

     1. If we directly connect to the driver/library, then any buffer
        overflows in the driver/library might be exploited to gain
        root access.  Thus, we won't directly connect...

     2. If we indirectly connect to the driver/library, and do it
        "safely" with a non-priviledged user with pipes to and from
        the backend so the driver can communicate with the device,
        we run the risk of a DoS attack if more than one user wants
        to print at the same time and needs the "dynamic" driver
        data.  This also falls under the performance umbrella...

The mechanism we will be using in CUPS 1.2 is an asynchronous
device daemon with a "port monitor" facility that will allow
developers to provide printer driver filter(s) and a "port
monitor" program; the filter(s) will handle the production of
data suitable for the printer, while the (optional) port
monitor handles printer queries, data encoding, etc.  One other
task for the port monitor is periodic status updates via the
device monitor - this will allow the port monitor to update the
PPD file for current device configuration, update the printer
object for current state, etc.

> ...
> Another issue that didn't occur to me last night is that actually
> going through and computing the constraints (to generate PPD
> constraints) is expensive; in principle, genppd would have to set all
> of the option to all of the possible values to determine the legal
> combinations.  While in practice it's not that bad, it's much easier
> to determine the legal values for a given option in the context of all
> other current settings.
 > ...

I have some code we're using for the HP APDK drivers in ESP Print
Pro (those are the same ones that come in HP IJS, although the IJS
drivers are stripped down in comparison...) that may come in handy
for doing the basic constraints.  It isn't that bad for the
relatively small number of drivers we have to generate PPD files
for...

Ideally we should be able to provide a GIMP-print API for
retrieving the driver constraints and/or put all of the driver-
specific data in the printers.xml file so that the driver and
PPD files are data driven and not hardcoded.  This would also
make it possible for programmatic PPD file generation - CUPS
would ask GIMP-print for a list of the drivers it supports
along with "virtual" PPD filenames, and then CUPS can have
GIMP-print write the PPD file in /etc/cups/ppd as requested by
the administrator.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike at easysw.com
Printing Software for UNIX                       http://www.easysw.com




From hamzy at us.ibm.com  Wed Mar 26 15:51:07 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Wed, 26 Mar 2003 17:51:07 -0600
Subject: [printing-driver] FSG Printer Working Group meeting notes 03/26/03
Message-ID: <OF681B092B.0DF4A39F-ON86256CF5.0081DB93-86256CF5.008305E7@us.ibm.com>




Attendees:
Mark Hamzy
Charles Hemstreet
Norm Jacobs
Till Kamppeter
Ira McDonald
Glen Petrie
David Suffield

Meeting notes:

> * should printer drivers implement a required set of common job
properties (JP)?
>   Examples of keys would be: orientation, form, tray, media, duplex,
resolution.

Yes. We talked about two examples.

   resolution
      integerXinteger
   quality (level of effort in a print job)
      draft, normal, presentation, high, etc...

Future issues are:
   * should we allow structured JPs?  That is, a complex JP that binds two
or more
     simple JPs in it.  Ex:  form, tray, and media could be combined into
one JP.
     We could also have extra informational data in the JP value.  Ex:  the
form
     key could have data that describes if it is installed in the printer.
On a
     query return forms = "letter_installed, legal_notinstalled, ..." and
on a set
     only look at the first part.  This of course would require the driver
to
     hold/fail a job that does not have a form installed in the printer.

>   + Should we use
>        - one existing standard
>           PWG well known values
(http://www.pwg.org/schemas/sm/latest/MediaWellKnownValues.xsd)
>        - two or more existing standards
>           PWG and/or JDF
>        - a new standard

One standard.

>   + is support of the FSG's Job Ticket (JT) standard a requirement?

Yes.  Supporting the key=values from the JT is a requirement.  This would
lead us to
consider the JT keys and values as the standard to use.  We need to make
sure that
all printer drivers have either a mapping from their old keys/values to the
new
JT keys/values or have their keys and values added to the JT standard.

In the future we may want to support JT better by allowing printing of a
job
with just the JT.

> * should all JPs be passed in one call or only one JP for each call
>   (requiring multiple calls to a driver)?

One worry is size of data if all are passed in at once.  One solution that
is
proposed is to query the driver for the number of key/values that can be
passed
in one call.
   PDC                         driver
   PDC queries the driver
   begin JP keys/values     ->
                               driver returns a number which can be the
following
                            <- all
                            <- 1
                            <- number
   PDC sends the key/values
   ...
   PDC notifies the end
   end JP keys/values       ->
                               driver returns success or failure
                            <- success
                            <- failure

In this approach, drivers that need all of the data at once will work and
driver that need only one at a time will work.

> * can there be default job properties or must every property be set?

We decided that default JPs are allowed.  For example, a print job
can be sent with "form=legal" as all of the JPs.

New issues that occurred during the meeting:
   * should there be API to set/query default job properties?

     Yes.

   * should there be multiple named storage areas with default job
properties?

     It should be optional that the default JP set can have a named
storage.

> * should we use a named pipe (or similar) to communicate to a driver or
>   can we use an API?
>
>   + If an API, should that API implement a pipe under the covers?

We decided to use an API.  That API can then use named pipes or some other
communications protocol under the covers.

Future issues are:
   * should we use a structured data message format?

      + should it be
         - XML
         - a simple human readable ASCII string encoding
         - binary
            ~ big-endian/little-endian
            ~ 8-bit clean

      + should it have a length in the structure?

         - 20-octet end-of-string marker instead of sizeof structure

> * should there be different pipes for each print job or should the driver
>   be required to multiplex between the jobs in one pipe?

We decided that supporting different jobs at the same time should be
optional.
   PDC                         driver
   PDC queries the driver
   accept another job       ->
                               driver returns success/failure
                            <- yes
                            <- no

Future issues are:
   - should this be a capability?

> * should there be application presentation information that can be
>   queried?  Some examples are:
>      printable page size
>      resolution
>      current color depth
>      font metrics

Yes.

Future issues are:
   - should there be a driver level of capabilities where an application
can ask
     for a device that supports a certain resolution and page size.  This
could be
     optional.

> * can there be different job properties for each page?
>
>   + Can this can be optional?

Yes.  If a device cannot handle switching job properties on a new page,
then
the driver should stop the print job and start another one.

> * should we allow for future extensibility to support optional components
of
>   a printer driver?

Yes.

>   + vector graphics
>
>     - should we use existing vector language? (SVG, PDF)
>
>     - can it be multiple languages?
>
>     - should we require simulation?
>       That is if a driver only accepts bitmaps, then create a raster
image
>       of the vector commands.  If a driver doesn't support rounded boxes
>       but does support arcs and lines, then break a round box into
>       multiple arc and line calls.
>
>   + device fonts

Unicode font metrics can be a large message.

>
> * should we have an interface to query the printer's job dialog?
>   This will allow for programmatic support of setting/querying the JPs.

Yes.  This should be part of the capabilities.

>      + grouping/structuring
>
>      + constraints
>
>      + type of data (boolean, int, float, string, password, etc)

> * should we require a standard install path?
>   /usr/lib/print/driver/drivername
>   /usr/share/print/font/drivername/

This question was asked because we need some method of detectability or
discoverability of installed drivers.  This can be as simple as an ini file
that is found at a certain location.  This file can contain:
   - what driver is installed
   - where it is located
   - how do I communicate with it

Future issues are:
   - should there be calls to the driver to notify when the driver is
      + installed
      + uninstalled
      + upgraded


Mark

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




From rlk at alum.mit.edu  Wed Mar 26 16:54:53 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Wed, 26 Mar 2003 19:54:53 -0500
Subject: [Printing-architecture] Re: [printing-driver] FSG Printer Wor
	 king Group conference call 03/26/03
In-Reply-To: <A134E2426B46D711BB4B000347AE6E7CAA5344@xvan02.vcd.hp.com>
	(bobt@hp.com)
References: <A134E2426B46D711BB4B000347AE6E7CAA5344@xvan02.vcd.hp.com>
Message-ID: <200303270054.h2R0srrq001356@dsl092-065-009.bos1.dsl.speakeasy.net>

   From: "TAYLOR,BOB (HP-Vancouver,ex1)" <bobt at hp.com>
   Date: Wed, 26 Mar 2003 10:33:53 -0500

   There should be an API - but the API needs some kind of data model.
   I'd rather see this API adopt one of the more flexible existing
   data models (PSI capabilities, UPDF, ...) that make yet another,
   which just adds another translation into the pile - and in many
   cases, this may be an unnecessary translation.  This doesn't mean
   that the "back end file" has to be the same format as that passed
   through the API - but in some (many?) cases it could be.

Sounds reasonable to me.



From rlk at alum.mit.edu  Wed Mar 26 17:01:13 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Wed, 26 Mar 2003 20:01:13 -0500
Subject: [Printing-architecture] Re: [printing-driver] FSG Printer Working
 Group conference call 03/26/03
In-Reply-To: <3E812D30.40701@easysw.com> (mike@easysw.com)
References: <OFC5111351.DFB34EDB-ON86256CF3.006ACF5B-86256CF3.006B2C0C@us.ibm.com> <200303250116.h2P1GZVc009025@dsl092-065-009.bos1.dsl.speakeasy.net> <3E7FBB4F.4040503@easysw.com> <200303250242.h2P2gEia009925@dsl092-065-009.bos1.dsl.speakeasy.net> <3E807421.9050508@easysw.com> <200303260156.h2Q1udkt023508@dsl092-065-009.bos1.dsl.speakeasy.net> <3E812D30.40701@easysw.com>
Message-ID: <200303270101.h2R11DYt001480@dsl092-065-009.bos1.dsl.speakeasy.net>

   Date: Tue, 25 Mar 2003 23:31:44 -0500
   From: Mike Sweet <mike at easysw.com>

   Robert L Krawitz wrote:
    > ...
   >    (and from the CUPS standpoint, we *will not* be supporting a
   >    direct scheduler<->driver interface, as that opens up serious
   >    security and performance issues...)
   > 
   > What's the security issue?

   The two main ones are:

	1. If we directly connect to the driver/library, then any buffer
	   overflows in the driver/library might be exploited to gain
	   root access.  Thus, we won't directly connect...

Yup, that makes sense.  The driver should in any event run with the
least possible privilege.

	2. If we indirectly connect to the driver/library, and do it
	   "safely" with a non-priviledged user with pipes to and from
	   the backend so the driver can communicate with the device,
	   we run the risk of a DoS attack if more than one user wants
	   to print at the same time and needs the "dynamic" driver
	   data.  This also falls under the performance umbrella...

   The mechanism we will be using in CUPS 1.2 is an asynchronous
   device daemon with a "port monitor" facility that will allow
   developers to provide printer driver filter(s) and a "port monitor"
   program; the filter(s) will handle the production of data suitable
   for the printer, while the (optional) port monitor handles printer
   queries, data encoding, etc.  One other task for the port monitor
   is periodic status updates via the device monitor - this will allow
   the port monitor to update the PPD file for current device
   configuration, update the printer object for current state, etc.

That sounds like a good architecture anyway.  I don't see why the
filter couldn't also act as an "option server" or some such, though.

   Ideally we should be able to provide a GIMP-print API for
   retrieving the driver constraints and/or put all of the driver-
   specific data in the printers.xml file so that the driver and PPD
   files are data driven and not hardcoded.  This would also make it
   possible for programmatic PPD file generation - CUPS would ask
   GIMP-print for a list of the drivers it supports along with
   "virtual" PPD filenames, and then CUPS can have GIMP-print write
   the PPD file in /etc/cups/ppd as requested by the administrator.

Any suggestions from your experience what kind of constructs might be
good for this purpose?

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From mike at easysw.com  Wed Mar 26 19:15:50 2003
From: mike at easysw.com (Mike Sweet)
Date: Wed, 26 Mar 2003 22:15:50 -0500
Subject: [printing-driver] Re: [Printing-architecture] FSG Printer Working Group meeting notes
 03/26/03
In-Reply-To: <OF681B092B.0DF4A39F-ON86256CF5.0081DB93-86256CF5.008305E7@us.ibm.com>
References: <OF681B092B.0DF4A39F-ON86256CF5.0081DB93-86256CF5.008305E7@us.ibm.com>
Message-ID: <3E826CE6.7010904@easysw.com>

Mark Hamzy wrote:
> ...
> Yes. Supporting the key=values from the JT is a requirement. This
> would lead us to consider the JT keys and values as the standard to
> use. We need to make sure that all printer drivers have either a
> mapping from their old keys/values to the new JT keys/values or
 > have their keys and values added to the JT standard.

Better to define a standard mechanism for vendors to add their own
attributes, e.g. com.vendor.attr.

Also, I'm not clear if you are advocating using the subverted IPP
names (e.g. documentFormat instead of document-format?) instead?
If so, that will be a hard sell - we already have to map IPP
attributes to PPD options...

> ...
> One worry is size of data if all are passed in at once.  One
 > solution that is proposed is to query the driver for the number
 > of key/values that can be passed in one call.

I think it will be a lot better to just require drivers accept
data of arbitrary size; drivers can read/process attributes
incrementally on their own, and if a driver only supports a very
small buffer then some attributes may be lost (no way to send a
long attribute if the buffer is too small...)

 > ...
> New issues that occurred during the meeting:
>    * should there be API to set/query default job properties?
> 
>      Yes.

papiPrinterQuery() already supports this...

> ...
>    * should we use a structured data message format?
> 
>       + should it be
>          - XML
>          - a simple human readable ASCII string encoding
>          - binary
>             ~ big-endian/little-endian
>             ~ 8-bit clean
> 
>       + should it have a length in the structure?
> 
>          - 20-octet end-of-string marker instead of sizeof structure

PAPI defines a format for ASCII attributes; from the standpoint of
passing command-line arguments, etc., using this format would make
sense, and it maps cleanly to XML and/or IPP data streams.

> ...
>>* can there be different job properties for each page?
>>
>>  + Can this can be optional?
> 
> 
> Yes.  If a device cannot handle switching job properties on a new page,
> then
> the driver should stop the print job and start another one.

Note: this MUST be transparent to the print system and application,
so in the end per-page properties are not optional, and the driver
MUST support per-page properties by starting a new job.

> ...
> Unicode font metrics can be a large message.

It might be useful to include the range of interest, e.g. "give me
font metrics for chars 0 to 255".

> ...
>>* should we require a standard install path?
>>  /usr/lib/print/driver/drivername
>>  /usr/share/print/font/drivername/
> 
> 
> This question was asked because we need some method of detectability or
> discoverability of installed drivers.  This can be as simple as an ini file
> that is found at a certain location.  This file can contain:
>    - what driver is installed
>    - where it is located
>    - how do I communicate with it

As I mentioned before, a better interface would be to provide a
standard command that can be used to install one or more printer
drivers in a standard format; this command would then handle the
printing system specific installation stuff.

> Future issues are:
>    - should there be calls to the driver to notify when the driver is
>       + installed
>       + uninstalled
>       + upgraded

Aside from actual installation/removal/upgrade of the software
itself, there could also be an issue with initial device
configuration when the printer is connected and queue is setup
for the printing system (e.g. for CUPS to query the printer and
update the PPD file for installed options...)

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike at easysw.com
Printing Software for UNIX                       http://www.easysw.com




From mike at easysw.com  Wed Mar 26 19:42:11 2003
From: mike at easysw.com (Mike Sweet)
Date: Wed, 26 Mar 2003 22:42:11 -0500
Subject: [Printing-architecture] Re: [printing-driver] FSG Printer Working
 Group conference call 03/26/03
In-Reply-To: <200303270101.h2R11DYt001480@dsl092-065-009.bos1.dsl.speakeasy.net>
References: <OFC5111351.DFB34EDB-ON86256CF3.006ACF5B-86256CF3.006B2C0C@us.ibm.com> <200303250116.h2P1GZVc009025@dsl092-065-009.bos1.dsl.speakeasy.net> <3E7FBB4F.4040503@easysw.com> <200303250242.h2P2gEia009925@dsl092-065-009.bos1.dsl.speakeasy.net> <3E807421.9050508@easysw.com> <200303260156.h2Q1udkt023508@dsl092-065-009.bos1.dsl.speakeasy.net> <3E812D30.40701@easysw.com> <200303270101.h2R11DYt001480@dsl092-065-009.bos1.dsl.speakeasy.net>
Message-ID: <3E827313.5020706@easysw.com>

Robert L Krawitz wrote:
> ...
> That sounds like a good architecture anyway.  I don't see why the
> filter couldn't also act as an "option server" or some such, though.

You'd be forcing every driver to handle multiple requests at the
same time, or serializing requests which would invoke a serious
performance hit.  Also, keep in mind that serving a static file/
data store involves MUCH less CPU/IO than processing each query
individually.  Any solution we come up with has to scale to
thousands of printers and users.

>    Ideally we should be able to provide a GIMP-print API for
>    retrieving the driver constraints and/or put all of the driver-
>    specific data in the printers.xml file so that the driver and PPD
>    files are data driven and not hardcoded.  This would also make it
>    possible for programmatic PPD file generation - CUPS would ask
>    GIMP-print for a list of the drivers it supports along with
>    "virtual" PPD filenames, and then CUPS can have GIMP-print write
>    the PPD file in /etc/cups/ppd as requested by the administrator.
> 
> Any suggestions from your experience what kind of constructs might be
> good for this purpose?

You already have most of the data in structures right now - just move
it to the XML file and add the constraint data.  The PPD file then
just needs to reference the instance in the XML file (e.g. driver
name, ID, etc., like we already have...)

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike at easysw.com
Printing Software for UNIX                       http://www.easysw.com




From bobt at hp.com  Tue Mar 25 11:06:31 2003
From: bobt at hp.com (TAYLOR,BOB (HP-Vancouver,ex1))
Date: Tue, 25 Mar 2003 11:06:31 -0800
Subject: [Printing-architecture] Re: [printing-driver] FSG Printer Wor
	king Group conference call 03/26/03
Message-ID: <A134E2426B46D711BB4B000347AE6E7CAA532C@xvan02.vcd.hp.com>

see inline -

bt

> -----Original Message-----
> From: Robert L Krawitz [mailto:rlk at alum.mit.edu] 
> Sent: Monday, March 24, 2003 6:42 PM
> To: mike at easysw.com
> Cc: printing-driver at freestandards.org; 
> printing-architecture at freestandards.org
> Subject: Re: [Printing-architecture] Re: [printing-driver] 
> FSG Printer Working Group conference call 03/26/03
> 
> 
>    Date: Mon, 24 Mar 2003 21:13:35 -0500
>    From: Mike Sweet <mike at easysw.com>
> 
>    >    * should we have an interface to query the printer's 
> job dialog?
>    >      This will allow for programmatic support of 
> setting/querying the JPs.
>    > 
>    > Yes.  This actually maps very well to Gimp-print, particularly in
>    > 4.3.  It's a lot more flexible than a static file; expressing
>    > constraints using boolean logic can get extremely complex.
> 
>    First, we need static files (or the equivalent attributes) for the
>    UI; there cannot be a direct interface between app and driver,
>    otherwise we're repeating the same old errors that have been cursed
>    on Windows.
> 
> True; I guess I glossed over the "job dialog" part.  However, 
> I don't think that there actually need to be static files; an 
> API to the printing system (whereby the printing system acts 
> as an abstraction barrier between the application and the 
> driver) would also accomplish this end.  The back end of this 
> could be whatever the driver and the printing system agree 
> on: it could be a PPD file for some drivers and an interface 
> module (like rastertoprinter or ijsgimpprint) between the 
> driver and the printing system for others.

<bt>
Thought I'm not sure I'd call them "static files", I do think we should
try to keep this as data driven as possible - i.e., emphasize capabilities
data to drive UI over custom device dialogs.
</bt>

> 
>    Second, all constraints can be expressed using boolean logic;
>    putting them in code or in a file doesn't matter much - the same
>    amount of complexity is required either way.
> 
> Not necessarily; the internal logic might be dynamic, based 
> on the printer state (e. g. the driver might want to offer 
> only options that are actually installed on the printer), or 
> it might reference internal driver logic that's unwieldly to 
> express via logic or simply doesn't need to be exposed to the 
> application.  To illustrate what I mean, the compressed 
> Gimp-print PPD files for the Epson Stylus printers total 1440 
> KB (each one totals about 12 KB; the entire compressed source 
> code for the Epson family driver totals 48 KB, even though 
> Gimp-print doesn't query printer status (it does offer 
> dynamic options based on the state of other options).

<bt>
It is definitely possible to express these "dynamic" constraints - we
are doing this with the PSI capabilities model, and I believe UPDF can
handle this as well.

In my experience, most of our core capabilities files are in the 10-50k
range.
Anything much beyond that are usually localizations of strings.
</bt>

> 						 
> 						 Keep in mind that we
>    are planning on providing a constraint mechanism that is a superset
>    of that supported by PPD and that there will still be a way to do
>    full round-trip constraint checks through the printing system (if
>    supported); the latter checks are meant for sanity checks when
>    submitting options/jobs and not for on-the-fly constraint checking
>    when a user changes an option.
> 
> Can it express certain options being entirely unavailable in 
> some circumstances (e. g. when the user chooses to print in 
> black and white, color controls should be disabled)?

<bt>
I know our PSI capabilities model can handle this, and I'm pretty sure UPDF
can as well.
</bt>

> 
> -- 
> Robert Krawitz                                     
> <rlk at alum.mit.edu>      
> 
> Tall Clubs International  --  http://www.tall.org/ or 
> 1-888-IM-TALL-2 Member of the League for Programming Freedom 
> -- mail lpf at uunet.uu.net
> Project lead for Gimp Print   --    http://gimp-print.sourceforge.net
> 
> "Linux doesn't dictate how I work, I dictate how Linux 
> works." --Eric Crampton
> 
> _______________________________________________
> printing-driver mailing list
> printing-driver at freestandards.org 
> http://freestandards.org/mailman/listinfo/prin> ting-driver
> 



From bobt at hp.com  Tue Mar 25 11:14:33 2003
From: bobt at hp.com (TAYLOR,BOB (HP-Vancouver,ex1))
Date: Tue, 25 Mar 2003 14:14:33 -0500
Subject: [Printing-architecture] Re: [printing-driver] FSG Printer Wor
	king Group conference call 03/26/03
Message-ID: <A134E2426B46D711BB4B000347AE6E7CAA532D@xvan02.vcd.hp.com>

see inline -

bt

> -----Original Message-----
> From: Robert L Krawitz [mailto:rlk at alum.mit.edu] 
> 
>      + Should we use
> 	  - one existing standard
> 	     PWG well known values (
>    http://www.pwg.org/schemas/sm/latest/MediaWellKnownValues.xsd)
> 	  - two or more existing standards
> 	     PWG and/or JDF
> 	  - a new standard
> 
> I don't like the fixed values at all; they basically try to 
> force all papers into specific niches.  For example, Epson 
> offers a number of different photographic papers (Photo 
> Paper, Premium Glossy Photo Paper, Premium Semiglosss, etc.), 
> and each one has different characteristics.  There are a lot 
> of third party papers as well, and these also have different 
> characteristics.  Having the MediaTypeExtensionPattern is 
> fine, but on Epson (and other inkjet) printers, 
> "photographic-glossy" simply isn't a very useful description; 
> there are enormous differences between different 
> photographic-glossy papers, and it's important for the user 
> to specify the precise paper by name.  Subtle differences in 
> the coating (which users generally can't distinguish except 
> by name) require great differences; for example, when 
> printing to Premium Glossy on the Stylus C80, it's important 
> to not use black ink, which is formulated differently and 
> doesn't adhere correctly to the paper.  Other glossy photo 
> papers should be printed with black ink, however.

<bt>
Agreed - and note that this is a good example of why we need to be able
to pass localized UI strings through the capabilities interface as well.
I don't think it's a reasonable expectation that all of these
rapidly-evolving
vendor-specific media types will be registered, much less actually supported
with localized strings in most clients.
</bt>

> 
>    * can there be default job properties or must every 
> property be set?
> 
> Defaults should be allowed.  For example (using a Gimp-print 
> property), a user should not have to specify the ink type; 
> the driver should pick it automatically.

<bt>
Agreed - though we have found the need for a device/service to declare 
that certain features !must! be specified - e.g., a fax phone number.
</bt>

> 
>    * should we have an interface to query the printer's job dialog?
>      This will allow for programmatic support of 
> setting/querying the JPs.
> 
> Yes.  This actually maps very well to Gimp-print, 
> particularly in 4.3.  It's a lot more flexible than a static 
> file; expressing constraints using boolean logic can get 
> extremely complex.

<bt>
Although we may want to provide an extension mechanism to get to a printer's
job dialog, I'd much rather see the core dialog be data driven.  We've yet
to
find "extremely" complex constraints - in most cases they're pretty
reasonable.

Note that you end up defining these constraints someplace anyway - the
question
is whether you do it in code that's bound to an implementation or in a data
structure that can be evaluated in many implementations.
</bt>



From bobt at hp.com  Wed Mar 26 07:33:53 2003
From: bobt at hp.com (TAYLOR,BOB (HP-Vancouver,ex1))
Date: Wed, 26 Mar 2003 10:33:53 -0500
Subject: [Printing-architecture] Re: [printing-driver] FSG Printer Wor
	 king Group conference call 03/26/03
Message-ID: <A134E2426B46D711BB4B000347AE6E7CAA5344@xvan02.vcd.hp.com>

see inline -

bt

> -----Original Message-----
> From: Robert L Krawitz [mailto:rlk at alum.mit.edu] 
> 
>    >    * should we have an interface to query the printer's 
> job dialog?
>    >      This will allow for programmatic support of 
>    > setting/querying the JPs.
>    > 
>    > Yes.  This actually maps very well to Gimp-print, 
>    > particularly in 4.3.  It's a lot more flexible than a static 
>    > file; expressing constraints using boolean logic can get 
>    > extremely complex.
> 
>    Note that you end up defining these constraints someplace anyway -
>    the question is whether you do it in code that's bound to an
>    implementation or in a data structure that can be evaluated in many
>    implementations.
> 
> The flat file's already bound to the implementation; a 
> Gimp-print PPD file won't work with the HPIJS driver and vice 
> versa.  IMHO, an application should neither know nor care 
> whether the back end is a PPD file, an XML file of some kind, 
> a driver, or even a relational database of some kind.  There 
> should be an API by which it can get this information from 
> the core printing system.

<bt>
There should be an API - but the API needs some kind of data model.  I'd
rather see this API adopt one of the more flexible existing data models
(PSI capabilities, UPDF, ...) that make yet another, which just adds another
translation into the pile - and in many cases, this may be an unnecessary
translation.  This doesn't mean that the "back end file" has to be the same
format as that passed through the API - but in some (many?) cases it could
be.
</bt>

> 
> -- 
> Robert Krawitz                                     
> <rlk at alum.mit.edu>      
> 
> Tall Clubs International  --  http://www.tall.org/ or 
> 1-888-IM-TALL-2 Member of the League for Programming Freedom 
> -- mail lpf at uunet.uu.net
> Project lead for Gimp Print   --    http://gimp-print.sourceforge.net
> 
> "Linux doesn't dictate how I work, I dictate how Linux 
> works." --Eric Crampton
> 



From hamzy at us.ibm.com  Mon Mar 31 13:45:18 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 31 Mar 2003 15:45:18 -0600
Subject: [printing-driver] FSG Printer Working Group conference call 04/02/03
Message-ID: <OF27AFA33A.01E32C4E-ON86256CF5.0081F563-86256CFA.00778122@us.ibm.com>




Wednesday, April 2

GMT 19:00
EST 14:00
CST 13:00
MST 12:00
PST 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Topics

Talk about API calls

initialize session ( "client version" )
<- "server version"

close session

is command supported ( cmd )
<- success/failure

set translatable language ( "abbreviationX" )
<- success/failure

get translatable language
<- "abbreviationX"

query translatable languages
<- "abbreviation1 abbreviation2 ... abbreviationN"

enumerate devices
<- "display_device_string1 load_hints1 ... display_device_stringN load_hintsN"

select device ( "load_hintsX" )
<- success/failure

is device valid ( "load_hintsX" )
<- success/failure

get PDL info
<- "PDL info"

query current job properties
<- "key1=value1 key2=value2 ... keyN=valueN"

list job property keys
<- "key1 key2 ... keyN"

get job property ( "key" )
<- "value"

get job property type ( "key" )
<- string/integer/boolean/...

translate job property key/value ( "key=value" )
<- "display_key=display_value"

begin job
<- success/failure

start page
<- success/failure

end page
<- success/failure

end job
<- success/failure

abort page
<- success/failure

abort job
<- success/failure

Mark

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




From hamzy at us.ibm.com  Wed Apr  2 16:06:31 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Wed, 2 Apr 2003 18:06:31 -0600
Subject: [printing-driver] FSG Printing Driver meeting notes 04/02/03
Message-ID: <OF904F8B2C.AAC37CCF-ON86256CFC.0083863B-86256CFD.000098E1@us.ibm.com>




Attendees:

Mark Hamzy
Till Kamppeter
Helen Ko
Ira McDonald
Kevin Nuwer
Glen Petrie
Pete Zannucci

There were two issues that came up during the call.  Everyone had different
semantic interpretations of words used in this standard.  The other problem
was that there are different views of how the architecture should look
like.

We need to use a common an consistent naming scheme of API verbs.
   begin/initialize
   everything (getAll) vs one
inside/outside job

> * what are the top level messages?
> * should we use a message header format and if so, how should it be
encoded?
>
> Talk about API calls
>
> initialize session ( "client version" )
> <- "server version"

This call is used to initialize the library before talking to a driver.

An API will be added to query the installed drivers.  Once a driver
is chosen, there will be APIs to initialize the driver and to close the
driver.

> close session
>
> is command supported ( cmd )
> <- success/failure
>
> set translatable language ( "abbreviationX" )
> <- success/failure
>
> get translatable language
> <- "abbreviationX"
>
> query translatable languages
> <- "abbreviation1 abbreviation2 ... abbreviationN"
>
> enumerate devices
> <- "display_device_string1 load_hints1 ... display_device_stringN
load_hintsN"

The hints are opaque to an application.  The application is not supposed to
read or modify them but to pass them back to the driver.

It is mandatory that there are unique display_device strings.

It was suggested to change the name from load_hints to load_handle.

This handle should not be kept in persistent storage but only used during
the communications session.

> select device ( "load_hintsX" )
> <- success/failure
>
> is device valid ( "load_hintsX" )
> <- success/failure

We will remove this API.

> get PDL info
> <- "PDL info"
>
> query current job properties
> <- "key1=value1 key2=value2 ... keyN=valueN"
>
> list job property keys
> <- "key1 key2 ... keyN"
>
> get job property ( "key" )
> <- "value"
>
> get job property type ( "key" )
> <- string/integer/boolean/...
>
> translate job property key/value ( "key=value" )
> <- "display_key=display_value"
>
> begin job
> <- success/failure
>
> start page
> <- success/failure

We need to add an option set of new properties to use.

> end page
> <- success/failure
>
> end job
> <- success/failure
>
> abort page
> <- success/failure
>
> abort job
> <- success/failure

Two new APIs were suggested:
   - suspend job
   - continue job
These were for spoolers that might hold/release print jobs.

Other new APIs are
   - font metrics
      + install
      + query
   - color management
   - bidirectional communication

We agreed that printer properties are also required to be supported
by drivers.

We gave some initial properties that should be considered
   - printer properties
      + ink cartridges
      + forms in trays
      + memory
      + duplexer
      + fonts installed

   - job properties
      + form
      + input-tray
      + media-coating
      + media-color
      + media-type
      + resolution
      + orientation
      + duplex
      + nup
      + scaling
      + collation
      + booklet
      + output-bin
      + stapling
      + jogging
      + stapling
      + hole-punching
      + folding
      + quality

Mark

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




From mike at easysw.com  Wed Apr  2 18:31:37 2003
From: mike at easysw.com (Mike Sweet)
Date: Wed, 02 Apr 2003 21:31:37 -0500
Subject: [printing-driver] FSG Printing Driver meeting notes 04/02/03
In-Reply-To: <OF904F8B2C.AAC37CCF-ON86256CFC.0083863B-86256CFD.000098E1@us.ibm.com>
References: <OF904F8B2C.AAC37CCF-ON86256CFC.0083863B-86256CFD.000098E1@us.ibm.com>
Message-ID: <3E8B9D09.4020408@easysw.com>

Mark Hamzy wrote:
> ...
>    - job properties
 > ...

These should use the IPP/PWG naming conventions...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike at easysw.com
Printing Software for UNIX                       http://www.easysw.com




From hamzy at us.ibm.com  Tue Apr  8 08:17:05 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Tue, 8 Apr 2003 10:17:05 -0500
Subject: [printing-driver] FSG Printing Driver conference call 04/09/03
Message-ID: <OFC3F2A970.C897C0CE-ON86256CFD.0000A4A5-86256D02.0053F682@us.ibm.com>




Wednesday, April 9

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Topics

Perhaps we should add an API
   get device handle ( "display_deviceX" )
   <- load_hintsX

Discuss Job Properties:

FeedOrientation
   + LongEdgeFirst
   + ShortEdgeFirst

input-tray?
TRAY_AUTO,                /* aka default */
TRAY_USE_PRINTER_SETTING,
TRAY_AUTO_FEEDER,
TRAY_AUTOSWITCH,
TRAY_TRAY,
TRAY_UPPER_TRAY,
TRAY_LOWER_TRAY,
TRAY_MULTI_TRAY,
TRAY_CASSETTE,
TRAY_UPPER_CASSETTE,
TRAY_LOWER_CASSETTE,
TRAY_MULTI_CASSETTE,
TRAY_OPTION_CASSETTE,
TRAY_MANUAL_FEEDER,
TRAY_MANUAL_ENVELOPE,
TRAY_PAPER_FEEDER,
TRAY_ENVELOPE_FEEDER,
TRAY_CSF,
TRAY_FRONT_CONTINUOUS,
TRAY_REAR_CONTINUOUS,
TRAY_SINGLE_SHEET,
TRAY_SHEET_FEEDER,
TRAY_BIN_1,
TRAY_BIN_2,
TRAY_PORTABLE_SHEET,
TRAY_TRAY_1,
TRAY_TRAY_2,
TRAY_TRAY_3,
TRAY_TRAY_4,
TRAY_TRAY_5,
TRAY_TRAY_6,
TRAY_CASSETTE1,
TRAY_CASSETTE2,
TRAY_CASSETTE3,
TRAY_CASSETTE4,
TRAY_CASSETTE5,
TRAY_FRONT_TRAY,
TRAY_OPTION_MULTI_SF,
TRAY_MULTI_FEEDER,
TRAY_PAPER_DECK,
TRAY_TRACTOR_UNIT,
TRAY_ROLL_1,
TRAY_ROLL_2,
TRAY_ROLL_3,
TRAY_ROLL_4,
TRAY_ROLL_5,
TRAY_AUXILIARY_TRAY,
TRAY_LARGE_CAPACITY_TRAY,
TRAY_HIGH_CAPACITY_FEEDER,
TRAY_ZERO_MARGINS

Media
   + na_letter_8.5x11in
   + iso_a4_210x297mm
   + ...
   + MediaCol
     - collection of all MediaXXX
MediaColor
   + nocolor
   + white
   + pink
   + yellow
   + blue
   + green
   + buff
   + goldenrod
   + red
   + gray
   + ivory
   + orange
MediaBackCoating
MediaFrontCoating
   + None
   + Glossy
   + HighGloss
   + SemiGloss
   + Satin
   + Matte
MediaGrain
MediaTooth
   + Fine
   + Medium
   + Coarse
MediaType
   + stationery
   + transparency envelope
   + envelope-plain
   + envelope-window
   + continuous
   + continuous-long
   + continuous-short
   + tab-stock
   + pre-cut-tabs
   + full-cut-tabs
   + multi-part-forms
   + labels
   + multi-layer
   + screen
   + screen-paged
   + photographic
   + cardstock
   + other

MEDIA_PLAIN,
MEDIA_TRANSPARENCY,
MEDIA_GLOSSY,
MEDIA_SPECIAL,
MEDIA_COATED,
MEDIA_BACKPRINT,
MEDIA_CLOTH,
MEDIA_THICK,
MEDIA_HIGH_GLOSS_FILM,
MEDIA_HIGH_RESOLUTION,
MEDIA_SPECIAL_360,
MEDIA_SPECIAL_720,
MEDIA_PLAIN_ENHANCED,
MEDIA_IRON_ON,
MEDIA_LABECA,
MEDIA_THERMAL,
MEDIA_CD_MASTER,
MEDIA_CARDBOARD,
MEDIA_POSTCARD,
MEDIA_PHOTOGRAPHIC_PAPER,
MEDIA_PHOTOGRAPHIC_LABEL,
MEDIA_HP_PREMIUM_PAPER,
MEDIA_HP_PHOTOGRAPHIC_PAPER,
MEDIA_ENVELOPE,
MEDIA_PREPRINTED,
MEDIA_LETTERHEAD,
MEDIA_PREPUNCHED,
MEDIA_LABELS,
MEDIA_BOND,
MEDIA_RECYCLED,
MEDIA_COLOR,
MEDIA_CARDSTOCK,
MEDIA_ROUGH,
MEDIA_ARCHIVAL_MATTE_PAPER,
MEDIA_BRIGHT_WHITE_INK_JET_PAPER,
MEDIA_COLORLIFE_PHOTO_PAPER,
MEDIA_DOUBLE_SIDED_MATTE_PAPER,
MEDIA_HEAVYWEIGH_MATTE_PAPER,
MEDIA_PREMIUM_SEMIGLOSS_PHOTO_PAPER,
MEDIA_PHOTOGRAPHIC_INK_JET_PAPER,
MEDIA_CUSTOM_1,
MEDIA_CUSTOM_2,
MEDIA_CUSTOM_3,
MEDIA_CUSTOM_4,
MEDIA_CUSTOM_5,
MEDIA_SPECIAL_BLUE,
MEDIA_SPECIAL_GREEN,
MEDIA_SPECIAL_GREY,
MEDIA_SPECIAL_IVORY,
MEDIA_SPECIAL_LETTERHEAD,
MEDIA_SPECIAL_ORANGE,
MEDIA_SPECIAL_PINK,
MEDIA_SPECIAL_PURPLE,
MEDIA_SPECIAL_RED,
MEDIA_SPECIAL_YELLOW,
MEDIA_SPECIAL_USER_COLOR,
MEDIA_TABSTOCK,
MEDIA_TABSTOCK_2,
MEDIA_TABSTOCK_3,
MEDIA_TABSTOCK_4,
MEDIA_TABSTOCK_5,
MEDIA_TABSTOCK_6,
MEDIA_TABSTOCK_7,
MEDIA_TABSTOCK_8,
MEDIA_TABSTOCK_9,
MEDIA_THICK_1,
MEDIA_THICK_2,
MEDIA_THICK_3,
MEDIA_THICK_BLUE,
MEDIA_THICK_GREEN,
MEDIA_THICK_GREY,
MEDIA_THICK_IVORY,
MEDIA_THICK_LETTERHEAD,
MEDIA_THICK_ORANGE,
MEDIA_THICK_PINK,
MEDIA_THICK_PURPLE,
MEDIA_THICK_RED,
MEDIA_THICK_YELLOW,
MEDIA_THICK_USER_COLOR,
MEDIA_TRANSLUCENT,

NumberUp
   + PresentationDirectionNumberUp
      - TorightTobottom
      - TobottomToright
      - ToleftTobottom
      - TobottomToleft
      - TorightTotop
      - TotopToright
      - ToleftTotop
OrientationRequested
   + Portrait
   + Landscape
   + ReversePortrait
   + ReverseLandscape
OutputBin
   + Bottom
   + Center
   + FaceDown
   + FaceUp
   + LargeCapacity
   + Left
   + MailboxN
   + Middle
   + MyMailbox
   + Rear
   + Right
   + Side
   + StackerN
   + Top
   + TrayN
PrintQuality
   + Draft
   + Normal
   + High

RESOLUTION_DRAFT,
RESOLUTION_NORMAL,
RESOLUTION_HIGH,
RESOLUTION_FINE,
RESOLUTION_GROUP_3,
RESOLUTION_GROUP_4,
RESOLUTION_LOW,
RESOLUTION_MEDIUM,
RESOLUTION_PHOTO_QUALITY,
RESOLUTION_PRESENTATION

PrinterResolution
   + integerXinteger
SheetCollate
   + Uncollated
   + Collated
Sides
   + OneSided
   + TwoSidedLongEdge
   + TwoSidedShortEdge
   + Tumble
Staple
   + None
   + Staple
   + StapleTopLeft
   + StapleBottomLeft
   + StapleTopRight
   + StapleBottomRight
   + StapleDualLeft
   + StapleDualTop
   + StapleDualRight
   + StapleDualBottom
Stitching
   + StitchingLocation
      - integer
   + StitchingOffset
      - integer
   + StitchingReferenceEdge
      - Bottom
      - Top
      - Left
      - Right

Mark

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




From hamzy at us.ibm.com  Tue Apr 15 11:14:10 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Tue, 15 Apr 2003 13:14:10 -0500
Subject: [printing-driver] FSG Printing Driver conference call 04/16/03
Message-ID: <OFEBE716A3.404192A5-ON86256D09.0063AF68-86256D09.00642CE0@us.ibm.com>




Wednesday, April 9

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Topics

bitmap input formats to printer drivers.
are other formats allowed?

Mark

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




From hamzy at us.ibm.com  Tue Apr 15 11:14:15 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Tue, 15 Apr 2003 13:14:15 -0500
Subject: [printing-driver] FSG Printing Driver meeting notes 04/09/03
Message-ID: <OFE9DA75A0.811650F6-ON86256D09.006345A8-86256D09.00642E82@us.ibm.com>




Attendees:
Mark Hamzy
Till Kamppeter
Ira McDonald
Glen Petrie
Pete Zannucci

We will add not-set and none to all job property values.
We will wait for the job ticket group to progress farther before we discuss
job property keys and values.
We agreed to use the following compression for "over the wire"
communication.  All job property keys
and values will be replaced with an enumerated number.

Mark

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




From mike at easysw.com  Tue Apr 15 12:23:37 2003
From: mike at easysw.com (Michael Sweet)
Date: Tue, 15 Apr 2003 15:23:37 -0400
Subject: [printing-driver] FSG Printing Driver meeting notes 04/09/03
In-Reply-To: <OFE9DA75A0.811650F6-ON86256D09.006345A8-86256D09.00642E82@us.ibm.com>
References: <OFE9DA75A0.811650F6-ON86256D09.006345A8-86256D09.00642E82@us.ibm.com>
Message-ID: <3E9C5C39.1010705@easysw.com>

Mark Hamzy wrote:
> 
> 
> 
> Attendees:
> Mark Hamzy
> Till Kamppeter
> Ira McDonald
> Glen Petrie
> Pete Zannucci
> 
> We will add not-set and none to all job property values.
> We will wait for the job ticket group to progress farther before we discuss
> job property keys and values.
> We agreed to use the following compression for "over the wire"
> communication.  All job property keys
> and values will be replaced with an enumerated number.

Thats a nice way to ensure that the protocol/interface can't be
easily extended...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com






From alimpich at us.ibm.com  Tue Apr 15 14:25:37 2003
From: alimpich at us.ibm.com (Claudia Alimpich)
Date: Tue, 15 Apr 2003 15:25:37 -0600
Subject: [printing-driver] Input Tray Names and Output Bin Names
Message-ID: <OF2C77F707.1F036A4B-ON87256D09.006E81E1@us.ibm.com>




Following is the list of input tray names and output bin names that we
agreed to for the JTAPI.. It was compiled using the IPP list, JDF list, and
PPD list.

Input Tray names:
   AnySmallFormat
   AnyLargeFormat
   AutoSelect
   Bottom         same as Lower
   BypassTray
   BypassTray-n   where n is an integer
   Center
   Envelope
   Envelope-n           where n is an integer
   InsertTray
   InsertTray-n         where n is an integer
   LargeCapacity  same as Main
   LargeCapacity-n      where n is an interger
   Left
   Middle
   Rear
   Right
   Side
   Top                  same as Upper
   Tray-n         where n is an integer, same as Cassette
   SystemSpecified      This is the default.


Output Bin names:
   Booklet
   Bottom         same as Lower
   Center
   FaceDown
   FaceUp
   FitMedia
   LargeCapacity  same as Main
   Left
   MailBox-n            where n is an integer
   Middle
   MyMailbox
   Rear
   Right
   Side
   Stacker-n            where n is an integer
   SystemSpecified      this is the same as AutoSelect and is the default
   Top                  same as Upper
   Tray-n               where n is an integer




From imcdonald at sharplabs.com  Wed Apr 16 11:03:25 2003
From: imcdonald at sharplabs.com (McDonald, Ira)
Date: Wed, 16 Apr 2003 11:03:25 -0700
Subject: [printing-driver] FSG Printing Driver meeting notes 04/09/03
Message-ID: <116DB56CD7DED511BC7800508B2CA53735CF82@mailsrvnt02.enet.sharplabs.com>

Hi Michael,

On the contrary - it's very easily extended:

1)  Any standard job property key (name) or value
    can be sent on the wire either:
    (a) standard string label; or
    (b) standard wholly numeric token (just like WAP)

2)  Any vendor job property key (name) or value
    can be sent on the wire ONLY using string labels.

Thus a parser can know that a numeric token for job
property key or value can ALWAYS be machine-translated
to the standard string label for normalization.

OK?

Cheers,
- Ira


-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Tuesday, April 15, 2003 2:24 PM
To: printing-driver at freestandards.org
Subject: Re: [printing-driver] FSG Printing Driver meeting notes
04/09/03


Mark Hamzy wrote:
> 
> 
> 
> Attendees:
> Mark Hamzy
> Till Kamppeter
> Ira McDonald
> Glen Petrie
> Pete Zannucci
> 
> We will add not-set and none to all job property values.
> We will wait for the job ticket group to progress farther before we
discuss
> job property keys and values.
> We agreed to use the following compression for "over the wire"
> communication.  All job property keys
> and values will be replaced with an enumerated number.

Thats a nice way to ensure that the protocol/interface can't be
easily extended...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com




_______________________________________________
printing-driver mailing list
printing-driver at freestandards.org
http://freestandards.org/mailman/listinfo/printing-driver



From mike at easysw.com  Wed Apr 16 11:43:16 2003
From: mike at easysw.com (Michael Sweet)
Date: Wed, 16 Apr 2003 14:43:16 -0400
Subject: [printing-driver] FSG Printing Driver meeting notes 04/09/03
In-Reply-To: <116DB56CD7DED511BC7800508B2CA53735CF82@mailsrvnt02.enet.sharplabs.com>
References: <116DB56CD7DED511BC7800508B2CA53735CF82@mailsrvnt02.enet.sharplabs.com>
Message-ID: <3E9DA444.4020500@easysw.com>

McDonald, Ira wrote:
> Hi Michael,
> 
> On the contrary - it's very easily extended:
> 
> 1)  Any standard job property key (name) or value
>     can be sent on the wire either:
>     (a) standard string label; or
>     (b) standard wholly numeric token (just like WAP)
> 
> 2)  Any vendor job property key (name) or value
>     can be sent on the wire ONLY using string labels.
> 
> Thus a parser can know that a numeric token for job
> property key or value can ALWAYS be machine-translated
> to the standard string label for normalization.

OK, the summary sounded like ALL values would be converted to a
corresponding number when sent over the wire, so it would be
impossible to send an extension/non-standardized name over the
wire.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com






From hamzy at us.ibm.com  Mon Apr 21 10:42:21 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 21 Apr 2003 12:42:21 -0500
Subject: [printing-driver] FSG Printing Driver conference call 04/21/03
Message-ID: <OF77AB3B08.29B8081C-ON86256D0F.00612CBC-86256D0F.006142DE@us.ibm.com>




Wednesday, April 21

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Topics
      schedule roadmap

Mark

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




From hamzy at us.ibm.com  Mon Apr 21 13:52:54 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 21 Apr 2003 15:52:54 -0500
Subject: [printing-driver] FSG Printing Driver meeting notes 04/16/03
Message-ID: <OF54758D9F.80C465B7-ON86256D0F.0070BFF1-86256D0F.0072B4DF@us.ibm.com>




Attendees:
Claudia Alimpich
Mark Hamzy
Till Kamppeter
Ira McDonald
Glen Petrie

Reviewed common job properties.

> bitmap input formats to printer drivers.
> are other formats allowed?

we should allow the following formats:
   - fsg, tiff, jpeg, bmp, png
   - use mime types to differentiate between them
   - all drivers must support fsg type

The fsg type has the following:
   - header composed of ASCII text with CR LF
     type
        monochrome
        grayscale
        rgb
     bits per plane
     width
     height
     bytes per line/alignment
     start of band position on page in ypels
     end-of-header
   - binary scanline data.

Mark

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




From hamzy at us.ibm.com  Mon Apr 21 13:54:51 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 21 Apr 2003 15:54:51 -0500
Subject: [printing-driver] FSG Printing Driver meeting notes 04/21/03
Message-ID: <OF330AA12B.48A1FFB9-ON86256D0F.00721BE3-86256D0F.0072E2B4@us.ibm.com>




Attendees:
Mark Hamzy
Charles Hemstreet
Glen Petrie
David Suffield

we discussed the schedule roadmap and came up with the following:
   API aplication/library
      common job properties            (1M - May    23)
      API calls                        (     July   31)
   API library/driver
      common job properties - same as above
      registration/detection/discovery (2W - May     9)
      message protocol transport
         linking                       (2W - June    6)
         named pipe                    (2W - June    6)
         tcp/ip
   documentation                       (     August 29)
   reference implementation

cvs tree will be held in omni project under the PDC directory
   http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/omniprint/Omni/PDC/
zip file snapshots of stable releases will be put in the PWG's ftp site
   ftp://ftp.pwg.org/pub/pwg/fsg/driver/

Mark

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




From hamzy at us.ibm.com  Mon Apr 21 14:01:53 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 21 Apr 2003 16:01:53 -0500
Subject: [printing-driver] FSG Printing Driver conference call 04/28/03
Message-ID: <OF06CDC6A8.B5DB8095-ON86256D0F.0072BBA1-86256D0F.007387C6@us.ibm.com>




Monday, April 28

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Topics

what license to use for library
review standard job properties

FeedOrientation
   - instuction for what media to select.  does it override? no
   - information to PDL intrep about how to send image data

NOTE: do we really need this?

InputTray
   AnySmallFormat
   AnyLargeFormat
   AutoSelect
   Bottom               same as Lower
   BypassTray
   BypassTray-n         where n is an integer
   Center
   Envelope
   Envelope-n           where n is an integer
   InsertTray
   InsertTray-n         where n is an integer
   LargeCapacity        same as Main
   LargeCapacity-n      where n is an interger
   Left
   Middle
   Rear
   Right
   Side
   Top                  same as Upper
   Tray-n               where n is an integer, same as Cassette
   NotSet
   None

OutputBin
   Booklet
   Bottom               same as Lower
   Center
   FaceDown
   FaceUp
   FitMedia
   LargeCapacity        same as Main
   Left
   MailBox-n            where n is an integer
   Middle
   MyMailbox
   Rear
   Right
   Side
   Stacker-n            where n is an integer
   Top                  same as Upper
   Tray-n               where n is an integer
   NotSet
   None

Sides
   OneSidedBackflipX
   OneSidedBackflipY
   OneSidedFront
   TwoSidedFlipX
   TwoSidedFlipY
   NotSet
   None

StitchingPosition
   integer
   NotSet
   None
   - what are the units?
StitchingOffset
   integer
   NotSet
   None
StitchingReferenceEdge
   Bottom
   Top
   Left
   Right
   NotSet
   None
StitchingType
   Corner
   Saddle
   Side
   NotSet
   None
StitchingCount
   integer
   NotSet
   None
StitchingAngle
   integer
   NotSet
   None
   - should there only be 8 cardinal keywords?

NOTE: stapling is a form of stictching
      does it need to be this complex?

SheetCollate
   SheetCollated
   SheetAndJobCollated
   Uncollated
   NotSet
   None

Resolution
   integerXinteger
   NotSet
   None

PrintQuality
   Economy
   Draft
   Normal
   High
   Fine
   Photo
   NotSet
   None

Rotation
   Portrait
   Landscape
   ReversePortrait
   ReverseLandscape
   NotSet
   None

NOTE: It is the actual orientations that the printer supports.

NumberUp
   integerXinteger
   NotSet
   None
NumberUpPresentationDirection
   TorightTobottom
   TobottomToright
   ToleftTobottom
   TobottomToleft
   TorightTotop
   TotopToright
   ToleftTotop
   TotopToleft
   NotSet
   None

Copies
   integer
   NotSet
   None

Trimming
   None
   Trim
   Face
   Gutter
   Tab
   NotSet
   None

Scaling
   none
   fit
   percentage
   up
   down
   NotSet
   None

Mark

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




From hamzy at us.ibm.com  Fri Apr 25 12:19:11 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Fri, 25 Apr 2003 14:19:11 -0500
Subject: [printing-driver] Initial PDC library
Message-ID: <OF4D502A4F.E5B5BDE3-ON86256D13.0069BCB1-86256D13.006A2061@us.ibm.com>




Ok, the initial PDC library is out in Omni's CVS tree.

You can view it with the following commands:
      cvs -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/omniprint
login ?     cvs -z3
-d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/omniprint co Omni/PDC

Two questions.
      - Does anyone have a problem with me using XML to describe the
configuration file?
      - Does anyone have a problem with me using gmodule routines to load
drivers?

Mark

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




From till.kamppeter at gmx.net  Fri Apr 25 12:39:10 2003
From: till.kamppeter at gmx.net (Till Kamppeter)
Date: Fri, 25 Apr 2003 21:39:10 +0200
Subject: [printing-driver] Initial PDC library
In-Reply-To: <OF4D502A4F.E5B5BDE3-ON86256D13.0069BCB1-86256D13.006A2061@us.ibm.com>
References: <OF4D502A4F.E5B5BDE3-ON86256D13.0069BCB1-86256D13.006A2061@us.ibm.com>
Message-ID: <3EA98EDE.20403@gmx.net>

Mark Hamzy wrote:
> Ok, the initial PDC library is out in Omni's CVS tree.
> 
> You can view it with the following commands:
>       cvs -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/omniprint
> login -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/omniprint co Omni/PDC

For anyone who has problems with doing a CVS download due to his 
employers firewall, every night at 0:30am Boston time there is a new 
snapshot of the Omni CVS on

http://www.linuxprinting.org/download/cvs-snapshots/omni-0.9.0-current.tar.gz

    Till




From hamzy at us.ibm.com  Fri Apr 25 12:48:49 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Fri, 25 Apr 2003 14:48:49 -0500
Subject: [printing-driver] Initial PDC library
Message-ID: <OF0218C315.7AC6D6A8-ON86256D13.006CADA1-86256D13.006CD6EF@us.ibm.com>




Cool!

Thanks Till.

Mark

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




From imcdonald at sharplabs.com  Mon May  5 07:53:10 2003
From: imcdonald at sharplabs.com (McDonald, Ira)
Date: Mon, 5 May 2003 07:53:10 -0700 
Subject: [printing-driver] 5 May 2pm EDT - FSG Printing Driver telecon??
Message-ID: <116DB56CD7DED511BC7800508B2CA53735CFB4@mailsrvnt02.enet.sharplabs.com>

Hi Mark,

Are we having an FSG Printer Driver telecon this afternoon?

Cheers,
- Ira McDonald
  High North Inc




From hamzy at us.ibm.com  Mon May  5 07:22:21 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 5 May 2003 09:22:21 -0500
Subject: [printing-driver] FSG Printing Driver conference call 05/05/03 has been cancelled
Message-ID: <OFC4EE0D8A.E12496DC-ON86256D1D.004EDBB9-86256D1D.004EF348@us.ibm.com>




The FSG Printing Driver conference call 05/05/03 has been cancelled

Mark

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




From hamzy at us.ibm.com  Mon May  5 09:21:39 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 5 May 2003 11:21:39 -0500
Subject: [printing-driver] FSG Printing Driver conference call 05/05/03 has been cancelled
Message-ID: <OF32D04F25.76312375-ON86256D1D.0059D1C6-86256D1D.0059DF7F@us.ibm.com>




Try number 2.

FSG Printing Driver conference call 05/05/03 has been cancelled.

Mark

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




From hamzy at us.ibm.com  Mon May  5 09:25:46 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 5 May 2003 11:25:46 -0500
Subject: [printing-driver] 5 May 2pm EDT - FSG Printing Driver telecon??
Message-ID: <OF26635955.EAD413DB-ON86256D1D.005A041D-86256D1D.005A3FEF@us.ibm.com>




Hi Ira,

Mail seems to be hiccuping today.  I don't think that we have enough to
talk about to make it worthwhile today.  So I am cancelling today's
meeting.  This will give some time to the job ticket group (job properties
finalization) and myself (library coding).

Mark

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




From imcdonald at sharplabs.com  Mon May  5 10:46:03 2003
From: imcdonald at sharplabs.com (McDonald, Ira)
Date: Mon, 5 May 2003 10:46:03 -0700 
Subject: [printing-driver] 5 May 2pm EDT - FSG Printing Driver telecon
	??
Message-ID: <116DB56CD7DED511BC7800508B2CA53735CFB5@mailsrvnt02.enet.sharplabs.com>

Hi Mark,

Note that FSG JTAPI call is CANCELED for tomorrow (5/6), because
both Claudia A and Tom H are at CIP4 meetings all week.

Cheers,
- Ira


-----Original Message-----
From: Mark Hamzy [mailto:hamzy at us.ibm.com]
Sent: Monday, May 05, 2003 12:26 PM
To: printing-driver at freestandards.org
Cc: 'printing-driver at freestandards.org';
printing-driver-admin at freestandards.org
Subject: Re: [printing-driver] 5 May 2pm EDT - FSG Printing Driver
telecon??






Hi Ira,

Mail seems to be hiccuping today.  I don't think that we have enough to
talk about to make it worthwhile today.  So I am cancelling today's
meeting.  This will give some time to the job ticket group (job properties
finalization) and myself (library coding).

Mark

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


_______________________________________________
printing-driver mailing list
printing-driver at freestandards.org
http://freestandards.org/mailman/listinfo/printing-driver



From hamzy at us.ibm.com  Fri May  9 08:00:00 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Fri, 9 May 2003 10:00:00 -0500
Subject: [printing-driver] FSG Printing Driver meeting notes 04/28/03
Message-ID: <OF24AFCF35.A49C5443-ON86256D21.0051B651-86256D21.005265C9@us.ibm.com>




Attendees:

Claudia Alimpich
Mark Hamzy
Norm Jacobs
Till Kamppeter
Ira McDonald
Glen Petrie

We will distribute the source code under the MIT license.
We will remove from the common job properties:
      FeedOrientation
      StitchingOffset
      Scaling
We will add to the common job properties:
      ScalingType
            FitToPage
            RotateAndOrFit
            Clip
                  - center oriented
            None
            NotSet

      ScalingPercentage
            double
            None
            NotSet
Common job properties still not finalized are:
      Sides
Any numbers (integers/doubles) that are in units will have the following
abbreviations appended to them:
      pel - pels
      in  - inches
      pt  - points
      mm  - millimeters
      hmm - hundredths of a mm
      tmm - thousands of a mm
      mi  - miles
There will be a call to enumerate supported units.

Mark

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




From hamzy at us.ibm.com  Fri May  9 08:02:03 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Fri, 9 May 2003 10:02:03 -0500
Subject: [printing-driver] FSG Printing Driver conference call 05/12/03
Message-ID: <OFFCF7295F.6CE3984B-ON86256D21.00518F6D-86256D21.005295DB@us.ibm.com>




Monday, May 12

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Topics

working code discussion/review
better integration with PAPI?
capabilities
grouping job properties into a structure for related properties
color space sRGB w/ ICC
PDF/is

Mark

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




From mike at easysw.com  Fri May  9 08:32:20 2003
From: mike at easysw.com (Michael Sweet)
Date: Fri, 09 May 2003 11:32:20 -0400
Subject: [printing-driver] FSG Printing Driver meeting notes 04/28/03
In-Reply-To: <OF24AFCF35.A49C5443-ON86256D21.0051B651-86256D21.005265C9@us.ibm.com>
References: <OF24AFCF35.A49C5443-ON86256D21.0051B651-86256D21.005265C9@us.ibm.com>
Message-ID: <3EBBCA04.2060706@easysw.com>

Mark Hamzy wrote:
> ...
> Any numbers (integers/doubles) that are in units will have the following
> abbreviations appended to them:
>       pel - pels
>       in  - inches
>       pt  - points
>       mm  - millimeters
>       hmm - hundredths of a mm
>       tmm - thousands of a mm

Also known as micrometers, or "um" (use "u" instead of greek
letter...)

>       mi  - miles
> There will be a call to enumerate supported units.

OK, miles?  Are we just trying to see if anyone is watching?

You are missing some other units that a likely more relavent
for printing:

     ft  - feet
     m   - meters
     cm  - centimeters

If you really *do* want miles, then you should also include
kilometers (km); also, if you *do* specify miles, be sure to
specify statute (5280 feet) or nautical (6076.1 feet) miles.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com






From shawn.pratt at hp.com  Fri May  9 09:00:58 2003
From: shawn.pratt at hp.com (PRATT,SHAWN (HP-Boise,ex1))
Date: Fri, 9 May 2003 12:00:58 -0400 
Subject: [printing-driver] FSG Printing Driver meeting notes 04/28/03
Message-ID: <CBD6266EA291D5118144009027AA63350F7C021D@xboi05.boi.hp.com>

Mark, I talked with the executive chair of FSG about this.  He said the MIT
license is fine to use.  Sorry I did not get back to you sooner.

- Shawn

-----Original Message-----
From: Mark Hamzy [mailto:hamzy at us.ibm.com] 
Sent: Friday, May 09, 2003 9:00 AM
To: printing-driver at freestandards.org
Subject: [printing-driver] FSG Printing Driver meeting notes 04/28/03





Attendees:

Claudia Alimpich
Mark Hamzy
Norm Jacobs
Till Kamppeter
Ira McDonald
Glen Petrie

We will distribute the source code under the MIT license.
We will remove from the common job properties:
      FeedOrientation
      StitchingOffset
      Scaling
We will add to the common job properties:
      ScalingType
            FitToPage
            RotateAndOrFit
            Clip
                  - center oriented
            None
            NotSet

      ScalingPercentage
            double
            None
            NotSet
Common job properties still not finalized are:
      Sides
Any numbers (integers/doubles) that are in units will have the following
abbreviations appended to them:
      pel - pels
      in  - inches
      pt  - points
      mm  - millimeters
      hmm - hundredths of a mm
      tmm - thousands of a mm
      mi  - miles
There will be a call to enumerate supported units.

Mark

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


_______________________________________________
printing-driver mailing list
printing-driver at freestandards.org
http://freestandards.org/mailman/listinfo/printing-driver



From hamzy at us.ibm.com  Fri May  9 09:26:21 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Fri, 9 May 2003 11:26:21 -0500
Subject: [printing-driver] FSG Printing Driver meeting notes 04/28/03
Message-ID: <OFD170587C.4BFF0CBD-ON86256D21.0059E07D-86256D21.005A4DCA@us.ibm.com>





I added your suggestions.

> OK, miles?  Are we just trying to see if anyone is watching?

Yes.  :)  Although will roll feeds, it is possible...

> If you really *do* want miles, then you should also include...

If the group decides that they do want them, then we will use your
suggestions as well.

Thanks.

Mark

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




From imcdonald at sharplabs.com  Sat May 10 18:57:01 2003
From: imcdonald at sharplabs.com (McDonald, Ira)
Date: Sat, 10 May 2003 18:57:01 -0700
Subject: [printing-driver] FSG Printing Driver meeting notes 04/28/03
Message-ID: <116DB56CD7DED511BC7800508B2CA53735CFC5@mailsrvnt02.enet.sharplabs.com>

Hi,

To be even-handed, we should no doubt have:

  mi - miles (statute - 5,280 feet)
  km - kilometers

Sure, roll feed on a _really_ grand scale might use them...

Cheers,
- Ira



-----Original Message-----
From: Mark Hamzy [mailto:hamzy at us.ibm.com]
Sent: Friday, May 09, 2003 12:26 PM
To: printing-driver at freestandards.org
Subject: Re: [printing-driver] FSG Printing Driver meeting notes
04/28/03







I added your suggestions.

> OK, miles?  Are we just trying to see if anyone is watching?

Yes.  :)  Although will roll feeds, it is possible...

> If you really *do* want miles, then you should also include...

If the group decides that they do want them, then we will use your
suggestions as well.

Thanks.

Mark

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


_______________________________________________
printing-driver mailing list
printing-driver at freestandards.org
http://freestandards.org/mailman/listinfo/printing-driver



From hamzy at us.ibm.com  Mon May 12 13:16:04 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 12 May 2003 15:16:04 -0500
Subject: [printing-driver] FSG Printing Driver meeting notes 05/12/03
Message-ID: <OFBD6F5CBC.FD32D04F-ON86256D24.006F3081-86256D24.006F55F3@us.ibm.com>




Attendees:
Mark Hamzy
Charles Hemstreet
Ira McDonald

We did not have enough of an attendance so the meeting was canceled.

Mark

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




From hamzy at us.ibm.com  Mon May 12 13:19:21 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 12 May 2003 15:19:21 -0500
Subject: [printing-driver] FSG Printing Driver conference call 05/19/03
Message-ID: <OFA60332A0.83F3D7F6-ON86256D24.006F5B74-86256D24.006FA2AF@us.ibm.com>




Monday, May 19

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Topics

working code discussion/review
discuss new Tray keys
better integration with PAPI?
start capabilities API
grouping job properties into a structure for related properties
color space sRGB w/ ICC
PDF/is

Mark

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




From hamzy at us.ibm.com  Tue May 13 06:53:29 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Tue, 13 May 2003 08:53:29 -0500
Subject: [printing-driver] Tray additions/corrections
Message-ID: <OF2C18BD39.D61F0B05-ON86256D25.004C302B-86256D25.004C4F0F@us.ibm.com>




Resending as I do not see it on the list archives.

The following is a list of omni trays that still need to be mapped:

TRAY_AUXILIARY_TRAY
TRAY_OPTION_CASSETTE
TRAY_PORTABLE_SHEET
TRAY_SINGLE_SHEET
TRAY_SHEET_FEEDER
TRAY_MANUAL_FEEDER

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/
----- Forwarded by Mark Hamzy/Austin/IBM on 05/13/2003 08:52 AM -----
                                                                                                                          
                      Mark Hamzy                                                                                          
                                               To:       printing-driver at freestandards.org                                
                      05/12/2003 09:49         cc:                                                                        
                      AM                       From:     Mark Hamzy/Austin/IBM at IBMUS                                      
                                               Subject:  Tray additions/corrections                                       
                                                                                                                          
                                                                                                                          



After trying to map the Tray keys to omni driver tray keys, I have the
following corrections/additions:

AnySmallFormat        define?
AnyLargeFormat        define?
AutoSelect
Envelope
Envelope-n
InsertTray            define?
InsertTray-n
BypassTray            define?
BypassTray-n
LargeCapacityTray     modify - make consistent with above tray modifier
pattern
LargeCapacityTray-n   modify - make consistent with above tray modifier
pattern
Tray                  add - consistent with above tray modifier pattern
Tray-n
Top
Center
Middle
Bottom
Left
Right
Front                 add - opposite of rear
Side
Rear
Tractor               add - missing
Roll                  add - missing
Roll-n                add - missing
ZeroMarginTray        add - missing, consistent with tray modifier pattern
ZeroMarginTray-n      add - missing, consistent with tray modifier pattern
ZeroMarginRoll        add - missing, consistent with tray modifier pattern
ZeroMarginRoll-n      add - missing, consistent with tray modifier pattern
SingleSheetTray       ?
SingleSheetTray-n     ?
NotSet
None

Mark

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




From alimpich at us.ibm.com  Tue May 13 13:47:19 2003
From: alimpich at us.ibm.com (Claudia Alimpich)
Date: Tue, 13 May 2003 14:47:19 -0600
Subject: [printing-driver] Re: Tray additions/corrections
Message-ID: <OFBC861915.D5920551-ON87256D25.006AE529@us.ibm.com>





The JT working group met today and we talked about the input tray mapping
questions that Mark Hamzy brought up in his note (see attached note).

Participants:
   Ira McDonald (High North Inc)
   Tom Hastings (Xerox)
   Till Kamppeter (MandrakeSoft)
   Claudia Alimpich (IBM)

Following is a table of the trays that JDF defines and a description for
each:
|---------------+----------------------------------------------------------------|
| Name          | Description                                                    |
|---------------+----------------------------------------------------------------|
| AnySmallFormat| Tray that holds smaller format media. The media dimensions must|
|               | be specified. AnySmallFormat is defined for a PPD.             |
|---------------+----------------------------------------------------------------|
|AnyLargeFormat |Tray that holds larger format media with one dimension larger   |
|               |than 11 inches.. The media dimensions must be specified.        |
|               |AnyLargeFormat is defined for a PPD.                            |
|---------------+----------------------------------------------------------------|
|AutoSelect     |Requests the device to select an input tray based on the Media  |
|               |specification.                                                  |
|---------------+----------------------------------------------------------------|
|Bottom         |*The input tray that, when facing the device, can best be       |
|               |identified as ?bottom?.                                         |
|---------------+----------------------------------------------------------------|
|BypassTray     |The input tray used to handle odd or special papers. May be used|
|               |to specify the input tray that is used for inserts sheets that  |
|               |are not to be imaged.                                           |
|---------------+----------------------------------------------------------------|
|BypassTray-N   |The input tray used to handle odd or special papers. May be used|
|               |to specify the input tray that is used for inserts sheets that  |
|               |are not to be imaged.                                           |
|---------------+----------------------------------------------------------------|
|CD             |The input tray contains CDs.                                    |
|---------------+----------------------------------------------------------------|
|Continuous     |The input source is continuous feed.                            |
|---------------+----------------------------------------------------------------|
|Envelope       |The input tray that is to contain envelopes.                    |
|---------------+----------------------------------------------------------------|
|Envelope-N     |The input tray that is to contain envelopes.                    |
|---------------+----------------------------------------------------------------|
|Front          |*The input that, when facing the device, can best be identified |
|               |as ?front?.                                                     |
|---------------+----------------------------------------------------------------|
|InsertTray     |The input tray that can best be identified as 'inserttray'. Used|
|               |to specify the input tray that is used for inserts sheets       |
|               |(insert sheets are never imaged).                               |
|---------------+----------------------------------------------------------------|
|InsertTray-N   |The input tray that can best be identified as 'inserttray-1'.   |
|               |Used to specify the input tray that is used for inserts sheets  |
|               |(insert sheets are never imaged).                               |
|---------------+----------------------------------------------------------------|
|LargeCapacity  |The input tray that can best be identified as the ?large        |
|               |capacity? input tray (in terms of the number of sheets) with    |
|               |respect to the device.                                          |
|---------------+----------------------------------------------------------------|
|LargeCapacity-N|The input tray that can best be identified as the ?large        |
|               |capacity-1', 'large-capacity-2? ? etc input tray (in terms of   |
|               |the number of sheets) with respect to the device.               |
|---------------+----------------------------------------------------------------|
|Left           |*The input tray that, when facing the device, can best be       |
|               |identified as ?left.                                            |
|---------------+----------------------------------------------------------------|
|Middle         |*The input tray that, when facing the device, can best be       |
|               |identified as ?middle?.                                         |
|---------------+----------------------------------------------------------------|
|Rear           |*The input that, when facing the device, can best be identified |
|               |as ?rear?.                                                      |
|---------------+----------------------------------------------------------------|
|Right          |*The input tray that, when facing the device, can best be       |
|               |identified as ?right.                                           |
|---------------+----------------------------------------------------------------|
|Roll           |The input source is a roll feeder.                              |
|---------------+----------------------------------------------------------------|
|Side           |*The input tray that, when facing the device, can best be       |
|               |identified as ?side?.                                           |
|---------------+----------------------------------------------------------------|
|Top            |*The input tray that, when facing the device, can best be       |
|               |identified as ?top?.                                            |
|---------------+----------------------------------------------------------------|
|Tray-N         |The input tray is identified as ?Tray-1?, ?Tray-2? ? etc.       |
|---------------+----------------------------------------------------------------|
|SystemSpecified|The input tray selected is defined by the system. The default.  |
|---------------+----------------------------------------------------------------|



Following is a table that lists some common input tray names that are
analogous to an input tray name in the above table. The input tray names
listed in the table above should be used when possible.
|---------------+------------------------|
| Name          | Input Tray Name to use |
|               | instead                |
|---------------+------------------------|
|  Cassette     |  Tray-N                |
|---------------+------------------------|
| Center        | Middle                 |
|---------------+------------------------|
| Lower         | Bottom                 |
|---------------+------------------------|
| Main          | LargeCapcity           |
|---------------+------------------------|
| Upper         |  Top                   |
|---------------+------------------------|




Following are the trays that Mark said still need to be mapped and our
suggestions for a mapping:
TRAY_AUXILIARY_TRAY           use BypassTray, BypassTray-n, or Tray-n
TRAY_OPTION_CASSETTE    use Tray-n
TRAY_PORTABLE_SHEET           What is a portable sheet? Is the tray
portable?
TRAY_SINGLE_SHEET       same as TRAY_MANUAL_FEEDER below
TRAY_SHEET_FEEDER       use any of the tray names for cut sheet paper
TRAY_MANUAL_FEEDER            use media-manual-feed attribute (boolean)
                        and optionally a tray name (for example Envelope)

---------------------- Forwarded by Claudia Alimpich/Boulder/IBM on
05/13/2003 01:30 PM ---------------------------

Mark Hamzy/Austin/IBM at IBMUS@freestandards.org on 05/13/2003 07:53:29 AM

Please respond to printing-driver at freestandards.org

Sent by:    printing-driver-admin at freestandards.org


To:    printing-driver at freestandards.org
cc:
Subject:    [printing-driver] Tray additions/corrections







Resending as I do not see it on the list archives.

The following is a list of omni trays that still need to be mapped:

TRAY_AUXILIARY_TRAY
TRAY_OPTION_CASSETTE
TRAY_PORTABLE_SHEET
TRAY_SINGLE_SHEET
TRAY_SHEET_FEEDER
TRAY_MANUAL_FEEDER

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/
----- Forwarded by Mark Hamzy/Austin/IBM on 05/13/2003 08:52 AM -----

                      Mark Hamzy
                                               To:
                                               printing-driver at freestandards.org
                      05/12/2003 09:49         cc:
                      AM                       From:     Mark
                      Hamzy/Austin/IBM at IBMUS
                                               Subject:  Tray
                                               additions/corrections





After trying to map the Tray keys to omni driver tray keys, I have the
following corrections/additions:

AnySmallFormat        define?
AnyLargeFormat        define?
AutoSelect
Envelope
Envelope-n
InsertTray            define?
InsertTray-n
BypassTray            define?
BypassTray-n
LargeCapacityTray     modify - make consistent with above tray modifier
pattern
LargeCapacityTray-n   modify - make consistent with above tray modifier
pattern
Tray                  add - consistent with above tray modifier pattern
Tray-n
Top
Center
Middle
Bottom
Left
Right
Front                 add - opposite of rear
Side
Rear
Tractor               add - missing
Roll                  add - missing
Roll-n                add - missing
ZeroMarginTray        add - missing, consistent with tray modifier pattern
ZeroMarginTray-n      add - missing, consistent with tray modifier pattern
ZeroMarginRoll        add - missing, consistent with tray modifier pattern
ZeroMarginRoll-n      add - missing, consistent with tray modifier pattern
SingleSheetTray       ?
SingleSheetTray-n     ?
NotSet
None

Mark

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


_______________________________________________
printing-driver mailing list
printing-driver at freestandards.org
 http://freestandards.org/mailman/listinfo/printing-driver

From hamzy at us.ibm.com  Tue May 13 14:09:31 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Tue, 13 May 2003 16:09:31 -0500
Subject: [printing-driver] Re: Tray additions/corrections
Message-ID: <OF673A5475.548FD185-ON86256D25.0073AD6C-86256D25.00743A4D@us.ibm.com>





LargeCapacity should be renamed to LargeCapacityTray to be consistent with
all of the other trays.
The following should be added:
      Tray
      CD-n
      Roll-n
      ZeroMarginTray
      ZeroMarginTray-n
      ZeroMarginRoll
      ZeroMarginRoll-n
      SingleSheetTray
      SingleSheetTray-n

Mark

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


                                                                                                                                     
                      Claudia                                                                                                        
                      Alimpich/Boulder/IBM at IBMUS          To:       printing-driver at freestandards.org,                               
                      Sent by:                             printing-jobticket at freestandards.org                                      
                      printing-driver-admin at freest        cc:                                                                        
                      andards.org                         Subject:  [printing-driver] Re: Tray additions/corrections                 
                                                                                                                                     
                                                                                                                                     
                      05/13/2003 03:47 PM                                                                                            
                      Please respond to                                                                                              
                      printing-driver                                                                                                
                                                                                                                                     
                                                                                                                                     








The JT working group met today and we talked about the input tray mapping
questions that Mark Hamzy brought up in his note (see attached note).

Participants:
   Ira McDonald (High North Inc)
   Tom Hastings (Xerox)
   Till Kamppeter (MandrakeSoft)
   Claudia Alimpich (IBM)

Following is a table of the trays that JDF defines and a description for
each:
|---------------+----------------------------------------------------------------|

| Name          | Description
|
|---------------+----------------------------------------------------------------|

| AnySmallFormat| Tray that holds smaller format media. The media
dimensions must|
|               | be specified. AnySmallFormat is defined for a PPD.
|
|---------------+----------------------------------------------------------------|

|AnyLargeFormat |Tray that holds larger format media with one dimension
larger   |
|               |than 11 inches.. The media dimensions must be specified.
|
|               |AnyLargeFormat is defined for a PPD.
|
|---------------+----------------------------------------------------------------|

|AutoSelect     |Requests the device to select an input tray based on the
Media  |
|               |specification.
|
|---------------+----------------------------------------------------------------|

|Bottom         |*The input tray that, when facing the device, can best be
|
|               |identified as ?bottom?.
|
|---------------+----------------------------------------------------------------|

|BypassTray     |The input tray used to handle odd or special papers. May
be used|
|               |to specify the input tray that is used for inserts sheets
that  |
|               |are not to be imaged.
|
|---------------+----------------------------------------------------------------|

|BypassTray-N   |The input tray used to handle odd or special papers. May
be used|
|               |to specify the input tray that is used for inserts sheets
that  |
|               |are not to be imaged.
|
|---------------+----------------------------------------------------------------|

|CD             |The input tray contains CDs.
|
|---------------+----------------------------------------------------------------|

|Continuous     |The input source is continuous feed.
|
|---------------+----------------------------------------------------------------|

|Envelope       |The input tray that is to contain envelopes.
|
|---------------+----------------------------------------------------------------|

|Envelope-N     |The input tray that is to contain envelopes.
|
|---------------+----------------------------------------------------------------|

|Front          |*The input that, when facing the device, can best be
identified |
|               |as ?front?.
|
|---------------+----------------------------------------------------------------|

|InsertTray     |The input tray that can best be identified as
'inserttray'. Used|
|               |to specify the input tray that is used for inserts sheets
|
|               |(insert sheets are never imaged).
|
|---------------+----------------------------------------------------------------|

|InsertTray-N   |The input tray that can best be identified as
'inserttray-1'.   |
|               |Used to specify the input tray that is used for inserts
sheets  |
|               |(insert sheets are never imaged).
|
|---------------+----------------------------------------------------------------|

|LargeCapacity  |The input tray that can best be identified as the ?large
|
|               |capacity? input tray (in terms of the number of sheets)
with    |
|               |respect to the device.
|
|---------------+----------------------------------------------------------------|

|LargeCapacity-N|The input tray that can best be identified as the ?large
|
|               |capacity-1', 'large-capacity-2? ? etc input tray (in terms
of   |
|               |the number of sheets) with respect to the device.
|
|---------------+----------------------------------------------------------------|

|Left           |*The input tray that, when facing the device, can best be
|
|               |identified as ?left.
|
|---------------+----------------------------------------------------------------|

|Middle         |*The input tray that, when facing the device, can best be
|
|               |identified as ?middle?.
|
|---------------+----------------------------------------------------------------|

|Rear           |*The input that, when facing the device, can best be
identified |
|               |as ?rear?.
|
|---------------+----------------------------------------------------------------|

|Right          |*The input tray that, when facing the device, can best be
|
|               |identified as ?right.
|
|---------------+----------------------------------------------------------------|
|Roll           |The input source is a roll feeder.
|
|---------------+----------------------------------------------------------------|

|Side           |*The input tray that, when facing the device, can best be
|
|               |identified as ?side?.
|
|---------------+----------------------------------------------------------------|

|Top            |*The input tray that, when facing the device, can best be
|
|               |identified as ?top?.
|
|---------------+----------------------------------------------------------------|

|Tray-N         |The input tray is identified as ?Tray-1?, ?Tray-2? ? etc.
|
|---------------+----------------------------------------------------------------|

|SystemSpecified|The input tray selected is defined by the system. The
default.  |
|---------------+----------------------------------------------------------------|




Following is a table that lists some common input tray names that are
analogous to an input tray name in the above table. The input tray names
listed in the table above should be used when possible.
|---------------+------------------------|
| Name          | Input Tray Name to use |
|               | instead                |
|---------------+------------------------|
|  Cassette     |  Tray-N                |
|---------------+------------------------|
| Center        | Middle                 |
|---------------+------------------------|
| Lower         | Bottom                 |
|---------------+------------------------|
| Main          | LargeCapcity           |
|---------------+------------------------|
| Upper         |  Top                   |
|---------------+------------------------|




Following are the trays that Mark said still need to be mapped and our
suggestions for a mapping:
TRAY_AUXILIARY_TRAY           use BypassTray, BypassTray-n, or Tray-n
TRAY_OPTION_CASSETTE    use Tray-n
TRAY_PORTABLE_SHEET           What is a portable sheet? Is the tray
portable?
TRAY_SINGLE_SHEET       same as TRAY_MANUAL_FEEDER below
TRAY_SHEET_FEEDER       use any of the tray names for cut sheet paper
TRAY_MANUAL_FEEDER            use media-manual-feed attribute (boolean)
                        and optionally a tray name (for example Envelope)

---------------------- Forwarded by Claudia Alimpich/Boulder/IBM on
05/13/2003 01:30 PM ---------------------------

Mark Hamzy/Austin/IBM at IBMUS@freestandards.org on 05/13/2003 07:53:29 AM

Please respond to printing-driver at freestandards.org

Sent by:    printing-driver-admin at freestandards.org


To:    printing-driver at freestandards.org
cc:
Subject:    [printing-driver] Tray additions/corrections







Resending as I do not see it on the list archives.

The following is a list of omni trays that still need to be mapped:

TRAY_AUXILIARY_TRAY
TRAY_OPTION_CASSETTE
TRAY_PORTABLE_SHEET
TRAY_SINGLE_SHEET
TRAY_SHEET_FEEDER
TRAY_MANUAL_FEEDER

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/
----- Forwarded by Mark Hamzy/Austin/IBM on 05/13/2003 08:52 AM -----

                      Mark Hamzy
                                               To:

printing-driver at freestandards.org
                      05/12/2003 09:49         cc:
                      AM                       From:     Mark
                      Hamzy/Austin/IBM at IBMUS
                                               Subject:  Tray
                                               additions/corrections





After trying to map the Tray keys to omni driver tray keys, I have the
following corrections/additions:

AnySmallFormat        define?
AnyLargeFormat        define?
AutoSelect
Envelope
Envelope-n
InsertTray            define?
InsertTray-n
BypassTray            define?
BypassTray-n
LargeCapacityTray     modify - make consistent with above tray modifier
pattern
LargeCapacityTray-n   modify - make consistent with above tray modifier
pattern
Tray                  add - consistent with above tray modifier pattern
Tray-n
Top
Center
Middle
Bottom
Left
Right
Front                 add - opposite of rear
Side
Rear
Tractor               add - missing
Roll                  add - missing
Roll-n                add - missing
ZeroMarginTray        add - missing, consistent with tray modifier pattern
ZeroMarginTray-n      add - missing, consistent with tray modifier pattern
ZeroMarginRoll        add - missing, consistent with tray modifier pattern
ZeroMarginRoll-n      add - missing, consistent with tray modifier pattern
SingleSheetTray       ?
SingleSheetTray-n     ?
NotSet
None

Mark

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


_______________________________________________
printing-driver mailing list
printing-driver at freestandards.org
 http://freestandards.org/mailman/listinfo/printing-driver


From hamzy at us.ibm.com  Mon May 19 11:17:45 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 19 May 2003 13:17:45 -0500
Subject: [printing-driver] pdc.h version 0.01
Message-ID: <OF0F997743.841E866E-ON86256D2B.00646E1D-86256D2B.006480A4@us.ibm.com>




/*
** Copyright (c) 2003 International Business Machines
**
** Permission is hereby granted, free of charge, to any person obtaining a
** copy of this software and associated documentation files (the
"Software"),
** to deal in the Software without restriction, including without
limitation
** the rights to use, copy, modify, merge, publish, distribute, sublicense,
** and/or sell copies of the Software, and to permit persons to whom the
** Software is furnished to do so, subject to the following conditions:
**
** The above copyright notice and this permission notice shall be included
** in all copies or substantial portions of the Software.
**
** THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
** OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
** MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
** IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
** CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
** TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
** SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
**
*/
#ifndef _PDC_H
#define _PDC_H 1

#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */

const void *pdcOpenLibrary                ();

/* Library level calls: */
int         pdcCloseLibrary               (const void *pvPDCHandle);
const char *pdcEnumerateDrivers           (const void *pvPDCHandle);
const void *pdcOpenDriver                 (const void *pvPDCHandle,
                                           const char *pszDriver);

/* Driver level calls: */
int         pdcCloseDriver                (const void *pvDriverHandle);
const char *pdcEnumerateDevices           (const void *pvDriverHandle);
const char *pdcGetDeviceHandle            (const void *pvDriverHandle,
                                           const char *pszDisplayHandle);
const void *pdcOpenDevice                 (const void *pvDriverHandle,
                                           const char *pszDeviceHandle);

/* Device level calls: */
int         pdcCloseDevice                (const void *pvDeviceHandle);
int         pdcSetTranslatableLanguage    (const void *pvDeviceHandle,
                                           const char *pszLanguage);
const char *pdcGetTranslatableLanguage    (const void *pvDeviceHandle);
const char *pdcQueryTranslatableLanguages (const void *pvDeviceHandle);

const char *pdcGetPDLInformation          (const void *pvDeviceHandle);

const char *pdcQueryCurrentJobProperties  (const void *pvDeviceHandle);
int         pdcSetJobProperties           (const void *pvDeviceHandle,
                                           const char *pszJobProperties);
const char *pdcListJobPropertyKeys        (const void *pvDeviceHandle);
const char *pdcListJobPropertyKeyValues   (const void *pvDeviceHandle,
                                           const char *pszKey);
const char *pdcGetJobProperty             (const void *pvDeviceHandle,
                                           const char *pszKey);
const char *pdcGetJobPropertyType         (const void *pvDeviceHandle,
                                           const char *pszKey);
const char *pdcTranslateJobProperty       (const void *pvDeviceHandle,
                                           const char *pszKey,
                                           const char *pszValue);

int         pdcBeginJob                   (const void *pvDeviceHandle);
int         pdcStartPage                  (const void *pvDeviceHandle);
int         pdcStartPageWithProperties    (const void *pvDeviceHandle,
                                           const char *pszJobProperties);
int         pdcEndPage                    (const void *pvDeviceHandle);
int         pdcEndJob                     (const void *pvDeviceHandle);
int         pdcAbortPage                  (const void *pvDeviceHandle);
int         pdcAbortJob                   (const void *pvDeviceHandle);

#ifdef __cplusplus
}
#endif /* __cplusplus */

#endif /* _PDC_H */


Mark

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




From alimpich at us.ibm.com  Tue May 20 19:14:49 2003
From: alimpich at us.ibm.com (Claudia Alimpich)
Date: Tue, 20 May 2003 20:14:49 -0600
Subject: [printing-driver] Re: Tray additions/corrections
Message-ID: <OF847E0257.4358C6DD-ON87256D2C.0069ACFA@us.ibm.com>





We talked about this during today's JT working group meeting and have some
questions. So instead of going back and forth on the mailing list, how
about if we talk about this next week during a combined Driver and JT
working group meeting and try to resolve it once and for all?

Next Monday is a US holiday and some people won't be at work next Tuesday.
Is there another day and another time that we could meet? I can arrange a
call in number once we decide on the day and time. Please post your
available days and timesfor next week to the JT mailing list by the end of
the day Wednesday May 21st.

We are also having coordinate system discussions/problems that someone in
the driver group may be able to help us with since some of you may
underdstand PS and PCL coordinates better than we do.
Claudia


---------------------- Forwarded by Claudia Alimpich/Boulder/IBM on
05/20/2003 01:16 PM ---------------------------

Mark Hamzy/Austin/IBM at IBMUS@freestandards.org on 05/13/2003 03:09:31 PM

Sent by:    printing-jobticket-admin at freestandards.org


To:    printing-driver at freestandards.org,
       printing-jobticket at freestandards.org
cc:
Subject:    [printing-jobticket] Re: [printing-driver] Re: Tray
       additions/corrections







LargeCapacity should be renamed to LargeCapacityTray to be consistent with
all of the other trays.
The following should be added:
      Tray
      CD-n
      Roll-n
      ZeroMarginTray
      ZeroMarginTray-n
      ZeroMarginRoll
      ZeroMarginRoll-n
      SingleSheetTray
      SingleSheetTray-n

Mark

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



                      Claudia
                      Alimpich/Boulder/IBM at IBMUS          To:
                      printing-driver at freestandards.org,
                      Sent by:
                      printing-jobticket at freestandards.org
                      printing-driver-admin at freest        cc:
                      andards.org                         Subject:
                      [printing-driver] Re: Tray additions/corrections


                      05/13/2003 03:47 PM
                      Please respond to
                      printing-driver










The JT working group met today and we talked about the input tray mapping
questions that Mark Hamzy brought up in his note (see attached note).

Participants:
   Ira McDonald (High North Inc)
   Tom Hastings (Xerox)
   Till Kamppeter (MandrakeSoft)
   Claudia Alimpich (IBM)

Following is a table of the trays that JDF defines and a description for
each:
|---------------+----------------------------------------------------------------|


| Name          | Description
|
|---------------+----------------------------------------------------------------|


| AnySmallFormat| Tray that holds smaller format media. The media
dimensions must|
|               | be specified. AnySmallFormat is defined for a PPD.
|
|---------------+----------------------------------------------------------------|


|AnyLargeFormat |Tray that holds larger format media with one dimension
larger   |
|               |than 11 inches.. The media dimensions must be specified.
|
|               |AnyLargeFormat is defined for a PPD.
|
|---------------+----------------------------------------------------------------|


|AutoSelect     |Requests the device to select an input tray based on the
Media  |
|               |specification.
|
|---------------+----------------------------------------------------------------|


|Bottom         |*The input tray that, when facing the device, can best be
|
|               |identified as ?bottom?.
|
|---------------+----------------------------------------------------------------|


|BypassTray     |The input tray used to handle odd or special papers. May
be used|
|               |to specify the input tray that is used for inserts sheets
that  |
|               |are not to be imaged.
|
|---------------+----------------------------------------------------------------|


|BypassTray-N   |The input tray used to handle odd or special papers. May
be used|
|               |to specify the input tray that is used for inserts sheets
that  |
|               |are not to be imaged.
|
|---------------+----------------------------------------------------------------|


|CD             |The input tray contains CDs.
|
|---------------+----------------------------------------------------------------|


|Continuous     |The input source is continuous feed.
|
|---------------+----------------------------------------------------------------|


|Envelope       |The input tray that is to contain envelopes.
|
|---------------+----------------------------------------------------------------|


|Envelope-N     |The input tray that is to contain envelopes.
|
|---------------+----------------------------------------------------------------|


|Front          |*The input that, when facing the device, can best be
identified |
|               |as ?front?.
|
|---------------+----------------------------------------------------------------|


|InsertTray     |The input tray that can best be identified as
'inserttray'. Used|
|               |to specify the input tray that is used for inserts sheets
|
|               |(insert sheets are never imaged).
|
|---------------+----------------------------------------------------------------|


|InsertTray-N   |The input tray that can best be identified as
'inserttray-1'.   |
|               |Used to specify the input tray that is used for inserts
sheets  |
|               |(insert sheets are never imaged).
|
|---------------+----------------------------------------------------------------|


|LargeCapacity  |The input tray that can best be identified as the ?large
|
|               |capacity? input tray (in terms of the number of sheets)
with    |
|               |respect to the device.
|
|---------------+----------------------------------------------------------------|


|LargeCapacity-N|The input tray that can best be identified as the ?large
|
|               |capacity-1', 'large-capacity-2? ? etc input tray (in terms
of   |
|               |the number of sheets) with respect to the device.
|
|---------------+----------------------------------------------------------------|


|Left           |*The input tray that, when facing the device, can best be
|
|               |identified as ?left.
|
|---------------+----------------------------------------------------------------|


|Middle         |*The input tray that, when facing the device, can best be
|
|               |identified as ?middle?.
|
|---------------+----------------------------------------------------------------|


|Rear           |*The input that, when facing the device, can best be
identified |
|               |as ?rear?.
|
|---------------+----------------------------------------------------------------|


|Right          |*The input tray that, when facing the device, can best be
|
|               |identified as ?right.
|
|---------------+----------------------------------------------------------------|

|Roll           |The input source is a roll feeder.
|
|---------------+----------------------------------------------------------------|


|Side           |*The input tray that, when facing the device, can best be
|
|               |identified as ?side?.
|
|---------------+----------------------------------------------------------------|


|Top            |*The input tray that, when facing the device, can best be
|
|               |identified as ?top?.
|
|---------------+----------------------------------------------------------------|


|Tray-N         |The input tray is identified as ?Tray-1?, ?Tray-2? ? etc.
|
|---------------+----------------------------------------------------------------|


|SystemSpecified|The input tray selected is defined by the system. The
default.  |
|---------------+----------------------------------------------------------------|





Following is a table that lists some common input tray names that are
analogous to an input tray name in the above table. The input tray names
listed in the table above should be used when possible.
|---------------+------------------------|
| Name          | Input Tray Name to use |
|               | instead                |
|---------------+------------------------|
|  Cassette     |  Tray-N                |
|---------------+------------------------|
| Center        | Middle                 |
|---------------+------------------------|
| Lower         | Bottom                 |
|---------------+------------------------|
| Main          | LargeCapcity           |
|---------------+------------------------|
| Upper         |  Top                   |
|---------------+------------------------|




Following are the trays that Mark said still need to be mapped and our
suggestions for a mapping:
TRAY_AUXILIARY_TRAY           use BypassTray, BypassTray-n, or Tray-n
TRAY_OPTION_CASSETTE    use Tray-n
TRAY_PORTABLE_SHEET           What is a portable sheet? Is the tray
portable?
TRAY_SINGLE_SHEET       same as TRAY_MANUAL_FEEDER below
TRAY_SHEET_FEEDER       use any of the tray names for cut sheet paper
TRAY_MANUAL_FEEDER            use media-manual-feed attribute (boolean)
                        and optionally a tray name (for example Envelope)

---------------------- Forwarded by Claudia Alimpich/Boulder/IBM on
05/13/2003 01:30 PM ---------------------------

Mark Hamzy/Austin/IBM at IBMUS@freestandards.org on 05/13/2003 07:53:29 AM

Please respond to printing-driver at freestandards.org

Sent by:    printing-driver-admin at freestandards.org


To:    printing-driver at freestandards.org
cc:
Subject:    [printing-driver] Tray additions/corrections







Resending as I do not see it on the list archives.

The following is a list of omni trays that still need to be mapped:

TRAY_AUXILIARY_TRAY
TRAY_OPTION_CASSETTE
TRAY_PORTABLE_SHEET
TRAY_SINGLE_SHEET
TRAY_SHEET_FEEDER
TRAY_MANUAL_FEEDER

Mark

Take a look at the Linux Omni Printer Driver Framework at
http://www.ibm.com/linux/ltc/projects/omni/
----- Forwarded by Mark Hamzy/Austin/IBM on 05/13/2003 08:52 AM -----

                      Mark Hamzy
                                               To:

printing-driver at freestandards.org
                      05/12/2003 09:49         cc:
                      AM                       From:     Mark
                      Hamzy/Austin/IBM at IBMUS
                                               Subject:  Tray
                                               additions/corrections





After trying to map the Tray keys to omni driver tray keys, I have the
following corrections/additions:

AnySmallFormat        define?
AnyLargeFormat        define?
AutoSelect
Envelope
Envelope-n
InsertTray            define?
InsertTray-n
BypassTray            define?
BypassTray-n
LargeCapacityTray     modify - make consistent with above tray modifier
pattern
LargeCapacityTray-n   modify - make consistent with above tray modifier
pattern
Tray                  add - consistent with above tray modifier pattern
Tray-n
Top
Center
Middle
Bottom
Left
Right
Front                 add - opposite of rear
Side
Rear
Tractor               add - missing
Roll                  add - missing
Roll-n                add - missing
ZeroMarginTray        add - missing, consistent with tray modifier pattern
ZeroMarginTray-n      add - missing, consistent with tray modifier pattern
ZeroMarginRoll        add - missing, consistent with tray modifier pattern
ZeroMarginRoll-n      add - missing, consistent with tray modifier pattern
SingleSheetTray       ?
SingleSheetTray-n     ?
NotSet
None

Mark

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


_______________________________________________
printing-driver mailing list
printing-driver at freestandards.org
 http://freestandards.org/mailman/listinfo/printing-driver


From hamzy at us.ibm.com  Thu May 22 07:59:06 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Thu, 22 May 2003 09:59:06 -0500
Subject: [printing-driver] new version of pdc.h
Message-ID: <OFE6E97D64.8311DC33-ON86256D2E.00523F4C-86256D2E.005250E1@us.ibm.com>




/*
** Copyright (c) 2003 International Business Machines
**
** Permission is hereby granted, free of charge, to any person obtaining a
** copy of this software and associated documentation files (the
"Software"),
** to deal in the Software without restriction, including without
limitation
** the rights to use, copy, modify, merge, publish, distribute, sublicense,
** and/or sell copies of the Software, and to permit persons to whom the
** Software is furnished to do so, subject to the following conditions:
**
** The above copyright notice and this permission notice shall be included
** in all copies or substantial portions of the Software.
**
** THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
** OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
** MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
** IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
** CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
** TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
** SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
**
*/
#ifndef _PDC_H
#define _PDC_H 1

#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */

/* This is the handle to a Printer Driver Communications library
*/
typedef const void *PDCHANDLE;
/* This is the handle to a printer driver
*/
typedef const void *DRIVERHANDLE;
/* This is the handle to a printer device
*/
typedef const void *DEVICEHANDLE;
/* In the form "string1\0string2\0...\0stringN\0\0"
*/
typedef const char *STRINGARRAY;
/* In the form
"string1\0handle1\0string2\0handle2\0...\0...\0stringN\0handleN\0\0\0"
*/
typedef const char *STRINGPAIRARRAY;

/*
*/
PDCHANDLE       pdcOpenLibrary               ();

/* Library level calls: */

/*
*/
int             pdcCloseLibrary              (PDCHANDLE   handlePDC);
/*
*/
STRINGARRAY     pdcEnumerateDrivers          (PDCHANDLE   handlePDC);
/*
*/
DRIVERHANDLE    pdcOpenDriver                (PDCHANDLE   handlePDC,
                                              const char *pszDriver);

/* Driver level calls: */

/*
*/
int             pdcCloseDriver               (DRIVERHANDLE  handleDriver);
/*
*/
STRINGPAIRARRAY pdcEnumerateDevices          (DRIVERHANDLE  handleDriver);
/*
*/
const char     *pdcGetDeviceHandle           (DRIVERHANDLE  handleDriver,
                                              const char
*pszDisplayHandle);
/*
*/
DEVICEHANDLE    pdcOpenDevice                (DRIVERHANDLE  handleDriver,
                                              const char
*pszDeviceHandle);

/* Device level calls: */

/*
*/
int             pdcCloseDevice                (DEVICEHANDLE  handleDevice);

/*
*/
int             pdcSetTranslatableLanguage    (DEVICEHANDLE  handleDevice,
                                               const char   *pszLanguage);
/*
*/
const char     *pdcGetTranslatableLanguage    (DEVICEHANDLE  handleDevice);
/*
*/
STRINGARRAY     pdcQueryTranslatableLanguages (DEVICEHANDLE  handleDevice);

/*
*/
const char     *pdcGetPDLInformation          (DEVICEHANDLE  handleDevice);

/*
*/
const char     *pdcQueryCurrentJobProperties  (DEVICEHANDLE  handleDevice);
/*
*/
int             pdcSetJobProperties           (DEVICEHANDLE  handleDevice,
                                               const char
*pszJobProperties);
/*
*/
STRINGARRAY     pdcListJobPropertyKeys        (DEVICEHANDLE  handleDevice);
/*
*/
STRINGARRAY     pdcListJobPropertyKeyValues   (DEVICEHANDLE  handleDevice,
                                               const char   *pszKey);
/*
*/
const char     *pdcGetJobProperty             (DEVICEHANDLE  handleDevice,
                                               const char   *pszKey);
/*
*/
const char     *pdcGetJobPropertyType         (DEVICEHANDLE  handleDevice,
                                               const char   *pszKey);
/*
*/
const char     *pdcTranslateJobProperty       (DEVICEHANDLE  handleDevice,
                                               const char   *pszKey,
                                               const char   *pszValue);

/*
*/
int             pdcBeginJob                   (DEVICEHANDLE  handleDevice);
/*
*/
int             pdcStartPage                  (DEVICEHANDLE  handleDevice);
/*
*/
int             pdcStartPageWithProperties    (DEVICEHANDLE  handleDevice,
                                               const char
*pszJobProperties);
/*
*/
int             pdcEndPage                    (DEVICEHANDLE  handleDevice);
/*
*/
int             pdcEndJob                     (DEVICEHANDLE  handleDevice);
/*
*/
int             pdcAbortPage                  (DEVICEHANDLE  handleDevice);
/*
*/
int             pdcAbortJob                   (DEVICEHANDLE  handleDevice);

#ifdef __cplusplus
}
#endif /* __cplusplus */

#endif /* _PDC_H */


Mark

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




From Norm.Jacobs at Sun.COM  Thu May 22 22:18:26 2003
From: Norm.Jacobs at Sun.COM (Norm Jacobs)
Date: Fri, 23 May 2003 00:18:26 -0500
Subject: [printing-driver] new version of pdc.h
References: <OFE6E97D64.8311DC33-ON86256D2E.00523F4C-86256D2E.005250E1@us.ibm.com>
Message-ID: <3ECDAF22.B58C8AB3@Sun.COM>

You really want this to be "char **".  That would be an array of
pointers to
characters arrays (strings).  On the wire it may be encoded string,
string, ...\0\0

> /* In the form "string1\0string2\0...\0stringN\0\0"
> */

You really want this to be structured.

> typedef const char *STRINGARRAY;
> /* In the form
> "string1\0handle1\0string2\0handle2\0...\0...\0stringN\0handleN\0\0\0"
> */
> typedef const char *STRINGPAIRARRAY;
> 

I took the header you supplied and changed it so it was more in line
with what I
was thinking about when we talked about pdc.h in the meeting Monday. 
I'm sure it's
incomplete and probably not entirely consistent.  Quite a bit of
comments would need to
be added before anyone could really figure out how it works.  I added a
status type to
aid in returning meaningful errors from some of the functions (more than
NULL, failed) and structured the properties.  I also enumerated the
property value types.


		-Norm

#ifndef _PDC_H
#define _PDC_H

#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */

/* This is the handle to a Printer Driver Communications library
*/
typedef void *pdc_handle_t;		/* Printer Driver Communications Lib */
typedef void *pdc_driver_handle_t;	/* Printer Driver handle */
typedef void *pdc_device_handle_t;	/* Printer Device handle */
typedef enum {
	PDC_OK,
	PDC_NOT_FOUND,
	PDC_YIKES
} pdc_status_t;

/*
 * we may want to consider the PAPI attribute interface here.  The
interface
 * supports named multi-value attributes, but supports more than just
strings.
 * There are also a bunch of functions defined that allow you to get/set
 * attributes/attribute values in attribute lists.
 */
typedef struct {
	char *key;	/* property name */
	char **values;	/* property values (assuming multivalue) */
} pdc_property_t;

typedef enum {
	PDC_STRING,
	PDC_INTEGER,
	PDC_BOOLEAN,
	PDC_RESOLUTION
} pdc_property_type_t
	

/*
 * basic driver object handling routines
 */
pdc_status_t	pdcOpenLibrary(pdc_handle_t *pdc_handle);
pdc_status_t	pdcCloseLibrary(pdc_handle_t pdc_handle);
char 		**pdcEnumerateDriverNames(pdc_handle_t pdc_handle);

/*
 * basic driver handling routines
 */
pdc_status_t	pdcOpenDriver(pdc_handle_t pdc_handle, const char
*driver_name,
				pdc_driver_handle_t *driver_handle);
pdc_status_t	pdcCloseDriver(pdc_driver_handle_t driver_handle);
char		**pdcEnumerateDeviceNames(pdc_driver_handle_t  driver_handle);

/*
 * basic device handling routines
 */
pdc_status_t	pdcOpenDevice(pdc_driver_handle_t driver_handle,
				const char *device_name,
				pdc_device_handle_t *device_handle);
pdc_status_t	pdcCloseDevice(pdc_device_handle_t device_handle);

pdc_status_t	pdcSetTranslatableLanguage(pdc_device_handle_t
device_handle,
				const char *language);
char		*pdcGetTranslatableLanguage(pdc_device_handle_t device_handle);
char		**pdcQueryTranslatableLnaguages(
				pdc_device_handle_t device_handle);
char		*pdcGetPDLInformation(pdc_device_handle_t device_handle);

/*
 * this is where the PAPI attribute interface might make sense.
 */
pdc_property_t	**pdcQueryCurrentJobProperties(
				pdc_device_handle_t device_handle);

pdc_status_t	pdcSetJobProperties(pdc_device_handle_t device_handle,
				const char *property_name,
				const char **property_values);

char		**pdcListJobPropertyKeys(pdc_device_handle_t device_handle);
char		**pdcGetJobPropertySupportedValues(
				pdc_device_handle_t device_handle,
				const char *property_name);
char		**pdcGetJobPropertyValues(pdc_device_handle_t device_handle,
				const char *property_name);
pdc_property_type_t pdcGetJobPropertyType(pdc_device_handle_t
device_handle,
				const char *property_name);
char		*pdcTranslateJobProperty(pdc_device_handle_t device_handle,
				const char *property_name,
				const char *property_value);

pdc_status_t pdcBeginJob(pdc_device_handle_t device_handle);
pdc_status_t pdcStartPage(pdc_device_handle_t device_handle);
pdc_status_t pdcStartPageWithProperties(pdc_device_handle_t
device_handle,
				const pdc_property_t **page_properties);
pdc_status_t pdcAbortPage(pdc_device_handle_t device_handle);
pdc_status_t pdcEndPage(pdc_device_handle_t device_handle);
pdc_status_t pdcEndJob(pdc_device_handle_t device_handle);
pdc_status_t pdcAbortJob(pdc_device_handle_t device_handle);

#ifdef __cplusplus
}
#endif /* __cplusplus */

#endif /* _PDC_H */



From hamzy at us.ibm.com  Wed May 28 07:33:07 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Wed, 28 May 2003 09:33:07 -0500
Subject: [printing-driver] new version of pdc.h
Message-ID: <OF41735A94.0F996869-ON86256D34.004D2F59-86256D34.004FF00E@us.ibm.com>




Hey Norm,

Thanks for the input.  I will add the enumerated return codes to the
library.

> On the wire it may be encoded string, string, ...\0\0
> You really want this to be structured.

I had thought of that but I realized that it involved a lot of extra
overhead
for little benefit.  Let me explain.

On the "wire", it is encoded as an array of strings.  In CVS, the driver
will
return an array of strings to the library and the library will turn around
and return it to the application which will then print it out and free the
strings.

What you are proposing is that the library will now have to do the
following:
Iterate over the list and find out how many strings are returned.  Allocate
a new block of memory for the strings and the array of pointers.  Copy the
strings
and initialize the pointers.  Free the array of strings.  Return the new
array
of pointers.  These calls are the calls that are called the majority of the
time
for dealing with and showing job properties.

All of this so that the application does not have to index the strings by
strlen ().  Is that indexing method so strange?

Mark

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




From hastings at cp10.es.xerox.com  Wed May 28 10:48:49 2003
From: hastings at cp10.es.xerox.com (Hastings, Tom N)
Date: Wed, 28 May 2003 10:48:49 -0700
Subject: [printing-driver] RE: [printing-jobticket] Wed - May 28th - 2-4pm EDT - Job Ticket/
 Driver telecon - trays [the driver phone number]
Message-ID: <E0BE13326C4EBC45BBC635197DEB7E3FB5460A@x-crt-es-ms1.cp10.es.xerox.com>

I called Claudia and she said we're using the Driver number (not the job
ticket number):

1(800) 497-2024  password: 160458#

Tom

-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Wednesday, May 28, 2003 10:29
To: 'Claudia Alimpich'; printing-jobticket at freestandards.org
Subject: RE: [printing-jobticket] Wed - May 28th - 2-4pm EDT - Job
Ticket/ Driver telecon - trays
Importance: High


Hi Claudia and Mark,

WHICH call-in number are we using in half an hour, please?
(JTAPI or Driver)?

Cheers,
- Ira


-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Friday, May 23, 2003 11:48 AM
To: 'Claudia Alimpich'; printing-jobticket at freestandards.org
Subject: RE: [printing-jobticket] Wed - May 28th - 2-4pm EDT - Job
Ticket/ Driver telecon - trays


Hi,

Retitled to make obvious the joint JT/Driver telecon next Wednesday.

Cheers,
- Ira McDonald
  High North Inc

PS - Claudia - you typed May 17th in your original Subject line.

-----Original Message-----
From: Claudia Alimpich [mailto:alimpich at us.ibm.com]
Sent: Friday, May 23, 2003 2:49 AM
To: printing-jobticket at freestandards.org
Subject: [printing-jobticket] Wed - May 28th - 2-4pm EDT - Job
Ticket/Driver telecon - trays


The next Job Ticket working group meeting on Tuesday May 27th is canceled.
Instead, we will have a one time only combined Driver and Job Ticket
working group meeting on Wednesday May 28th from 2:00-4:00 PM Eastern time
to resolve Input Tray Names.

Claudia

_______________________________________________
printing-jobticket mailing list
printing-jobticket at freestandards.org
http://freestandards.org/mailman/listinfo/printing-jobticket

_______________________________________________
printing-jobticket mailing list
printing-jobticket at freestandards.org
http://freestandards.org/mailman/listinfo/printing-jobticket

_______________________________________________
printing-jobticket mailing list
printing-jobticket at freestandards.org
http://freestandards.org/mailman/listinfo/printing-jobticket



From alimpich at us.ibm.com  Wed May 28 13:05:01 2003
From: alimpich at us.ibm.com (Claudia Alimpich)
Date: Wed, 28 May 2003 14:05:01 -0600
Subject: [printing-driver] Input tray names - final list
Message-ID: <OFB36F1A38.D8B73589-ON87256D34.0063F321@us.ibm.com>




During the combined Driver and Job Ticket working group meeting today (Wed
May 28th) we decided on the following input tray names.

 Participants:
    Norm Jacobs
    Ira McDonald
    Till Kamppeter
    Mark Hamzy
    Tom Hastings
    Glen Petrie
    Pete Zannucci
    Pete Zehler
    Claudia Alimpich

 Input tray names:
   AnySmallFormat
   AnyLargeFormat
   AutoSelect
   Bottom
   Continuous           Fanfold or perforated
   BypassTray
   BypassTray-N
   Disc           Tray that contains media such as CD or DVD
   Disc-N
   Envelope
   Envelope-N
   Front
   InsertTray
   InsertTray-N
   LargeCapacity
   LargeCapacity-N
   Left
   Middle
   Rear
   Right
   Roll
   Roll-N
   Side
   Top
   Tray           Use when there is a single tray, otherwise for multiple
   trays use Tray-N
   Tray-N

   Input tray name aliases:
      For Cassette use Tray-N
      For Center use Middle
      For Lower use Bottom
      For Main use LargeCapacity
      For Upper use Top
      For Removeable or Portable use one of the above that best describes
      the tray
      For SheetFeeder use Tray-N
      For AuxiliaryTray use BypassTray, BypassTray-N or Tray-N




From Norm.Jacobs at Sun.COM  Wed May 28 13:25:40 2003
From: Norm.Jacobs at Sun.COM (Norm Jacobs)
Date: Wed, 28 May 2003 15:25:40 -0500
Subject: [printing-driver] new version of pdc.h
References: <OF41735A94.0F996869-ON86256D34.004D2F59-86256D34.004FF00E@us.ibm.com>
Message-ID: <3ED51B44.1AAA5EED@Sun.COM>

Mark Hamzy wrote:
> 

> > On the wire it may be encoded string, string, ...\0\0
> > You really want this to be structured.
> 
> I had thought of that but I realized that it involved a lot of extra
> overhead
> for little benefit.  Let me explain.
> 
> On the "wire", it is encoded as an array of strings.  In CVS, the driver
> will
> return an array of strings to the library and the library will turn around
> and return it to the application which will then print it out and free the
> strings.

It's returning an array of bytes with null separators.  This is
something
that the consumer will have to parse each time the use it.

> 
> What you are proposing is that the library will now have to do the
> following:
> Iterate over the list and find out how many strings are returned.  Allocate
> a new block of memory for the strings and the array of pointers.  Copy the
> strings
> and initialize the pointers.  Free the array of strings.  Return the new
> array
> of pointers.  These calls are the calls that are called the majority of the
> time
> for dealing with and showing job properties.

In addition to your current array of bytes with null separators, you
would only need to allocate the pointer array and fill it with the
indexes in your array.  Though from a memory management perspective,
depending on whether any of the lists are dynamic, you might want to
dup the strings from the stream of bytes.

Once in pointer array form, it is more efficient and easier to use and
process.  Searching no longer requires looking at each byte in the
stream until it matches or fails.  Indexing the array is simple
pointer arithmetic, it doesn't require examining each byte of the
stream until the proper place in the stream is found.  Counting
the number of properties only requires walking the pointer array, not
each byte of the stream.
Assuming that some of the arrays are dynamic, adding to or removing from
also requires less overhead than doing so with a array of bytes with
separators.

> 
> All of this so that the application does not have to index the strings by
> strlen ().  Is that indexing method so strange?

The index would really be "strlen() + 1".  To me it doesn't seem like a
natural representation of an array of strings in C.

It all probably boils down to a simple question: Do you want to
incur a small amount of up front overhead to cut code complexity
and overhead in actual use of the data?

I tend to believe that the consumer of the interface is at least
as dumb as I am, so I tend to want to present the data in a well
structured form that requires the least amount of work (or thought)
to use.  If you make them (or me) think (parse the array when
using it), they (or I) will tend to make more mistakes than if
you supply a parsed array of pointers to strings.  I believe
that representing the data this way will make it easier for
consumers to get it right the first time and ultimately lead to
more maintainable code.

Regardless of how it's represented, we need to make it clear as to
who is responsible for the memory associated with the various
bits of data.

		-Norm



From hamzy at us.ibm.com  Mon Jun  2 07:57:49 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 2 Jun 2003 09:57:49 -0500
Subject: [printing-driver] FSG Printing Driver conference call 06/02/03
Message-ID: <OF47F1BC9C.95195521-ON86256D39.00521009-86256D39.0052328D@us.ibm.com>




Monday, June 2

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Mark

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




From hamzy at us.ibm.com  Mon Jun  9 07:37:56 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 9 Jun 2003 09:37:56 -0500
Subject: [printing-driver] FSG Printing Driver conference call 06/07/03
Message-ID: <OF6E14F770.D4B627C7-ON86256D40.005054AE-86256D40.00506091@us.ibm.com>




Monday, June 7

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Mark

Mark

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




From imcdonald at sharplabs.com  Mon Jun  9 18:53:52 2003
From: imcdonald at sharplabs.com (McDonald, Ira)
Date: Mon, 9 Jun 2003 18:53:52 -0700 
Subject: [printing-driver] Mapping FSG Driver job properties to IPP/PAPI
Message-ID: <116DB56CD7DED511BC7800508B2CA53735D038@mailsrvnt02.enet.sharplabs.com>

Hi Mark,                                            Monday (9 June 2003)

Below is an IPP mapping of all of the current FSG OP Driver API common
job properties, based on the IPP/JDF Mapping table for FSG Job Ticket:

    ftp://ftp.pwg.org/pub/pwg/fsg/jobticket/IPP_Mappings/
        ippjdf-mapping-06-Jun-2003.pdf

If we made the change proposed at today's FSG Open Printer Driver API
telecon to use an exact subset of PAPI/1.0 for the FSG OP Driver API and
the attribute/property names and value names from IPP/PAPI, then these
would be the common job property names.

I have shown the mapping to the IPP attribute(s) and the source IPP
standards-track documents.

Note:
- 2 attributes are only defined in an IPP working draft;
- 3 attributes are NOT defined in any current IPP standard or draft.

Cheers,
- Ira McDonald
  High North Inc


------------------------------------------------------------------------
From: Mark Hamzy [hamzy at us.ibm.com]
Sent: Monday, June 09, 2003 3:40 PM
To: imcdonald at sharplabs.com
Subject: common job properties


Copies                          - IPP/PAPI 'copies'
                                  [IETF RFC 2911 - IPP/1.1]
   integer
   NotSet
   None

Form                            - IPP/PAPI 'media' or 'media-key' member
                                  [IETF RFC 2911 - IPP/1.1]
                                  [IEEE PWG 5100.3 - IPP Prod Print]
                                  [IEEE PWG 5101.1 - Std Media Names]
   na_letter_8.5x11in
   iso_a4_210x297mm
   ...
   NotSet
   None

InputTray                       - IPP/PAPI 'media' or 'media-key' member
                                  [IETF RFC 2911 - IPP/1.1]
                                  [IEEE PWG 5100.3 - IPP Prod Print]
                                  [IEEE PWG 5101.1 - Std Media Names]
   AnySmallFormat
   AnyLargeFormat
   AutoSelect
   Bottom
   BypassTray
   BypassTray-n
   Continuous           Fanfold or perforated
   Disc                 Tray that contains media such as CD or DVD
   Disc-n
   Envelope
   Envelope-n
   Front
   InsertTray
   InsertTray-n
   LargeCapacity
   LargeCapacity-n
   Left
   Middle
   Rear
   Right
   Roll
   Roll-n
   Side
   Top
   Tray
   Tray-n
   NotSet
   None

   Input tray name aliases:
      Cassette               use Tray-n
      Center                 use Middle
      Lower                  use Bottom
      Main                   use LargeCapacity
      Upper                  use Top
      Removeable or Portable use one of the above that best describes
                             the tray
      SheetFeeder            use Tray-n
      AuxiliaryTray          use BypassTray, BypassTray-n or Tray-n


MediaColor                      - IPP/PAPI 'media-color' member
                                  [IEEE PWG 5100.3 - IPP Prod Print]
                                  [IEEE PWG 5101.1 - Std Media Names]
   self describing _RxGxB

MediaBackCoating                - IPP/PAPI 'media-back-coating' member
                                  [IEEE PWG 5100.3 - IPP Prod Print]

MediaFrontCoating               - IPP/PAPI 'media-front-coating' member
                                  [IEEE PWG 5100.3 - IPP Prod Print]
   + None
   + Glossy
   + HighGloss
   + SemiGloss
   + Satin
   + Matte
   inkjet

MediaGrain                      - IPP/PAPI 'media-grain' member
                                  [working draft - IPP Prod Print Set2]

MediaTooth                      - IPP/PAPI 'media-tooth' member
                                  [working draft - IPP Prod Print Set2]
   + Fine
   + Medium
   + Coarse

MediaType                       - IPP/PAPI 'media-type' member
                                  [IEEE PWG 5100.3 - IPP Prod Print]
                                  [IEEE PWG 5101.1 - Std Media Names]
   + stationery
   + transparency envelope
   + envelope-plain
   + envelope-window
   + continuous
   + continuous-long
   + continuous-short
   + tab-stock
   + pre-cut-tabs
   + full-cut-tabs
   + multi-part-forms
   + labels
   + multi-layer
   + screen
   + screen-paged
   + photographic
   + cardstock
   + other
   plain?

NumberUp                        - IPP/PAPI 'number-up'
                                  [IETF RFC 2911 - IPP/1.1]
   integerXinteger
   NotSet
   None

NumberUpPresentationDirection   - IPP/PAPI
                                  'presentation-direction-number-up'
                                  [IEEE PWG 5100.3 - IPP Prod Print]
   TorightTobottom
   TobottomToright
   ToleftTobottom
   TobottomToleft
   TorightTotop
   TotopToright
   ToleftTotop
   TotopToleft
   NotSet
   None

OutputBin                       - IPP/PAPI 'output-bin'
                                  [IEEE PWG 5100.2 - IPP Output Bin]
   Booklet
   Bottom               same as Lower
   Center
   FaceDown
   FaceUp
   FitMedia
   LargeCapacity        same as Main
   Left
   MailBox-n            where n is an integer
   Middle
   MyMailbox
   Rear
   Right
   Side
   Stacker-n            where n is an integer
   Top                  same as Upper
   Tray-n               where n is an integer
   NotSet
   None

PrintQuality                    - IPP/PAPI 'print-quality'
                                  [IETF RFC 2911 - IPP/1.1]
   Economy
   Draft
   Normal
   High
   Fine
   Photo
   NotSet
   None

Resolution                      - IPP/PAPI 'printer-resolution'
                                  [IETF RFC 2911 - IPP/1.1]
   integerXinteger
   NotSet
   None

Rotation                        - IPP/PAPI 'orientation-requested'
                                  [IETF RFC 2911 - IPP/1.1]
   Portrait
   Landscape
   ReversePortrait
   ReverseLandscape
   NotSet
   None

ScalingType                     - no IPP/PAPI attribute defined
                                  [ISSUE]
   FitToPage
   RotateAndOrFit
   Clip
   None
   NotSet

ScalingPercentage               - no IPP/PAPI attribute defined
                                  [ISSUE]
   double
   None
   NotSet

SheetCollate                    - IPP/PAPI 'multiple-document-handling'
                                  or 'sheet-collate'
                                  [IETF RFC 2911 - IPP/1.1]
                                  [IETF RFC 3381 - Job Progress]
   SheetCollated
   SheetAndJobCollated
   SheetUncollated
   NotSet
   None

Sides                           - IPP/PAPI 'sides'
                                  [IETF RFC 2911 - IPP/1.1]
   OneSidedBackflipX
   OneSidedBackflipY
   OneSidedFront
   TwoSidedFlipX
   TwoSidedFlipY
   NotSet
   None

StitchingPosition               - IPP/PAPI 'stitching-locations' member
                                  and 'stitching-offset' member
                                  [IEEE PWG 5100.3 - IPP Prod Print]
   integer
   NotSet
   None

StitchingReferenceEdge          - IPP/PAPI 'stitching-reference-edge'
                                  member
                                  [IEEE PWG 5100.3 - IPP Prod Print]
   Bottom
   Top
   Left
   Right
   NotSet
   None

StitchingType                   - IPP/PAPI 'finishings'
                                  [IETF RFC 2911 - IPP/1.1]
   Corner
   Saddle
   Side
   NotSet
   None

StitchingCount                  - IPP/PAPI 'stitching-locations' member
                                  [IEEE PWG 5100.3 - IPP Prod Print]
   integer
   NotSet
   None

StitchingAngle                  - no IPP/PAPI attribute defined
                                  [ISSUE]
   integer
   NotSet
   None

Trimming                        - IPP/PAPI 'finishings'
                                  [IEEE PWG 5100.1 - IPP Finishings]
   None
   Trim
   Face
   Gutter
   Tab
   NotSet
   None



From hamzy at us.ibm.com  Tue Jun 10 11:45:22 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Tue, 10 Jun 2003 13:45:22 -0500
Subject: [printing-driver] Mapping FSG Driver job properties to IPP/PAPI
Message-ID: <OF88F6BDBF.B4CAA190-ON86256D41.0065A902-86256D41.006707C7@us.ibm.com>




Hi Ira,

I was hoping for a complete mapping.  For the two keys that I checked, it
seems that not every value is defined in IPP.  For example,

"4.2.13 print-quality (type2 enum)

   This attribute specifies the print quality that the Printer uses for
   the Job.

   The standard enum values are:

   Value  Symbolic Name and Description

   '3'    'draft': lowest quality available on the printer
   '4'    'normal': normal or intermediate quality on the printer
   '5'    'high': highest quality available on the printer"

It is not clear which one is sent to the printer.  So, we could not handle
print-quality=3.  Also, Economy, Fine, Photo, NotSet, and None are not
defined.

"4.2.9 number-up (integer(1:MAX))

   This attribute specifies the number of print-stream pages to impose
   upon a single side of an instance of a selected medium.  For example,
   if the value is:

   Value  Description

   '1'    the Printer MUST place one print-stream page on a single side
             of an instance of the selected medium (MAY add some sort
             of translation, scaling, or rotation).
   '2'    the Printer MUST place two print-stream pages on a single side
             of an instance of the selected medium (MAY add some sort
             of translation, scaling, or rotation).
   '4'    the Printer MUST place four print-stream pages on a single
             side of an instance of the selected medium (MAY add some
             sort of translation, scaling, or rotation)."

This is different than the format that we choose which is an x 'x' y value
and not a single value.


Mark

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




From imcdonald at sharplabs.com  Tue Jun 10 14:47:10 2003
From: imcdonald at sharplabs.com (McDonald, Ira)
Date: Tue, 10 Jun 2003 14:47:10 -0700
Subject: [printing-jobticket] Re: [printing-driver] Mapping FSG Driver
	 job properties to IPP/PAPI
Message-ID: <116DB56CD7DED511BC7800508B2CA53735D03E@mailsrvnt02.enet.sharplabs.com>

Hi Mark,

Right - we discussed 'print-quality' today at FSG Job Ticket telecon
(Tom H, Claudia A, and me).  We want to throw out 'photo' entirely
and say "use the media-type of 'photo', not the print-quality".

We rewrote definitions for 'fine' (higher than 'high') and
'economy' (lower than 'draft') for JDF.  They will later also be
submitted as new IPP 'print-quality' enum values to the IANA
IPP Registry.  For now, IPP can only represent 'draft', 'normal',
and 'high'.

Right again - 'number-up' in IPP does NOT specify 'x by y'.  A
future extension to IPP (again IANA registered) could add new
'number-up-x' and 'number-up-y' attributes.  It won't happen
very rapidly (because new attributes, not just values of existing
ones).  Is this real important?

Tom informs me that there _are_ IPP scaling attributes (in some
extension document), so we'll have to research this.

The value-to-value mapping is (planned to be) fully specified
in Tom and Claudia's big PDF document, the IPP/JDF Mapping table.  
I don't really have the time to do the mapping right now.

I also plan to shortly send out a list of PAPI v0.9 operations
that must be supported for a mapping of our existing proposed
FSG Driver API in your header file.  PAPI v0.9 is entirely
clear about physical representation of all data types (in
native C types) and also has AttributesList[From/To]String
that allows an application (or a driver) to access any attributes
list as a simple set of key=value members, e.g.,

"copies=1 finishings=staple-dual-top-left media=iso_a4_210x297mm"

Cheers,
- Ira



-----Original Message-----
From: Mark Hamzy [mailto:hamzy at us.ibm.com]
Sent: Tuesday, June 10, 2003 2:45 PM
To: printing-driver at freestandards.org
Cc: printing-driver at freestandards.org;
printing-driver-admin at freestandards.org;
printing-jobticket at freestandards.org
Subject: [printing-jobticket] Re: [printing-driver] Mapping FSG Driver
job properties to IPP/PAPI






Hi Ira,

I was hoping for a complete mapping.  For the two keys that I checked, it
seems that not every value is defined in IPP.  For example,

"4.2.13 print-quality (type2 enum)

   This attribute specifies the print quality that the Printer uses for
   the Job.

   The standard enum values are:

   Value  Symbolic Name and Description

   '3'    'draft': lowest quality available on the printer
   '4'    'normal': normal or intermediate quality on the printer
   '5'    'high': highest quality available on the printer"

It is not clear which one is sent to the printer.  So, we could not handle
print-quality=3.  Also, Economy, Fine, Photo, NotSet, and None are not
defined.

"4.2.9 number-up (integer(1:MAX))

   This attribute specifies the number of print-stream pages to impose
   upon a single side of an instance of a selected medium.  For example,
   if the value is:

   Value  Description

   '1'    the Printer MUST place one print-stream page on a single side
             of an instance of the selected medium (MAY add some sort
             of translation, scaling, or rotation).
   '2'    the Printer MUST place two print-stream pages on a single side
             of an instance of the selected medium (MAY add some sort
             of translation, scaling, or rotation).
   '4'    the Printer MUST place four print-stream pages on a single
             side of an instance of the selected medium (MAY add some
             sort of translation, scaling, or rotation)."

This is different than the format that we choose which is an x 'x' y value
and not a single value.


Mark

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


_______________________________________________
printing-jobticket mailing list
printing-jobticket at freestandards.org
http://freestandards.org/mailman/listinfo/printing-jobticket



From imcdonald at sharplabs.com  Mon Jun 23 09:41:43 2003
From: imcdonald at sharplabs.com (McDonald, Ira)
Date: Mon, 23 Jun 2003 09:41:43 -0700
Subject: [printing-driver] FSG Print Driver telecon this today (11 PDT / 2 EDT)??
Message-ID: <116DB56CD7DED511BC7800508B2CA53735D06B@mailsrvnt02.enet.sharplabs.com>

Hi,

Are we having a meeting today?

Are there any minutes from the Driver discussions in Portland?

Cheers,
- Ira McDonald
  High North Inc



From alimpich at us.ibm.com  Tue Jun 24 17:26:54 2003
From: alimpich at us.ibm.com (Claudia Alimpich)
Date: Tue, 24 Jun 2003 18:26:54 -0600
Subject: [printing-driver] Proposal to add new IPP print-optimize attribute
Message-ID: <OF2A2CB110.F0D8B9C3-ON87256D4F.008238EF@us.ibm.com>




Last Tuesday during the PWG/FSG meeting in Portland we had a discussion
about the IPP print-quality attribute and FSG's desire to add two new
values, "economy" and "fine", where "economy" is lower than "draft" and
"fine" is higher than "high". After some discussion we all pretty much
decided that it is not possible to add these new values to the already
existing "draft", "normal", and "high" values because of the current
definitions of the existing values (high is defined as the highest quality
and draft is defined as the lowest quality). It also seemed like what FSG
wanted was a way to specify print optimization and not additional levels of
print quality.

The FSG working group met today, and based on the input from last Tuesday's
meeting, we would like to propose the addition of a new attribute, called
print-optimize, that is defined as follows:

   print-optimize (type2 keyword)

      This attribute refines the value specified by the print-quality
      attribute.

      The standard keyword values are:

         'image': optimize for image clarity
         'photo': optimize for photo clarity
         'text': optimize for text clarity
         'text-and-image': optimize for both text and image clarity
         'save-toner': optimize for minimal toner usage
         'speed': optimize for printing speed

We would appreciate your feedback on this proposal including suggestions
for additional values.

If this proposal looks good, we would like to propose that it be included
in the JobX Spec. If the print-optimize attribute is approved by PWG by the
end of August, then we can propose that it be added to the JDF 1.2 Spec
that is being finalized in early September.

Thank you for your time and feedback.
Claudia Alimpich
IBM Printing Systems Division
Boulder CO
303-924-4418
alimpich at us.ibm.com




From bobt at hp.com  Tue Jun 24 17:38:33 2003
From: bobt at hp.com (TAYLOR,BOB (HP-Vancouver,ex1))
Date: Tue, 24 Jun 2003 20:38:33 -0400
Subject: [printing-driver] RE: [printing-jobticket] Proposal to add new IPP print-optimize a
 ttribute
Message-ID: <A134E2426B46D711BB4B000347AE6E7CAA592B@xvan02.vcd.hp.com>

I understand the desire to avoid violating the semantics of the IPP
attribute - but
adding these enumerations to print-quality does not feel as objectionable to
me
as splitting a single semantic concept into two different attributes.  If
this is
the precedent we take for extending the semantic model, I'm worried that
we'll end
up with an increasingly confusing and complex.  I would rather we take the
minor hit
and fix the high & draft definitions in the semantic model than create
another
~equivalent attribute with a whole bunch of special semantic rules (e.g. -
what should the
service do if print-quality=high and print-optimize=save-toner?).

bt

---------------------------------------------------
Bob Taylor                                        
Senior Architect                            
IPG Strategic Technology Development  
Hewlett-Packard Co.       
mailto:bobt at hp.com                        
phone: 360.212.2625/T212.2625                    
fax: 208.730-5111                 
---------------------------------------------------   

> -----Original Message-----
> From: Claudia Alimpich [mailto:alimpich at us.ibm.com] 
> Sent: Tuesday, June 24, 2003 5:27 PM
> To: ipp at pwg.org; printing-jobticket at freestandards.org; 
> printing-driver at freestandards.org
> Subject: [printing-jobticket] Proposal to add new IPP 
> print-optimize attribute
> 
> 
> 
> 
> 
> 
> Last Tuesday during the PWG/FSG meeting in Portland we had a 
> discussion about the IPP print-quality attribute and FSG's 
> desire to add two new values, "economy" and "fine", where 
> "economy" is lower than "draft" and "fine" is higher than 
> "high". After some discussion we all pretty much decided that 
> it is not possible to add these new values to the already 
> existing "draft", "normal", and "high" values because of the 
> current definitions of the existing values (high is defined 
> as the highest quality and draft is defined as the lowest 
> quality). It also seemed like what FSG wanted was a way to 
> specify print optimization and not additional levels of print quality.
> 
> The FSG working group met today, and based on the input from 
> last Tuesday's meeting, we would like to propose the addition 
> of a new attribute, called print-optimize, that is defined as follows:
> 
>    print-optimize (type2 keyword)
> 
>       This attribute refines the value specified by the print-quality
>       attribute.
> 
>       The standard keyword values are:
> 
>          'image': optimize for image clarity
>          'photo': optimize for photo clarity
>          'text': optimize for text clarity
>          'text-and-image': optimize for both text and image clarity
>          'save-toner': optimize for minimal toner usage
>          'speed': optimize for printing speed
> 
> We would appreciate your feedback on this proposal including 
> suggestions for additional values.
> 
> If this proposal looks good, we would like to propose that it 
> be included in the JobX Spec. If the print-optimize attribute 
> is approved by PWG by the end of August, then we can propose 
> that it be added to the JDF 1.2 Spec that is being finalized 
> in early September.
> 
> Thank you for your time and feedback.
> Claudia Alimpich
> IBM Printing Systems Division
> Boulder CO
> 303-924-4418
> alimpich at us.ibm.com
> 
> 
> _______________________________________________
> printing-jobticket mailing list printing-jobticket at freestandards.org
> http://freestandards.org/mailman/listinfo/printing-jobticket
> 



From hastings at cp10.es.xerox.com  Wed Jun 25 13:07:42 2003
From: hastings at cp10.es.xerox.com (Hastings, Tom N)
Date: Wed, 25 Jun 2003 13:07:42 -0700
Subject: [printing-driver] RE: [printing-jobticket] Proposal to add ne
	w IPP print-optimize attribute
Message-ID: <E0BE13326C4EBC45BBC635197DEB7E3FB54E27@x-crt-es-ms1.cp10.es.xerox.com>

Bob,

I think that the proposal to add "print-optimize" solves two separate
problems, not just a single problem of adding some values:

1. Doesn't invalidate the semantics of "print-quality" (which we are
treating in the same way as an enumeration in JDF, i.e., a closed end list,
in which these are the only values that can be supported: 'draft', 'normal',
and 'high').

2. The Optimize mechanism isn't really just additional print quality values,
but is more specific as to what to optimize.  Therefore, it would be wrong
just to add the proposed new values to "print-quality" as you suggest.
Semantics meaning would be lost or mixed.  (Also the "print-optimize"
attribute is like the JDF XxxDetails which is an extensible NMTOKEN value,
not an enumeration.)

Also note that "print-quality" may be used in combination with
"print-optimize".  So you can have 'draft', 'normal' or 'high' optimization
of, say, 'photo'.

ISSUE:  We didn't say that a Printer that supports "print-optimize" MUST
support "print-quality" as well.  Should we, since the definition of
"print-optimize" is that it "refines the value supplied (or defaulted) in
"print-quality")?

Also this isn't a precedent that we can't add values to an existing
attribute in IPP or the Semantic Model.  It just seems that for this one
"print-quality" attribute both reasons support not adding new values to the
existing attribute.

Tom

-----Original Message-----
From: TAYLOR,BOB (HP-Vancouver,ex1) [mailto:bobt at hp.com]
Sent: Tuesday, June 24, 2003 17:39
To: Claudia Alimpich; ipp at pwg.org; printing-jobticket at freestandards.org;
printing-driver at freestandards.org
Subject: [printing-driver] RE: [printing-jobticket] Proposal to add new
IPP print-optimize a ttribute


I understand the desire to avoid violating the semantics of the IPP
attribute - but
adding these enumerations to print-quality does not feel as objectionable to
me
as splitting a single semantic concept into two different attributes.  If
this is
the precedent we take for extending the semantic model, I'm worried that
we'll end
up with an increasingly confusing and complex.  I would rather we take the
minor hit
and fix the high & draft definitions in the semantic model than create
another
~equivalent attribute with a whole bunch of special semantic rules (e.g. -
what should the
service do if print-quality=high and print-optimize=save-toner?).

bt

---------------------------------------------------
Bob Taylor                                        
Senior Architect                            
IPG Strategic Technology Development  
Hewlett-Packard Co.       
mailto:bobt at hp.com                        
phone: 360.212.2625/T212.2625                    
fax: 208.730-5111                 
---------------------------------------------------   

> -----Original Message-----
> From: Claudia Alimpich [mailto:alimpich at us.ibm.com] 
> Sent: Tuesday, June 24, 2003 5:27 PM
> To: ipp at pwg.org; printing-jobticket at freestandards.org; 
> printing-driver at freestandards.org
> Subject: [printing-jobticket] Proposal to add new IPP 
> print-optimize attribute
> 
> 
> 
> 
> 
> 
> Last Tuesday during the PWG/FSG meeting in Portland we had a 
> discussion about the IPP print-quality attribute and FSG's 
> desire to add two new values, "economy" and "fine", where 
> "economy" is lower than "draft" and "fine" is higher than 
> "high". After some discussion we all pretty much decided that 
> it is not possible to add these new values to the already 
> existing "draft", "normal", and "high" values because of the 
> current definitions of the existing values (high is defined 
> as the highest quality and draft is defined as the lowest 
> quality). It also seemed like what FSG wanted was a way to 
> specify print optimization and not additional levels of print quality.
> 
> The FSG working group met today, and based on the input from 
> last Tuesday's meeting, we would like to propose the addition 
> of a new attribute, called print-optimize, that is defined as follows:
> 
>    print-optimize (type2 keyword)
> 
>       This attribute refines the value specified by the print-quality
>       attribute.
> 
>       The standard keyword values are:
> 
>          'image': optimize for image clarity
>          'photo': optimize for photo clarity
>          'text': optimize for text clarity
>          'text-and-image': optimize for both text and image clarity
>          'save-toner': optimize for minimal toner usage
>          'speed': optimize for printing speed
> 
> We would appreciate your feedback on this proposal including 
> suggestions for additional values.
> 
> If this proposal looks good, we would like to propose that it 
> be included in the JobX Spec. If the print-optimize attribute 
> is approved by PWG by the end of August, then we can propose 
> that it be added to the JDF 1.2 Spec that is being finalized 
> in early September.
> 
> Thank you for your time and feedback.
> Claudia Alimpich
> IBM Printing Systems Division
> Boulder CO
> 303-924-4418
> alimpich at us.ibm.com
> 
> 
> _______________________________________________
> printing-jobticket mailing list printing-jobticket at freestandards.org
> http://freestandards.org/mailman/listinfo/printing-jobticket
> 

_______________________________________________
printing-driver mailing list
printing-driver at freestandards.org
http://freestandards.org/mailman/listinfo/printing-driver



From bobt at hp.com  Thu Jun 26 16:22:50 2003
From: bobt at hp.com (TAYLOR,BOB (HP-Vancouver,ex1))
Date: Thu, 26 Jun 2003 19:22:50 -0400
Subject: [printing-driver] RE: [printing-jobticket] Proposal to add ne
	 w IPP print-optimize attribute
Message-ID: <A134E2426B46D711BB4B000347AE6E7CAA5965@xvan02.vcd.hp.com>

Hi Tom,

To me, #2 is the issue to really focus on: is this really two semantic
concepts,
or one?  If any of these values are semantically really just additional
enumerations for
print-quality, I'd much rather we fix this than do the split it.

As for #2, what "semantic meaning would be lost or mixed" if we just
extended 
the enumeration for print-quality?  Although you can, by having these as
two attributes, specify "draft" and "photo" - in practice, this is 
virtually never done: "photo" is usually specified in one of a couple ways:
- my media type (i.e., photo-glossy paper model #C239847A)
- PrintQuality (quality = Photo4800DPI) - i.e., another print-quality
enumeration
If it's something other than one of these, it's usually what we call in PSI
capabilities a "macro feature" - i.e., it's not a real attribute sent to the
device, but a feature defined as a macro combination of other features -
which
I don't think is a concept currently supported by IPP.

Fundamentally, "refines the value specified by the print-quality" seems like
a
weak semantic differentiation, and I believe it is inconsistent with how
extensions
to the print-quality concept have been applied in at least the inkjet
segment of
the market.

thanks,

bt

> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com] 
> Sent: Wednesday, June 25, 2003 1:08 PM
> To: printing-driver at freestandards.org; Claudia Alimpich; ipp at pwg.org
> Cc: printing-jobticket at freestandards.org
> Subject: RE: [printing-driver] RE: [printing-jobticket] 
> Proposal to add ne w IPP print-optimize attribute
> 
> 
> Bob,
> 
> I think that the proposal to add "print-optimize" solves two 
> separate problems, not just a single problem of adding some values:
> 
> 1. Doesn't invalidate the semantics of "print-quality" (which 
> we are treating in the same way as an enumeration in JDF, 
> i.e., a closed end list, in which these are the only values 
> that can be supported: 'draft', 'normal', and 'high').
> 
> 2. The Optimize mechanism isn't really just additional print 
> quality values, but is more specific as to what to optimize.  
> Therefore, it would be wrong just to add the proposed new 
> values to "print-quality" as you suggest. Semantics meaning 
> would be lost or mixed.  (Also the "print-optimize" attribute 
> is like the JDF XxxDetails which is an extensible NMTOKEN 
> value, not an enumeration.)
> 
> Also note that "print-quality" may be used in combination 
> with "print-optimize".  So you can have 'draft', 'normal' or 
> 'high' optimization of, say, 'photo'.
> 
> ISSUE:  We didn't say that a Printer that supports 
> "print-optimize" MUST support "print-quality" as well.  
> Should we, since the definition of "print-optimize" is that 
> it "refines the value supplied (or defaulted) in "print-quality")?
> 
> Also this isn't a precedent that we can't add values to an 
> existing attribute in IPP or the Semantic Model.  It just 
> seems that for this one "print-quality" attribute both 
> reasons support not adding new values to the existing attribute.
> 
> Tom
> 
> -----Original Message-----
> From: TAYLOR,BOB (HP-Vancouver,ex1) [mailto:bobt at hp.com]
> Sent: Tuesday, June 24, 2003 17:39
> To: Claudia Alimpich; ipp at pwg.org; 
> printing-jobticket at freestandards.org;
> printing-driver at freestandards.org
> Subject: [printing-driver] RE: [printing-jobticket] Proposal 
> to add new IPP print-optimize a ttribute
> 
> 
> I understand the desire to avoid violating the semantics of 
> the IPP attribute - but adding these enumerations to 
> print-quality does not feel as objectionable to me as 
> splitting a single semantic concept into two different 
> attributes.  If this is the precedent we take for extending 
> the semantic model, I'm worried that we'll end up with an 
> increasingly confusing and complex.  I would rather we take 
> the minor hit and fix the high & draft definitions in the 
> semantic model than create another ~equivalent attribute with 
> a whole bunch of special semantic rules (e.g. - what should 
> the service do if print-quality=high and print-optimize=save-toner?).
> 
> bt
> 
> ---------------------------------------------------
> Bob Taylor                                        
> Senior Architect                            
> IPG Strategic Technology Development  
> Hewlett-Packard Co.       
> mailto:bobt at hp.com                        
> phone: 360.212.2625/T212.2625                    
> fax: 208.730-5111                 
> ---------------------------------------------------   
> 
> > -----Original Message-----
> > From: Claudia Alimpich [mailto:alimpich at us.ibm.com]
> > Sent: Tuesday, June 24, 2003 5:27 PM
> > To: ipp at pwg.org; printing-jobticket at freestandards.org; 
> > printing-driver at freestandards.org
> > Subject: [printing-jobticket] Proposal to add new IPP 
> > print-optimize attribute
> > 
> > 
> > 
> > 
> > 
> > 
> > Last Tuesday during the PWG/FSG meeting in Portland we had a
> > discussion about the IPP print-quality attribute and FSG's 
> > desire to add two new values, "economy" and "fine", where 
> > "economy" is lower than "draft" and "fine" is higher than 
> > "high". After some discussion we all pretty much decided that 
> > it is not possible to add these new values to the already 
> > existing "draft", "normal", and "high" values because of the 
> > current definitions of the existing values (high is defined 
> > as the highest quality and draft is defined as the lowest 
> > quality). It also seemed like what FSG wanted was a way to 
> > specify print optimization and not additional levels of 
> print quality.
> > 
> > The FSG working group met today, and based on the input from
> > last Tuesday's meeting, we would like to propose the addition 
> > of a new attribute, called print-optimize, that is defined 
> as follows:
> > 
> >    print-optimize (type2 keyword)
> > 
> >       This attribute refines the value specified by the 
> print-quality
> >       attribute.
> > 
> >       The standard keyword values are:
> > 
> >          'image': optimize for image clarity
> >          'photo': optimize for photo clarity
> >          'text': optimize for text clarity
> >          'text-and-image': optimize for both text and image clarity
> >          'save-toner': optimize for minimal toner usage
> >          'speed': optimize for printing speed
> > 
> > We would appreciate your feedback on this proposal including
> > suggestions for additional values.
> > 
> > If this proposal looks good, we would like to propose that it
> > be included in the JobX Spec. If the print-optimize attribute 
> > is approved by PWG by the end of August, then we can propose 
> > that it be added to the JDF 1.2 Spec that is being finalized 
> > in early September.
> > 
> > Thank you for your time and feedback.
> > Claudia Alimpich
> > IBM Printing Systems Division
> > Boulder CO
> > 303-924-4418
> > alimpich at us.ibm.com
> > 
> > 
> > _______________________________________________
> > printing-jobticket mailing list printing-jobticket at freestandards.org
> > http://freestandards.org/mailman/listinfo/printing-jobticket
> > 
> 
> _______________________________________________
> printing-driver mailing list
> printing-driver at freestandards.org 
> http://freestandards.org/mailman/listinfo/prin> ting-driver
> 
> 
> _______________________________________________
> 
> printing-driver mailing list
> printing-driver at freestandards.org 
> http://freestandards.org/mailman/listinfo/prin> ting-driver
> 



From till.kamppeter at gmx.net  Thu Jun 26 17:19:27 2003
From: till.kamppeter at gmx.net (Till Kamppeter)
Date: Fri, 27 Jun 2003 02:19:27 +0200
Subject: [printing-driver] RE: [printing-jobticket] Proposal to add ne
  w IPP print-optimize attribute
In-Reply-To: <A134E2426B46D711BB4B000347AE6E7CAA5965@xvan02.vcd.hp.com>
References: <A134E2426B46D711BB4B000347AE6E7CAA5965@xvan02.vcd.hp.com>
Message-ID: <3EFB8D8F.1060308@gmx.net>

TAYLOR,BOB (HP-Vancouver,ex1) wrote:
> Hi Tom,
> 
> To me, #2 is the issue to really focus on: is this really two semantic
> concepts,
> or one?  If any of these values are semantically really just additional
> enumerations for
> print-quality, I'd much rather we fix this than do the split it.
> 
> As for #2, what "semantic meaning would be lost or mixed" if we just
> extended 
> the enumeration for print-quality?  Although you can, by having these as
> two attributes, specify "draft" and "photo" - in practice, this is 
> virtually never done: "photo" is usually specified in one of a couple ways:
> - my media type (i.e., photo-glossy paper model #C239847A)
> - PrintQuality (quality = Photo4800DPI) - i.e., another print-quality
> enumeration
> If it's something other than one of these, it's usually what we call in PSI
> capabilities a "macro feature" - i.e., it's not a real attribute sent to the
> device, but a feature defined as a macro combination of other features -
> which
> I don't think is a concept currently supported by IPP.
>

These "macro feature"s I have already implemented in Foomatic as the 
so-called "composite options". The "PrintoutMode" option in GIMP-Print 
for example controls 5 options of GIMP-Print when the user chooses out 
of Draft, Fraft.Garyscale, Normal, Normal.Garyscale, High, 
High.Grayscale, VeryHigh, VeryHigh.Grayscale, Photo, Photo.Grayscale.

> Fundamentally, "refines the value specified by the print-quality" seems like
> a
> weak semantic differentiation, and I believe it is inconsistent with how
> extensions
> to the print-quality concept have been applied in at least the inkjet
> segment of
> the market.
>

The "PrintoutMode"option is both a quality and an intent option. What is 
tried here in this discussion is to have two options, once quality 
(draft, normal, high, ...) and intent (text, image, text-with-image, 
photo, toner-saving). Most drivers have too few adjustment possibilities 
to really fill the matrix of all intent/quality combinations, probably 
only GIMP-Print will hardly serve with enough settings. For most drivers 
the one-dimensional "PrintoutMode" (or however to call it) is enough to 
provide a newbie-friendly quick-setup option (which plays the same roll 
as the setting for Normal, Macro, Sports, Night shot ... on some digital 
cameras). It also must always be possible to set the individual options 
of the driver, so that advanced users can get all out of the driver (as 
implemented in Foomatic).

    Till




From hamzy at us.ibm.com  Mon Jun 30 08:04:03 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 30 Jun 2003 10:04:03 -0500
Subject: [printing-driver] Today's meeting is cancelled
Message-ID: <OFDF168C61.77FCB126-ON86256D55.0052A75A-86256D55.0052C4F3@us.ibm.com>




Due to the holiday week, today's meeting is cancelled.

Have fun...

Mark

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




From bobt at hp.com  Tue Jul  1 10:45:04 2003
From: bobt at hp.com (TAYLOR,BOB (HP-Vancouver,ex1))
Date: Tue, 1 Jul 2003 10:45:04 -0700 
Subject: [printing-driver] RE: [printing-jobticket] Proposal to add ne
	 w IPP print-optimize attribute
Message-ID: <A134E2426B46D711BB4B000347AE6E7CAA599E@xvan02.vcd.hp.com>

My concern is in creating an extra attribute for "other stuff" that is
poorly distinguished from PrintQuality.  Let's look at the suggested
enumerations:

         'image': optimize for image clarity
         'photo': optimize for photo clarity
         'text': optimize for text clarity
         'text-and-image': optimize for both text and image clarity
         'save-toner': optimize for minimal toner usage
         'speed': optimize for printing speed
and from PrintQuality:
         'draft': lowest quality available on the printer
         'normal': normal or intermediate quality on the printer
         'high': highest quality available on the printer

There really are a few of semantic concepts in here:

print quality: bad <-> good
performance: slow <-> fast
marker/toner/ink usage: cheap <-> expense 
content metadata hints: image, photo, text, text-and-image, etc. 

Realize though that the semantics of things like "print with bad quality",
"print with lousy performance", or "use lots of extra toner" don't make any
practical sense:  what you're really trying to do is give the service/device
feedback on the tradeoffs of PQ/performance/marker usage.  So, while the
PrintQuality definitions just officially talks about "quality", that's not
what they really are in practice.  What is more realistic is:

'draft': fast & cheap - sacrifice print quality for speed and low marker
usage
'normal': balance - decent print quality with good speed and moderate marker
usage
'high': look good - optimize print quality at the expense of speed and
marker usage

Many in the industry have extended this list (IPP extension rules
notwithstanding) for things like "econofast" and "bestphoto" - which are
merely additional tradeoff combinations.

So I'd argue that PrintQuality is already PrintOptimize - they are
effectively doing the same thing, just with different sets of enumerations.
I would much rather we extend the enumerations than create another attribute
to do what we've already done.

As for the "content metadata hints" - if the intent is a different
PW-performance-marker usage tradeoff, I'd add them to the PrintQuality
enumeration.  If we're really trying to provide hints about the coming
document content, then they should be an attribute of the document object,
since they are document metadata.  Realize also that this information is
often object specific - optimization is often done to different objects on
the same page of a document (e.g., different halftoning for an image on a
page vs. the bar chart on the same page).  I don't think we want to go very
far down the path of document content metadata here - this could get very
messy.

As a separate note, not all printers use "toner" - save-toner should
probably be something like "save-marker"

thanks,

bt

> -----Original Message-----
> From: Till Kamppeter [mailto:till.kamppeter at gmx.net]
> Sent: Thursday, June 26, 2003 5:19 PM
> To: TAYLOR,BOB (HP-Vancouver,ex1)
> Cc: printing-driver at freestandards.org; Claudia Alimpich;
> ipp at pwg.org; printing-jobticket at freestandards.org
> Subject: Re: [printing-driver] RE: [printing-jobticket] 
> Proposal to add ne w IPP print-optimize attribute
> 
> 
> TAYLOR,BOB (HP-Vancouver,ex1) wrote:
> > Hi Tom,
> > 
> > To me, #2 is the issue to really focus on: is this really
> two semantic
> > concepts, or one?  If any of these values are semantically
> really just
> > additional enumerations for
> > print-quality, I'd much rather we fix this than do the split it.
> > 
> > As for #2, what "semantic meaning would be lost or mixed"
> if we just
> > extended the enumeration for print-quality?  Although you can, by 
> > having these as two attributes, specify "draft" and "photo" - in 
> > practice, this is virtually never done: "photo" is usually
> specified
> > in one of a couple ways:
> > - my media type (i.e., photo-glossy paper model #C239847A)
> > - PrintQuality (quality = Photo4800DPI) - i.e., another
> print-quality
> > enumeration If it's something other than one of these, it's usually 
> > what we call in PSI capabilities a "macro feature" - i.e.,
> it's not a
> > real attribute sent to the device, but a feature defined as a macro 
> > combination of other features - which I don't think is a concept 
> > currently supported by IPP.
> >
> 
> These "macro feature"s I have already implemented in Foomatic as the 
> so-called "composite options". The "PrintoutMode" option in GIMP-Print
> for example controls 5 options of GIMP-Print when the user 
> chooses out 
> of Draft, Fraft.Garyscale, Normal, Normal.Garyscale, High, 
> High.Grayscale, VeryHigh, VeryHigh.Grayscale, Photo, Photo.Grayscale.
> 
> > Fundamentally, "refines the value specified by the print-quality" 
> > seems like a weak semantic differentiation, and I believe it is 
> > inconsistent with how extensions to the print-quality concept have 
> > been applied in at least
> the inkjet
> > segment of
> > the market.
> >
> 
> The "PrintoutMode"option is both a quality and an intent option. What 
> is tried here in this discussion is to have two options, once quality
> (draft, normal, high, ...) and intent (text, image, text-with-image, 
> photo, toner-saving). Most drivers have too few adjustment 
> possibilities 
> to really fill the matrix of all intent/quality combinations, 
> probably 
> only GIMP-Print will hardly serve with enough settings. For 
> most drivers 
> the one-dimensional "PrintoutMode" (or however to call it) is 
> enough to 
> provide a newbie-friendly quick-setup option (which plays the 
> same roll 
> as the setting for Normal, Macro, Sports, Night shot ... on 
> some digital 
> cameras). It also must always be possible to set the 
> individual options 
> of the driver, so that advanced users can get all out of the 
> driver (as 
> implemented in Foomatic).
> 
>     Till
> 



From PZehler at crt.xerox.com  Wed Jul  2 08:15:38 2003
From: PZehler at crt.xerox.com (Zehler, Peter)
Date: Wed, 2 Jul 2003 11:15:38 -0400 
Subject: [printing-driver] Semantic Model (JobX) teleconference
Message-ID: <CA9D3573509ECA46A712181F58C0A64D1472F2@x-wb-0128-nt8.wrc.xerox.com>

All,

Thursday July 10th at 1pm EDT is the Semantic Model teleconference. This 
week's Teleconference will be dedicated to IPP JobX.  The document is 
available on the PWG server at 
ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-ippjobx10-20030702.doc
<ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-ippjobx10-20030702.doc>  
(If someone could convert this to PDF I would appreciate it.  I haven't
found my copy of distiller to put on my new system yet.)

The teleconference is 2 hours long.  It will be run using phone and Webex.
Anyone that does not yet have Webex installed should do that before
Thursday.  Information for the phone and Webex are included below.  NOTE:
New Dial in number and passcode

The agenda for the Semantic Model teleconference is:
1) Discuss the print-quality issue (see included notes below)
2) Discuss the document-xxx-supplied changes in JobX
3) Discuss the output-device resolution

Pete

PS: Bob let me know if there is a problem hosting Webex.

________________________________________________

Dial in Info:
Phone Number:(877) 707-6056
(Phone Number for Xerox Employees: 8*594-0077)
 PARTICIPANT PASSCODE: 437874#
________________________________________________
webex info:
We will also use an on line tool called webex,
if you have not used this before, setup up by
following the First Time Users instructions.
Do this in advance of the meeting.

-------------------------
FIRST TIME USERS
-------------------------
For fully interactive meetings, including the ability
to present your documents and applications, a one-time
setup takes less than 10 minutes. Click this URL to set up now:

http://hp.webex.com <http://hp.webex.com> 

Then click New User.
-------------------------

On Thursday use:
https://hp.webex.com/join/ <https://hp.webex.com/join/> 

Then click join unlisted meeting.
Use the info below:
-------------------------

Webex MEETING SUMMARY
-------------------------
Topic: PWG Semantic Model 
Date: Thursday, July 10, 2003 
Time: 10:00 am, Pacific Daylight Time (GMT -07:00, San Jose) 
Meeting number: 21366675 
Meeting password: pwg_sm1! 
Host: 
Bob Taylor (HP)

___________________________________________________


				Peter Zehler
				XEROX
				Xerox Innovation Group
				Email: PZehler at crt.xerox.com
				Voice:    (585) 265-8755
				FAX:      (585) 422-7961
				US Mail: Peter Zehler
				        Xerox Corp.
				        800 Phillips Rd.
				        M/S 128-25E
				        Webster NY, 14580-9701

Print Quality Issue:

Last Tuesday during the PWG/FSG meeting in Portland we had a discussion
about the IPP print-quality attribute and FSG's desire to add two new
values, "economy" and "fine", where "economy" is lower than "draft" and
"fine" is higher than "high". After some discussion we all pretty much
decided that it is not possible to add these new values to the already
existing "draft", "normal", and "high" values because of the current
definitions of the existing values (high is defined as the highest quality
and draft is defined as the lowest quality). It also seemed like what FSG
wanted was a way to specify print optimization and not additional levels of
print quality.

The FSG working group met today, and based on the input from last Tuesday's
meeting, we would like to propose the addition of a new attribute, called
print-optimize, that is defined as follows:

   print-optimize (type2 keyword)

      This attribute refines the value specified by the print-quality
      attribute.

      The standard keyword values are:

         'image': optimize for image clarity
         'photo': optimize for photo clarity
         'text': optimize for text clarity
         'text-and-image': optimize for both text and image clarity
         'save-toner': optimize for minimal toner usage
         'speed': optimize for printing speed

We would appreciate your feedback on this proposal including suggestions for
additional values.

If this proposal looks good, we would like to propose that it be included in
the JobX Spec. If the print-optimize attribute is approved by PWG by the end
of August, then we can propose that it be added to the JDF 1.2 Spec that is
being finalized in early September.

Thank you for your time and feedback.
Claudia Alimpich
IBM Printing Systems Division
Boulder CO
303-924-4418
alimpich at us.ibm.com

Response to Print Quality Issue:

I understand the desire to avoid violating the semantics of the IPP
attribute - but adding these enumerations to print-quality does not feel as
objectionable to me as splitting a single semantic concept into two
different attributes.  If this is the precedent we take for extending the
semantic model, I'm worried that we'll end up with an increasingly confusing
and complex.  I would rather we take the minor hit and fix the high & draft
definitions in the semantic model than create another ~equivalent attribute
with a whole bunch of special semantic rules (e.g. - what should the service
do if print-quality=high and print-optimize=save-toner?).

bt

---------------------------------------------------
Bob Taylor                                        
Senior Architect                            
IPG Strategic Technology Development  
Hewlett-Packard Co.       
mailto:bobt at hp.com <mailto:bobt at hp.com>                         
phone: 360.212.2625/T212.2625                    
fax: 208.730-5111                 
---------------------------------------------------   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030702/98d0b0ff/attachment.htm 

From imcdonald at sharplabs.com  Mon Jul  7 09:37:38 2003
From: imcdonald at sharplabs.com (McDonald, Ira)
Date: Mon, 7 Jul 2003 09:37:38 -0700 
Subject: [printing-driver] Meeting today??
Message-ID: <116DB56CD7DED511BC7800508B2CA53735D08B@mailsrvnt02.enet.sharplabs.com>

Hi,

Is there an FSG OP Driver meeting in 90 minutes?

Cheers,
- Ira McDonald
  High North Inc



From hastings at cp10.es.xerox.com  Wed Jul  9 16:08:45 2003
From: hastings at cp10.es.xerox.com (Hastings, Tom N)
Date: Wed, 9 Jul 2003 16:08:45 -0700 
Subject: [printing-driver] RE: SM> Semantic Model (JobX) teleconference
Message-ID: <E0BE13326C4EBC45BBC635197DEB7E3FB55100@x-crt-es-ms1.cp10.es.xerox.com>

I've down loaded the .pdf for the .doc files as Peter requested for
tomorrow's telecon.  I've also put all four in the proper place in the IPP
spec hierarchy as well under the new_JOBX arc (but I did not delete them
from the Semantic_Model sub-tree):
 
ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702.pdf
<ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702.pdf> 
ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702.doc
<ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702.doc> 
ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702-rev.pdf
<ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702-rev.pdf> 
ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702-rev.doc
<ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702-rev.doc> 
 <ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702.doc>  
 
 
Tom

-----Original Message-----
From: Zehler, Peter [mailto:PZehler at crt.xerox.com]
Sent: Wednesday, July 02, 2003 08:16
To: PWG Semantic Model WG (sm at pwg.org)
Cc: 'Claudia Alimpich'; IPP Discussion List (IPP at pwg.org);
printing-jobticket at freestandards.org; printing-driver at freestandards.org
Subject: SM> Semantic Model (JobX) teleconference



All,

Thursday July 10th at 1pm EDT is the Semantic Model teleconference. This 

week's Teleconference will be dedicated to IPP JobX.  The document is 

available on the PWG server at 

 <ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-ippjobx10-20030702.doc>
ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-ippjobx10-20030702.doc 

(If someone could convert this to PDF I would appreciate it.  I haven't

found my copy of distiller to put on my new system yet.)

The teleconference is 2 hours long.  It will be run using phone and Webex.

Anyone that does not yet have Webex installed should do that before

Thursday.  Information for the phone and Webex are included below.  NOTE:

New Dial in number and passcode

The agenda for the Semantic Model teleconference is:

1) Discuss the print-quality issue (see included notes below)

2) Discuss the document-xxx-supplied changes in JobX

3) Discuss the output-device resolution

Pete

PS: Bob let me know if there is a problem hosting Webex.

________________________________________________

Dial in Info:

Phone Number:(877) 707-6056

(Phone Number for Xerox Employees: 8*594-0077)

 PARTICIPANT PASSCODE: 437874#

________________________________________________

webex info:

We will also use an on line tool called webex,

if you have not used this before, setup up by

following the First Time Users instructions.

Do this in advance of the meeting.

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

FIRST TIME USERS

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

For fully interactive meetings, including the ability

to present your documents and applications, a one-time

setup takes less than 10 minutes. Click this URL to set up now:

 <http://hp.webex.com> http://hp.webex.com

Then click New User.

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

On Thursday use:

 <https://hp.webex.com/join/> https://hp.webex.com/join/

Then click join unlisted meeting.

Use the info below:

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

Webex MEETING SUMMARY

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

Topic: PWG Semantic Model 

Date: Thursday, July 10, 2003 

Time: 10:00 am, Pacific Daylight Time (GMT -07:00, San Jose) 

Meeting number: 21366675 

Meeting password: pwg_sm1! 

Host: 

Bob Taylor (HP)

___________________________________________________


	BM__MailAutoSigPeter Zehler

	XEROX

	Xerox Innovation Group

	Email: PZehler at crt.xerox.com

	Voice:    (585) 265-8755

	FAX:      (585) 422-7961

	US Mail: Peter Zehler

	        Xerox Corp.

	        800 Phillips Rd.

	        M/S 128-25E

	        Webster NY, 14580-9701

Print Quality Issue:

Last Tuesday during the PWG/FSG meeting in Portland we had a discussion
about the IPP print-quality attribute and FSG's desire to add two new
values, "economy" and "fine", where "economy" is lower than "draft" and
"fine" is higher than "high". After some discussion we all pretty much
decided that it is not possible to add these new values to the already
existing "draft", "normal", and "high" values because of the current
definitions of the existing values (high is defined as the highest quality
and draft is defined as the lowest quality). It also seemed like what FSG
wanted was a way to specify print optimization and not additional levels of
print quality.

The FSG working group met today, and based on the input from last Tuesday's
meeting, we would like to propose the addition of a new attribute, called
print-optimize, that is defined as follows:

   print-optimize (type2 keyword)

      This attribute refines the value specified by the print-quality

      attribute.

      The standard keyword values are:

         'image': optimize for image clarity

         'photo': optimize for photo clarity

         'text': optimize for text clarity

         'text-and-image': optimize for both text and image clarity

         'save-toner': optimize for minimal toner usage

         'speed': optimize for printing speed

We would appreciate your feedback on this proposal including suggestions for
additional values.

If this proposal looks good, we would like to propose that it be included in
the JobX Spec. If the print-optimize attribute is approved by PWG by the end
of August, then we can propose that it be added to the JDF 1.2 Spec that is
being finalized in early September.

Thank you for your time and feedback.

Claudia Alimpich

IBM Printing Systems Division

Boulder CO

303-924-4418

alimpich at us.ibm.com

Response to Print Quality Issue:

I understand the desire to avoid violating the semantics of the IPP
attribute - but adding these enumerations to print-quality does not feel as
objectionable to me as splitting a single semantic concept into two
different attributes.  If this is the precedent we take for extending the
semantic model, I'm worried that we'll end up with an increasingly confusing
and complex.  I would rather we take the minor hit and fix the high & draft
definitions in the semantic model than create another ~equivalent attribute
with a whole bunch of special semantic rules (e.g. - what should the service
do if print-quality=high and print-optimize=save-toner?).

bt

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

Bob Taylor                                        

Senior Architect                            

IPG Strategic Technology Development  

Hewlett-Packard Co.       

 <mailto:bobt at hp.com> mailto:bobt at hp.com                        

phone: 360.212.2625/T212.2625                    

fax: 208.730-5111                 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030709/eaa72de2/attachment.htm 

From imcdonald at sharplabs.com  Thu Jul 10 08:49:56 2003
From: imcdonald at sharplabs.com (McDonald, Ira)
Date: Thu, 10 Jul 2003 08:49:56 -0700
Subject: [printing-driver] RE: SM> Semantic Model (JobX) teleconference
Message-ID: <116DB56CD7DED511BC7800508B2CA53735D09B@mailsrvnt02.enet.sharplabs.com>

Hi Tom and Pete,

Are we reviewing the '-rev.pdf' or the plain '.pdf' today?

Will you be using the WebEx to edit the document?

I picked up the '-rev.pdf', because it seemed most useful.

Cheers,
- Ira


-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Wednesday, July 09, 2003 7:09 PM
To: Zehler, Peter; PWG Semantic Model WG (sm at pwg.org)
Cc: 'Claudia Alimpich'; IPP Discussion List (IPP at pwg.org);
printing-jobticket at freestandards.org; printing-driver at freestandards.org
Subject: RE: SM> Semantic Model (JobX) teleconference


I've down loaded the .pdf for the .doc files as Peter requested for
tomorrow's telecon.  I've also put all four in the proper place in the IPP
spec hierarchy as well under the new_JOBX arc (but I did not delete them
from the Semantic_Model sub-tree):

ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702-rev.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_JOBX/wd-ippjobx10-20030702-rev.doc



Tom
-----Original Message-----
From: Zehler, Peter [mailto:PZehler at crt.xerox.com]
Sent: Wednesday, July 02, 2003 08:16
To: PWG Semantic Model WG (sm at pwg.org)
Cc: 'Claudia Alimpich'; IPP Discussion List (IPP at pwg.org);
printing-jobticket at freestandards.org; printing-driver at freestandards.org
Subject: SM> Semantic Model (JobX) teleconference


All,
Thursday July 10th at 1pm EDT is the Semantic Model teleconference. This 
week's Teleconference will be dedicated to IPP JobX.  The document is 
available on the PWG server at 
ftp://ftp.pwg.org/pub/pwg/Semantic-Model/wd-ippjobx10-20030702.doc 
(If someone could convert this to PDF I would appreciate it.  I haven't
found my copy of distiller to put on my new system yet.)
The teleconference is 2 hours long.  It will be run using phone and Webex.
Anyone that does not yet have Webex installed should do that before
Thursday.  Information for the phone and Webex are included below.  NOTE:
New Dial in number and passcode
The agenda for the Semantic Model teleconference is:
1) Discuss the print-quality issue (see included notes below)
2) Discuss the document-xxx-supplied changes in JobX
3) Discuss the output-device resolution
Pete
PS: Bob let me know if there is a problem hosting Webex.
________________________________________________
Dial in Info:
Phone Number:(877) 707-6056
(Phone Number for Xerox Employees: 8*594-0077)
 PARTICIPANT PASSCODE: 437874#
________________________________________________
webex info:
We will also use an on line tool called webex,
if you have not used this before, setup up by
following the First Time Users instructions.
Do this in advance of the meeting.
-------------------------
FIRST TIME USERS
-------------------------
For fully interactive meetings, including the ability
to present your documents and applications, a one-time
setup takes less than 10 minutes. Click this URL to set up now:
http://hp.webex.com
Then click New User.
-------------------------
On Thursday use:
https://hp.webex.com/join/
Then click join unlisted meeting.
Use the info below:
-------------------------
Webex MEETING SUMMARY
-------------------------
Topic: PWG Semantic Model 
Date: Thursday, July 10, 2003 
Time: 10:00 am, Pacific Daylight Time (GMT -07:00, San Jose) 
Meeting number: 21366675 
Meeting password: pwg_sm1! 
Host: 
Bob Taylor (HP)
___________________________________________________


Peter Zehler
XEROX
Xerox Innovation Group
Email: PZehler at crt.xerox.com
Voice:    (585) 265-8755
FAX:      (585) 422-7961
US Mail: Peter Zehler
        Xerox Corp.
        800 Phillips Rd.
        M/S 128-25E
        Webster NY, 14580-9701
Print Quality Issue:
Last Tuesday during the PWG/FSG meeting in Portland we had a discussion
about the IPP print-quality attribute and FSG's desire to add two new
values, "economy" and "fine", where "economy" is lower than "draft" and
"fine" is higher than "high". After some discussion we all pretty much
decided that it is not possible to add these new values to the already
existing "draft", "normal", and "high" values because of the current
definitions of the existing values (high is defined as the highest quality
and draft is defined as the lowest quality). It also seemed like what FSG
wanted was a way to specify print optimization and not additional levels of
print quality.
The FSG working group met today, and based on the input from last Tuesday's
meeting, we would like to propose the addition of a new attribute, called
print-optimize, that is defined as follows:
   print-optimize (type2 keyword)
      This attribute refines the value specified by the print-quality
      attribute.
      The standard keyword values are:
         'image': optimize for image clarity
         'photo': optimize for photo clarity
         'text': optimize for text clarity
         'text-and-image': optimize for both text and image clarity
         'save-toner': optimize for minimal toner usage
         'speed': optimize for printing speed
We would appreciate your feedback on this proposal including suggestions for
additional values.
If this proposal looks good, we would like to propose that it be included in
the JobX Spec. If the print-optimize attribute is approved by PWG by the end
of August, then we can propose that it be added to the JDF 1.2 Spec that is
being finalized in early September.
Thank you for your time and feedback.
Claudia Alimpich
IBM Printing Systems Division
Boulder CO
303-924-4418
alimpich at us.ibm.com
Response to Print Quality Issue:
I understand the desire to avoid violating the semantics of the IPP
attribute - but adding these enumerations to print-quality does not feel as
objectionable to me as splitting a single semantic concept into two
different attributes.  If this is the precedent we take for extending the
semantic model, I'm worried that we'll end up with an increasingly confusing
and complex.  I would rather we take the minor hit and fix the high & draft
definitions in the semantic model than create another ~equivalent attribute
with a whole bunch of special semantic rules (e.g. - what should the service
do if print-quality=high and print-optimize=save-toner?).
bt
---------------------------------------------------
Bob Taylor                                        
Senior Architect                            
IPG Strategic Technology Development  
Hewlett-Packard Co.       
mailto:bobt at hp.com                        
phone: 360.212.2625/T212.2625                    
fax: 208.730-5111                 
---------------------------------------------------   



From PZehler at crt.xerox.com  Thu Jul 10 12:41:31 2003
From: PZehler at crt.xerox.com (Zehler, Peter)
Date: Thu, 10 Jul 2003 15:41:31 -0400
Subject: [printing-driver] Print Quality Issue resolution
Message-ID: <CA9D3573509ECA46A712181F58C0A64D147306@x-wb-0128-nt8.wrc.xerox.com>

All,

During the PWG/FSG meeting in Portland we had a discussion about the IPP
"print-quality" attribute and FSG's desire to add two new values, 'economy'
and 'fine', where 'economy' is lower than 'draft' and 'fine' is higher than
'high'. The FSG further proposed the addition of a new attribute, called
"print-optimize", that would augment "print-quality" with values of 'image',
'photo', 'text', 'text-and-image', 'save-toner' and 'speed'.

With regard to 'economy' and 'fine', we agreed that 'economy' would map to
"print-quality"='draft' and 'fine' to "print-quality"='high'.  There may be
end user visible features that map to multiple attributes.  We leave it to
specific print domains to model these higher level aggregate features.  When
appropriate we will add needed elements to the Semantic Model.

There was a lot of push back on "print-optimize".  The main concern was that
"print-optimize" contained a mixed bag of items.  The two main categories
were content metadata and rendering hints.  We finally agreed that the two
values 'save-toner' and 'speed' are implied by the "print-quality".  Since
they were not required, they were removed.  The remaining values are needed
to direct the type of optimization/processing that will be performed on the
content.  It does not necessarily mean the value describes the content.  To
clarify this we changed the attribute name to "print-content-optimize".
Finally the value 'image' seemed the same as 'photo'.  The name for this was
changed to 'graphic'.

As a result the following attribute will be added to the JobX specification
in it next revision.

   print-content-optimize (type2 keyword)

      This attribute refines the value specified by the print-quality
      attribute.

      The standard keyword values are:

         'graphic': optimize for graphic clarity
         'photo': optimize for photo clarity
         'text': optimize for text clarity
         'text-and-graphic': optimize for both text and graphic clarity



				Peter Zehler
				XEROX
				Xerox Innovation Group
				Email: PZehler at crt.xerox.com
				Voice:    (585) 265-8755
				FAX:      (585) 422-7961
				US Mail: Peter Zehler
				        Xerox Corp.
				        800 Phillips Rd.
				        M/S 128-25E
				        Webster NY, 14580-9701


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030710/d2077649/attachment.htm 

From mike at easysw.com  Thu Jul 10 14:08:45 2003
From: mike at easysw.com (Mike Sweet)
Date: Thu, 10 Jul 2003 17:08:45 -0400
Subject: [printing-driver] Re: IPP> RE: [printing-jobticket] Print Quality Issue resolution
In-Reply-To: <7F2C5DA4096E9D44B70E967CB54EEEDB75AE21@mamail.digi.com>
References: <7F2C5DA4096E9D44B70E967CB54EEEDB75AE21@mamail.digi.com>
Message-ID: <3F0DD5DD.2090907@easysw.com>

Wagner,William wrote:
> Peter,
> 
> Seems  a reasonable resolution. However,  since you  state: ...the
> value 'image' seemed the same as 'photo'.  The name for this was 
> changed to 'graphic'.
> 
> I  do not understand why the values  include both "Graphic" and
> "Photo".:

"Graphic" presumably means business graphics (lines, bars, graphs,
and other computer-generated imagery), while "photo" means an actual
photographic image.

Some devices can be optimized for different types of output; e.g.,
photo output might use a variable dot size mode on the device, while
graphic output might use a single dot size mode for speed.  Similarly,
the resolution enhancements provided on laser printers are not all
appropriate for all types of output.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike at easysw.com
Printing Software for UNIX                       http://www.easysw.com




From PZehler at crt.xerox.com  Fri Jul 11 03:34:59 2003
From: PZehler at crt.xerox.com (Zehler, Peter)
Date: Fri, 11 Jul 2003 06:34:59 -0400
Subject: [printing-driver] RE: IPP> RE: [printing-jobticket] Print Quality Issue resolution
Message-ID: <CA9D3573509ECA46A712181F58C0A64D147309@x-wb-0128-nt8.wrc.xerox.com>

Bill,
We asked what difference was between 'image' and 'photo'.  Based on that
explanation we felt that the term 'image' was actually 'graphic'.  The value
'graphic' was for business graphics as clarified by Mike below.  I will make
the definitions clearer in the JobX spec. (The value 'image' was confusing
and seemed to be equivalent to 'photo'.  We went with 'photo' since it is
commonly used by end users today)
Pete

				Peter Zehler
				XEROX
				Xerox Innovation Group
				Email: PZehler at crt.xerox.com
				Voice:    (585) 265-8755
				FAX:      (585) 422-7961
				US Mail: Peter Zehler
					        Xerox Corp.
					        800 Phillips Rd.
					        M/S 128-25E
					        Webster NY, 14580-9701


> -----Original Message-----
> From: Wagner,William [mailto:WWagner at NetSilicon.com]
> Sent: Thursday, July 10, 2003 5:38 PM
> To: Mike Sweet
> Cc: Zehler, Peter; IPP at pwg.org; printing-jobticket at freestandards.org;
> printing-driver at freestandards.org
> Subject: RE: IPP> RE: [printing-jobticket] Print Quality Issue resolution
> 
> Yes, that may be  a reasonable distinction. But it seems inconsistent with
> the statement that "'image' seemed the same as 'photo'.  The name for this
> was  changed to 'graphic'".  But  I  may just be reading it wrong.
> 
> Bill Wagner
> 
> -----Original Message-----
> From: Mike Sweet [mailto:mike at easysw.com]
> Sent: Thursday, July 10, 2003 5:09 PM
> To: Wagner,William
> Cc: Zehler, Peter; IPP at pwg.org; printing-jobticket at freestandards.org;
> printing-driver at freestandards.org
> Subject: Re: IPP> RE: [printing-jobticket] Print Quality Issue
> resolution
> 
> 
> Wagner,William wrote:
> > Peter,
> >
> > Seems  a reasonable resolution. However,  since you  state: ...the
> > value 'image' seemed the same as 'photo'.  The name for this was
> > changed to 'graphic'.
> >
> > I  do not understand why the values  include both "Graphic" and
> > "Photo".:
> 
> "Graphic" presumably means business graphics (lines, bars, graphs,
> and other computer-generated imagery), while "photo" means an actual
> photographic image.
> 
> Some devices can be optimized for different types of output; e.g.,
> photo output might use a variable dot size mode on the device, while
> graphic output might use a single dot size mode for speed.  Similarly,
> the resolution enhancements provided on laser printers are not all
> appropriate for all types of output.
> 
> --
> ______________________________________________________________________
> Michael Sweet, Easy Software Products                  mike at easysw.com
> Printing Software for UNIX                       http://www.easysw.com



From PZehler at crt.xerox.com  Fri Jul 11 03:54:22 2003
From: PZehler at crt.xerox.com (Zehler, Peter)
Date: Fri, 11 Jul 2003 06:54:22 -0400
Subject: [printing-driver] RE: IPP> Print Quality Issue resolution
Message-ID: <CA9D3573509ECA46A712181F58C0A64D14730A@x-wb-0128-nt8.wrc.xerox.com>

Harry,

We felt that there are many different attributes involved in heuristics for
saving toner and printing fast.  Some of those are "resolution", "media" and
aspects of the document content.  We felt the requirements were met by
keeping the existing "print-quality" values and augmenting them with hints
on how to process the document content to achieve 'draft' 'normal' and
'high'.  The assumption is that draft is fastest and uses the least toner.

Pete

 

Peter Zehler 
XEROX 
Xerox Innovation Group 
Email: PZehler at crt.xerox.com 
Voice:    (585) 265-8755 
FAX:      (585) 422-7961 
US Mail: Peter Zehler 

        Xerox Corp. 
        800 Phillips Rd. 
        M/S 128-25E 
        Webster NY, 14580-9701 

-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com] 
Sent: Thursday, July 10, 2003 11:26 PM
To: Zehler, Peter
Cc: IPP Discussion List (IPP at pwg.org); printing-driver at freestandards.org;
printing-jobticket at freestandards.org
Subject: Re: IPP> Print Quality Issue resolution

 


> We finally agreed that the two values 'save-toner' and 'speed' are implied
by the "print-quality".  Since they were not required, they were removed. 

I think this warrants further examination. I have known toner saving methods
that do a very good job of preserving print quality. 
---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 




"Zehler, Peter" <PZehler at crt.xerox.com> 
Sent by: owner-ipp at pwg.org 

07/10/2003 01:41 PM 


To

"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>,
printing-jobticket at freestandards.org, printing-driver at freestandards.org 


cc

 


Subject

IPP> Print Quality Issue resolution

 


 

 




All, 

During the PWG/FSG meeting in Portland we had a discussion about the IPP
"print-quality" attribute and FSG's desire to add two new values, 'economy'
and 'fine', where 'economy' is lower than 'draft' and 'fine' is higher than
'high'. The FSG further proposed the addition of a new attribute, called
"print-optimize", that would augment "print-quality" with values of 'image',
'photo', 'text', 'text-and-image', 'save-toner' and 'speed'. 

With regard to 'economy' and 'fine', we agreed that 'economy' would map to
"print-quality"='draft' and 'fine' to "print-quality"='high'.  There may be
end user visible features that map to multiple attributes.  We leave it to
specific print domains to model these higher level aggregate features.  When
appropriate we will add needed elements to the Semantic Model. 

There was a lot of push back on "print-optimize".  The main concern was that
"print-optimize" contained a mixed bag of items.  The two main categories
were content metadata and rendering hints.  We finally agreed that the two
values 'save-toner' and 'speed' are implied by the "print-quality".  Since
they were not required, they were removed.  The remaining values are needed
to direct the type of optimization/processing that will be performed on the
content.  It does not necessarily mean the value describes the content.  To
clarify this we changed the attribute name to "print-content-optimize".
Finally the value 'image' seemed the same as 'photo'.  The name for this was
changed to 'graphic'. 

As a result the following attribute will be added to the JobX specification
in it next revision. 

   print-content-optimize (type2 keyword) 

      This attribute refines the value specified by the print-quality 

      attribute. 

      The standard keyword values are: 

         'graphic': optimize for graphic clarity 

         'photo': optimize for photo clarity 

         'text': optimize for text clarity 

         'text-and-graphic': optimize for both text and graphic clarity 

 

Peter Zehler 

XEROX 

Xerox Innovation Group 

Email: PZehler at crt.xerox.com 

Voice:    (585) 265-8755 

FAX:      (585) 422-7961 

US Mail: Peter Zehler 

        Xerox Corp. 

        800 Phillips Rd. 

        M/S 128-25E 

        Webster NY, 14580-9701 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030711/7ca716c9/attachment.htm 

From imcdonald at sharplabs.com  Sat Jul 12 09:40:54 2003
From: imcdonald at sharplabs.com (McDonald, Ira)
Date: Sat, 12 Jul 2003 09:40:54 -0700
Subject: [printing-driver] RE: IPP> Print Quality Issue resolution
Message-ID: <116DB56CD7DED511BC7800508B2CA53735D09E@mailsrvnt02.enet.sharplabs.com>

Hi Harry,

Not a flat set - we already had a multi-attribute set of (at least):

1)  print-quality
2)  printer-resolution
3)  media

They interact to produce the desired print quality, as Pete observed.

Having said that, since "print-content-optimize" now ONLY enumerates
document content metadata, yes I'd be happy to add another new
attribute:

    print-ink-save (boolean)

Bob Taylor and others have correctly pointed out that 'toner' is
only used in laser printing - 'ink' or 'marker' or something else
is used in the other printing processes.

Cheers,
- Ira McDonald
  High North Inc


-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Friday, July 11, 2003 9:49 AM
To: Zehler, Peter
Cc: IPP Discussion List (IPP at pwg.org); printing-driver at freestandards.org;
printing-jobticket at freestandards.org; Zehler, Peter
Subject: RE: IPP> Print Quality Issue resolution



My concern is that "save toner" is probably the most concrete concept
compared to "Good, Better, Best" or "Text, Image, Graphics". The later has
efficient application only in special cases (some of which may be very
significant, like printing photo's). Otherwise, people stare at their mixed
object document and wonder. I feel "save toner" should be explicit. 

We went from a flat set of descriptors to a pairing.. perhaps we should
really go to a matrix (although I don't like the perceived complexity) 

Good - Better - Best 
Text - Text+Graphics - Graphics - Image 
TonerSaving 

---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 


"Zehler, Peter" <PZehler at crt.xerox.com> 
07/11/2003 04:54 AM ToHarry Lewis/Boulder/IBM at IBMUS, "Zehler, Peter"
<PZehler at crt.xerox.com> 
cc"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>,
printing-driver at freestandards.org, printing-jobticket at freestandards.org 
SubjectRE: IPP> Print Quality Issue resolution







Harry, 
We felt that there are many different attributes involved in heuristics for
saving toner and printing fast.  Some of those are "resolution", "media" and
aspects of the document content.  We felt the requirements were met by
keeping the existing "print-quality" values and augmenting them with hints
on how to process the document content to achieve 'draft' 'normal' and
'high'.  The assumption is that draft is fastest and uses the least toner. 
Pete 
  
Peter Zehler 
XEROX 
Xerox Innovation Group 
Email: PZehler at crt.xerox.com 
Voice:    (585) 265-8755 
FAX:      (585) 422-7961 
US Mail: Peter Zehler 
        Xerox Corp. 
       800 Phillips Rd. 
       M/S 128-25E 
       Webster NY, 14580-9701 
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com] 
Sent: Thursday, July 10, 2003 11:26 PM
To: Zehler, Peter
Cc: IPP Discussion List (IPP at pwg.org); printing-driver at freestandards.org;
printing-jobticket at freestandards.org
Subject: Re: IPP> Print Quality Issue resolution 
  

> We finally agreed that the two values 'save-toner' and 'speed' are implied
by the "print-quality".  Since they were not required, they were removed. 

I think this warrants further examination. I have known toner saving methods
that do a very good job of preserving print quality. 
---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 

"Zehler, Peter" <PZehler at crt.xerox.com> 
Sent by: owner-ipp at pwg.org 
07/10/2003 01:41 PM 
To"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>,
printing-jobticket at freestandards.org, printing-driver at freestandards.org 
cc  
SubjectIPP> Print Quality Issue resolution

  

   






All, 
During the PWG/FSG meeting in Portland we had a discussion about the IPP
"print-quality" attribute and FSG's desire to add two new values, 'economy'
and 'fine', where 'economy' is lower than 'draft' and 'fine' is higher than
'high'. The FSG further proposed the addition of a new attribute, called
"print-optimize", that would augment "print-quality" with values of 'image',
'photo', 'text', 'text-and-image', 'save-toner' and 'speed'. 
With regard to 'economy' and 'fine', we agreed that 'economy' would map to
"print-quality"='draft' and 'fine' to "print-quality"='high'.  There may be
end user visible features that map to multiple attributes.  We leave it to
specific print domains to model these higher level aggregate features.  When
appropriate we will add needed elements to the Semantic Model. 
There was a lot of push back on "print-optimize".  The main concern was that
"print-optimize" contained a mixed bag of items.  The two main categories
were content metadata and rendering hints.  We finally agreed that the two
values 'save-toner' and 'speed' are implied by the "print-quality".  Since
they were not required, they were removed.  The remaining values are needed
to direct the type of optimization/processing that will be performed on the
content.  It does not necessarily mean the value describes the content.  To
clarify this we changed the attribute name to "print-content-optimize".
Finally the value 'image' seemed the same as 'photo'.  The name for this was
changed to 'graphic'. 
As a result the following attribute will be added to the JobX specification
in it next revision. 
   print-content-optimize (type2 keyword) 
      This attribute refines the value specified by the print-quality 
      attribute. 
      The standard keyword values are: 
         'graphic': optimize for graphic clarity 
         'photo': optimize for photo clarity 
         'text': optimize for text clarity 
         'text-and-graphic': optimize for both text and graphic clarity 
 
Peter Zehler 
XEROX 
Xerox Innovation Group 
Email: PZehler at crt.xerox.com 
Voice:    (585) 265-8755 
FAX:      (585) 422-7961 
US Mail: Peter Zehler 
        Xerox Corp. 
        800 Phillips Rd. 
        M/S 128-25E 
        Webster NY, 14580-9701 



From rlk at alum.mit.edu  Sat Jul 12 10:28:11 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Sat, 12 Jul 2003 13:28:11 -0400
Subject: [printing-driver] RE: IPP> Print Quality Issue resolution
In-Reply-To: 
	<116DB56CD7DED511BC7800508B2CA53735D09E@mailsrvnt02.enet.sharplabs.com>
	(imcdonald@sharplabs.com)
References: <116DB56CD7DED511BC7800508B2CA53735D09E@mailsrvnt02.enet.sharplabs.com>
Message-ID: <200307121728.h6CHSBDm018697@dsl092-065-009.bos1.dsl.speakeasy.net>

I was out on vacation for a few weeks, and very busy this week.  This
is an interesting discussion.

   From: "McDonald, Ira" <imcdonald at sharplabs.com>
   Date: Sat, 12 Jul 2003 09:40:54 -0700

   Hi Harry,

   Not a flat set - we already had a multi-attribute set of (at least):

   1)  print-quality
   2)  printer-resolution
   3)  media

   They interact to produce the desired print quality, as Pete observed.

   Having said that, since "print-content-optimize" now ONLY enumerates
   document content metadata, yes I'd be happy to add another new
   attribute:

       print-ink-save (boolean)

What exactly is this supposed to do?  There are a number of ways a
driver could interpret it:

1) On a photo (6 or 7 color printer with light cyan, magenta, and/or
black) use only the dark inks.

2) On a photo printer, attempt to balance the amount of light and dark
inks used to minimize the amount of ink used.

3) Reduce the ink density.

4) Use more black in place of CMY (more aggressive GCR and/or UCR).

Is this something a driver is expected to decide on for itself, or
should there be a standard meaning for it?

   -----Original Message-----
   From: Harry Lewis [mailto:harryl at us.ibm.com]

   My concern is that "save toner" is probably the most concrete concept
   compared to "Good, Better, Best" or "Text, Image, Graphics". The later has
   efficient application only in special cases (some of which may be very
   significant, like printing photo's). Otherwise, people stare at their mixed
   object document and wonder. I feel "save toner" should be explicit. 

   We went from a flat set of descriptors to a pairing.. perhaps we should
   really go to a matrix (although I don't like the perceived complexity) 

   Good - Better - Best 
   Text - Text+Graphics - Graphics - Image 

A lot of people would love for us to simplify Gimp-Print to this :-) I
think that these are somewhat independent, but that the image setting
can be simplified: there can be a default setting in which case the
driver doesn't try to do anything special.  If the user doesn't select
anything, the driver will simply try to do something reasonable for
anything that's being printed.  In contrast, for quality there always
has to be a setting.  There can be a "Standard" quality or something
that you get if you don't specify a different setting, but the output
quality is something the user always has in mind to at least some
degree (at the least, it should "look OK").

However, a lot of people specifically want to print photographs on
their printers.  If someone's printing a sequence of photographs from
their digital camera, they would logically think in terms of what
they're printing (photographs) and the quality (or perhaps speed) with
which they're printed.

For reference, Gimp-Print (or at least the Epson driver within it)
supports the following named quality settings:

Fast Economy -- this is an economy mode offered on certain printers
		that prints particularly fast.  It's typically 360x90
		or 360x120 DPI.
Economy	     -- this is a more normal economy mode (360x180 or
		360x240).
Draft	     -- 360 DPI
Standard     -- 720x360 DPI
High	     -- 720 DPI
Photo	     -- 1440x720 DPI (for printers that support it, and for
		papers better than plain paper).
Super Photo  -- 2880x1440 DPI on printers that support it (on top
		quality photo papers only).
Ultra Photo  -- 2880x2880 DPI on printers that support it (on top
		quality photo papers only).
Best	     -- The best reasonable quality offered for a given
		combination of paper and printer (e. g. it doesn't
		wind up printing at 2880x1440 on plain paper).

Right now this only sets the printing resolution; we'll probably make
it set other options (such as the dither algorithm, and possibly the
image optimization) as well.

   "Zehler, Peter" <PZehler at crt.xerox.com> 
   07/11/2003 04:54 AM ToHarry Lewis/Boulder/IBM at IBMUS, "Zehler, Peter"
   <PZehler at crt.xerox.com> 
   cc"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>,
   printing-driver at freestandards.org, printing-jobticket at freestandards.org 
   SubjectRE: IPP> Print Quality Issue resolution

   We felt that there are many different attributes involved in heuristics for
   saving toner and printing fast.  Some of those are "resolution", "media" and
   aspects of the document content.  We felt the requirements were met by
   keeping the existing "print-quality" values and augmenting them with hints
   on how to process the document content to achieve 'draft' 'normal' and
   'high'.  The assumption is that draft is fastest and uses the least toner. 

This raises another issue: it's not necessarily the case that draft
mode would use less ink.  On plain paper, for example, Epson inkjet
printers are capable of depositing enough ink to create solid black
even at 360 DPI, which is commonly thought of as a "draft" resolution
on inkjets.  In general, I've heard the belief that higher resolutions
mean more ink is used, which isn't necessarily the case.  We should be
careful not to add to that confusion.



From WWagner at NetSilicon.com  Thu Jul 10 13:48:17 2003
From: WWagner at NetSilicon.com (Wagner,William)
Date: Thu, 10 Jul 2003 16:48:17 -0400
Subject: [printing-driver] RE: [printing-jobticket] Print Quality Issue resolution
Message-ID: <7F2C5DA4096E9D44B70E967CB54EEEDB75AE21@mamail.digi.com>

Peter,
 
Seems  a reasonable resolution. However,  since you  state:
...the value 'image' seemed the same as 'photo'.  The name for this was changed to 'graphic'.
 
I  do not understand why the values  include both "Graphic" and "Photo".:
 
         'graphic': optimize for graphic clarity 

         'photo': optimize for photo clarity

         'text': optimize for text clarity

         'text-and-graphic': optimize for both text and graphic clarity

 

Bill Wagner

 
 
 
 

-----Original Message-----
From: Zehler, Peter [mailto:PZehler at crt.xerox.com]
Sent: Thursday, July 10, 2003 3:42 PM
To: IPP Discussion List (IPP at pwg.org); printing-jobticket at freestandards.org; printing-driver at freestandards.org
Subject: [printing-jobticket] Print Quality Issue resolution



All,

During the PWG/FSG meeting in Portland we had a discussion about the IPP "print-quality" attribute and FSG's desire to add two new values, 'economy' and 'fine', where 'economy' is lower than 'draft' and 'fine' is higher than 'high'. The FSG further proposed the addition of a new attribute, called "print-optimize", that would augment "print-quality" with values of 'image', 'photo', 'text', 'text-and-image', 'save-toner' and 'speed'.

With regard to 'economy' and 'fine', we agreed that 'economy' would map to "print-quality"='draft' and 'fine' to "print-quality"='high'.  There may be end user visible features that map to multiple attributes.  We leave it to specific print domains to model these higher level aggregate features.  When appropriate we will add needed elements to the Semantic Model.

There was a lot of push back on "print-optimize".  The main concern was that "print-optimize" contained a mixed bag of items.  The two main categories were content metadata and rendering hints.  We finally agreed that the two values 'save-toner' and 'speed' are implied by the "print-quality".  Since they were not required, they were removed.  The remaining values are needed to direct the type of optimization/processing that will be performed on the content.  It does not necessarily mean the value describes the content.  To clarify this we changed the attribute name to "print-content-optimize".  Finally the value 'image' seemed the same as 'photo'.  The name for this was changed to 'graphic'.

As a result the following attribute will be added to the JobX specification in it next revision.

   print-content-optimize (type2 keyword)

      This attribute refines the value specified by the print-quality

      attribute.

      The standard keyword values are:

         'graphic': optimize for graphic clarity

         'photo': optimize for photo clarity

         'text': optimize for text clarity

         'text-and-graphic': optimize for both text and graphic clarity



	Peter Zehler

	XEROX

	Xerox Innovation Group

	Email: PZehler at crt.xerox.com

	Voice:    (585) 265-8755

	FAX:      (585) 422-7961

	US Mail: Peter Zehler

	        Xerox Corp.

	        800 Phillips Rd.

	        M/S 128-25E

	        Webster NY, 14580-9701



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030710/4c43b3e9/attachment.htm 

From WWagner at NetSilicon.com  Thu Jul 10 14:38:13 2003
From: WWagner at NetSilicon.com (Wagner,William)
Date: Thu, 10 Jul 2003 17:38:13 -0400
Subject: [printing-driver] RE: IPP> RE: [printing-jobticket] Print Quality Issue resolution
Message-ID: <7F2C5DA4096E9D44B70E967CB54EEEDB5CE916@mamail.digi.com>

Yes, that may be  a reasonable distinction. But it seems inconsistent with  the statement that "'image' seemed the same as 'photo'.  The name for this was  changed to 'graphic'".  But  I  may just be reading it wrong. 

Bill Wagner

-----Original Message-----
From: Mike Sweet [mailto:mike at easysw.com]
Sent: Thursday, July 10, 2003 5:09 PM
To: Wagner,William
Cc: Zehler, Peter; IPP at pwg.org; printing-jobticket at freestandards.org;
printing-driver at freestandards.org
Subject: Re: IPP> RE: [printing-jobticket] Print Quality Issue
resolution


Wagner,William wrote:
> Peter,
> 
> Seems  a reasonable resolution. However,  since you  state: ...the
> value 'image' seemed the same as 'photo'.  The name for this was 
> changed to 'graphic'.
> 
> I  do not understand why the values  include both "Graphic" and
> "Photo".:

"Graphic" presumably means business graphics (lines, bars, graphs,
and other computer-generated imagery), while "photo" means an actual
photographic image.

Some devices can be optimized for different types of output; e.g.,
photo output might use a variable dot size mode on the device, while
graphic output might use a single dot size mode for speed.  Similarly,
the resolution enhancements provided on laser printers are not all
appropriate for all types of output.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike at easysw.com
Printing Software for UNIX                       http://www.easysw.com




From harryl at us.ibm.com  Thu Jul 10 20:26:07 2003
From: harryl at us.ibm.com (Harry Lewis)
Date: Thu, 10 Jul 2003 21:26:07 -0600
Subject: [printing-driver] Re: IPP> Print Quality Issue resolution
In-Reply-To: <CA9D3573509ECA46A712181F58C0A64D147306@x-wb-0128-nt8.wrc.xerox.com>
Message-ID: <OF7BE5A837.4E439D6E-ON87256D60.00121FDA-87256D60.0012D247@us.ibm.com>

> We finally agreed that the two values 'save-toner' and 'speed' are 
implied by the "print-quality".  Since they were not required, they were 
removed.

I think this warrants further examination. I have known toner saving 
methods that do a very good job of preserving print quality. 
---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 



"Zehler, Peter" <PZehler at crt.xerox.com> 
Sent by: owner-ipp at pwg.org
07/10/2003 01:41 PM

To
"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>, 
printing-jobticket at freestandards.org, printing-driver at freestandards.org
cc

Subject
IPP> Print Quality Issue resolution






All,
During the PWG/FSG meeting in Portland we had a discussion about the IPP 
"print-quality" attribute and FSG's desire to add two new values, 
'economy' and 'fine', where 'economy' is lower than 'draft' and 'fine' is 
higher than 'high'. The FSG further proposed the addition of a new 
attribute, called "print-optimize", that would augment "print-quality" 
with values of 'image', 'photo', 'text', 'text-and-image', 'save-toner' 
and 'speed'.
With regard to 'economy' and 'fine', we agreed that 'economy' would map to 
"print-quality"='draft' and 'fine' to "print-quality"='high'.  There may 
be end user visible features that map to multiple attributes.  We leave it 
to specific print domains to model these higher level aggregate features. 
When appropriate we will add needed elements to the Semantic Model.
There was a lot of push back on "print-optimize".  The main concern was 
that "print-optimize" contained a mixed bag of items.  The two main 
categories were content metadata and rendering hints.  We finally agreed 
that the two values 'save-toner' and 'speed' are implied by the 
"print-quality".  Since they were not required, they were removed.  The 
remaining values are needed to direct the type of optimization/processing 
that will be performed on the content.  It does not necessarily mean the 
value describes the content.  To clarify this we changed the attribute 
name to "print-content-optimize".  Finally the value 'image' seemed the 
same as 'photo'.  The name for this was changed to 'graphic'.
As a result the following attribute will be added to the JobX 
specification in it next revision.
   print-content-optimize (type2 keyword)
      This attribute refines the value specified by the print-quality
      attribute.
      The standard keyword values are:
         'graphic': optimize for graphic clarity
         'photo': optimize for photo clarity
         'text': optimize for text clarity
         'text-and-graphic': optimize for both text and graphic clarity


Peter Zehler
XEROX
Xerox Innovation Group
Email: PZehler at crt.xerox.com
Voice:    (585) 265-8755
FAX:      (585) 422-7961
US Mail: Peter Zehler
        Xerox Corp.
        800 Phillips Rd.
        M/S 128-25E
        Webster NY, 14580-9701
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030710/bfc4f101/attachment.htm 

From harryl at us.ibm.com  Fri Jul 11 06:49:02 2003
From: harryl at us.ibm.com (Harry Lewis)
Date: Fri, 11 Jul 2003 07:49:02 -0600
Subject: [printing-driver] RE: IPP> Print Quality Issue resolution
In-Reply-To: <CA9D3573509ECA46A712181F58C0A64D14730A@x-wb-0128-nt8.wrc.xerox.com>
Message-ID: <OF874CE209.66EC8B84-ON87256D60.00499FB2-87256D60.004BD9A5@us.ibm.com>

My concern is that "save toner" is probably the most concrete concept 
compared to "Good, Better, Best" or "Text, Image, Graphics". The later has 
efficient application only in special cases (some of which may be very 
significant, like printing photo's). Otherwise, people stare at their 
mixed object document and wonder. I feel "save toner" should be explicit. 

We went from a flat set of descriptors to a pairing.. perhaps we should 
really go to a matrix (although I don't like the perceived complexity)

Good - Better - Best
Text - Text+Graphics - Graphics - Image
TonerSaving

---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 



"Zehler, Peter" <PZehler at crt.xerox.com> 
07/11/2003 04:54 AM

To
Harry Lewis/Boulder/IBM at IBMUS, "Zehler, Peter" <PZehler at crt.xerox.com>
cc
"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>, 
printing-driver at freestandards.org, printing-jobticket at freestandards.org
Subject
RE: IPP> Print Quality Issue resolution






Harry,
We felt that there are many different attributes involved in heuristics 
for saving toner and printing fast.  Some of those are "resolution", 
"media" and aspects of the document content.  We felt the requirements 
were met by keeping the existing "print-quality" values and augmenting 
them with hints on how to process the document content to achieve 'draft' 
'normal' and 'high'.  The assumption is that draft is fastest and uses the 
least toner.
Pete
 
Peter Zehler 
XEROX 
Xerox Innovation Group 
Email: PZehler at crt.xerox.com 
Voice:    (585) 265-8755 
FAX:      (585) 422-7961 
US Mail: Peter Zehler 
        Xerox Corp. 
        800 Phillips Rd. 
        M/S 128-25E 
        Webster NY, 14580-9701 
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com] 
Sent: Thursday, July 10, 2003 11:26 PM
To: Zehler, Peter
Cc: IPP Discussion List (IPP at pwg.org); printing-driver at freestandards.org; 
printing-jobticket at freestandards.org
Subject: Re: IPP> Print Quality Issue resolution
 

> We finally agreed that the two values 'save-toner' and 'speed' are 
implied by the "print-quality".  Since they were not required, they were 
removed. 

I think this warrants further examination. I have known toner saving 
methods that do a very good job of preserving print quality. 
---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 


"Zehler, Peter" <PZehler at crt.xerox.com> 
Sent by: owner-ipp at pwg.org 
07/10/2003 01:41 PM 


To
"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>, 
printing-jobticket at freestandards.org, printing-driver at freestandards.org 
cc
 
Subject
IPP> Print Quality Issue resolution
 


 
 




All, 
During the PWG/FSG meeting in Portland we had a discussion about the IPP 
"print-quality" attribute and FSG's desire to add two new values, 
'economy' and 'fine', where 'economy' is lower than 'draft' and 'fine' is 
higher than 'high'. The FSG further proposed the addition of a new 
attribute, called "print-optimize", that would augment "print-quality" 
with values of 'image', 'photo', 'text', 'text-and-image', 'save-toner' 
and 'speed'. 
With regard to 'economy' and 'fine', we agreed that 'economy' would map to 
"print-quality"='draft' and 'fine' to "print-quality"='high'.  There may 
be end user visible features that map to multiple attributes.  We leave it 
to specific print domains to model these higher level aggregate features. 
When appropriate we will add needed elements to the Semantic Model. 
There was a lot of push back on "print-optimize".  The main concern was 
that "print-optimize" contained a mixed bag of items.  The two main 
categories were content metadata and rendering hints.  We finally agreed 
that the two values 'save-toner' and 'speed' are implied by the 
"print-quality".  Since they were not required, they were removed.  The 
remaining values are needed to direct the type of optimization/processing 
that will be performed on the content.  It does not necessarily mean the 
value describes the content.  To clarify this we changed the attribute 
name to "print-content-optimize".  Finally the value 'image' seemed the 
same as 'photo'.  The name for this was changed to 'graphic'. 
As a result the following attribute will be added to the JobX 
specification in it next revision. 
   print-content-optimize (type2 keyword) 
      This attribute refines the value specified by the print-quality 
      attribute. 
      The standard keyword values are: 
         'graphic': optimize for graphic clarity 
         'photo': optimize for photo clarity 
         'text': optimize for text clarity 
         'text-and-graphic': optimize for both text and graphic clarity 
 
Peter Zehler 
XEROX 
Xerox Innovation Group 
Email: PZehler at crt.xerox.com 
Voice:    (585) 265-8755 
FAX:      (585) 422-7961 
US Mail: Peter Zehler 
        Xerox Corp. 
        800 Phillips Rd. 
        M/S 128-25E 
        Webster NY, 14580-9701 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030711/baffc33f/attachment.htm 

From harryl at us.ibm.com  Sat Jul 12 12:29:19 2003
From: harryl at us.ibm.com (Harry Lewis)
Date: Sat, 12 Jul 2003 13:29:19 -0600
Subject: [printing-driver] RE: IPP> Print Quality Issue resolution
In-Reply-To: <116DB56CD7DED511BC7800508B2CA53735D09E@mailsrvnt02.enet.sharplabs.com>
Message-ID: <OF2095B2C1.24211DEF-ON87256D61.006A8162-87256D61.006B010F@us.ibm.com>

My goal is not to make things more complicated so I would propose 
"print-ink-save" and let the implementation decide what or how, as you 
suggest. My main point is that "toner-saver" is too concrete a concept in 
too many implementations for it not to be explicit. 

As far as choosing a name - Toner, vs, Ink, vs Glop... whatever...
---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 



"McDonald, Ira" <imcdonald at sharplabs.com> 
Sent by: owner-ipp at pwg.org
07/12/2003 10:40 AM

To
Harry Lewis/Boulder/IBM at IBMUS, "Zehler, Peter" <PZehler at crt.xerox.com>
cc
"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>, 
printing-driver at freestandards.org, printing-jobticket at freestandards.org, 
"Zehler, Peter" <PZehler at crt.xerox.com>
Subject
RE: IPP> Print Quality Issue resolution






Hi Harry,

Not a flat set - we already had a multi-attribute set of (at least):

1)  print-quality
2)  printer-resolution
3)  media

They interact to produce the desired print quality, as Pete observed.

Having said that, since "print-content-optimize" now ONLY enumerates
document content metadata, yes I'd be happy to add another new
attribute:

    print-ink-save (boolean)

Bob Taylor and others have correctly pointed out that 'toner' is
only used in laser printing - 'ink' or 'marker' or something else
is used in the other printing processes.

Cheers,
- Ira McDonald
  High North Inc


-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Friday, July 11, 2003 9:49 AM
To: Zehler, Peter
Cc: IPP Discussion List (IPP at pwg.org); printing-driver at freestandards.org;
printing-jobticket at freestandards.org; Zehler, Peter
Subject: RE: IPP> Print Quality Issue resolution



My concern is that "save toner" is probably the most concrete concept
compared to "Good, Better, Best" or "Text, Image, Graphics". The later has
efficient application only in special cases (some of which may be very
significant, like printing photo's). Otherwise, people stare at their 
mixed
object document and wonder. I feel "save toner" should be explicit. 

We went from a flat set of descriptors to a pairing.. perhaps we should
really go to a matrix (although I don't like the perceived complexity) 

Good - Better - Best 
Text - Text+Graphics - Graphics - Image 
TonerSaving 

---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 


"Zehler, Peter" <PZehler at crt.xerox.com> 
07/11/2003 04:54 AM ToHarry Lewis/Boulder/IBM at IBMUS, "Zehler, Peter"
<PZehler at crt.xerox.com> 
cc"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>,
printing-driver at freestandards.org, printing-jobticket at freestandards.org 
SubjectRE: IPP> Print Quality Issue resolution







Harry, 
We felt that there are many different attributes involved in heuristics 
for
saving toner and printing fast.  Some of those are "resolution", "media" 
and
aspects of the document content.  We felt the requirements were met by
keeping the existing "print-quality" values and augmenting them with hints
on how to process the document content to achieve 'draft' 'normal' and
'high'.  The assumption is that draft is fastest and uses the least toner. 

Pete 
 
Peter Zehler 
XEROX 
Xerox Innovation Group 
Email: PZehler at crt.xerox.com 
Voice:    (585) 265-8755 
FAX:      (585) 422-7961 
US Mail: Peter Zehler 
        Xerox Corp. 
       800 Phillips Rd. 
       M/S 128-25E 
       Webster NY, 14580-9701 
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com] 
Sent: Thursday, July 10, 2003 11:26 PM
To: Zehler, Peter
Cc: IPP Discussion List (IPP at pwg.org); printing-driver at freestandards.org;
printing-jobticket at freestandards.org
Subject: Re: IPP> Print Quality Issue resolution 
 

> We finally agreed that the two values 'save-toner' and 'speed' are 
implied
by the "print-quality".  Since they were not required, they were removed. 

I think this warrants further examination. I have known toner saving 
methods
that do a very good job of preserving print quality. 
---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 

"Zehler, Peter" <PZehler at crt.xerox.com> 
Sent by: owner-ipp at pwg.org 
07/10/2003 01:41 PM 
To"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>,
printing-jobticket at freestandards.org, printing-driver at freestandards.org 
cc 
SubjectIPP> Print Quality Issue resolution

 

 






All, 
During the PWG/FSG meeting in Portland we had a discussion about the IPP
"print-quality" attribute and FSG's desire to add two new values, 
'economy'
and 'fine', where 'economy' is lower than 'draft' and 'fine' is higher 
than
'high'. The FSG further proposed the addition of a new attribute, called
"print-optimize", that would augment "print-quality" with values of 
'image',
'photo', 'text', 'text-and-image', 'save-toner' and 'speed'. 
With regard to 'economy' and 'fine', we agreed that 'economy' would map to
"print-quality"='draft' and 'fine' to "print-quality"='high'.  There may 
be
end user visible features that map to multiple attributes.  We leave it to
specific print domains to model these higher level aggregate features. 
When
appropriate we will add needed elements to the Semantic Model. 
There was a lot of push back on "print-optimize".  The main concern was 
that
"print-optimize" contained a mixed bag of items.  The two main categories
were content metadata and rendering hints.  We finally agreed that the two
values 'save-toner' and 'speed' are implied by the "print-quality".  Since
they were not required, they were removed.  The remaining values are 
needed
to direct the type of optimization/processing that will be performed on 
the
content.  It does not necessarily mean the value describes the content. To
clarify this we changed the attribute name to "print-content-optimize".
Finally the value 'image' seemed the same as 'photo'.  The name for this 
was
changed to 'graphic'. 
As a result the following attribute will be added to the JobX 
specification
in it next revision. 
   print-content-optimize (type2 keyword) 
      This attribute refines the value specified by the print-quality 
      attribute. 
      The standard keyword values are: 
         'graphic': optimize for graphic clarity 
         'photo': optimize for photo clarity 
         'text': optimize for text clarity 
         'text-and-graphic': optimize for both text and graphic clarity 
 
Peter Zehler 
XEROX 
Xerox Innovation Group 
Email: PZehler at crt.xerox.com 
Voice:    (585) 265-8755 
FAX:      (585) 422-7961 
US Mail: Peter Zehler 
        Xerox Corp. 
        800 Phillips Rd. 
        M/S 128-25E 
        Webster NY, 14580-9701 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030712/167f3966/attachment.htm 

From imcdonald at sharplabs.com  Mon Jul 14 09:03:36 2003
From: imcdonald at sharplabs.com (McDonald, Ira)
Date: Mon, 14 Jul 2003 09:03:36 -0700
Subject: [printing-driver] Driver meeting today??
Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0A0@mailsrvnt02.enet.sharplabs.com>

Hi,

Is there an FSG OP Driver meeting today?
No announcement on the list.

Cheers,
- Ira McDonald
  High North Inc

_______________________________________________
printing-driver mailing list
printing-driver at freestandards.org
http://freestandards.org/mailman/listinfo/printing-driver



From hamzy at us.ibm.com  Mon Jul 14 09:12:06 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 14 Jul 2003 11:12:06 -0500
Subject: [printing-driver] FSG Printing Driver conference call 07/14/03
Message-ID: <OFA27FD51E.7173AD26-ON86256D63.0058E332-86256D63.0058FFC4@us.ibm.com>




Monday, July 14

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Mark

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




From hamzy at us.ibm.com  Mon Jul 14 11:24:46 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 14 Jul 2003 13:24:46 -0500
Subject: [printing-driver] FSG Printing Driver conference call 07/21/03
Message-ID: <OF8A7913A3.511796C3-ON86256D63.0064EA6F-86256D63.0065250C@us.ibm.com>




Monday, July 21

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Topics:
Remap common job properties to something.  Redecide what of the new common
job properties are necessary.

Mark

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




From bobt at hp.com  Mon Jul 14 13:36:16 2003
From: bobt at hp.com (TAYLOR,BOB (HP-Vancouver,ex1))
Date: Mon, 14 Jul 2003 13:36:16 -0700
Subject: [printing-driver] RE: IPP> Print Quality Issue resolution
Message-ID: <A134E2426B46D711BB4B000347AE6E7CAA5A53@xvan02.vcd.hp.com>

My main question with TonerSaving/InkSaving/MarkerSaving is how this is any
different than PrintQuality(High|Normal|Draft).  We as well have nifty
algorithms for saving "marker" without impacting quality - but I don't know
why we'd ever want to turn it "off" seperately from the notion of
PQ/performance/economy tradeoff (which I maintain is what PrintQuality
actually is).  The semantics of this as a separate attribute seem somewhat
odd to me - i.e., PrintQuality=High & MarkerSaving=False would seem to say
"print in high quality, and waste toner/ink for no good reason", and
PrintQuality=Draft & MarkerSaving=False would seem to say "print in poor
quality, but waste tone/ink anyway".  IMHO, a "separate" TonerSaving mode is
really a vendor-specific extension of PrintQuality, which as Ira noted as
already supported (though they are supposed to be IANA-registered, which I'm
guessing most vendors have not bothered to do).
 
thanks,
 
bt

-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com] 
Sent: Friday, July 11, 2003 6:49 AM
To: Zehler, Peter
Cc: IPP Discussion List (IPP at pwg.org); printing-driver at freestandards.org;
printing-jobticket at freestandards.org; Zehler, Peter
Subject: [printing-driver] RE: IPP> Print Quality Issue resolution



My concern is that "save toner" is probably the most concrete concept
compared to "Good, Better, Best" or "Text, Image, Graphics". The later has
efficient application only in special cases (some of which may be very
significant, like printing photo's). Otherwise, people stare at their mixed
object document and wonder. I feel "save toner" should be explicit. 

We went from a flat set of descriptors to a pairing.. perhaps we should
really go to a matrix (although I don't like the perceived complexity) 

Good - Better - Best 
Text - Text+Graphics - Graphics - Image 
TonerSaving 

---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 



"Zehler, Peter" <PZehler at crt.xerox.com> 


07/11/2003 04:54 AM 


To
Harry Lewis/Boulder/IBM at IBMUS, "Zehler, Peter" <PZehler at crt.xerox.com> 

cc
"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>,
printing-driver at freestandards.org, printing-jobticket at freestandards.org 

Subject
RE: IPP> Print Quality Issue resolution

	




Harry, 
We felt that there are many different attributes involved in heuristics for
saving toner and printing fast.  Some of those are "resolution", "media" and
aspects of the document content.  We felt the requirements were met by
keeping the existing "print-quality" values and augmenting them with hints
on how to process the document content to achieve 'draft' 'normal' and
'high'.  The assumption is that draft is fastest and uses the least toner. 
Pete 
  

Peter Zehler 
XEROX 
Xerox Innovation Group 
Email: PZehler at crt.xerox.com 
Voice:    (585) 265-8755 
FAX:      (585) 422-7961 
US Mail: Peter Zehler 


        Xerox Corp. 
       800 Phillips Rd. 
       M/S 128-25E 
       Webster NY, 14580-9701 
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com] 
Sent: Thursday, July 10, 2003 11:26 PM
To: Zehler, Peter
Cc: IPP Discussion List (IPP at pwg.org); printing-driver at freestandards.org;
printing-jobticket at freestandards.org
Subject: Re: IPP> Print Quality Issue resolution 
  

> We finally agreed that the two values 'save-toner' and 'speed' are implied
by the "print-quality".  Since they were not required, they were removed. 

I think this warrants further examination. I have known toner saving methods
that do a very good job of preserving print quality. 
---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 





"Zehler, Peter" <PZehler at crt.xerox.com> 
Sent by: owner-ipp at pwg.org 


07/10/2003 01:41 PM 




To
"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>,
printing-jobticket at freestandards.org, printing-driver at freestandards.org 

cc
  

Subject
IPP> Print Quality Issue resolution

  




  	 






All, 

During the PWG/FSG meeting in Portland we had a discussion about the IPP
"print-quality" attribute and FSG's desire to add two new values, 'economy'
and 'fine', where 'economy' is lower than 'draft' and 'fine' is higher than
'high'. The FSG further proposed the addition of a new attribute, called
"print-optimize", that would augment "print-quality" with values of 'image',
'photo', 'text', 'text-and-image', 'save-toner' and 'speed'. 


With regard to 'economy' and 'fine', we agreed that 'economy' would map to
"print-quality"='draft' and 'fine' to "print-quality"='high'.  There may be
end user visible features that map to multiple attributes.  We leave it to
specific print domains to model these higher level aggregate features.  When
appropriate we will add needed elements to the Semantic Model. 


There was a lot of push back on "print-optimize".  The main concern was that
"print-optimize" contained a mixed bag of items.  The two main categories
were content metadata and rendering hints.  We finally agreed that the two
values 'save-toner' and 'speed' are implied by the "print-quality".  Since
they were not required, they were removed.  The remaining values are needed
to direct the type of optimization/processing that will be performed on the
content.  It does not necessarily mean the value describes the content.  To
clarify this we changed the attribute name to "print-content-optimize".
Finally the value 'image' seemed the same as 'photo'.  The name for this was
changed to 'graphic'. 


As a result the following attribute will be added to the JobX specification
in it next revision. 


   print-content-optimize (type2 keyword) 


      This attribute refines the value specified by the print-quality 


      attribute. 


      The standard keyword values are: 


         'graphic': optimize for graphic clarity 


         'photo': optimize for photo clarity 


         'text': optimize for text clarity 


         'text-and-graphic': optimize for both text and graphic clarity 



Peter Zehler 


XEROX 


Xerox Innovation Group 


Email: PZehler at crt.xerox.com 


Voice:    (585) 265-8755 


FAX:      (585) 422-7961 


US Mail: Peter Zehler 


        Xerox Corp. 


        800 Phillips Rd. 


        M/S 128-25E 


        Webster NY, 14580-9701 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030714/61ce9f32/attachment.htm 

From bobt at hp.com  Tue Jul 15 10:21:03 2003
From: bobt at hp.com (TAYLOR,BOB (HP-Vancouver,ex1))
Date: Tue, 15 Jul 2003 10:21:03 -0700
Subject: [printing-driver] RE: IPP> Print Quality Issue resolution
Message-ID: <A134E2426B46D711BB4B000347AE6E7CAA5A74@xvan02.vcd.hp.com>

The trick here is that there are also implementations in the field that do
the same thing with extensions to print quality - e.g.
(Ultra|High|Normal|Draft|EconoFast) {insert any SpinalTap jokes about "my
amp goes to 11" here ;)}.  In other words, PrintQuality is already being
used to provide optimization options between PQ/Saving/Speed.  I don't have
a fundamental issue with declaring *Saving - but the semantics to me are
somewhat duplicative with how PrintQuality is actually used in many
implementations.  I'd also add that, as Harry noted, there are algorithm(s)
"plural" that can save toner/ink/market, so *Saving is probably a
vendor-extensible enumeration, not a boolean - which makes it look yet more
like PrintQuality.
 
bt

-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com] 
Sent: Monday, July 14, 2003 3:05 PM
To: TAYLOR,BOB (HP-Vancouver,ex1)
Cc: IPP Discussion List (IPP at pwg.org); printing-driver at freestandards.org;
printing-jobticket at freestandards.org; Zehler, Peter
Subject: RE: [printing-driver] RE: IPP> Print Quality Issue resolution



>My main question with TonerSaving/InkSaving/MarkerSaving is how this is any
different than PrintQuality(High|Normal|Draft) 
To answer this question, straightforward, there are implementations where
you can select High|Normal|Draft independently from "Saver".  Administrators
may want to configure policy that "Saving" must always be on yet still allow
the choice of High|Normal|Draft, within that context. 

>PrintQuality=High & MarkerSaving=False would seem to say "print in high
quality, and waste toner/ink for no good reason 
I think people would expect: 
 PQ=High|Saving=Off to result in the BEST possible quality. 
 PQ=High|Saving=On to result in the best possible quality while still saving
marker (toner, ink ...) 
 PQ=Draft|Saving=Off to result in the FASTEST possible printing 
 PQ=Draft|Saving=On to result in the fastest possible printing with
legibility that may not stand up to close scrutiny because marker (toner,
ink...) has been used sparingly. 

---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 



"TAYLOR,BOB (HP-Vancouver,ex1)" <bobt at hp.com> 
Sent by: owner-ipp at pwg.org 


07/14/2003 02:36 PM 


To
printing-driver at freestandards.org, "Zehler, Peter" <PZehler at crt.xerox.com> 

cc
"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>,
printing-jobticket at freestandards.org 

Subject
RE: [printing-driver] RE: IPP> Print Quality Issue resolution

	




My main question with TonerSaving/InkSaving/MarkerSaving is how this is any
different than PrintQuality(High|Normal|Draft).  We as well have nifty
algorithms for saving "marker" without impacting quality - but I don't know
why we'd ever want to turn it "off" seperately from the notion of
PQ/performance/economy tradeoff (which I maintain is what PrintQuality
actually is).  The semantics of this as a separate attribute seem somewhat
odd to me - i.e., PrintQuality=High & MarkerSaving=False would seem to say
"print in high quality, and waste toner/ink for no good reason", and
PrintQuality=Draft & MarkerSaving=False would seem to say "print in poor
quality, but waste tone/ink anyway".  IMHO, a "separate" TonerSaving mode is
really a vendor-specific extension of PrintQuality, which as Ira noted as
already supported (though they are supposed to be IANA-registered, which I'm
guessing most vendors have not bothered to do). 
  
thanks, 
  
bt 
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com] 
Sent: Friday, July 11, 2003 6:49 AM
To: Zehler, Peter
Cc: IPP Discussion List (IPP at pwg.org); printing-driver at freestandards.org;
printing-jobticket at freestandards.org; Zehler, Peter
Subject: [printing-driver] RE: IPP> Print Quality Issue resolution


My concern is that "save toner" is probably the most concrete concept
compared to "Good, Better, Best" or "Text, Image, Graphics". The later has
efficient application only in special cases (some of which may be very
significant, like printing photo's). Otherwise, people stare at their mixed
object document and wonder. I feel "save toner" should be explicit. 

We went from a flat set of descriptors to a pairing.. perhaps we should
really go to a matrix (although I don't like the perceived complexity) 

Good - Better - Best 
Text - Text+Graphics - Graphics - Image 
TonerSaving 

---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 


"Zehler, Peter" <PZehler at crt.xerox.com> 


07/11/2003 04:54 AM 




To
Harry Lewis/Boulder/IBM at IBMUS, "Zehler, Peter" <PZehler at crt.xerox.com> 

cc
"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>,
printing-driver at freestandards.org, printing-jobticket at freestandards.org 

Subject
RE: IPP> Print Quality Issue resolution


	





Harry, 
We felt that there are many different attributes involved in heuristics for
saving toner and printing fast.  Some of those are "resolution", "media" and
aspects of the document content.  We felt the requirements were met by
keeping the existing "print-quality" values and augmenting them with hints
on how to process the document content to achieve 'draft' 'normal' and
'high'.  The assumption is that draft is fastest and uses the least toner. 
Pete 
  

Peter Zehler 
XEROX 
Xerox Innovation Group 
Email: PZehler at crt.xerox.com 
Voice:    (585) 265-8755 
FAX:      (585) 422-7961 
US Mail: Peter Zehler 


        Xerox Corp. 
      800 Phillips Rd. 
      M/S 128-25E 
      Webster NY, 14580-9701 
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com] 
Sent: Thursday, July 10, 2003 11:26 PM
To: Zehler, Peter
Cc: IPP Discussion List (IPP at pwg.org); printing-driver at freestandards.org;
printing-jobticket at freestandards.org
Subject: Re: IPP> Print Quality Issue resolution 
 

> We finally agreed that the two values 'save-toner' and 'speed' are implied
by the "print-quality".  Since they were not required, they were removed. 

I think this warrants further examination. I have known toner saving methods
that do a very good job of preserving print quality. 
---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 




"Zehler, Peter" <PZehler at crt.xerox.com> 
Sent by: owner-ipp at pwg.org 


07/10/2003 01:41 PM 




To
"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>,
printing-jobticket at freestandards.org, printing-driver at freestandards.org 

cc
  

Subject
IPP> Print Quality Issue resolution


  




  	 






All, 


During the PWG/FSG meeting in Portland we had a discussion about the IPP
"print-quality" attribute and FSG's desire to add two new values, 'economy'
and 'fine', where 'economy' is lower than 'draft' and 'fine' is higher than
'high'. The FSG further proposed the addition of a new attribute, called
"print-optimize", that would augment "print-quality" with values of 'image',
'photo', 'text', 'text-and-image', 'save-toner' and 'speed'. 


With regard to 'economy' and 'fine', we agreed that 'economy' would map to
"print-quality"='draft' and 'fine' to "print-quality"='high'.  There may be
end user visible features that map to multiple attributes.  We leave it to
specific print domains to model these higher level aggregate features.  When
appropriate we will add needed elements to the Semantic Model. 


There was a lot of push back on "print-optimize".  The main concern was that
"print-optimize" contained a mixed bag of items.  The two main categories
were content metadata and rendering hints.  We finally agreed that the two
values 'save-toner' and 'speed' are implied by the "print-quality".  Since
they were not required, they were removed.  The remaining values are needed
to direct the type of optimization/processing that will be performed on the
content.  It does not necessarily mean the value describes the content.  To
clarify this we changed the attribute name to "print-content-optimize".
Finally the value 'image' seemed the same as 'photo'.  The name for this was
changed to 'graphic'. 


As a result the following attribute will be added to the JobX specification
in it next revision. 


   print-content-optimize (type2 keyword) 


      This attribute refines the value specified by the print-quality 


      attribute. 


      The standard keyword values are: 


         'graphic': optimize for graphic clarity 


         'photo': optimize for photo clarity 


         'text': optimize for text clarity 


         'text-and-graphic': optimize for both text and graphic clarity 


Peter Zehler 


XEROX 


Xerox Innovation Group 


Email: PZehler at crt.xerox.com 


Voice:    (585) 265-8755 


FAX:      (585) 422-7961 


US Mail: Peter Zehler 


        Xerox Corp. 


        800 Phillips Rd. 


        M/S 128-25E 


        Webster NY, 14580-9701 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030715/29ca252a/attachment.htm 

From imcdonald at sharplabs.com  Sat Jul 19 16:38:46 2003
From: imcdonald at sharplabs.com (McDonald, Ira)
Date: Sat, 19 Jul 2003 16:38:46 -0700
Subject: [printing-driver] Mon 21 July - FSG Printing Driver conferenc
	e call
Message-ID: <116DB56CD7DED511BC7800508B2CA53735D0B9@mailsrvnt02.enet.sharplabs.com>

Hi Mark,

Besides the current (FSG Job Ticket) common job property names
and values, there are at least three other obvious choices for
the names/values used by FSG Driver:

(1) IETF/PWG IPP names/values (used by IPP with binary encoding
    and used by PAPI libary with both binary or string encoding)
    - C-style - e.g., "printer-resolution (resolution)"

(2) CIP4 JDF (Job Definition Format) names/values 
    - XML Schema attributes - e.g., "ObjectResolution"

(3) PWG Semantic Model names/values (used by PWG PSI and future
    PWG WBMM [Web-Based Monitoring and Management])
    - XML Schema elements - e.g., "Printer Resolution"


Some background:

(1) IPP attributes are NOT written into a PWG Job Ticket - their
    XML schema equivalent elements from PWG SM are used instead -
    so that both C-style (IPP) and XML-style (PWG SM) properties
    must be consumed by an IPP spooler that supports job tickets.
 
(2) JDF Jobs are highly structured (more than FSG Job Tickets)
    and a 'flat list' mapping of job properties for FSG Driver 
    looks difficult to me, without additional naming rules.  
    NOTE:  The JDF spec uses XML schema attributes (rather than 
    elements), which is an XML modelling error and means that:
    (a) no off-the-shelf tool can convert from instances of JDF 
        schema to instances of PWG schema; and
    (b) the parse-trees are very different (program logic can't
        be efficiently and reasonably shared for JDF and PWG).

(3) PWG SM Jobs are structured (essentially) the same as IPP Jobs,
    with the JobStatus, JobDescription, and JobProcessing element
    groups, which contain (generally) simple, flat elements
    (also optional DocumentDescription and DocumentProcessing
    elements are allowed).
    Note:  The mapping between IPP and PWG SM names and values
    is NOT always strictly algorithmic (i.e., delete hyphens and 
    capitalize each word). 

Talk to you all on Monday.

Cheers,
- Ira McDonald
  High North Inc




-----Original Message-----
From: Mark Hamzy [mailto:hamzy at us.ibm.com]
Sent: Monday, July 14, 2003 2:25 PM
To: printing-driver at freestandards.org
Subject: [printing-driver] Mon 21 July - FSG Printing Driver conference
call






Monday, July 21

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Topics:
Remap common job properties to something.  Redecide what of the new common
job properties are necessary.

Mark

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


_______________________________________________
printing-driver mailing list
printing-driver at freestandards.org
http://freestandards.org/mailman/listinfo/printing-driver



From hamzy at us.ibm.com  Mon Jul 28 07:45:10 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 28 Jul 2003 09:45:10 -0500
Subject: [printing-driver] No FSG Printing Driver meetings for the next two weeks
Message-ID: <OF87FAEE53.F859A892-ON86256D71.0050F374-86256D71.00510A40@us.ibm.com>




There will be no driver meetings for the next two weeks.

Mark

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




From hamzy at us.ibm.com  Mon Aug 18 08:47:40 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 18 Aug 2003 10:47:40 -0500
Subject: [printing-driver] FSG Printing Driver conference call 08/18/03
Message-ID: <OF7A6899EC.30F7A73F-ON86256D86.0056A4D1-86256D86.0056C32C@us.ibm.com>




Monday, August 18

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Mark

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




From imcdonald at sharplabs.com  Mon Aug 18 08:54:20 2003
From: imcdonald at sharplabs.com (McDonald, Ira)
Date: Mon, 18 Aug 2003 08:54:20 -0700
Subject: [printing-driver] Ira unable to attend today
Message-ID: <116DB56CD7DED511BC7800508B2CA537B00163@mailsrvnt02.enet.sharplabs.com>

Hi,

I don't see any announcement of the FSG Printer Driver telecon
today, but I'm out of town for the afternoon, if you have one.

Cheers,
- Ira McDonald
  High North Inc



From hamzy at us.ibm.com  Tue Aug 19 07:46:52 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Tue, 19 Aug 2003 09:46:52 -0500
Subject: [printing-driver] FSG Printing Driver meeting notes 08/18/03
Message-ID: <OF5BBCEDC1.766ED1DD-ON86256D87.005065B5-86256D87.0051320C@us.ibm.com>




Attendees:
Mark Hamzy
Norm Jacobs
Till Kamppeter
Glen Petrie

Till talked about the print dialog in KDE dialog which is a widget.
   paper size
   paper type
   paper tray
   orientation
   nup
   duplex
   resolution

Norm feels that PAPI should be the interface that the applications use to
print.  PAPI will then turn around and send all of the queries to the PDC
library which will then ask the driver.

Here are the list of common job properties that the driver should handle:

manditory
---------
Form
unprintable area
Resolution
Color

recommended
-----------
all media

Otherwise there is a default selection in the common job property and it is
the library's responsibility to handle the driver returning unsupported and
replacing it with the default.

Mark

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




From harryl at us.ibm.com  Mon Jul 14 15:04:31 2003
From: harryl at us.ibm.com (Harry Lewis)
Date: Mon, 14 Jul 2003 16:04:31 -0600
Subject: [printing-driver] RE: IPP> Print Quality Issue resolution
In-Reply-To: <A134E2426B46D711BB4B000347AE6E7CAA5A53@xvan02.vcd.hp.com>
Message-ID: <OF92B2995F.E27CCBA6-ON87256D63.00732C3D-87256D63.00792B19@us.ibm.com>

>My main question with TonerSaving/InkSaving/MarkerSaving is how this is 
any different than PrintQuality(High|Normal|Draft)
To answer this question, straightforward, there are implementations where 
you can select High|Normal|Draft independently from "Saver". 
Administrators may want to configure policy that "Saving" must always be 
on yet still allow the choice of High|Normal|Draft, within that context. 

>PrintQuality=High & MarkerSaving=False would seem to say "print in high 
quality, and waste toner/ink for no good reason
I think people would expect:
 PQ=High|Saving=Off to result in the BEST possible quality. 
 PQ=High|Saving=On to result in the best possible quality while still 
saving marker (toner, ink ...)
 PQ=Draft|Saving=Off to result in the FASTEST possible printing
 PQ=Draft|Saving=On to result in the fastest possible printing with 
legibility that may not stand up to close scrutiny because marker (toner, 
ink...) has been used sparingly. 

---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 



"TAYLOR,BOB (HP-Vancouver,ex1)" <bobt at hp.com> 
Sent by: owner-ipp at pwg.org
07/14/2003 02:36 PM

To
printing-driver at freestandards.org, "Zehler, Peter" <PZehler at crt.xerox.com>
cc
"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>, 
printing-jobticket at freestandards.org
Subject
RE: [printing-driver] RE: IPP> Print Quality Issue resolution






My main question with TonerSaving/InkSaving/MarkerSaving is how this is 
any different than PrintQuality(High|Normal|Draft).  We as well have nifty 
algorithms for saving "marker" without impacting quality - but I don't 
know why we'd ever want to turn it "off" seperately from the notion of 
PQ/performance/economy tradeoff (which I maintain is what PrintQuality 
actually is).  The semantics of this as a separate attribute seem somewhat 
odd to me - i.e., PrintQuality=High & MarkerSaving=False would seem to say 
"print in high quality, and waste toner/ink for no good reason", and 
PrintQuality=Draft & MarkerSaving=False would seem to say "print in poor 
quality, but waste tone/ink anyway".  IMHO, a "separate" TonerSaving mode 
is really a vendor-specific extension of PrintQuality, which as Ira noted 
as already supported (though they are supposed to be IANA-registered, 
which I'm guessing most vendors have not bothered to do).
 
thanks,
 
bt
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com] 
Sent: Friday, July 11, 2003 6:49 AM
To: Zehler, Peter
Cc: IPP Discussion List (IPP at pwg.org); printing-driver at freestandards.org; 
printing-jobticket at freestandards.org; Zehler, Peter
Subject: [printing-driver] RE: IPP> Print Quality Issue resolution


My concern is that "save toner" is probably the most concrete concept 
compared to "Good, Better, Best" or "Text, Image, Graphics". The later has 
efficient application only in special cases (some of which may be very 
significant, like printing photo's). Otherwise, people stare at their 
mixed object document and wonder. I feel "save toner" should be explicit. 

We went from a flat set of descriptors to a pairing.. perhaps we should 
really go to a matrix (although I don't like the perceived complexity) 

Good - Better - Best 
Text - Text+Graphics - Graphics - Image 
TonerSaving 

---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 


"Zehler, Peter" <PZehler at crt.xerox.com> 
07/11/2003 04:54 AM 


To
Harry Lewis/Boulder/IBM at IBMUS, "Zehler, Peter" <PZehler at crt.xerox.com> 
cc
"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>, 
printing-driver at freestandards.org, printing-jobticket at freestandards.org 
Subject
RE: IPP> Print Quality Issue resolution








Harry, 
We felt that there are many different attributes involved in heuristics 
for saving toner and printing fast.  Some of those are "resolution", 
"media" and aspects of the document content.  We felt the requirements 
were met by keeping the existing "print-quality" values and augmenting 
them with hints on how to process the document content to achieve 'draft' 
'normal' and 'high'.  The assumption is that draft is fastest and uses the 
least toner. 
Pete 
  
Peter Zehler 
XEROX 
Xerox Innovation Group 
Email: PZehler at crt.xerox.com 
Voice:    (585) 265-8755 
FAX:      (585) 422-7961 
US Mail: Peter Zehler 
        Xerox Corp. 
       800 Phillips Rd. 
       M/S 128-25E 
       Webster NY, 14580-9701 
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com] 
Sent: Thursday, July 10, 2003 11:26 PM
To: Zehler, Peter
Cc: IPP Discussion List (IPP at pwg.org); printing-driver at freestandards.org; 
printing-jobticket at freestandards.org
Subject: Re: IPP> Print Quality Issue resolution 
  

> We finally agreed that the two values 'save-toner' and 'speed' are 
implied by the "print-quality".  Since they were not required, they were 
removed. 

I think this warrants further examination. I have known toner saving 
methods that do a very good job of preserving print quality. 
---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 

"Zehler, Peter" <PZehler at crt.xerox.com> 
Sent by: owner-ipp at pwg.org 
07/10/2003 01:41 PM 


To
"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>, 
printing-jobticket at freestandards.org, printing-driver at freestandards.org 
cc
  
Subject
IPP> Print Quality Issue resolution

  


  
 





All, 
During the PWG/FSG meeting in Portland we had a discussion about the IPP 
"print-quality" attribute and FSG's desire to add two new values, 
'economy' and 'fine', where 'economy' is lower than 'draft' and 'fine' is 
higher than 'high'. The FSG further proposed the addition of a new 
attribute, called "print-optimize", that would augment "print-quality" 
with values of 'image', 'photo', 'text', 'text-and-image', 'save-toner' 
and 'speed'. 
With regard to 'economy' and 'fine', we agreed that 'economy' would map to 
"print-quality"='draft' and 'fine' to "print-quality"='high'.  There may 
be end user visible features that map to multiple attributes.  We leave it 
to specific print domains to model these higher level aggregate features. 
When appropriate we will add needed elements to the Semantic Model. 
There was a lot of push back on "print-optimize".  The main concern was 
that "print-optimize" contained a mixed bag of items.  The two main 
categories were content metadata and rendering hints.  We finally agreed 
that the two values 'save-toner' and 'speed' are implied by the 
"print-quality".  Since they were not required, they were removed.  The 
remaining values are needed to direct the type of optimization/processing 
that will be performed on the content.  It does not necessarily mean the 
value describes the content.  To clarify this we changed the attribute 
name to "print-content-optimize".  Finally the value 'image' seemed the 
same as 'photo'.  The name for this was changed to 'graphic'. 
As a result the following attribute will be added to the JobX 
specification in it next revision. 
   print-content-optimize (type2 keyword) 
      This attribute refines the value specified by the print-quality 
      attribute. 
      The standard keyword values are: 
         'graphic': optimize for graphic clarity 
         'photo': optimize for photo clarity 
         'text': optimize for text clarity 
         'text-and-graphic': optimize for both text and graphic clarity 
Peter Zehler 
XEROX 
Xerox Innovation Group 
Email: PZehler at crt.xerox.com 
Voice:    (585) 265-8755 
FAX:      (585) 422-7961 
US Mail: Peter Zehler 
        Xerox Corp. 
        800 Phillips Rd. 
        M/S 128-25E 
        Webster NY, 14580-9701 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030714/f19b51c6/attachment.htm 

From harryl at us.ibm.com  Tue Jul 15 15:57:55 2003
From: harryl at us.ibm.com (Harry Lewis)
Date: Tue, 15 Jul 2003 16:57:55 -0600
Subject: [printing-driver] RE: IPP> Print Quality Issue resolution
In-Reply-To: <A134E2426B46D711BB4B000347AE6E7CAA5A74@xvan02.vcd.hp.com>
Message-ID: <OF9FE397A0.83E8BF00-ON87256D64.007DA115-87256D64.007E276B@us.ibm.com>

We don't have to continue this debate. This is a topic where there is no 
right/wrong or even optimal answer. I feel like focusing on flavors of 
print quality only exacerbates the already clouded sales and marketing 
overload of these few tokens whereas "saving money" (essentially) rings 
true enough in enough consumers minds that it deserves highlighting. But, 
we're already so far down the path (of behaving as if there is really 
meaningful and common understanding behind any of these descriptors) that 
I doubt it matters which handful we canonize. So... I'll be the first to 
"give"... so Peter can get on with his job.
---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 



"TAYLOR,BOB (HP-Vancouver,ex1)" <bobt at hp.com> 
Sent by: owner-ipp at pwg.org
07/15/2003 11:21 AM

To
Harry Lewis/Boulder/IBM at IBMUS
cc
"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>, 
printing-driver at freestandards.org, printing-jobticket at freestandards.org, 
"Zehler, Peter" <PZehler at crt.xerox.com>
Subject
RE: [printing-driver] RE: IPP> Print Quality Issue resolution






The trick here is that there are also implementations in the field that do 
the same thing with extensions to print quality - e.g. 
(Ultra|High|Normal|Draft|EconoFast) {insert any SpinalTap jokes about "my 
amp goes to 11" here ;)}.  In other words, PrintQuality is already being 
used to provide optimization options between PQ/Saving/Speed.  I don't 
have a fundamental issue with declaring *Saving - but the semantics to me 
are somewhat duplicative with how PrintQuality is actually used in many 
implementations.  I'd also add that, as Harry noted, there are 
algorithm(s) "plural" that can save toner/ink/market, so *Saving is 
probably a vendor-extensible enumeration, not a boolean - which makes it 
look yet more like PrintQuality.
 
bt
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com] 
Sent: Monday, July 14, 2003 3:05 PM
To: TAYLOR,BOB (HP-Vancouver,ex1)
Cc: IPP Discussion List (IPP at pwg.org); printing-driver at freestandards.org; 
printing-jobticket at freestandards.org; Zehler, Peter
Subject: RE: [printing-driver] RE: IPP> Print Quality Issue resolution


>My main question with TonerSaving/InkSaving/MarkerSaving is how this is 
any different than PrintQuality(High|Normal|Draft) 
To answer this question, straightforward, there are implementations where 
you can select High|Normal|Draft independently from "Saver". 
Administrators may want to configure policy that "Saving" must always be 
on yet still allow the choice of High|Normal|Draft, within that context. 

>PrintQuality=High & MarkerSaving=False would seem to say "print in high 
quality, and waste toner/ink for no good reason 
I think people would expect: 
 PQ=High|Saving=Off to result in the BEST possible quality. 
 PQ=High|Saving=On to result in the best possible quality while still 
saving marker (toner, ink ...) 
 PQ=Draft|Saving=Off to result in the FASTEST possible printing 
 PQ=Draft|Saving=On to result in the fastest possible printing with 
legibility that may not stand up to close scrutiny because marker (toner, 
ink...) has been used sparingly. 

---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 


"TAYLOR,BOB (HP-Vancouver,ex1)" <bobt at hp.com> 
Sent by: owner-ipp at pwg.org 
07/14/2003 02:36 PM 


To
printing-driver at freestandards.org, "Zehler, Peter" <PZehler at crt.xerox.com> 

cc
"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>, 
printing-jobticket at freestandards.org 
Subject
RE: [printing-driver] RE: IPP> Print Quality Issue resolution








My main question with TonerSaving/InkSaving/MarkerSaving is how this is 
any different than PrintQuality(High|Normal|Draft).  We as well have nifty 
algorithms for saving "marker" without impacting quality - but I don't 
know why we'd ever want to turn it "off" seperately from the notion of 
PQ/performance/economy tradeoff (which I maintain is what PrintQuality 
actually is).  The semantics of this as a separate attribute seem somewhat 
odd to me - i.e., PrintQuality=High & MarkerSaving=False would seem to say 
"print in high quality, and waste toner/ink for no good reason", and 
PrintQuality=Draft & MarkerSaving=False would seem to say "print in poor 
quality, but waste tone/ink anyway".  IMHO, a "separate" TonerSaving mode 
is really a vendor-specific extension of PrintQuality, which as Ira noted 
as already supported (though they are supposed to be IANA-registered, 
which I'm guessing most vendors have not bothered to do). 
  
thanks, 
  
bt 
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com] 
Sent: Friday, July 11, 2003 6:49 AM
To: Zehler, Peter
Cc: IPP Discussion List (IPP at pwg.org); printing-driver at freestandards.org; 
printing-jobticket at freestandards.org; Zehler, Peter
Subject: [printing-driver] RE: IPP> Print Quality Issue resolution


My concern is that "save toner" is probably the most concrete concept 
compared to "Good, Better, Best" or "Text, Image, Graphics". The later has 
efficient application only in special cases (some of which may be very 
significant, like printing photo's). Otherwise, people stare at their 
mixed object document and wonder. I feel "save toner" should be explicit. 

We went from a flat set of descriptors to a pairing.. perhaps we should 
really go to a matrix (although I don't like the perceived complexity) 

Good - Better - Best 
Text - Text+Graphics - Graphics - Image 
TonerSaving 

---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 

"Zehler, Peter" <PZehler at crt.xerox.com> 
07/11/2003 04:54 AM 


To
Harry Lewis/Boulder/IBM at IBMUS, "Zehler, Peter" <PZehler at crt.xerox.com> 
cc
"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>, 
printing-driver at freestandards.org, printing-jobticket at freestandards.org 
Subject
RE: IPP> Print Quality Issue resolution










Harry, 
We felt that there are many different attributes involved in heuristics 
for saving toner and printing fast.  Some of those are "resolution", 
"media" and aspects of the document content.  We felt the requirements 
were met by keeping the existing "print-quality" values and augmenting 
them with hints on how to process the document content to achieve 'draft' 
'normal' and 'high'.  The assumption is that draft is fastest and uses the 
least toner. 
Pete 
 
Peter Zehler 
XEROX 
Xerox Innovation Group 
Email: PZehler at crt.xerox.com 
Voice:    (585) 265-8755 
FAX:      (585) 422-7961 
US Mail: Peter Zehler 
        Xerox Corp. 
      800 Phillips Rd. 
      M/S 128-25E 
      Webster NY, 14580-9701 
-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com] 
Sent: Thursday, July 10, 2003 11:26 PM
To: Zehler, Peter
Cc: IPP Discussion List (IPP at pwg.org); printing-driver at freestandards.org; 
printing-jobticket at freestandards.org
Subject: Re: IPP> Print Quality Issue resolution 
 

> We finally agreed that the two values 'save-toner' and 'speed' are 
implied by the "print-quality".  Since they were not required, they were 
removed. 

I think this warrants further examination. I have known toner saving 
methods that do a very good job of preserving print quality. 
---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 

"Zehler, Peter" <PZehler at crt.xerox.com> 
Sent by: owner-ipp at pwg.org 
07/10/2003 01:41 PM 


To
"IPP Discussion List (IPP at pwg.org)" <IPP at pwg.org>, 
printing-jobticket at freestandards.org, printing-driver at freestandards.org 
cc
  
Subject
IPP> Print Quality Issue resolution


 


  
 





All, 
During the PWG/FSG meeting in Portland we had a discussion about the IPP 
"print-quality" attribute and FSG's desire to add two new values, 
'economy' and 'fine', where 'economy' is lower than 'draft' and 'fine' is 
higher than 'high'. The FSG further proposed the addition of a new 
attribute, called "print-optimize", that would augment "print-quality" 
with values of 'image', 'photo', 'text', 'text-and-image', 'save-toner' 
and 'speed'. 
With regard to 'economy' and 'fine', we agreed that 'economy' would map to 
"print-quality"='draft' and 'fine' to "print-quality"='high'.  There may 
be end user visible features that map to multiple attributes.  We leave it 
to specific print domains to model these higher level aggregate features. 
When appropriate we will add needed elements to the Semantic Model. 
There was a lot of push back on "print-optimize".  The main concern was 
that "print-optimize" contained a mixed bag of items.  The two main 
categories were content metadata and rendering hints.  We finally agreed 
that the two values 'save-toner' and 'speed' are implied by the 
"print-quality".  Since they were not required, they were removed.  The 
remaining values are needed to direct the type of optimization/processing 
that will be performed on the content.  It does not necessarily mean the 
value describes the content.  To clarify this we changed the attribute 
name to "print-content-optimize".  Finally the value 'image' seemed the 
same as 'photo'.  The name for this was changed to 'graphic'. 
As a result the following attribute will be added to the JobX 
specification in it next revision. 
   print-content-optimize (type2 keyword) 
      This attribute refines the value specified by the print-quality 
      attribute. 
      The standard keyword values are: 
         'graphic': optimize for graphic clarity 
         'photo': optimize for photo clarity 
         'text': optimize for text clarity 
         'text-and-graphic': optimize for both text and graphic clarity 
Peter Zehler 
XEROX 
Xerox Innovation Group 
Email: PZehler at crt.xerox.com 
Voice:    (585) 265-8755 
FAX:      (585) 422-7961 
US Mail: Peter Zehler 
        Xerox Corp. 
        800 Phillips Rd. 
        M/S 128-25E 
        Webster NY, 14580-9701 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030715/3f36ec7a/attachment.htm 

From imcdonald at sharplabs.com  Sun Aug 24 13:30:47 2003
From: imcdonald at sharplabs.com (McDonald, Ira)
Date: Sun, 24 Aug 2003 13:30:47 -0700
Subject: [printing-driver] Ira missing meeting on Mon 25 Aug
Message-ID: <116DB56CD7DED511BC7800508B2CA537B00177@mailsrvnt02.enet.sharplabs.com>

Hi folks,

I have to go out-of-town tomorrow and talk to a potential client!

Sorry I'll miss the Printing Driver meeting tomorrow.

Cheers,
- Ira McDonald
  High North Inc



From hamzy at us.ibm.com  Mon Aug 25 09:15:23 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 25 Aug 2003 11:15:23 -0500
Subject: [printing-driver] FSG Printing Driver conference call 08/25/03
Message-ID: <OF5AACC0AD.5C2E3472-ON86256D8D.005928D2-86256D8D.00594C8D@us.ibm.com>




Monday, August 25

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Mark

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




From glen.petrie at eitc.epson.com  Mon Aug 25 10:54:29 2003
From: glen.petrie at eitc.epson.com (Glen Petrie)
Date: Mon, 25 Aug 2003 10:54:29 -0700
Subject: [printing-driver] FSG Printing Driver conference call 08/25/03
In-Reply-To: <OF5AACC0AD.5C2E3472-ON86256D8D.005928D2-86256D8D.00594C8D@us.ibm.com>
Message-ID: <003b01c36b31$ef6e0400$11031f8a@GWPLAPTOP>

Our phone system is down today.  I will not be able to call in.

Rgds,
Glen W. Petrie
Manager, Software Printing Solutions
Epson Imaging Technology Center
150 River Oaks Parkway, Suite 200
San Jose, CA, 95134
Voice: 408.576.4131  Fax: 408.474.0511

-----Original Message-----
From: printing-driver-admin at freestandards.org
[mailto:printing-driver-admin at freestandards.org]On Behalf Of Mark Hamzy
Sent: Monday, August 25, 2003 9:15 AM
To: printing-driver at freestandards.org
Subject: [printing-driver] FSG Printing Driver conference call 08/25/03




Monday, August 25

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Mark

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


_______________________________________________
printing-driver mailing list
printing-driver at freestandards.org
http://freestandards.org/mailman/listinfo/printing-driver




From hamzy at us.ibm.com  Thu Aug 28 13:10:05 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Thu, 28 Aug 2003 15:10:05 -0500
Subject: [printing-driver] version 1 of pdc document is available
Message-ID: <OFE6ECCAD9.C0772A00-ON86256D90.006970FE-86256D90.006EC96B@us.ibm.com>




ftp://ftp.pwg.org/pub/pwg/fsg/driver/fsg-PDC-V0-1.pdf
ftp://ftp.pwg.org/pub/pwg/fsg/driver/fsg-PDC-V0-1.sxi

Mark

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




From imcdonald at sharplabs.com  Sun Sep  7 16:46:53 2003
From: imcdonald at sharplabs.com (McDonald, Ira)
Date: Sun, 7 Sep 2003 16:46:53 -0700 
Subject: [printing-driver] Ira missing Driver tomorrow
Message-ID: <116DB56CD7DED511BC7800508B2CA537B00197@mailsrvnt02.enet.sharplabs.com>

Hi,

I have to be out of town all day tomorrow.  Good luck 
with the Printing Driver telecon.

Cheers,
- Ira McDonald
  High North Inc




From hamzy at us.ibm.com  Mon Sep  8 07:48:03 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 8 Sep 2003 09:48:03 -0500
Subject: [printing-driver] FSG Printing Driver conference call 09/08/03
Message-ID: <OF2B5FC61F.C8BB5F2E-ON86256D9B.00512D95-86256D9B.00514DCF@us.ibm.com>




Monday, September 8

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Mark

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




From imcdonald at sharplabs.com  Mon Sep 15 08:03:37 2003
From: imcdonald at sharplabs.com (McDonald, Ira)
Date: Mon, 15 Sep 2003 08:03:37 -0700
Subject: [printing-driver] Missing driver today
Message-ID: <116DB56CD7DED511BC7800508B2CA537B001AF@mailsrvnt02.enet.sharplabs.com>

Hi,

I have to take Nancy for her monthly bee-string allergy shots
(after which, of course, she can't drive).

Good luck this week,
- Ira McDonald



From hamzy at us.ibm.com  Mon Sep 15 08:40:32 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 15 Sep 2003 10:40:32 -0500
Subject: [printing-driver] FSG Printing Driver conference call 09/15/03
Message-ID: <OF0BBD58E0.54475287-ON86256DA2.0056015F-86256DA2.00561C06@us.ibm.com>




Monday, September 15

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Mark

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




From hamzy at us.ibm.com  Mon Sep 15 15:53:10 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 15 Sep 2003 17:53:10 -0500
Subject: [printing-driver] Driver and architecture status on ftp site
Message-ID: <OF6735897F.2F3EB049-ON86256DA2.007D95BA-86256DA2.007DB7B3@us.ibm.com>




They are located in:

ftp://ftp.pwg.org/pub/pwg/fsg/status_reports/

Mark

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




From hamzy at us.ibm.com  Thu Sep 18 13:32:11 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Thu, 18 Sep 2003 15:32:11 -0500
Subject: [printing-driver] FSG Printing Driver conference call 09/22/03
Message-ID: <OF25E0308B.096EBC60-ON86256DA5.006FC0C8-86256DA5.0070CF84@us.ibm.com>




Monday, September 22

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Agenda:
      review latest document
      fill out an outline to flesh out in October.
      make a scheldule until the end of the year.  Note:  I am gone in Oct.

Mark

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




From hamzy at us.ibm.com  Thu Sep 18 13:32:06 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Thu, 18 Sep 2003 15:32:06 -0500
Subject: [printing-driver] New version of driver document on ftp site
Message-ID: <OF762573DF.A89D1F1B-ON86256DA5.00701701-86256DA5.0070CDB9@us.ibm.com>




ftp://ftp.pwg.org/pub/pwg/fsg/driver/fsg-PDC-V02-092203.sxw

Mark

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




From imcdonald at sharplabs.com  Mon Sep 29 10:49:13 2003
From: imcdonald at sharplabs.com (McDonald, Ira)
Date: Mon, 29 Sep 2003 10:49:13 -0700
Subject: [printing-driver] Mon 29 Sept -  Driver call?
Message-ID: <116DB56CD7DED511BC7800508B2CA537B001D3@mailsrvnt02.enet.sharplabs.com>

Hi,

Is there a call today?  I haven't seen any announcement.

Cheers,
- Ira McDonald
  High North Inc


-----Original Message-----
From: Mark Hamzy [mailto:hamzy at us.ibm.com]
Sent: Thursday, September 18, 2003 4:32 PM
To: printing-driver at freestandards.org
Subject: [printing-driver] Mon 22 Sept 2pm EDT - FSG Printing Driver
conference call

Monday, September 22

GMT 18:00
EDT 14:00
CDT 13:00
MDT 12:00
PDT 11:00

Tie Line:    650-3239
Toll Free:   1-800-497-2024
Toll Number: 1-719-457-3821
Passcode:     160458

Agenda:
      review latest document
      fill out an outline to flesh out in October.
      make a scheldule until the end of the year.  Note:  I am gone in Oct.

Mark

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


_______________________________________________
printing-driver mailing list
printing-driver at freestandards.org
http://freestandards.org/mailman/listinfo/printing-driver



From alimpich at us.ibm.com  Fri Oct 10 15:18:35 2003
From: alimpich at us.ibm.com (Claudia Alimpich)
Date: Fri, 10 Oct 2003 16:18:35 -0600
Subject: [printing-driver] Oct Printer Driver status report on pwg site
Message-ID: <OF73712873.F43469EF-ON87256DBB.007A5A4D@us.ibm.com>




I put a copy of the Printer Driver working group status report for October
on the pwg site:
      ftp://ftp.pwg.org/pub/pwg/fsg/status_reports/PD_WG_Status_10Oct2003.txt

Claudia




From hamzy at us.ibm.com  Fri Oct 31 13:56:10 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Fri, 31 Oct 2003 15:56:10 -0600
Subject: [printing-driver] FSG Printing Driver conference call 11/03/03
Message-ID: <OF04462604.A471EF0E-ON86256DD0.0077A011-86256DD0.00787FCC@us.ibm.com>




Monday, November 3

GMT 19:00-21:00
EDT 14:00-16:00
CDT 13:00-15:00
MDT 12:00-14:00
PDT 11:00-13:00

Toll Free: 1-888-206-4960
Tie Line:        650-3080
Passcode:          633661

Note: New number.  Participants must wait until moderator arrives.

Mark

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




From till.kamppeter at gmx.net  Fri Oct 31 13:07:15 2003
From: till.kamppeter at gmx.net (Till Kamppeter)
Date: Fri, 31 Oct 2003 22:07:15 +0100
Subject: [printing-driver] FSG Printing Driver conference call 11/03/03
In-Reply-To: <OF04462604.A471EF0E-ON86256DD0.0077A011-86256DD0.00787FCC@us.ibm.com>
References: <OF04462604.A471EF0E-ON86256DD0.0077A011-86256DD0.00787FCC@us.ibm.com>
Message-ID: <3FA2CF03.4070007@gmx.net>

Mark Hamzy wrote:
> 
> 
> 
> Monday, November 3
> 
> GMT 19:00-21:00
> EDT 14:00-16:00
> CDT 13:00-15:00
> MDT 12:00-14:00
> PDT 11:00-13:00
> 
> Toll Free: 1-888-206-4960
> Tie Line:        650-3080
> Passcode:          633661

Can you also get a normal (no toll-free) phone number, so that I can 
participate from Paris? Thanks.

    Till




From hamzy at us.ibm.com  Mon Nov  3 08:58:53 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 3 Nov 2003 10:58:53 -0600
Subject: [printing-driver] FSG Printing Driver conference call 11/03/03
Message-ID: <OFE2C74DA3.16E70FF9-ON86256DD3.005C167D-86256DD3.005D4859@us.ibm.com>




The toll number is 719 457-3545

Mark

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


                                                                                                                                     
                      Till Kamppeter                                                                                                 
                      <till.kamppeter at gmx.net>            To:       printing-driver at freestandards.org                                
                      Sent by:                            cc:                                                                        
                      printing-driver-admin at freest        Subject:  Re: [printing-driver] FSG Printing Driver conference call        
                      andards.org                          11/03/03                                                                  
                                                                                                                                     
                                                                                                                                     
                      10/31/2003 03:07 PM                                                                                            
                      Please respond to                                                                                              
                      printing-driver                                                                                                
                                                                                                                                     
                                                                                                                                     




Mark Hamzy wrote:
>
>
>
> Monday, November 3
>
> GMT 19:00-21:00
> EDT 14:00-16:00
> CDT 13:00-15:00
> MDT 12:00-14:00
> PDT 11:00-13:00
>
> Toll Free: 1-888-206-4960
> Tie Line:        650-3080
> Passcode:          633661

Can you also get a normal (no toll-free) phone number, so that I can
participate from Paris? Thanks.

    Till


_______________________________________________
printing-driver mailing list
printing-driver at freestandards.org
http://freestandards.org/mailman/listinfo/printing-driver






From hamzy at us.ibm.com  Mon Nov  3 12:23:21 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 3 Nov 2003 14:23:21 -0600
Subject: [printing-driver] Monthly status due this week
Message-ID: <OF99E022A0.7F3F7293-ON86256DD3.006FBD01-86256DD3.00700052@us.ibm.com>




This month's deadline is Friday, November 7.

Please submit your monthly status report that covers work completed,
ongoing
work and planned work.

Mark

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




From hamzy at us.ibm.com  Thu Nov 13 07:52:23 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Thu, 13 Nov 2003 09:52:23 -0600
Subject: [printing-driver] FSG Printing Driver conference call 11/17/03
Message-ID: <OFD6A8C2B1.3EDF33AE-ON86256DDD.00571C15-86256DDD.005731D0@us.ibm.com>




Monday, November 17

GMT 19:00-21:00
EDT 14:00-16:00
CDT 13:00-15:00
MDT 12:00-14:00
PDT 11:00-13:00

Toll Free: 1-888-206-4960
Toll:      1-719-457-3545
Tie Line:        650-3080
Passcode:          633661

Note: New number.  Participants must wait until moderator arrives.

Mark

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




From hamzy at us.ibm.com  Mon Dec  1 13:49:44 2003
From: hamzy at us.ibm.com (Mark Hamzy)
Date: Mon, 1 Dec 2003 15:49:44 -0600
Subject: [printing-driver] Monthly status due this week
Message-ID: <OF5B642841.9FA2EE3E-ON86256DEF.0077D294-86256DEF.0077E8FD@us.ibm.com>




This month's deadline is Friday, December 5.

Please submit your monthly status report that covers work completed,
ongoing
work and planned work.

Mark

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




From rlk at alum.mit.edu  Sat Jan  4 20:13:58 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Sat, 4 Jan 2003 23:13:58 -0500
Subject: [Inkjet-list] ANNOUNCE: Gimp-Print 4.3.7
Message-ID: <200301050413.h054DwBb030246@dsl092-065-009.bos1.dsl.speakeasy.net>

Gimp-Print 4.3.7, released January 4, 2003, is a development release of
this package.

Gimp-Print is a suite of printer drivers that may be used with most
common UNIX print spooling systems, including CUPS, lpr, LPRng, or
others.  These drivers provide high quality printing for UNIX
(including Macintosh OS X 10.2 and newer) and Linux systems in many
cases equal to or better than proprietary vendor-supplied drivers, and
can be used for many of the most demanding printing tasks.

This software includes the Print plug-in for the Gimp, and Ghostscript
and CUPS drivers, including Foomatic data.

The print plugin for the Gimp requires the Gimp 1.2 (later versions of
the Gimp are not supported).

The CUPS driver requires CUPS 1.1.9 or higher.  1.1.14 or above is
highly recommended, as certain translation-related bugs are fixed and
it is possible to print true CMYK.

The IJS-based GhostScript plugin driver requires GNU Ghostscript 6.53
or later, ESP Ghostscript 7.05 or later, or APFL GhostScript 7.04 or
later.

Users of Macintosh OS X 10.2 and above can use this package, as the
printing system is based on CUPS, which is supported by Gimp-print.
Note that Macintosh OS X 10.0 and 10.1 (including 10.1.5) cannot use
this package.

Please read the README file for full instructions on installing this
package.

Gimp-Print 4.3.7 is considered to be an unstable release, as more
significant API changes have been introduced with relatively limited
testing.  While most of the changes improve the clarity of the code,
the limited testing and extensive nature of the changes suggests that
this release is likely to be quite unstable.  We recommend that only
people who want access to these new API features for development use
this release.  There are very significant user-visible changes over
earlier 4.3 releases, and few changes over the 4.2 stable line.

Gimp-Print 4.3.7 contains the following major changes over Gimp-Print
4.3.6:

1) Further internal API changes.  Please see
   include/gimp-print/gimp-print.h, and the various header files in
   src/main, for details.  There will be significant further changes,
   particularly in the color code.  The API is considerably more
   consistent than before.

2) Parameters are now stored as variables within stp_vars_t, rather
   than as fixed fields.  This change is largely transparent at the
   API level, but it marks an important advance.

3) The Gimp Print plugin has been split into a GTK-based library
   (libgimpprintui) and the actual Print plugin.  The libgimpprintui
   code permits creating print panels for other applications, or
   standalone graphical print utilities, all using the same user
   interface.

   In addition, the thumbnail preview mechanism has been changed to
   use the stp_image_t API rather than to make direct calls to the
   color machinery.  This was done by creating a new family driver
   (print-raw.c) and by creating a new stp_image_t implementation for
   thumbnail creation.  This removed the only reason to export the
   color API, and will permit us to simplify the very complex color
   API.  This work is currently in progress.

   To simplify coding while avoiding an unnecessary dependency, some
   widgets have been borrowed from libgimp.

   The two files comprising the Gimp plugin proper total less than 900
   lines of code, out of about 60,000 lines total in the core library,
   UI library, and Print plugin.

   This work is not complete; support for multiple pages still needs
   to be added, for example.  However, there should be a sufficient
   base to permit interested developers to experiment.

   A very desirable project that someone may wish to undertake is to
   write a ghostscript front end (or extension to ghostview or gv)
   that uses this UI library.  This would create a full-featured
   graphical printing application.

4) Many parameters for Epson printer control, dither matrix control,
   and HSL adjustment have been exported as settable parameters.
   While currently no Gimp-print applications provide access to these
   controls, they are available for developer use.  Please read the
   code to see where they are made available.  This is a work in
   progress; expect major changes in the future.

5) A new header file, gimp-print-version.h, has been created to store
   the autogen-time versioning information.

6) The Gimp Print plugin now uses g_message to deliver error messages
   to pop-ups rather than to stderr.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From raph.levien at artifex.com  Tue Jan  7 02:25:40 2003
From: raph.levien at artifex.com (Raph Levien)
Date: Tue, 7 Jan 2003 02:25:40 -0800
Subject: [Inkjet-list] Notes towards an IJS 1.0 protocol rev
Message-ID: <20030107102540.GC21299@casper.ghostscript.com>

Inkjetters,

   The IJS spec has been relatively stable at 0.34 for some time.
Since it seems to be useful in a number of applications, I think it's
a good time to do some minor cleanups and push to a 1.0 version.

   Glen Petrie and his team at Epson have provided some good feedback,
including good suggestions for new features. I'll summarize these, and
also solicit other suggestions for much-needed new features or
clarifications of the spec language. Then, I'll post some diffs for
the spec in a few days.

1. FD's for running the protocol

   The current IJS spec uses stdin and stdout as hardwired channels to
run the protocol. I've been thinking about other ways to run the
protocol, including domain sockets (useful for persistent demons), and
of course various network sockets. However, there are numerous cans of
worms, including security and authentication, and I don't see the
infrastructure as being mature enough to support expansion in this
direction. For people who do want to wrangle with these issues,
there's also IPP in the protocol space.

   Even so, stdin and stdout can be limiting. In particular, they make
these channels unavailable for the server (driver) itself.

   Thus, Glen has proposed, and I agree, that we should be able to
specify alternate FD's for the IJS protocol, on the command line
invoking the server. For detailed syntax, see point 2 below.

   Note that FD's are basically a Unix-ism, although as I understand
it you can use them without too much trouble in Win32 as well (please
correct me if I'm wrong). Fortunately, their use is optional, so can
be ignored on systems that simply do not support them.

2. Command line options.

   Currently, the command line is empty. There are a few things that
would be reasonable to put on the command line, including FD's as
above.

   Glen proposes a simple syntax, which I would like to adapt slightly
as follows:

   ijssrv
   ijssrv -f <client to server fd>,<server to client fd>
   ijssrv -v
   ijssrv -h

   The first syntax (no arguments) behaves as now - the IJS protocol
runs on stdin and stdout.

   The second syntax specifies numeric fd's. Thus, -f 0,1 is
equivalent to no arguments.

   The -v option prints out version information in a stylized format:

IJS server info:
<name of server> <version of server>
IJS protocol version <n>.<mm>

   An optional fourth line consists of:

For more info, see: <url>

   Additional lines are reserved for future extension. Version 1.00
clients are expected to ignore any lines not matching the above
template. In particular, it seems like a lightweight and transparent
way to discover IJS version numbers.

   The -h option prints out a help message, in a human-readable
format. In general, clients aren't expected to parse -h output,
although it's perfectly reasonable to display it in a dialog box,
primarily for troubleshooting purposes.

   This "info" mechanism on the command line is actually a reasonable
path for servers to provide UI information to clients, but we're not
actually doing any of that for 1.00.

3. Clarification of extension namespaces.

   I realize that the language regarding who owns which bits of
namespace is fairly vague. I'd like to clarify that so that people can
move forward with their own extensions without fear of conflict.

   Extension namespaces are designed for parameters specific to a
given driver, or family of drivers. In general, clients should
discover available extensions through the IJS_CMD_LIST_PARAMS command.
There are a number of scenarios for clients to "know" what to do with
extension parameters. For example, it could be a customized client
integrated as part of a larger system including known servers. A
general-purpose client could attempt to track known extensions, which
of course puts the burden on server authors to publish those. Finally,
there could be some UI mechanism for the driver to tell the client in
detail what all those fiddly extensions mean. Such a mechanism is
beyond the scope of the IJS protocol, but of course I still hope
somebody manages to do it.

   In general, the extension name should be the name of the driver. In
the case of manufacturer-supplied drivers, it should be the
manufacturer.  For example, if the STP project added a feature to
drive printer motors in sync with a techno soundtrack, a reasonable
name for the parameter is "STP:BeatBox".

   Each such project in effect owns its slice of parameter namespace,
and has considerable latitude what to do with it, including any of the
following options:

a. Keep it secret, so that only customized clients can use it.

b. Make the parameters known, but reserve the right to change them, so
clients basically use them at their own risk.

c. Publish the parameters so that clients can freely use them, but not
encourage other servers to use the same parameter.

d. Publish it as a "first-class" parameter, with good documentation
and change control, so that both clients and servers can use it
with confidence.

   Any such parameter in this last class is of course a good candidate
for being added to the core IJS spec, but it could just as well stay
in the "extension" namespace if there's a feeling it's being well
managed there.

   I'll give another hypothetical example. HP could decide to publish
a parameter for controlling the blue LED present in many of their
models. Obviously, you'd expect HP's own drivers to implement this
parameter, but it would be reasonable for other drivers to do so as
well. A reasonable name would then be "HP:BlueLED", even for drivers
other than the HP-supplied ones.

   It is of course considered unfriendly for a server to implement a
parameter in somebody else's extension namespace without their
blessing.

   Does this clarify the use of extension namespaces enough? It seems
to me that they should be a generally useful technique for dealing
with the profusion of options provided by modern devices.

4. Standardization of Quality parameters

   The 0.34 spec states that individual drivers manage the Quality:
namespace in any way they see fit. This is good for flexibility, but
not so helpful for clients who just want to present a set of
reasonable options. Thus, I think it would be good for 1.00 to
standardize _some_ parameters within this namespace, while allowing
drivers to use other Quality: parameters as they see fit, for even
more fiddly control.

Glen suggests:

Quality:Quality           --> Normal, Draft, High, Photo
Quality:PenSet            --> CMYK, CcMmYK, CcMmYyK, CMY, K
Quality:MediaType         --> PlainMedia, PhotoMedia, TransMedia

   In general, a client should be able to throw any of these settings to
the server without having to do the parameter enumeration dance.
However, a server is free to implement more values in the enumeration,
as reported through IJS_CMD_ENUM_PARAM. For example, a client who
enumerates Quality:Quality might discover a "Highest" value as well.

   If a specific value is not supported, the server should choose some
reasonable default.

   Notes: I'm pretty unsure about the standard values for PenSet. This
seems like something that wouldn't actually be useful without querying
the printer. This is as opposed to the other two parameters, which
seem pretty generally useful across all inkjet (and many non-inkjet)
printers. Also, drop the "Media" suffix? It's already clear that it's
a MediaType. There are lots of cool puns, though. A ream of assorted
papers could be "MixedMedia", and of course printable flags for the
Indianapolis 500 races are "IndyMedia".

   These parameters in particular sound like they need agreement from
the various driver projects. Comments are welcome.

   Comments are welcome about all these suggestions. In general, I'm
trying clean up existing usage, so that code in the field won't have
to be changed much, if at all. In particular, Ghostscript will
probably support both 0.34 and 1.00 versions for some time.

   Thanks again to Glen Petrie of Epson for input, and apologies to
all for taking so long.

Raph




From rlk at alum.mit.edu  Tue Jan  7 04:12:24 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Tue, 7 Jan 2003 07:12:24 -0500
Subject: [Inkjet-list] Notes towards an IJS 1.0 protocol rev
In-Reply-To: <20030107102540.GC21299@casper.ghostscript.com>
	(raph.levien@artifex.com)
References: <20030107102540.GC21299@casper.ghostscript.com>
Message-ID: <200301071212.h07CCOI4009182@dsl092-065-009.bos1.dsl.speakeasy.net>

I'm likely to have some comments on this, based on work we're doing
on Gimp-print 4.3.  I'll try to get to those over the next few days.



From mike at easysw.com  Tue Jan  7 05:48:32 2003
From: mike at easysw.com (Michael Sweet)
Date: Tue, 07 Jan 2003 08:48:32 -0500
Subject: [Inkjet-list] Notes towards an IJS 1.0 protocol rev
In-Reply-To: <20030107102540.GC21299@casper.ghostscript.com>
References: <20030107102540.GC21299@casper.ghostscript.com>
Message-ID: <3E1ADAB0.7030601@easysw.com>

Raph Levien wrote:
> ...
> Glen suggests:
> 
> Quality:Quality           --> Normal, Draft, High, Photo

Good

> Quality:PenSet            --> CMYK, CcMmYK, CcMmYyK, CMY, K

Also CcMmYKk (current EPSON 7-color printers provide light black)
and (why not) CcMmYyKk for a hypothetical 8-color printer.

However, it might be more useful to define three standard
pen sets: Grayscale, Color, Photo, which would cover 99% of
the usage.

> Quality:MediaType         --> PlainMedia, PhotoMedia, TransMedia

I've never been a fan of this - MediaType is a valid Adobe
page device attribute, dispite the fact that Ghostscript insists
upon using the InputAttributes dictionary even when a driver has
no easy way of populating it...  ESP Ghostscript includes a
run-time option that allows MediaType and other attributes to be
used...

FWIW, the "standard" names are: Plain, Special, Glossy, and
Transparency, corresponding to PlainMedia, CoatedMedia (missing
from your list), PhotoMedia, and TransMedia respectively.

Also, if you look at some of the IPP "media-col" attributes,
the media selection can be quite a bit more detailed - photo
media might be matte, semi-gloss, or glossy, for example, and
there is normal and heavy weight paper, etc.  The names I've
listed above only cover the basics but map well to HP and EPSON
printer media type selection.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com






From gsview at ghostgum.com.au  Tue Jan  7 12:54:21 2003
From: gsview at ghostgum.com.au (Russell Lang)
Date: Wed, 08 Jan 2003 07:54:21 +1100
Subject: [Inkjet-list] Notes towards an IJS 1.0 protocol rev
In-Reply-To: <20030107102540.GC21299@casper.ghostscript.com>
Message-ID: <3E1BD92D.10355.5CD36A3C@localhost>

Raph,

> 1. FD's for running the protocol
> 
>    Thus, Glen has proposed, and I agree, that we should be able to
> specify alternate FD's for the IJS protocol, on the command line
> invoking the server. For detailed syntax, see point 2 below.
> 
>    Note that FD's are basically a Unix-ism, although as I understand
> it you can use them without too much trouble in Win32 as well (please
> correct me if I'm wrong). Fortunately, their use is optional, so can
> be ignored on systems that simply do not support them.

Yes, it can be implemented on Windows, and isn't much more 
complex than the current ijs_exec_win.c.

> 2. Command line options.
>    ijssrv
>    ijssrv -f <client to server fd>,<server to client fd>
> 
>    The first syntax (no arguments) behaves as now - the IJS protocol
> runs on stdin and stdout.
> 
>    The second syntax specifies numeric fd's. Thus, -f 0,1 is
> equivalent to no arguments.

So the numeric values are treated as unsigned integers the same 
size as a pointer.  For Windows they would be an OS handle, not 
a C RTL handle.  -f 0,1 would not be equivalent to no arguments 
on Windows.

Russell Lang                   gsview at ghostgum.com.au
Ghostgum Software Pty Ltd      http://www.ghostgum.com.au/





From david.suffield at hp.com  Tue Jan  7 17:31:19 2003
From: david.suffield at hp.com (SUFFIELD,DAVID (HP-Vancouver,ex1))
Date: Tue, 7 Jan 2003 20:31:19 -0500 
Subject: [Inkjet-list] Notes towards an IJS 1.0 protocol rev
Message-ID: <6D805D4C4567D411AF32009027B683510CA45B49@xvan02.vcd.hp.com>

> 4. Standardization of Quality parameters
> 
>    The 0.34 spec states that individual drivers manage the Quality:
> namespace in any way they see fit. This is good for flexibility, but
> not so helpful for clients who just want to present a set of
> reasonable options. Thus, I think it would be good for 1.00 to
> standardize _some_ parameters within this namespace, while allowing
> drivers to use other Quality: parameters as they see fit, for even
> more fiddly control.
> 
> Glen suggests:
> 
> Quality:Quality           --> Normal, Draft, High, Photo
> Quality:PenSet            --> CMYK, CcMmYK, CcMmYyK, CMY, K
> Quality:MediaType         --> PlainMedia, PhotoMedia, TransMedia
> 
>    In general, a client should be able to throw any of these 
> settings to
> the server without having to do the parameter enumeration dance.
> However, a server is free to implement more values in the enumeration,
> as reported through IJS_CMD_ENUM_PARAM. For example, a client who
> enumerates Quality:Quality might discover a "Highest" value as well.
> 
>    If a specific value is not supported, the server should choose some
> reasonable default.
> 
>    Notes: I'm pretty unsure about the standard values for PenSet. This
> seems like something that wouldn't actually be useful without querying
> the printer. This is as opposed to the other two parameters, which
> seem pretty generally useful across all inkjet (and many non-inkjet)
> printers. Also, drop the "Media" suffix? It's already clear that it's
> a MediaType. There are lots of cool puns, though. A ream of assorted
> papers could be "MixedMedia", and of course printable flags for the
> Indianapolis 500 races are "IndyMedia".
> 
>    These parameters in particular sound like they need agreement from
> the various driver projects. Comments are welcome.

I don't think you are going to get consensus on common Quality parameters. I
prefer the IJS 0.34 method where the driver manufacture controls the
namespace parameters. HPIJS currently uses numeric values for Quality
parameters (ie: Quality:Quality=n where 0=normal, 1=draft, 2=best and
3=hires)

I believe Till Kamppeter's foomatic composite options accomplishes the same
goal here. In foomatic 2.9.1 composite options make Quality settings more
user friendly with generalized options like "Draft", "Normal", "High
Quality", and "Photo".

-dave




From rlk at alum.mit.edu  Tue Jan  7 19:21:23 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Tue, 7 Jan 2003 22:21:23 -0500
Subject: [Inkjet-list] Notes towards an IJS 1.0 protocol rev
In-Reply-To: <20030107102540.GC21299@casper.ghostscript.com>
	(raph.levien@artifex.com)
References: <20030107102540.GC21299@casper.ghostscript.com>
Message-ID: <200301080321.h083LNmv014762@dsl092-065-009.bos1.dsl.speakeasy.net>

   Date: Tue, 7 Jan 2003 02:25:40 -0800
   From: Raph Levien <raph.levien at artifex.com>

   1. FD's for running the protocol

      The current IJS spec uses stdin and stdout as hardwired channels to
   run the protocol. I've been thinking about other ways to run the
   protocol, including domain sockets (useful for persistent demons), and
   of course various network sockets. However, there are numerous cans of
   worms, including security and authentication, and I don't see the
   infrastructure as being mature enough to support expansion in this
   direction. For people who do want to wrangle with these issues,
   there's also IPP in the protocol space.

I'm concerned about the security issues here, although in a somewhat
different way, namely for acquisition of driver metadata.  In
particular, 4.4 or 5.0 is going to have much richer metadata,
including "curves" and "raw" parameters, which can't very practically
be passed on the Ghostscript command line.  We're quite feasibly
talking in the range of 10-1000 KB of data for advanced applications.

As an example of use of raw parameters, these could be used to pass
profiles that are opaque to Gimp-print.  Curves can be used for many
(very obvious) purposes.

A very useful service that IJS could provide is a secure file open
service (i. e. the IJS client provides ownership checking and such).

      Even so, stdin and stdout can be limiting. In particular, they make
   these channels unavailable for the server (driver) itself.

I'd be curious to see a use case for this; under what circumstances
would the driver use stdin or stdout for any purpose other than data
transmission?

   2. Command line options.

      Currently, the command line is empty. There are a few things that
   would be reasonable to put on the command line, including FD's as
   above.

      Glen proposes a simple syntax, which I would like to adapt slightly
   as follows:

      ijssrv
      ijssrv -f <client to server fd>,<server to client fd>
      ijssrv -v
      ijssrv -h

      The first syntax (no arguments) behaves as now - the IJS protocol
   runs on stdin and stdout.

      The second syntax specifies numeric fd's. Thus, -f 0,1 is
   equivalent to no arguments.

      The -v option prints out version information in a stylized format:

   IJS server info:
   <name of server> <version of server>
   IJS protocol version <n>.<mm>

      An optional fourth line consists of:

   For more info, see: <url>

      Additional lines are reserved for future extension. Version 1.00
   clients are expected to ignore any lines not matching the above
   template. In particular, it seems like a lightweight and transparent
   way to discover IJS version numbers.

      The -h option prints out a help message, in a human-readable
   format. In general, clients aren't expected to parse -h output,
   although it's perfectly reasonable to display it in a dialog box,
   primarily for troubleshooting purposes.

      This "info" mechanism on the command line is actually a reasonable
   path for servers to provide UI information to clients, but we're not
   actually doing any of that for 1.00.

This sounds good.

   3. Clarification of extension namespaces.

      I realize that the language regarding who owns which bits of
   namespace is fairly vague. I'd like to clarify that so that people can
   move forward with their own extensions without fear of conflict.

Something near and dear to my heart.  I'm including Roger Leigh, who's
leading a lot of the Gimp-print architecture work.

      Extension namespaces are designed for parameters specific to a
   given driver, or family of drivers. In general, clients should
   discover available extensions through the IJS_CMD_LIST_PARAMS command.
   There are a number of scenarios for clients to "know" what to do with
   extension parameters. For example, it could be a customized client
   integrated as part of a larger system including known servers. A
   general-purpose client could attempt to track known extensions, which
   of course puts the burden on server authors to publish those. Finally,
   there could be some UI mechanism for the driver to tell the client in
   detail what all those fiddly extensions mean. Such a mechanism is
   beyond the scope of the IJS protocol, but of course I still hope
   somebody manages to do it.

The Gimp-print 4.3 mainline has a generalized parameter mechanism that
does UI hinting, data typing, etc.  You may want to take a look at
that.  We also have curve, list, string list, and parameter list
abstractions (parameter list is "derived" from the base list type;
string list is separate, but we'll eventually derive that from the
base list type).  We'll probably also have a vector and at least a 2-d
matrix type derived from the curve base type.  I'm not going to
include the gimp-print.h header file here (it's about 36k); I'll be
happy to send it to anyone interested.

One concern I have is about parameters all being static.  Gimp-print
has a very rich parameter space, and it's going to get richer
(although most of the parameters are marked "advanced" at various
levels).  The availability of parameters depends upon what printer,
color module, and dither module is in use.  A Gimp-print client can
query the list of available parameters with the current choice of
settings, and ask for a description of the parameters (the default
value and bounds; for a string list parameter, for example, the
"bounds" consists of a list of the valid values that the parameter may
take on).  It's not possible at stp_init time to enumerate all of the
different parameters that may be available.  Conceivably we could load
all available modules, and query each <thing> for the list of
available parameters, but that seems excessive.

Perhaps we need a wildcard, e. g. accept "Gimp-Print:*", and the
driver's responsible for sorting it out.

      In general, the extension name should be the name of the driver. In
   the case of manufacturer-supplied drivers, it should be the
   manufacturer.  For example, if the STP project added a feature to
   drive printer motors in sync with a techno soundtrack, a reasonable
   name for the parameter is "STP:BeatBox".

      Each such project in effect owns its slice of parameter namespace,
   and has considerable latitude what to do with it, including any of the
   following options:

   a. Keep it secret, so that only customized clients can use it.

   b. Make the parameters known, but reserve the right to change them, so
   clients basically use them at their own risk.

   c. Publish the parameters so that clients can freely use them, but not
   encourage other servers to use the same parameter.

   d. Publish it as a "first-class" parameter, with good documentation
   and change control, so that both clients and servers can use it
   with confidence.

I suspect that Gimp-print is headed in this direction, too.

      Any such parameter in this last class is of course a good candidate
   for being added to the core IJS spec, but it could just as well stay
   in the "extension" namespace if there's a feeling it's being well
   managed there.

      I'll give another hypothetical example. HP could decide to publish
   a parameter for controlling the blue LED present in many of their
   models. Obviously, you'd expect HP's own drivers to implement this
   parameter, but it would be reasonable for other drivers to do so as
   well. A reasonable name would then be "HP:BlueLED", even for drivers
   other than the HP-supplied ones.

      It is of course considered unfriendly for a server to implement a
   parameter in somebody else's extension namespace without their
   blessing.

      Does this clarify the use of extension namespaces enough? It seems
   to me that they should be a generally useful technique for dealing
   with the profusion of options provided by modern devices.

   4. Standardization of Quality parameters

      The 0.34 spec states that individual drivers manage the Quality:
   namespace in any way they see fit. This is good for flexibility, but
   not so helpful for clients who just want to present a set of
   reasonable options. Thus, I think it would be good for 1.00 to
   standardize _some_ parameters within this namespace, while allowing
   drivers to use other Quality: parameters as they see fit, for even
   more fiddly control.

   Glen suggests:

   Quality:Quality           --> Normal, Draft, High, Photo
   Quality:PenSet            --> CMYK, CcMmYK, CcMmYyK, CMY, K
   Quality:MediaType         --> PlainMedia, PhotoMedia, TransMedia

This is an interesting idea.  We're currently using Quality very
differently, but this is a lot more structure.  I'm not sure that I
think of media type as being part of a quality setting per se, though;
that's a matter of whatever paper the user puts into the printer.

      In general, a client should be able to throw any of these settings to
   the server without having to do the parameter enumeration dance.
   However, a server is free to implement more values in the enumeration,
   as reported through IJS_CMD_ENUM_PARAM. For example, a client who
   enumerates Quality:Quality might discover a "Highest" value as well.

      If a specific value is not supported, the server should choose some
   reasonable default.

      Notes: I'm pretty unsure about the standard values for PenSet. This
   seems like something that wouldn't actually be useful without querying
   the printer. This is as opposed to the other two parameters, which
   seem pretty generally useful across all inkjet (and many non-inkjet)
   printers. Also, drop the "Media" suffix? It's already clear that it's
   a MediaType. There are lots of cool puns, though. A ream of assorted
   papers could be "MixedMedia", and of course printable flags for the
   Indianapolis 500 races are "IndyMedia".

We're currently using the name "Ink Type" for what amounts to PenSet.
This is probably wrong; InkType should probably refer to "OEM Epson
inks", "UltraChrome", "UltraChrome + Matte Black", "Pigment",
"Photographic Dye", "Lyson Small Gamut", and PenType should refer to
"CMYK" (or "Four Color Standard"), CcMmYK ("Six Color Photo"), CcMmYy
("Six Color Composite"), Quadtone, and what have you.

      These parameters in particular sound like they need agreement from
   the various driver projects. Comments are welcome.

This sounds fine and dandy to me.

      Comments are welcome about all these suggestions. In general, I'm
   trying clean up existing usage, so that code in the field won't have
   to be changed much, if at all. In particular, Ghostscript will
   probably support both 0.34 and 1.00 versions for some time.

      Thanks again to Glen Petrie of Epson for input, and apologies to
   all for taking so long.

   Raph


   _______________________________________________
   Inkjet-list mailing list
   Inkjet-list at linuxprinting.org
   http://www.linuxprinting.org/cgi-bin/mailman/listinfo/inkjet-list




From glen.petrie at eitc.epson.com  Thu Jan  9 07:41:06 2003
From: glen.petrie at eitc.epson.com (Glen Petrie)
Date: Thu, 9 Jan 2003 07:41:06 -0800
Subject: [Inkjet-list] Notes towards an IJS 1.0 protocol rev
In-Reply-To: <20030107102540.GC21299@casper.ghostscript.com>
Message-ID: <004f01c2b7f5$86fb93a0$26031f8a@GWPLAPTOP>

I would like to support Michael Sweet's addition of the 8-color penset.
For Michael Sweet's suggestions for media naming I think my original naming
could drop the "media" at the end of each type but I favor the type "photo"
versus "glossy".  As to the media type "special";  I think this is not
specific enough and the other three media type cover 99% of the case.  The
"special" should be vendor extension.

Rgds,
Glen W. Petrie
Manager, Software Printing Solutions
Epson Imaging Technology Center
150 River Oaks Parkway, Suite 200
San Jose, CA, 95134
Voice: 408.576.4131  Fax: 408.474.0511

-----Original Message-----
From: inkjet-list-admin at linuxprinting.org
[mailto:inkjet-list-admin at linuxprinting.org]On Behalf Of Raph Levien
Sent: Tuesday, January 07, 2003 2:26 AM
To: inkjet-list at linuxprinting.org
Subject: [Inkjet-list] Notes towards an IJS 1.0 protocol rev

Inkjetters, . . . .






From vikink2003 at yahoo.com  Fri Jan 17 09:01:25 2003
From: vikink2003 at yahoo.com (Vikink Vikink)
Date: Fri, 17 Jan 2003 09:01:25 -0800 (PST)
Subject: [Inkjet-list] Inkjet Head Cleaner
Message-ID: <20030117170125.53588.qmail@web14810.mail.yahoo.com>


 
Dear Madam/Sir, 

We are the manufacturer of the new and improved Ink-jet Head Cleaner: VIKINK?. 
VIKINK? is a powerful cleaner to open clogged cartridges and inkjet printheads. 
It breaks down dry ink easily and will not damage copper and plastics parts. 
VIKINK? opens the cartridges even waited for a long time. 
VIKINK? has been tested and approved by many end users and refillers. 
You can get further technical details in VIKINK? web site: http://www.vikink.com 
VIKINK? is sold in 25 ml plastic bottles. 
In case of interest, sample available. 
Looking forward for your reply. 
Best Regards, 

- 


 

Murat GURDOV

SEHA Ltd. Co.
Address: Mebusevleri, Ayten Sk., 27/2
Tandogan 06580 Ankara
TURKEY

Tel: + 90 312 215 7500 (Pbx)

Fax: + 90 312 215 7515, 223 4978, 212 8763




---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030117/df41dc16/attachment.htm 

From roger at whinlatter.uklinux.net  Sun Jan 19 14:16:49 2003
From: roger at whinlatter.uklinux.net (Roger Leigh)
Date: 19 Jan 2003 22:16:49 +0000
Subject: [Inkjet-list] Notes towards an IJS 1.0 protocol rev
In-Reply-To: <20030107102540.GC21299@casper.ghostscript.com>
References: <20030107102540.GC21299@casper.ghostscript.com>
Message-ID: <878yxgokdq.fsf@whinlatter.uklinux.net>

Raph Levien <raph.levien at artifex.com> writes:

> Inkjetters,
> 
>    The IJS spec has been relatively stable at 0.34 for some time.
> Since it seems to be useful in a number of applications, I think it's
> a good time to do some minor cleanups and push to a 1.0 version.

Will the IJS_VERSION protocol version number remain (VERSION * 100)?

I can't personally see any good reason why the wire protocol need bear
any relation to the release version number (and after 1.00 it's going
to get awfully big rather fast).


Another question is packaging.  The Debian version at

http://packages.debian.org/cgi-bin/search_packages.pl?keywords=ijs&searchon=names&subword=1&version=all&release=all

includes the necessary framework for proper library SONAME versioning
of libijs.  Would you like a patch to include this support for proper?
If you have a look at the binary package page, there's a link for the
.diff.gz part of the Debian source, which includes this, as well as
some extra Debian stuff (which should be kept separate).

Proper library versioning needs doing upstream, since the version
should be identical for ABI compatibility across distributions--so I
can't do this myself just for Debian.  I'm currently making a
libijs-0.3.4.so, but the name changes each release, breaking binary
compatibility.  A libijs.so.x.y.x would make things much better.


Regards,
Roger

-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers



From roger at whinlatter.uklinux.net  Sun Jan 19 15:04:10 2003
From: roger at whinlatter.uklinux.net (Roger Leigh)
Date: 19 Jan 2003 23:04:10 +0000
Subject: [Inkjet-list] Notes towards an IJS 1.0 protocol rev
In-Reply-To: <878yxgokdq.fsf@whinlatter.uklinux.net>
References: <20030107102540.GC21299@casper.ghostscript.com>
	<878yxgokdq.fsf@whinlatter.uklinux.net>
Message-ID: <87d6msn3md.fsf@whinlatter.uklinux.net>

Roger Leigh <roger at whinlatter.uklinux.net> writes:

> Another question is packaging.  The Debian version at
> 
> http://packages.debian.org/cgi-bin/search_packages.pl?keywords=ijs&searchon=names&subword=1&version=all&release=all

Sorry, it's actually

http://packages.debian.org/unstable/libs/libijs-0.34.html

and the diff against ijs-0.34 is at

http://ftp.debian.org/debian/pool/main/i/ijs/ijs_0.34-1.diff.gz


-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers



From rlk at alum.mit.edu  Sat Jan 25 17:21:54 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Sat, 25 Jan 2003 20:21:54 -0500
Subject: [Inkjet-list] IJS question
Message-ID: <200301260121.h0Q1LsJi022214@dsl092-065-009.bos1.dsl.speakeasy.net>

Is it possible for the page characteristics in a job (from
ijs_server_get_page_header()) to differ from page to page?

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From rlk at alum.mit.edu  Sun Jan 26 19:10:10 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Sun, 26 Jan 2003 22:10:10 -0500
Subject: [Inkjet-list] ANNOUNCE: Gimp-Print 4.3.8 (unstable development)
Message-ID: <200301270310.h0R3AAhm017699@dsl092-065-009.bos1.dsl.speakeasy.net>

Gimp-Print 4.3.8, released January 26, 2003, is a development release of
this package.

Gimp-Print is a suite of printer drivers that may be used with most
common UNIX print spooling systems, including CUPS, lpr, LPRng, or
others.  These drivers provide high quality printing for UNIX
(including Macintosh OS X 10.2 and newer) and Linux systems in many
cases equal to or better than proprietary vendor-supplied drivers, and
can be used for many of the most demanding printing tasks.

This software includes the Print plug-in for the Gimp, and Ghostscript
and CUPS drivers, including Foomatic data.

The print plugin for the Gimp requires the Gimp 1.2 (later versions of
the Gimp are not supported).

The CUPS driver requires CUPS 1.1.9 or higher.  1.1.14 or above is
highly recommended, as certain translation-related bugs are fixed and
it is possible to print true CMYK.

The IJS-based GhostScript plugin driver requires GNU Ghostscript 6.53
or later, ESP Ghostscript 7.05 or later, or APFL GhostScript 7.04 or
later.

Users of Macintosh OS X 10.2 and above can use this package, as the
printing system is based on CUPS, which is supported by Gimp-print.
Note that Macintosh OS X 10.0 and 10.1 (including 10.1.5) cannot use
this package.

Please read the README file for full instructions on installing this
package.

Gimp-Print 4.3.8 is considered to be an unstable release, as more
significant API changes have been introduced with relatively limited
testing.  While most of the changes improve the clarity of the code,
the limited testing and extensive nature of the changes suggests that
this release is likely to be quite unstable.  We recommend that only
people who want access to these new API features for development use
this release.  There are very significant user-visible changes over
earlier 4.3 releases, and few changes over the 4.2 stable line.

Gimp-Print 4.3.8 contains the following major changes over Gimp-Print
4.3.7:

1) Gimp-print now loads printer family drivers as modules, rather than
   building them in monolithically.  The net effect is that if you do
   not wish to run make install (i. e. you want to run programs out of
   the build tree), you must set the STP_MODULE_PATH environment
   variable to the directory (or search path) containing the loadable
   modules.  This is usually .../src/main or ...src/main/.libs.

   Other key components (color and dither algorithms) will be
   similarly modularized in the future.  This is an intermediate
   step.

2) Gimp-print now loads printer and paper size definitions, and dither
   matrices, from XML data files.  The net effect is that if you do
   not wish to run make install (i. e. you want to run programs out of
   the build tree), you must set the STP_DATA_PATH environmet variable
   to the directory (or search path) containing the XML files and
   dither matrices (.mat files).  This is usually .../src/main.

   Removing the dither matrices from the source code has resulted in a
   significant reduction in shared object size.

   Other key components and individual modules will define XML schemas
   in the future.

3) The color module now offers many new parameters for color
   adjustment, a few of which are reflected in the GUI (Gimp plugin).
   These parameters include density adjustments in addition to gamma
   adjustments for each channel, curves for each channel, GCR bounds
   and curves, and more.  Taking advantage of this currently requires
   programming skill; we *strongly* urge anyone interested in color
   management with a modicum of programming skill to take a look at
   this.

4) Each different processing module (color, dither, and printer) now
   offers its own parameters.

5) The stp_list_t type is no longer exported in gimp-print.h.  It is
   used internally in various ways; some of those (such as parameter
   lists) are exported.  However, the base type is considered an
   internal utility.

6) All internal symbols (not exported in gimp-print.h) that are
   exported for use within the core library are now prefixed with
   "stpi_" rather than "stp_".

7) CMYK generation from CMY (gray component reduction) is now handled
   within the color code rather than within the dither code.  In the
   future, we expect to move subchannel generation (photo and quadtone
   inksets, for example) into the color code, at least as an option.
   This will enable the dither code to make more intelligent choices
   about dot size selection, and simplify matters for people who want
   to experiment with their own inksets and transfer functions.

8) Density is now processed within the dither algorithms, rather than
   within the color code.  This simplifies color generation somewhat,
   and more accurately reflects the fact that density is a property of
   the resolution and paper type.

9) The dither code in general has been significantly reorganized; each
   algorithm has been split out into a file of its own.  This is a
   possible first step toward modularization of the dither code.

10) As a result of a number of the internal changes, the print quality
   has overall regressed slightly and performance has probably
   regressed significantly.  This is temporary; it is a result of
   getting things working in the environment of rapid change, and
   tuning wil occur later.

11) Valgrind has been used to detect some memory leaks and other
   errors.

12) There have been numerous other API changes.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From gsview at ghostgum.com.au  Mon Jan 27 01:45:57 2003
From: gsview at ghostgum.com.au (Russell Lang)
Date: Mon, 27 Jan 2003 20:45:57 +1100
Subject: [Inkjet-list] IJS question
In-Reply-To: <200301260121.h0Q1LsJi022214@dsl092-065-009.bos1.dsl.speakeasy.net>
Message-ID: <3E359A85.20523.C16D4B77@localhost>

Robert,

> Is it possible for the page characteristics in a job (from
> ijs_server_get_page_header()) to differ from page to page?

Since IjsPageHeader contains the width and height of the page, 
the answer is yes.  The page size can change from page to page 
when set by setpagedevice.  I think resolution is also allowed 
to change.  Some other items like bps (bits per sample) and 
n_chan (number of channels) are not allowed to change (at least 
not in Ghostscript which prevents BitsPerPixel from changing 
after the device is open).


Russell Lang                   gsview at ghostgum.com.au
Ghostgum Software Pty Ltd      http://www.ghostgum.com.au/





From rlk at alum.mit.edu  Mon Jan 27 03:37:21 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Mon, 27 Jan 2003 06:37:21 -0500
Subject: [Inkjet-list] IJS question
In-Reply-To: <3E359A85.20523.C16D4B77@localhost> (gsview@ghostgum.com.au)
References: <3E359A85.20523.C16D4B77@localhost>
Message-ID: <200301271137.h0RBbLdb021189@dsl092-065-009.bos1.dsl.speakeasy.net>

   From: "Russell Lang" <gsview at ghostgum.com.au>
   Date: Mon, 27 Jan 2003 20:45:57 +1100
   CC: inkjet-list at linuxprinting.org

   Robert,

   > Is it possible for the page characteristics in a job (from
   > ijs_server_get_page_header()) to differ from page to page?

   Since IjsPageHeader contains the width and height of the page, the
   answer is yes.  The page size can change from page to page when set
   by setpagedevice.  I think resolution is also allowed to change.
   Some other items like bps (bits per sample) and n_chan (number of
   channels) are not allowed to change (at least not in Ghostscript
   which prevents BitsPerPixel from changing after the device is
   open).

Thanks.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From mike at easysw.com  Mon Jan 27 05:44:19 2003
From: mike at easysw.com (Michael Sweet)
Date: Mon, 27 Jan 2003 08:44:19 -0500
Subject: [Inkjet-list] IJS question
In-Reply-To: <3E359A85.20523.C16D4B77@localhost>
References: <3E359A85.20523.C16D4B77@localhost>
Message-ID: <3E3537B3.4000003@easysw.com>

Russell Lang wrote:
> Robert,
> 
> 
>>Is it possible for the page characteristics in a job (from
>>ijs_server_get_page_header()) to differ from page to page?
> 
> 
> Since IjsPageHeader contains the width and height of the page, 
> the answer is yes.  The page size can change from page to page 
> when set by setpagedevice.  I think resolution is also allowed 
> to change.  Some other items like bps (bits per sample) and 
> n_chan (number of channels) are not allowed to change (at least 
> not in Ghostscript which prevents BitsPerPixel from changing 
> after the device is open).

Actually, this isn't true; the CUPS driver for Ghostscript can
change BitsPerPixel (actually for the CUPS driver it's
cupsBitsPerColor that changes) on-the-fly; it is only gdevprn.c
that doesn't check for a change in image depth.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com






From jgardiazabal at yahoo.com  Wed Jan 29 13:40:58 2003
From: jgardiazabal at yahoo.com (=?iso-8859-1?q?Jos=E9=20Gardiazabal?=)
Date: Wed, 29 Jan 2003 15:40:58 -0600 (CST)
Subject: [Inkjet-list] Problems with ijs
Message-ID: <20030129214058.67133.qmail@web40609.mail.yahoo.com>

Hello,
I'm writing because I've got a problem trying to
compile ijs under Solaris Sparc (8 and 9). I'm not
able to compile ijs, and I tried with gcc 2.95, 3.2.0
and 3.2.1. If you know why I'm having this problems,
please write me.
The make message is written at the end of the mail.

Thanks,

Jose Gardiazabal.


bash-2.03# make
gcc -g -Wall -ansi -pedantic -Wmissing-prototypes   -c
-o ijs.o ijs.c
gcc -g -Wall -ansi -pedantic -Wmissing-prototypes   -c
-o ijs_client.o 
ijs_client.c
gcc -g -Wall -ansi -pedantic -Wmissing-prototypes   -c
-o ijs_server.o 
ijs_server.c
gcc -g -Wall -ansi -pedantic -Wmissing-prototypes   -c
-o 
ijs_exec_unix.o ijs_exec_unix.c
rm -f libijs.a
ar qc libijs.a ijs.o ijs_client.o ijs_server.o
ijs_exec_unix.o
ranlib libijs.a
gcc -shared ijs.o ijs_client.o ijs_server.o
ijs_exec_unix.o -o 
libijs.so
Text relocation remains                        
referenced
    against symbol                  offset      in
file
ijs_recv_ack                        0x414      
ijs_client.o
ijs_recv_ack                        0x50c      
ijs_client.o
ijs_recv_ack                        0x6c8      
ijs_client.o
ijs_recv_ack                        0x804      
ijs_client.o
ijs_recv_ack                        0x9a4      
ijs_client.o
ijs_recv_ack                        0xa98      
ijs_client.o
ijs_send_block                      0x798      
ijs_client.o
ijs_send_block                      0x8f4      
ijs_client.o
ijs_send_block                      0x934      
ijs_client.o
ijs_send_block                      0xa2c      
ijs_client.o
ijs_send_block                      0xd20      
ijs_server.o
ijs_send_block                      0x1000     
ijs_server.o
ijs_send_block                      0x1ce0     
ijs_server.o
ijs_send_buf                        0x3bc      
ijs_client.o
ijs_send_buf                        0x484      
ijs_server.o
ijs_send_buf                        0x558      
ijs_server.o
ijs_send_buf                        0x6a4      
ijs_server.o
ijs_send_buf                        0xb38      
ijs_server.o
ijs_send_buf                        0xd7c      
ijs_server.o
ijs_send_buf                        0x105c     
ijs_server.o
ijs_send_buf                        0x1d3c     
ijs_server.o
write                               0x2c8       ijs.o
write                               0x148      
ijs_client.o
write                               0x4cc      
ijs_client.o
write                               0x124      
ijs_server.o
ijs_send_begin                      0x354      
ijs_client.o
ijs_send_begin                      0x44c      
ijs_server.o
ijs_send_begin                      0x4e4      
ijs_server.o
ijs_send_begin                      0x630      
ijs_server.o
ijs_send_begin                      0xac4      
ijs_server.o
ijs_send_begin                      0xcb4      
ijs_server.o
ijs_send_begin                      0xf94      
ijs_server.o
ijs_send_begin                      0x1c74     
ijs_server.o
memcpy                              0x23c       ijs.o
memcpy                              0x7d8       ijs.o
memcpy                              0x7c       
ijs_server.o
memcpy                              0x12b0     
ijs_server.o
memcpy                              0x14b4     
ijs_server.o
memcpy                              0x2408     
ijs_server.o
ijs_recv_block                      0x710      
ijs_client.o
ijs_recv_block                      0x84c      
ijs_client.o
ijs_recv_block                      0xae0      
ijs_client.o
ijs_recv_int                        0x288      
ijs_client.o
ijs_recv_int                        0x5c8      
ijs_server.o
ijs_recv_int                        0x748      
ijs_server.o
ijs_recv_int                        0x810      
ijs_server.o
ijs_recv_int                        0x8e8      
ijs_server.o
ijs_recv_int                        0x9c0      
ijs_server.o
ijs_recv_int                        0xb80      
ijs_server.o
ijs_recv_int                        0xdc4      
ijs_server.o
ijs_recv_int                        0x1824     
ijs_server.o
ijs_recv_int                        0x18c4     
ijs_server.o
ijs_recv_int                        0x1ac8     
ijs_server.o
ijs_recv_int                        0x1eb0     
ijs_server.o
ijs_recv_int                        0x1f78     
ijs_server.o
ijs_send_init                       0x110      
ijs_client.o
ijs_send_init                       0xc0       
ijs_server.o
ijs_get_int                         0x50c       ijs.o
ijs_get_int                         0x634       ijs.o
ijs_get_int                         0x688       ijs.o
ijs_get_int                         0x714       ijs.o
ijs_get_int                         0x2240     
ijs_server.o
ijs_recv_init                       0x130      
ijs_client.o
ijs_recv_init                       0xa8       
ijs_server.o
ijs_recv_buf                        0x60c       ijs.o
ijs_recv_buf                        0x2200     
ijs_server.o
ijs_recv_read                       0x4d8       ijs.o
ijs_recv_read                       0x5ac       ijs.o
ijs_recv_read                       0x1e4c     
ijs_server.o
ijs_send_int                        0x190       ijs.o
ijs_send_int                        0x228      
ijs_client.o
ijs_send_int                        0x38c      
ijs_client.o
ijs_send_int                        0x46c      
ijs_client.o
ijs_send_int                        0x484      
ijs_client.o
ijs_send_int                        0x5cc      
ijs_client.o
ijs_send_int                        0x620      
ijs_client.o
ijs_send_int                        0x67c      
ijs_client.o
ijs_send_int                        0x77c      
ijs_client.o
ijs_send_int                        0x8b8      
ijs_client.o
ijs_send_int                        0x8d8      
ijs_client.o
ijs_send_int                        0xa10      
ijs_client.o
ijs_send_int                        0xb30      
ijs_client.o
ijs_send_int                        0xb84      
ijs_client.o
ijs_send_int                        0x520      
ijs_server.o
ijs_send_int                        0x66c      
ijs_server.o
ijs_send_int                        0xb00      
ijs_server.o
read                                0x418       ijs.o
read                                0x194      
ijs_client.o
read                                0xe4       
ijs_server.o
<unknown>                           0x8        
ijs_client.o
<unknown>                           0xc        
ijs_client.o
<unknown>                           0x50       
ijs_client.o
<unknown>                           0x54       
ijs_client.o
strlen                              0x750      
ijs_client.o
strlen                              0x88c      
ijs_client.o
strlen                              0x9e4      
ijs_client.o
ijs_exec_server                     0xb4       
ijs_client.o
ijs_client_send_cmd                 0x3e4      
ijs_client.o
ijs_client_send_cmd                 0x490      
ijs_client.o
ijs_client_send_cmd                 0x688      
ijs_client.o
ijs_client_send_cmd                 0x7c4      
ijs_client.o
ijs_client_send_cmd                 0x964      
ijs_client.o
ijs_client_send_cmd                 0xa58      
ijs_client.o
memcmp                              0x1bc      
ijs_client.o
ijs_client_send_cmd_wait            0x250      
ijs_client.o
ijs_client_send_cmd_wait            0x54c      
ijs_client.o
ijs_client_send_cmd_wait            0x584      
ijs_client.o
ijs_client_send_cmd_wait            0x5d8      
ijs_client.o
ijs_client_send_cmd_wait            0x62c      
ijs_client.o
ijs_client_send_cmd_wait            0xb3c      
ijs_client.o
ijs_client_send_cmd_wait            0xb90      
ijs_client.o
close                               0x2f0      
ijs_client.o
close                               0x308      
ijs_client.o
close                               0x5c       
ijs_exec_unix.o
close                               0x68       
ijs_exec_unix.o
close                               0x9c       
ijs_exec_unix.o
close                               0xa8       
ijs_exec_unix.o
close                               0xb4       
ijs_exec_unix.o
close                               0xc0       
ijs_exec_unix.o
close                               0xec       
ijs_exec_unix.o
close                               0xf8       
ijs_exec_unix.o
close                               0x1f8      
ijs_exec_unix.o
close                               0x204      
ijs_exec_unix.o
malloc                              0xdc       
ijs_client.o
malloc                              0x5c       
ijs_server.o
malloc                              0x2098     
ijs_server.o
free                                0x314      
ijs_client.o
free                                0x4b8      
ijs_server.o
free                                0x247c     
ijs_server.o
ijs_client_begin_cmd                0x1f4      
ijs_client.o
ijs_client_begin_cmd                0x454      
ijs_client.o
ijs_client_begin_cmd                0x540      
ijs_client.o
ijs_client_begin_cmd                0x578      
ijs_client.o
ijs_client_begin_cmd                0x5b4      
ijs_client.o
ijs_client_begin_cmd                0x608      
ijs_client.o
ijs_client_begin_cmd                0x664      
ijs_client.o
ijs_client_begin_cmd                0x764      
ijs_client.o
ijs_client_begin_cmd                0x8a0      
ijs_client.o
ijs_client_begin_cmd                0x9f8      
ijs_client.o
ijs_client_begin_cmd                0xb18      
ijs_client.o
ijs_client_begin_cmd                0xb6c      
ijs_client.o
<unknown>                           0x1b4      
ijs_server.o
<unknown>                           0x1b8      
ijs_server.o
<unknown>                           0x1cc      
ijs_server.o
<unknown>                           0x1d0      
ijs_server.o
<unknown>                           0x70       
ijs_server.o
<unknown>                           0x74       
ijs_server.o
<unknown>                           0x1334     
ijs_server.o
<unknown>                           0x1338     
ijs_server.o
<unknown>                           0x13c4     
ijs_server.o
<unknown>                           0x13c8     
ijs_server.o
<unknown>                           0x1458     
ijs_server.o
<unknown>                           0x145c     
ijs_server.o
<unknown>                           0x1514     
ijs_server.o
<unknown>                           0x1518     
ijs_server.o
<unknown>                           0x15a8     
ijs_server.o
<unknown>                           0x15ac     
ijs_server.o
<unknown>                           0x163c     
ijs_server.o
<unknown>                           0x1640     
ijs_server.o
ijs_server_procs                    0x2280     
ijs_server.o
ijs_server_procs                    0x2284     
ijs_server.o
strtod                              0x12cc     
ijs_server.o
strcmp                              0x133c     
ijs_server.o
strcmp                              0x13cc     
ijs_server.o
strcmp                              0x1460     
ijs_server.o
strcmp                              0x151c     
ijs_server.o
strcmp                              0x15b0     
ijs_server.o
strcmp                              0x1644     
ijs_server.o
ijs_server_iter                     0x22ec     
ijs_server.o
ijs_server_iter                     0x2534     
ijs_server.o
ijs_server_done                     0x204      
ijs_server.o
<unknown>                           0x134      
ijs_exec_unix.o
<unknown>                           0x138      
ijs_exec_unix.o
<unknown>                           0x15c      
ijs_exec_unix.o
<unknown>                           0x160      
ijs_exec_unix.o
exit                                0x1dc      
ijs_exec_unix.o
dup2                                0x108      
ijs_exec_unix.o
dup2                                0x118      
ijs_exec_unix.o
pipe                                0x1c       
ijs_exec_unix.o
pipe                                0x44       
ijs_exec_unix.o
fork                                0x7c       
ijs_exec_unix.o
execvp                              0x1bc      
ijs_exec_unix.o
signal                              0x1ec      
ijs_exec_unix.o
ld: fatal: relocations remain against allocatable but
non-writable 
sections
collect2: ld returned 1 exit status
make: *** [libijs.so] Error 1

_________________________________________________________
Do You Yahoo!?
Informaci?n de Estados Unidos y Am?rica Latina, en Yahoo! Noticias.
Vis?tanos en http://noticias.espanol.yahoo.com



From gsview at ghostgum.com.au  Wed Jan 29 22:48:25 2003
From: gsview at ghostgum.com.au (Russell Lang)
Date: Thu, 30 Jan 2003 17:48:25 +1100
Subject: [Inkjet-list] Problems with ijs
In-Reply-To: <20030129214058.67133.qmail@web40609.mail.yahoo.com>
Message-ID: <3E396569.19885.D041A107@localhost>

Jos?

> I'm writing because I've got a problem trying to
> compile ijs under Solaris Sparc (8 and 9). I'm not
> able to compile ijs, and I tried with gcc 2.95, 3.2.0
> and 3.2.1. If you know why I'm having this problems,
> please write me.
> The make message is written at the end of the mail.

> gcc -shared ijs.o ijs_client.o ijs_server.o
> ijs_exec_unix.o -o 
> libijs.so
> Text relocation remains                        
> referenced
>     against symbol                  offset      in
> file

If building a shared object, you should use -fPIC to produce 
position independent code.  I don't know if this is your 
problem.  

Russell Lang                   gsview at ghostgum.com.au
Ghostgum Software Pty Ltd      http://www.ghostgum.com.au/





From roger at whinlatter.uklinux.net  Thu Jan 30 12:46:01 2003
From: roger at whinlatter.uklinux.net (Roger Leigh)
Date: 30 Jan 2003 20:46:01 +0000
Subject: [Inkjet-list] Problems with ijs
In-Reply-To: <3E396569.19885.D041A107@localhost>
References: <3E396569.19885.D041A107@localhost>
Message-ID: <8765s61i46.fsf@whinlatter.uklinux.net>

"Russell Lang" <gsview at ghostgum.com.au> writes:

> > I'm writing because I've got a problem trying to
> > compile ijs under Solaris Sparc (8 and 9). I'm not
> > able to compile ijs, and I tried with gcc 2.95, 3.2.0
> > and 3.2.1.

> > gcc -shared ijs.o ijs_client.o ijs_server.o
> > ijs_exec_unix.o -o 
> > libijs.so
> > Text relocation remains
> > referenced
> >     against symbol                  offset      in
> > file
> 
> If building a shared object, you should use -fPIC to produce 
> position independent code.  I don't know if this is your 
> problem.

If you download

ftp://ftp.debian.org/debian/pool/main/i/ijs/ijs_0.34-1.diff.gz

and apply this to the unpacked ijs 0.34 tarball
(gunzip -cd ijs_0.34-1.diff.gz | patch -p1), then libtool will be used
to compile and link the library.  This should know the correct
compiler and linker flags.


-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers



From dsuffiel at dsufflnx.vcd.hp.com  Thu Feb  6 17:36:52 2003
From: dsuffiel at dsufflnx.vcd.hp.com (David Suffield)
Date: Thu, 06 Feb 2003 17:36:52 -0800
Subject: [Inkjet-list] HP Inkjet Linux Driver 1.3.1 Release
Message-ID: <3E430DB4.70308@dsufflnx.vcd.hp.com>

This HP Inkjet Linux Driver (HPIJS) release has the following changes.

1. Added data compression to DJ3320.

2. Changed the default black pen vertical alignment value for the DJ3320.

3. Added support for custom paper size.

4. Removed 3425-COVER paper size, this is now a custom paper size.

5. Added Printable Area documentation.

6. Fixed a Officejet hang problem (ie: Officejet 500/600/700 and PSC 
300). The Officejet would hang after printing a job.

See hpinkjet.sourceforge.net and the hpijs_readme.html file for more 
information.





From rlk at alum.mit.edu  Sat Feb 22 10:50:33 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Sat, 22 Feb 2003 13:50:33 -0500
Subject: [Inkjet-list] IJS and Gimp-print
Message-ID: <200302221850.h1MIoXqc013226@dsl092-065-009.bos1.dsl.speakeasy.net>

I've put some code into IJS to handle the all the options that
Gimp-print 4.3 offers (it actually iterates over all of the printers
and generates a list of all of the options, to hand back in list_cb).
The two main issues are:

1) Foomatic doesn't handle all this stuff.  Till, you may want to look
   into it.  The right thing is not to hard code the options, but to
   query the library for the available options and generate the
   appropriate XML from that.  Note that not all printers handle all
   options.

2) It requires glib, for a hash table of all of the options (for
   efficiency).

The use of glib is tightly contained, and is not fundamental here;
it's a convenience.  We can always replace it with something else
(direct string manipulation or whatnot), if use of glib here is going
to impede anything.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From gsview at ghostgum.com.au  Sat Feb 22 13:26:22 2003
From: gsview at ghostgum.com.au (Russell Lang)
Date: Sun, 23 Feb 2003 08:26:22 +1100
Subject: [Inkjet-list] IJS and Gimp-print
In-Reply-To: <200302221850.h1MIoXqc013226@dsl092-065-009.bos1.dsl.speakeasy.net>
Message-ID: <3E5885AE.21386.35E9E33F@localhost>

Robert,

> I've put some code into IJS to handle the all the options that
> Gimp-print 4.3 offers (it actually iterates over all of the printers
> and generates a list of all of the options, to hand back in list_cb).
> The two main issues are:
>  ...
> 
> 2) It requires glib, for a hash table of all of the options (for
>    efficiency).
> 
> The use of glib is tightly contained, and is not fundamental here;
> it's a convenience.  We can always replace it with something else
> (direct string manipulation or whatnot), if use of glib here is going
> to impede anything.

I have compiled a previous version of gimp-print on Windows.  I 
was intending at some stage to compile the gimp-print ijs server 
on Windows.  Requiring glib would make that more difficult.

Russell Lang                   gsview at ghostgum.com.au
Ghostgum Software Pty Ltd      http://www.ghostgum.com.au/





From rlk at alum.mit.edu  Sat Feb 22 13:34:51 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Sat, 22 Feb 2003 16:34:51 -0500
Subject: [Inkjet-list] IJS and Gimp-print
In-Reply-To: <3E5885AE.21386.35E9E33F@localhost> (gsview@ghostgum.com.au)
References: <3E5885AE.21386.35E9E33F@localhost>
Message-ID: <200302222134.h1MLYpG4014169@dsl092-065-009.bos1.dsl.speakeasy.net>

   From: "Russell Lang" <gsview at ghostgum.com.au>
   Date: Sun, 23 Feb 2003 08:26:22 +1100

   Robert,

   > I've put some code into IJS to handle the all the options that
   > Gimp-print 4.3 offers (it actually iterates over all of the printers
   > and generates a list of all of the options, to hand back in list_cb).
   > The two main issues are:
   >  ...
   > 
   > 2) It requires glib, for a hash table of all of the options (for
   >    efficiency).
   > 
   > The use of glib is tightly contained, and is not fundamental here;
   > it's a convenience.  We can always replace it with something else
   > (direct string manipulation or whatnot), if use of glib here is going
   > to impede anything.

   I have compiled a previous version of gimp-print on Windows.  I 
   was intending at some stage to compile the gimp-print ijs server 
   on Windows.  Requiring glib would make that more difficult.

That's good to know.  This is certainly something we can work around,
but I'm glad to know up front.  This isn't in 4.2, so it shouldn't
interfere with what you're doing, but I'll remove the glib stuff at
some point.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From roger at whinlatter.uklinux.net  Mon Mar  3 07:22:04 2003
From: roger at whinlatter.uklinux.net (Roger Leigh)
Date: 03 Mar 2003 15:22:04 +0000
Subject: [Inkjet-list] OKI MICROLINE 321 Elite (9-pin printer)
Message-ID: <87d6l8zd9f.fsf@whinlatter.uklinux.net>

It's not an inkjet, but has anyone any knowledge of this printer?
I've recently got an old one of these, and I can't even get it to
print ASCII text.  It's a wide-format printer for up to 14" continuous
stationary, and it weighs half a ton!

It has a front panel with SEL [on-line], MODE, LF (GROUP), FF (ITEM), PARK
(SET) and TOF/QUIET (PRINT) buttons.  By pressing MODE, the functions
in parentheses become available, and the settings are printed out on
the printer as you navigate and set the options.  There are also Print
Quality and Char Pitch buttons.

Although there's no problem with the printed menu/options, when I do

echo "abcdefghiklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ" >
/dev/lp0

all I get is:

bdfhkmoqsuwy02468ACEGIKMOQSUWY

It's only printing every alternate character! (you can see I missed
`j'.)

I set it to use UNIX linefeeds, Char Set `I', Code Page `USA' and
Language Set `ASCII' (I don't have a manual to know what the
differences are, or what Char Set II might be).  There was also a
"Print Suppress Effective" option, but didn't have any effect set to
either `Yes' or `No'.

The printer is quite old, and so it might be broken, rather than
incorrectly set-up.  Could a broken Centronics interface produce this
effect?


Thanks,
Roger

-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers



From mike at easysw.com  Mon Mar  3 08:02:40 2003
From: mike at easysw.com (Michael Sweet)
Date: Mon, 03 Mar 2003 11:02:40 -0500
Subject: [Inkjet-list] OKI MICROLINE 321 Elite (9-pin printer)
In-Reply-To: <87d6l8zd9f.fsf@whinlatter.uklinux.net>
References: <87d6l8zd9f.fsf@whinlatter.uklinux.net>
Message-ID: <3E637CA0.6050904@easysw.com>

Roger Leigh wrote:
> It's not an inkjet, but has anyone any knowledge of this printer?
> I've recently got an old one of these, and I can't even get it to
> print ASCII text.  It's a wide-format printer for up to 14" continuous
> stationary, and it weighs half a ton!
> ...

(OKI still makes these...)

Have you tried the OKIDATA 9-pin driver included with CUPS?  Also,
have you tried a different parallel cable?

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com






From till.kamppeter at gmx.net  Mon Mar  3 08:53:34 2003
From: till.kamppeter at gmx.net (Till Kamppeter)
Date: Mon, 03 Mar 2003 17:53:34 +0100
Subject: [Inkjet-list] OKI MICROLINE 321 Elite (9-pin printer)
References: <87d6l8zd9f.fsf@whinlatter.uklinux.net> <3E637CA0.6050904@easysw.com>
Message-ID: <3E63888E.5000306@gmx.net>

Michael Sweet wrote:
> Roger Leigh wrote:
> 
>> It's not an inkjet, but has anyone any knowledge of this printer?
>> I've recently got an old one of these, and I can't even get it to
>> print ASCII text.  It's a wide-format printer for up to 14" continuous
>> stationary, and it weighs half a ton!
>> ...
> 
> 
> (OKI still makes these...)
> 
> Have you tried the OKIDATA 9-pin driver included with CUPS?  Also,
> have you tried a different parallel cable?
> 

On can probably switch this printer between IBM-ProPrinter-compatible 
and Epson-ESC/P-compatible by dip switches or by the front panel 
buttons. I don't know for which emulation mode is the CUPS driver which 
Mike recommended, there are also GhostScript drivers for both modes: 
"okiibm" and "epson". So there are at least three drivers for printing 
PostScript and images (where probably the CUPS driver is the easiest to 
configure, assuming that your spooler is CUPS). For printing plain text 
without converting it to PostScript,  you should use the printer in 
Epson emulation mode, there you have pronably the most common control 
sequences.

    Till




From till.kamppeter at gmx.net  Mon Mar  3 08:53:34 2003
From: till.kamppeter at gmx.net (Till Kamppeter)
Date: Mon, 03 Mar 2003 17:53:34 +0100
Subject: [Inkjet-list] OKI MICROLINE 321 Elite (9-pin printer)
References: <87d6l8zd9f.fsf@whinlatter.uklinux.net> <3E637CA0.6050904@easysw.com>
Message-ID: <3E63888E.5000306@gmx.net>

Michael Sweet wrote:
> Roger Leigh wrote:
> 
>> It's not an inkjet, but has anyone any knowledge of this printer?
>> I've recently got an old one of these, and I can't even get it to
>> print ASCII text.  It's a wide-format printer for up to 14" continuous
>> stationary, and it weighs half a ton!
>> ...
> 
> 
> (OKI still makes these...)
> 
> Have you tried the OKIDATA 9-pin driver included with CUPS?  Also,
> have you tried a different parallel cable?
> 

On can probably switch this printer between IBM-ProPrinter-compatible 
and Epson-ESC/P-compatible by dip switches or by the front panel 
buttons. I don't know for which emulation mode is the CUPS driver which 
Mike recommended, there are also GhostScript drivers for both modes: 
"okiibm" and "epson". So there are at least three drivers for printing 
PostScript and images (where probably the CUPS driver is the easiest to 
configure, assuming that your spooler is CUPS). For printing plain text 
without converting it to PostScript,  you should use the printer in 
Epson emulation mode, there you have pronably the most common control 
sequences.

    Till




From roger at whinlatter.uklinux.net  Mon Mar  3 12:42:42 2003
From: roger at whinlatter.uklinux.net (Roger Leigh)
Date: 03 Mar 2003 20:42:42 +0000
Subject: [Inkjet-list] OKI MICROLINE 321 Elite (9-pin printer)
In-Reply-To: <3E637CA0.6050904@easysw.com>
References: <87d6l8zd9f.fsf@whinlatter.uklinux.net>
	<3E637CA0.6050904@easysw.com>
Message-ID: <877kbg6v25.fsf@whinlatter.uklinux.net>

Michael Sweet <mike at easysw.com> writes:

> Roger Leigh wrote:
> > It's not an inkjet, but has anyone any knowledge of this printer?
> > I've recently got an old one of these, and I can't even get it to
> > print ASCII text.  It's a wide-format printer for up to 14" continuous
> > stationary, and it weighs half a ton!
> > ...
> 
> (OKI still makes these...)

That's good news--I'll not have as much trouble finding new ribbons!

> Have you tried the OKIDATA 9-pin driver included with CUPS?  Also,
> have you tried a different parallel cable?

I'll try a non-bidirectional cable later.  I've found I can print fine
from 4.6-FreeBSD (/dev/lpt1), or DOS (LPT1) without problems.  It's
the Linux lp/parport driver that's the problem.  I suspect it's a
timing issue, but I've not yet had any success tuning any of the
parport options with "tunelp".


Thanks,
Roger

-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers



From roger at whinlatter.uklinux.net  Tue Mar  4 06:04:51 2003
From: roger at whinlatter.uklinux.net (Roger Leigh)
Date: 04 Mar 2003 14:04:51 +0000
Subject: [Inkjet-list] OKI MICROLINE 321 Elite (9-pin printer)
In-Reply-To: <877kbg6v25.fsf@whinlatter.uklinux.net>
References: <87d6l8zd9f.fsf@whinlatter.uklinux.net>
	<3E637CA0.6050904@easysw.com> <877kbg6v25.fsf@whinlatter.uklinux.net>
Message-ID: <878yvv8by4.fsf@whinlatter.uklinux.net>

Roger Leigh <roger at whinlatter.uklinux.net> writes:

> Michael Sweet <mike at easysw.com> writes:
> 
> > Have you tried the OKIDATA 9-pin driver included with CUPS?

I have now.  It's not working correctly, though.  When I print a test
page (at single, double or quad density), it starts OK, but after a
few passes, turns to garbage, probably due to a missed byte.  CUPS
says "Unable to send print file to printer: Resource temporarily
unavailable" as the error status.

This is because I found I could print if I did

# tunelp /dev/lp0 -a on

which for some reason makes it stop missing out every alternate char,
but probably causes a write() error when the printer is BUSY, or
something, terminating the parallel backend.  This just sets the
LPABORT lp ioctl().  It must have some other side-effect, though, which
fixes my problem?  Perhaps it also changes some of the other options,
but I've had no luck with them myself.

> > Also, have you tried a different parallel cable?
> 
> I'll try a non-bidirectional cable later.  I've found I can print fine
> from 4.6-FreeBSD (/dev/lpt1), or DOS (LPT1) without problems.  It's
> the Linux lp/parport driver that's the problem.  I suspect it's a
> timing issue, but I've not yet had any success tuning any of the
> parport options with "tunelp".

I've also tried with a unidirectional cable which I used to use with a
9-pin FX-80 compatible printer.  It makes no difference.

It's quite weird that this is seemingly Linux-specific.  I've used
other 9-pin printers before, with exactly the same setup, with no
problems.


-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers


From roger at whinlatter.uklinux.net  Fri May  2 05:13:30 2003
From: roger at whinlatter.uklinux.net (Roger Leigh)
Date: 02 May 2003 13:13:30 +0100
Subject: [Inkjet-list] OKI MICROLINE 321 Elite (9-pin printer)
In-Reply-To: <87d6l8zd9f.fsf@whinlatter.uklinux.net>
References: <87d6l8zd9f.fsf@whinlatter.uklinux.net>
Message-ID: <87isstr1g5.fsf@whinlatter.uklinux.net>

Roger Leigh <roger at whinlatter.uklinux.net> writes:

> Although there's no problem with the printed menu/options, when I do
> 
> echo "abcdefghiklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ" >
> /dev/lp0
> 
> all I get is:
> 
> bdfhkmoqsuwy02468ACEGIKMOQSUWY
> 
> It's only printing every alternate character! (you can see I missed
> `j'.)
> 
> I set it to use UNIX linefeeds, Char Set `I', Code Page `USA' and
> Language Set `ASCII' (I don't have a manual to know what the
> differences are, or what Char Set II might be).  There was also a
> "Print Suppress Effective" option, but didn't have any effect set to
> either `Yes' or `No'.

I've finally found the cause of the problem.  It's one, or both, of
these Linux 2.4.x kernel parport config options:

CONFIG_PARPORT_PC_FIFO
CONFIG_PARPORT_PC_SUPERIO

Both of these are experimental, but the FIFO one seems the likely
culprit.  Building and using the parport_pc/parport/lp modules without
these options makes the printer work flawlessly.
                    ____ ___
I guess the printer BUSY/ACK timings could be confusing the kernel
somehow, perhaps in combination with interrupts, or the above
experimental features are themselves buggy.  Normal interrupt-driven
or polling parport operation appears to be working.


Regards,
Roger

-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers


From roger at whinlatter.uklinux.net  Tue May  6 04:36:53 2003
From: roger at whinlatter.uklinux.net (Roger Leigh)
Date: 06 May 2003 12:36:53 +0100
Subject: [Inkjet-list] OKI MICROLINE 321 Elite (9-pin printer)
In-Reply-To: <3E637CA0.6050904@easysw.com>
References: <87d6l8zd9f.fsf@whinlatter.uklinux.net>
	<3E637CA0.6050904@easysw.com>
Message-ID: <87fznsmhm2.fsf@whinlatter.uklinux.net>

Michael Sweet <mike at easysw.com> writes:

> Roger Leigh wrote:
> > It's not an inkjet, but has anyone any knowledge of this printer?
> > I've recently got an old one of these, and I can't even get it to
> > print ASCII text.  It's a wide-format printer for up to 14" continuous
> > stationary, and it weighs half a ton!
> > ...
> 
> (OKI still makes these...)
> 
> Have you tried the OKIDATA 9-pin driver included with CUPS?

I have it working with CUPS.  However, the A4 paper size doesn't work
properly, because it can't print on the top ?" of the page, or the
bottom 7/8" of the page.  I think the PPD is wrong:

*ImageableArea A4:      "18.0 18.0 577.0 824.0"

I think this is way too large in the vertical dimension (horizontal is
fine, with a ?" gap each side), but I'm not sure if the coordinates
are the top left or bottom left.  I'll see if I can improve things.

It's not too obvious to me (as a Briton) what size of paper FanFoldUS
is.  I use 8?" x 11" continuous paper (612 x 792 ps points), which
CUPS doesn't support.  There's also much wider paper (around 14" x
11") in use, but I don't have any to measure at the moment.

I'll probably use a raw queue, since I'm only using it for plaintext.
What is the best approach to get CUPS to add a final linefeed to each
job (if not already present)?  Can I write a filter for a raw queue?


Regards,
Roger

-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers


From hde at grics.net  Thu May 29 11:35:00 2003
From: hde at grics.net (Harley D. Eades III)
Date: Thu, 29 May 2003 13:35:00 -0500
Subject: [Inkjet-list] Help with PCL Printer Programming.
Message-ID: <3ED652D4.7030900@grics.net>

Hello,
    I am currently devolping a perl module to interface with HP 
printers. This will allow people to set up easy text printing in perl 
with out having to setup cups, etc..  I have ran into a problem  when 
sending commands to a printer. Everytime I send somthing to the printer, 
it just hangs first it pulls the paper into place and the head moves to 
0,0(Top right hand corner) and then the green light on the power button 
just blinks. After about 3min of the green light blinking the amber 
light beginnes to blink.  I think it is timing out wating for something.

Here is how I send things to the printer.
I use fopen to open /dev/lp0.
Then use fprintf to send things to the printer.
    fprintf (lp, "%s", "0x1bE");                    /* Reset the printer */
    fprintf (lp, "%s", "Perl is the name\n"); /* Send some data */
    fprintf (lp, "%s", "0x1b&l0H");             /* Eject the page */
    fprintf (lp, "%s", "0x1bE");                    /* Reset the printer */

Any ideas, comments, help will be vary appreciated.

Thanks
hde

perl -e 
'@x=(0x0A,0x21,0x72,0x65,0x6B,0x63,0x61,0x48,0x20,0x55,0x4E,0x47,0x20,0x72,0x65,0x68,0x74,0x6f,0x6E,0x41,0x20,0x74,0x73,0x75,0x4a);
while($i<=(@x+0)){$string[$i]=sprintf("%c",$x[$i++]);}print 
reverse(@string);'

OUTPUT:
Just Another GNU Hacker!



From mike at easysw.com  Thu May 29 13:14:40 2003
From: mike at easysw.com (Michael Sweet)
Date: Thu, 29 May 2003 16:14:40 -0400
Subject: [Inkjet-list] OKI MICROLINE 321 Elite (9-pin printer)
In-Reply-To: <87fznsmhm2.fsf@whinlatter.uklinux.net>
References: <87d6l8zd9f.fsf@whinlatter.uklinux.net>	<3E637CA0.6050904@easysw.com> <87fznsmhm2.fsf@whinlatter.uklinux.net>
Message-ID: <3ED66A30.3080709@easysw.com>

Roger Leigh wrote:
> ...
> I have it working with CUPS.  However, the A4 paper size doesn't work
> properly, because it can't print on the top ?" of the page, or the
> bottom 7/8" of the page.  I think the PPD is wrong:
> 
> *ImageableArea A4:      "18.0 18.0 577.0 824.0"

That defines an A4 page with a 1/4" margin all around.

The numbers are: left, bottom, right, top in points.

> I think this is way too large in the vertical dimension (horizontal is
> fine, with a ?" gap each side), but I'm not sure if the coordinates
> are the top left or bottom left.  I'll see if I can improve things.

For fanfold you can set the bottom margin (the second number)
to 0 and the top margin (the fourth number) to 842.

> It's not too obvious to me (as a Briton) what size of paper FanFoldUS
> is.  I use 8?" x 11" continuous paper (612 x 792 ps points), which
> CUPS doesn't support.  There's also much wider paper (around 14" x
> 11") in use, but I don't have any to measure at the moment.

FanFoldUS, as defined by Adobe, is 14.875x11in - the wide carriage
fanfold paper.  For 8.5x11", use Letter or Custom.8.5x11in.

> I'll probably use a raw queue, since I'm only using it for plaintext.
> What is the best approach to get CUPS to add a final linefeed to each
> job (if not already present)?  Can I write a filter for a raw queue?

Yeah, it's called an interface script and uses the same interface
as any other CUPS filter (see "man filter" and "man lpadmin"...)

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com





From dsuffiel at dsufflnx.vcd.hp.com  Fri May 30 14:57:07 2003
From: dsuffiel at dsufflnx.vcd.hp.com (David Suffield)
Date: Fri, 30 May 2003 14:57:07 -0700
Subject: [Inkjet-list] HP Linux Inkjet Driver 1.4.1 Release
Message-ID: <3ED7D3B3.9040208@dsufflnx.vcd.hp.com>

This HP Linux Inkjet Driver (HPIJS) release has the following changes.

1. Fixed a GCC 2.95 compile problem with debug.h.

2. Fixed a foomatic-install issue with gzip 1.3 in Makefile.am. Removed 
the gzip -r option.

3. Updated the foomatic PPD files for HPIJS.

See hpinkjet.sourceforge.net and the hpijs_readme.html file for more 
information.




From maple_jing at sina.com  Sun Jul 13 21:44:57 2003
From: maple_jing at sina.com (maple_jing)
Date: Mon, 14 Jul 2003 12:44:57 +0800
Subject: [Inkjet-list] how can i write my own client for hpijs?
Message-ID: <20030714044457.13214.qmail@sina.com>

Hi all, 
how can i write my own client to use hpijs directly ?

i have got the client code from epijs's example and which can work well with epijs, so i accept it as my own client for hpijs.

but hpijs just support "OutputFD", so i should open the device file for hpijs in my own client, and send the device file's file-descriptor with "OutputFD" to hpijs. but it can not work(no error hint in linux prompt, but the printer keep silent).

alse the client can not work with epijs when i use this mathod to tell epijs which "OutputFD" is.

there is my own client code in the attachment, please tell me why it can not work well in hpijs/epijs.
 
______________________________________

===================================================================

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Epijs_client_service.rar
Type: application/x-msdownload
Size: 222029 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030714/89765717/attachment.bin 

From jchang at eitc.epson.com  Fri Aug  8 15:25:09 2003
From: jchang at eitc.epson.com (Jackie Chang)
Date: Fri, 8 Aug 2003 15:25:09 -0700
Subject: [Inkjet-list] Proposed IJS v1.0 package available
Message-ID: <NHBBKCMCMLMNOJFAOLOAMEBDCGAA.jchang@eitc.epson.com>

Hi, All:
Epson has been working with Raph Levien to produce the IJS protocol 1.0
specification.  The new specification incorporated the feedback from the
Inkjet Printing Community and other solicited comments.  Epson strongly
believes that support for IJS continues to grow and that producing version
1.0 will go a long way to general adoption.  Since Raph Levien is currently
very busy on Ghostscript activities, Raph has agreed to let Epson publish
the proposed IJS v1.0 specification and would like to have the Inkjet
Printing Community review the proposed IJS v1.0 package for adoption as the
official release of IJS v1.0 package.  Please download the proposed IJS v1.0
package from http://www.eitcsv.com/sps/2003/ijs-v1.00-070103.tar.gz


Please read the IJS-Protocol-1.0-Spec.doc file for the proposed IJS v1.0
specification.  The ijs-spec.pdf file will be updated later when the final
version of IJS-Protocol-1.0-Spec is approved by the Inkjet Printing
Community.

Please also review the sample code in the proposed IJS v1.0 package.
Currently, there is one unsolved issue that will need some help from the
Windows/DOS exports.  The issue is to provide a good/clean mechanism for IJS
v1.0 compatible client to work with IJS v0.34 compatible server under
DOS/Windows environment.

Your feedback and help are needed to move the IJS forward.




From jchang at eitc.epson.com  Fri Aug  8 17:52:54 2003
From: jchang at eitc.epson.com (Jackie Chang)
Date: Fri, 8 Aug 2003 17:52:54 -0700
Subject: [Inkjet-list] CORRECTION: Proposed IJS v1.0 package available
In-Reply-To: <NHBBKCMCMLMNOJFAOLOAMEBDCGAA.jchang@eitc.epson.com>
Message-ID: <NHBBKCMCMLMNOJFAOLOAEEBFCGAA.jchang@eitc.epson.com>

Hi, All:
Sorry the ijs_spec.pdf and IJS-Protocol-1.0-Spec.doc in the previous release
package are corrupted.  The ijs_spec.pdf in the package is the same
ijs_spec.pdf in the IJS v0.34 package.  Epson didn't update ijs_spec.pdf
with the proposed IJS v1.0 specification.  IJS-Protocol-1.0-Spec.doc is a
Word document.

Please download the proposed IJS v1.0
package from http://www.eitcsv.com/sps/2003/ijs-v1.00-Aug082003.tar.gz.




-----Original Message-----
From: inkjet-list-admin at linuxprinting.org
[mailto:inkjet-list-admin at linuxprinting.org]On Behalf Of Jackie Chang
Sent: Friday, August 08, 2003 3:25 PM
To: Inkjet-List at Linuxprinting.Org
Subject: [Inkjet-list] Proposed IJS v1.0 package available

Hi, All:
Epson has been working with Raph Levien to produce the IJS protocol 1.0
specification.  The new specification incorporated the feedback from the
Inkjet Printing Community and other solicited comments.  Epson strongly
believes that support for IJS continues to grow and that producing version
1.0 will go a long way to general adoption.  Since Raph Levien is currently
very busy on Ghostscript activities, Raph has agreed to let Epson publish
the proposed IJS v1.0 specification and would like to have the Inkjet
Printing Community review the proposed IJS v1.0 package for adoption as the
official release of IJS v1.0 package.  Please download the proposed IJS v1.0
package from http://www.eitcsv.com/sps/2003/ijs-v1.00-070103.tar.gz


Please read the IJS-Protocol-1.0-Spec.doc file for the proposed IJS v1.0
specification.  The ijs-spec.pdf file will be updated later when the final
version of IJS-Protocol-1.0-Spec is approved by the Inkjet Printing
Community.

Please also review the sample code in the proposed IJS v1.0 package.
Currently, there is one unsolved issue that will need some help from the
Windows/DOS exports.  The issue is to provide a good/clean mechanism for IJS
v1.0 compatible client to work with IJS v0.34 compatible server under
DOS/Windows environment.

Your feedback and help are needed to move the IJS forward.


_______________________________________________
Inkjet-list mailing list
Inkjet-list at linuxprinting.org
http://www.linuxprinting.org/cgi-bin/mailman/listinfo/inkjet-list



From roger at whinlatter.uklinux.net  Sat Aug  9 10:30:48 2003
From: roger at whinlatter.uklinux.net (Roger Leigh)
Date: Sat, 09 Aug 2003 18:30:48 +0100
Subject: [Inkjet-list] CORRECTION: Proposed IJS v1.0 package available
In-Reply-To: <NHBBKCMCMLMNOJFAOLOAEEBFCGAA.jchang@eitc.epson.com> (Jackie
 Chang's message of "Fri, 8 Aug 2003 17:52:54 -0700")
References: <NHBBKCMCMLMNOJFAOLOAEEBFCGAA.jchang@eitc.epson.com>
Message-ID: <87bruypwl3.fsf@whinlatter.uklinux.net>

"Jackie Chang" <jchang at eitc.epson.com> writes:

> Hi, All:
> Sorry the ijs_spec.pdf and IJS-Protocol-1.0-Spec.doc in the previous release
> package are corrupted.  The ijs_spec.pdf in the package is the same
> ijs_spec.pdf in the IJS v0.34 package.  Epson didn't update ijs_spec.pdf
> with the proposed IJS v1.0 specification.  IJS-Protocol-1.0-Spec.doc is a
> Word document.
  ^^^^^^^^^^^^^

Could you provide the spec in an open format please, like plain text,
PDF, HTML or DocBook?

Reading MS Word files on Linux is not fun (or accurate) using the free
tools I have available.


Thanks,
Roger

-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers


From gsview at ghostgum.com.au  Sat Aug  9 23:53:04 2003
From: gsview at ghostgum.com.au (Russell Lang)
Date: Sun, 10 Aug 2003 16:53:04 +1000
Subject: [Inkjet-list] CORRECTION: Proposed IJS v1.0 package available
In-Reply-To: <NHBBKCMCMLMNOJFAOLOAEEBFCGAA.jchang@eitc.epson.com>
References: <NHBBKCMCMLMNOJFAOLOAMEBDCGAA.jchang@eitc.epson.com>
Message-ID: <3F367870.17001.660020F2@localhost>

Jackie,

I've now made the necessary changes to make it work on Windows,
including fixing OutputFD which did not previously work on 
Windows.  For Windows we need to pass the operating system 
handle, not the file descriptor.  I will send you the changes 
separately.

You have changed IJS from using stdin and stdout to using 
specified file descriptors (handles).  Could you please explain 
the reason for this change?  The documentation is now 
inconsistent, since it will now not work via ssh.  If this 
change is accepted, I'd like it documented clearly that it was 
changed between 0.34 and 1.00 and the consequences.

One consequence of this change is that an IJS 0.34 client can 
not talk to an IJS 1.00 server.  An IJS 1.00 client can talk to 
a 0.34 server by first trying the 1.00 protocol (specified file 
descriptors) and if it gets no response then kill the server and 
restart it using the IJS 0.34 protocol (stdin/stdout).  To 
convert a 0.34 client to 1.00 requires a few source lines to be 
changed and will require some makefile changes (the latter due 
to my changes).

I've made the necessary changes to the ghostscript ijs device.  
I'll submit them to ghostscript code review after the IJS 1.00 
changes are settled.

Russell



On 8 Aug 2003 at 17:52, Jackie Chang wrote:

> Hi, All:
> Sorry the ijs_spec.pdf and IJS-Protocol-1.0-Spec.doc in the previous release
> package are corrupted.  The ijs_spec.pdf in the package is the same
> ijs_spec.pdf in the IJS v0.34 package.  Epson didn't update ijs_spec.pdf
> with the proposed IJS v1.0 specification.  IJS-Protocol-1.0-Spec.doc is a
> Word document.
> 
> Please download the proposed IJS v1.0
> package from http://www.eitcsv.com/sps/2003/ijs-v1.00-Aug082003.tar.gz.
> 
> 
> 
> 
> -----Original Message-----
> From: inkjet-list-admin at linuxprinting.org
> [mailto:inkjet-list-admin at linuxprinting.org]On Behalf Of Jackie Chang
> Sent: Friday, August 08, 2003 3:25 PM
> To: Inkjet-List at Linuxprinting.Org
> Subject: [Inkjet-list] Proposed IJS v1.0 package available
> 
> Hi, All:
> Epson has been working with Raph Levien to produce the IJS protocol 1.0
> specification.  The new specification incorporated the feedback from the
> Inkjet Printing Community and other solicited comments.  Epson strongly
> believes that support for IJS continues to grow and that producing version
> 1.0 will go a long way to general adoption.  Since Raph Levien is currently
> very busy on Ghostscript activities, Raph has agreed to let Epson publish
> the proposed IJS v1.0 specification and would like to have the Inkjet
> Printing Community review the proposed IJS v1.0 package for adoption as the
> official release of IJS v1.0 package.  Please download the proposed IJS v1.0
> package from http://www.eitcsv.com/sps/2003/ijs-v1.00-070103.tar.gz
> 
> 
> Please read the IJS-Protocol-1.0-Spec.doc file for the proposed IJS v1.0
> specification.  The ijs-spec.pdf file will be updated later when the final
> version of IJS-Protocol-1.0-Spec is approved by the Inkjet Printing
> Community.
> 
> Please also review the sample code in the proposed IJS v1.0 package.
> Currently, there is one unsolved issue that will need some help from the
> Windows/DOS exports.  The issue is to provide a good/clean mechanism for IJS
> v1.0 compatible client to work with IJS v0.34 compatible server under
> DOS/Windows environment.
> 
> Your feedback and help are needed to move the IJS forward.
> 
> 
> _______________________________________________
> Inkjet-list mailing list
> Inkjet-list at linuxprinting.org
> http://www.linuxprinting.org/cgi-bin/mailman/listinfo/inkjet-list
> 
> _______________________________________________
> Inkjet-list mailing list
> Inkjet-list at linuxprinting.org
> http://www.linuxprinting.org/cgi-bin/mailman/listinfo/inkjet-list


Russell Lang                   gsview at ghostgum.com.au
Ghostgum Software Pty Ltd      http://www.ghostgum.com.au/




From jchang at eitc.epson.com  Mon Aug 11 09:41:15 2003
From: jchang at eitc.epson.com (Jackie Chang)
Date: Mon, 11 Aug 2003 09:41:15 -0700
Subject: [Inkjet-list] CORRECTION: Proposed IJS v1.0 package available
In-Reply-To: <87bruypwl3.fsf@whinlatter.uklinux.net>
Message-ID: <NHBBKCMCMLMNOJFAOLOACEBKCGAA.jchang@eitc.epson.com>

Hi, All:
Sorry that I didn't provide the proposed IJS v1.0 specification in the PDF
format since I don't have the original file of ijs_spec.pdf.  Thanks for
Karl Heinz to point out that I can convert a PostScript file to PDF using
Ghostscript.  I will try to do that ASAP.

Regards,
Jackie

-----Original Message-----
From: Roger Leigh [mailto:roger at whinlatter.uklinux.net]
Sent: Saturday, August 09, 2003 10:31 AM
To: Jackie Chang
Cc: Inkjet-List at Linuxprinting.Org
Subject: Re: [Inkjet-list] CORRECTION: Proposed IJS v1.0 package available

"Jackie Chang" <jchang at eitc.epson.com> writes:

> Hi, All:
> Sorry the ijs_spec.pdf and IJS-Protocol-1.0-Spec.doc in the previous
release
> package are corrupted.  The ijs_spec.pdf in the package is the same
> ijs_spec.pdf in the IJS v0.34 package.  Epson didn't update ijs_spec.pdf
> with the proposed IJS v1.0 specification.  IJS-Protocol-1.0-Spec.doc is a
> Word document.
  ^^^^^^^^^^^^^

Could you provide the spec in an open format please, like plain text,
PDF, HTML or DocBook?

Reading MS Word files on Linux is not fun (or accurate) using the free
tools I have available.


Thanks,
Roger

--
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers



From jchang at eitc.epson.com  Mon Aug 11 10:30:14 2003
From: jchang at eitc.epson.com (Jackie Chang)
Date: Mon, 11 Aug 2003 10:30:14 -0700
Subject: [Inkjet-list] CORRECTION: Proposed IJS v1.0 package available
In-Reply-To: <3F367870.17001.660020F2@localhost>
Message-ID: <NHBBKCMCMLMNOJFAOLOAMEBLCGAA.jchang@eitc.epson.com>

Hi, All:
The reason that we have changed IJS from using stdin and stdout to using
specified file descriptors (handles) is that we have some customers are
requesting to pipe the output of IJS server to stdout.  They want to pipe
the output of IJS server to another process.

Actually, the IJS v1.0 server still can communicate with the IJS client
through stdin and stdout.  It is up to IJS client to decide how it wants to
communicate with IJS server.  But at lease, IJS client can have the option
to communicate with the IJS v1.0 server though other channels.

The only drawback of this change is that the IJS v1.0 client won't be able
to talk to the IJS v0.34 server initially with the new -f option.  So the
work around that I come out for this problem is that the IJS v1.0 client
will invoke an IJS server with the -f option, and the IJS v1.0 client will
terminate the current running IJS server and invoke an IJS server without -f
option to use stdin and stdout as the communication channels if the IJS
client doesn't receive any respond back from the IJS server within 3
seconds.

Yes.  If this change accepted by the community, then we should document it
clearly in the spec.

I will try to incorporate your changes into the package soon.

Thanks for your contribution,
Jackie

-----Original Message-----
From: Russell Lang [mailto:gsview at ghostgum.com.au]
Sent: Saturday, August 09, 2003 11:53 PM
To: Jackie Chang
Cc: inkjet-list at linuxprinting.org
Subject: RE: [Inkjet-list] CORRECTION: Proposed IJS v1.0 package available

Jackie,

I've now made the necessary changes to make it work on Windows,
including fixing OutputFD which did not previously work on
Windows.  For Windows we need to pass the operating system
handle, not the file descriptor.  I will send you the changes
separately.

You have changed IJS from using stdin and stdout to using
specified file descriptors (handles).  Could you please explain
the reason for this change?  The documentation is now
inconsistent, since it will now not work via ssh.  If this
change is accepted, I'd like it documented clearly that it was
changed between 0.34 and 1.00 and the consequences.

One consequence of this change is that an IJS 0.34 client can
not talk to an IJS 1.00 server.  An IJS 1.00 client can talk to
a 0.34 server by first trying the 1.00 protocol (specified file
descriptors) and if it gets no response then kill the server and
restart it using the IJS 0.34 protocol (stdin/stdout).  To
convert a 0.34 client to 1.00 requires a few source lines to be
changed and will require some makefile changes (the latter due
to my changes).

I've made the necessary changes to the ghostscript ijs device.
I'll submit them to ghostscript code review after the IJS 1.00
changes are settled.

Russell



On 8 Aug 2003 at 17:52, Jackie Chang wrote:

> Hi, All:
> Sorry the ijs_spec.pdf and IJS-Protocol-1.0-Spec.doc in the previous
release
> package are corrupted.  The ijs_spec.pdf in the package is the same
> ijs_spec.pdf in the IJS v0.34 package.  Epson didn't update ijs_spec.pdf
> with the proposed IJS v1.0 specification.  IJS-Protocol-1.0-Spec.doc is a
> Word document.
>
> Please download the proposed IJS v1.0
> package from http://www.eitcsv.com/sps/2003/ijs-v1.00-Aug082003.tar.gz.
>
>
>
>
> -----Original Message-----
> From: inkjet-list-admin at linuxprinting.org
> [mailto:inkjet-list-admin at linuxprinting.org]On Behalf Of Jackie Chang
> Sent: Friday, August 08, 2003 3:25 PM
> To: Inkjet-List at Linuxprinting.Org
> Subject: [Inkjet-list] Proposed IJS v1.0 package available
>
> Hi, All:
> Epson has been working with Raph Levien to produce the IJS protocol 1.0
> specification.  The new specification incorporated the feedback from the
> Inkjet Printing Community and other solicited comments.  Epson strongly
> believes that support for IJS continues to grow and that producing version
> 1.0 will go a long way to general adoption.  Since Raph Levien is
currently
> very busy on Ghostscript activities, Raph has agreed to let Epson publish
> the proposed IJS v1.0 specification and would like to have the Inkjet
> Printing Community review the proposed IJS v1.0 package for adoption as
the
> official release of IJS v1.0 package.  Please download the proposed IJS
v1.0
> package from http://www.eitcsv.com/sps/2003/ijs-v1.00-070103.tar.gz
>
>
> Please read the IJS-Protocol-1.0-Spec.doc file for the proposed IJS v1.0
> specification.  The ijs-spec.pdf file will be updated later when the final
> version of IJS-Protocol-1.0-Spec is approved by the Inkjet Printing
> Community.
>
> Please also review the sample code in the proposed IJS v1.0 package.
> Currently, there is one unsolved issue that will need some help from the
> Windows/DOS exports.  The issue is to provide a good/clean mechanism for
IJS
> v1.0 compatible client to work with IJS v0.34 compatible server under
> DOS/Windows environment.
>
> Your feedback and help are needed to move the IJS forward.
>
>
> _______________________________________________
> Inkjet-list mailing list
> Inkjet-list at linuxprinting.org
> http://www.linuxprinting.org/cgi-bin/mailman/listinfo/inkjet-list
>
> _______________________________________________
> Inkjet-list mailing list
> Inkjet-list at linuxprinting.org
> http://www.linuxprinting.org/cgi-bin/mailman/listinfo/inkjet-list


Russell Lang                   gsview at ghostgum.com.au
Ghostgum Software Pty Ltd      http://www.ghostgum.com.au/



From jchang at eitc.epson.com  Mon Aug 11 11:28:29 2003
From: jchang at eitc.epson.com (Jackie Chang)
Date: Mon, 11 Aug 2003 11:28:29 -0700
Subject: [Inkjet-list] The proposed IJS v1.0 spec in the PDF format
Message-ID: <NHBBKCMCMLMNOJFAOLOAGEBNCGAA.jchang@eitc.epson.com>

Hi, All:
The attachment is the proposed IJS v1.0 spec in the PDF format.

Regards,
Jackie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IJS-Protocol-1.0-Spec.pdf
Type: application/pdf
Size: 29619 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030811/19b45cae/attachment.pdf 

From david.suffield at hp.com  Mon Aug 11 12:19:18 2003
From: david.suffield at hp.com (SUFFIELD,DAVID (HP-Vancouver,ex1))
Date: Mon, 11 Aug 2003 15:19:18 -0400
Subject: [Inkjet-list] RE: Prompting IJS Version 1.0
Message-ID: <A134E2426B46D711BB4B000347AE6E7C01028A26@xvan02.vcd.hp.com>

I'm not sure why we need the "ijssrv -f <client to server fd>,<server to
client fd>" option proposed in IJS 1.0. 

Piping the ijs server output to stdout is the normal configuration for the
ijs client/server printing application (ie: ghostscript/hpijs). The current
IJS 0.34 interface works great for this configuration.  

How does this work if the ijs client/server also uses stdin/stdout for IPC?
The key point is the "fd = dup(fileno(ijsdev->file))" call in gdevijs.c.

The dup guarantees that "OutputFD" does not use the same stdout file
descriptor, but fd will still use the same output path or file table
specified by stdout.

This means that "OutputFD" can point to the same file table as stdout and
the IJS protocol can still use pipes over stdin/stdout.

Remember file descriptors are just indexes into the kernel's open file
table. Stdin, stdout and stderr use file descriptors 0, 1 and 2. You can
make a file descriptor point to any open file.

-dave


> -----Original Message-----
> From: Jackie Chang [mailto:jchang at eitc.epson.com] 
> Sent: Thursday, August 07, 2003 1:48 PM
> To: SUFFIELD,DAVID (HP-Vancouver,ex1); 'Glen Petrie'
> Cc: HEMSTREET,CHARLES (HP-Vancouver,ex1)
> Subject: RE: Prompting IJS Version 1.0
> 
> 
> Hi, David:
> Thanks for your feedback.  The reason for proposing IJS 1.0 
> with command line option -f to specify the communication 
> channels between IJS client and server is that we have 
> customers are requesting to pipe the output of IJS server to stdout.
> 
> 1. ijssrv
> 2. ijssrv -f <client to server fd>,<server to client fd>
> Yes, the option 1 is really a work-around for IJS servers 
> that don't use option 2. Do you have any solution to solve 
> this problem for DOS/Windows environment?
> 
> How does the value of "OutputFD" get guaranteed not to equal 
> stdout?  Does Ghostscript do the checking for "OutputFD" not 
> to equal stdout? In gdevijs.c fd = dup(fileno(ijsdev->file));
> 
> Where is the value of "ijsdev->file" get assigned?  Isn't 
> that "OutputFD" can still be possible be assigned to stdout?
> 
> Regards,
> Jackie
> 
> -----Original Message-----
> From: SUFFIELD,DAVID (HP-Vancouver,ex1) [mailto:david.suffield at hp.com]
> Sent: Monday, July 28, 2003 2:56 PM
> To: 'Glen Petrie'
> Cc: 'Jackie Chang (E-mail)'; HEMSTREET,CHARLES (HP-Vancouver,ex1)
> Subject: RE: Prompting IJS Version 1.0
> 
> Hi Glen,
> Thanks for reminding me. I did test your latest IJS 1.0 
> implementation with hpijs using the following command.
> 
> ./ijs_client_example -s hpijs -l
> 
> This test does work. A IJS 1.0 client is backward compatible 
> with IJS 0.34 server. I did not try any printing tests, but 
> here are my initial thoughts.
> 
> IJS 1.0 has the following options for invoking the IJS server.
> 
> 1. ijssrv
> 2. ijssrv -f <client to server fd>,<server to client fd>
> 
> With IJS 1.0 Option 1 has a 3 second initial timeout. Option 
> 1 is not a good option because of the timeout. Option 2 will 
> always be faster because it has no timeout. A smaller timeout 
> would minimize the issue, but not solve it. Option 1 is 
> really a work-around for IJS servers that don't use option 2.
> 
> What problem are you trying to solve? I mention before that 
> Stdin/stdout is not a problem with hpijs since "OutputFD" is 
> guaranteed not to equal stdout. This does not mean that 
> "OutputFD" cannot point to stdout by using another file 
> descriptor. See the dup() in Ghostscript's gdevijs.c.
> 
> -dave
> 
> 
> > -----Original Message-----
> > From: Glen Petrie [mailto:glen.petrie at eitc.epson.com]
> > Sent: Thursday, July 24, 2003 7:32 AM
> > To: 'SUFFIELD,DAVID (HP-Vancouver,ex1)'
> > Cc: 'Jackie Chang (E-mail)'; 'HEMSTREET,CHARLES 
> (HP-Vancouver,ex1)'; 
> > Glen (E-mail)
> > Subject: RE: Prompting IJS Version 1.0
> >
> >
> > Hello David,
> >
> > I was wondering if had a change to review our latest 
> comments and IJS 
> > package.  Epson is very interested in prompting version 1.0 
> of IJS and 
> > would like to have HP's backing.
> >
> > Rgds,
> > Glen W. Petrie
> > Manager, Software Printing Solutions
> > Epson Imaging Technology Center
> > 150 River Oaks Parkway, Suite 200
> > San Jose, CA, 95134
> > Voice: 408.576.4131  Fax: 408.474.0511
> >
> > -----Original Message-----
> > From: Glen Petrie [mailto:glen.petrie at eitc.epson.com]
> > Sent: Tuesday, July 08, 2003 2:11 PM
> > To: 'SUFFIELD,DAVID (HP-Vancouver,ex1)'
> > Cc: Glen (E-mail); Jackie Chang (E-mail); 'HEMSTREET,CHARLES 
> > (HP-Vancouver,ex1)'
> > Subject: RE: Prompting IJS Version 1.0
> >
> > David
> > Sorry for the late reply...
> >
> > Attached is the new IJS v1.0 proposed release package that includes 
> > the patch for IJS client 1.0 to work with IJS server 0.34 
> under Linux 
> > and DOS.  (I would leave the patch for DOS in the package for 
> > reference. Although, the patch for DOS is not very clean.)
> >
> > Ideally, IJS v1.0 specification should be backward 
> compatible with IJS 
> > v0.34.  We do have the patch for IJS client v1.0 to work with IJS 
> > server v0.34 under Linux.  But we didn't put the patch in 
> the previous 
> > IJS v1.0 proposed release package since we are not sure what Raph 
> > Levien wants to do with this issue.
> >
> > Basically, under Linux IJS client will call "select" 
> function to test 
> > the availability of input data (the initialization handshake string 
> > from the IJS server).  If IJS client doesn't receive the 
> > initialization handshake string from IJS server within 3 
> seconds, IJS 
> > client will send a SIGKILL signal to the IJS server process to 
> > terminate the incompatible IJS server process, and 
> re-invoke the IJS 
> > server in the old way (IJS v0.34 spec).
> >
> > However, this patch will not work under DOS since the "select" 
> > function is defined to be a Windows sockets function and 
> will always 
> > return SOCKET_ERROR value. So under DOS, IJS client will 
> call "_fstat" 
> > to get the input data size from the receiving channel.  If 
> IJS client 
> > doesn't receive the initialization handshake string from IJS server 
> > within 20 loops, then IJS client will terminate the IJS server, and
> > re-invoke the IJS server in the old way (IJS v0.34 spec).
> >
> > There are 2 problems are encountered when implementing the 
> patch for 
> > DOS. 1. The IJS server process ID value returned back from the 
> > ijs_exec_server
> > (ijs_exec_win.c) seems to be incorrect.  (The 
> piProcInfo.dwProcessId 
> > contains a big negative number.) 2. I can't find a clean way to 
> > terminate the IJS server process under DOS. One of the MSDN 
> knowledge 
> > base articles states that "kill -f pid" can force terminate the pid 
> > process. However, the "kill" system function doesn't appear to be a
> > standard system function under DOS. We will to future
> > investigation or seek help from DOS/Windows experts to solve
> > these problems.
> >
> > Please provide your comments on this solution and how we 
> can proceed 
> > forward in getting adoption from the community? Rgds, Glen 
> W. Petrie 
> > Manager, Software Printing Solutions Epson Imaging 
> Technology Center 
> > 150 River Oaks Parkway, Suite 200 San Jose, CA, 95134
> > Voice: 408.576.4131  Fax: 408.474.0511
> >
> > -----Original Message-----
> > From: SUFFIELD,DAVID (HP-Vancouver,ex1) 
> [mailto:david.suffield at hp.com]
> > Sent: Thursday, June 26, 2003 4:59 PM
> > To: 'Glen Petrie'
> > Cc: HEMSTREET,CHARLES (HP-Vancouver,ex1)
> > Subject: RE: Prompting IJS Version 1.0
> >
> > Hi Glen,
> > I do have an issue with your proposed IJS 1.0 stdin/stdout change. 
> > After looking at the code, I don't believe IJS 1.0 is backward 
> > compatible with IJS 0.34. The README says the IJS client can be 
> > invoked by either one of the following commands.
> >
> > ijssrv
> > ijssrv -f <client to server fd>,<server to client fd>
> >
> > But, ijs_exec_unix.c is hardcoded to support the "-f 
> <client to server
> > fd>,<server to client fd>" syntax only when V0100 is defined.
> > This means
> > fd>the
> > stdin/stout change is a compile time option not a runtime 
> option. IJS 
> > 0.34 servers will not be compatible with IJS 1.0 clients.
> >
> > Stdin/stdout is not a problem with hpijs since "OutputFD" is 
> > guaranteed not to equal stdout in the Ghostscript IJS client 
> > gdevijs.c.
> >
> > The standardized Quality parameters should be ok as long as 
> they are 
> > optional.
> >
> > -dave
> >
> >
> > -----Original Message-----
> > From: Glen Petrie [mailto:glen.petrie at eitc.epson.com]
> > Sent: Wednesday, June 25, 2003 6:56 AM
> > To: 'Charles Hemstreet'; david_suffield at hp.com
> > Cc: Glen (E-mail)
> > Subject: Prompting IJS Version 1.0
> >
> >
> > Hello Charles and David,
> >
> > During last week FSG meeting in Portland, I discussed with you that 
> > Epson was trying to work with Raph Levin on releasing 
> Version 1.0 of 
> > the IJS specification and reference implementation.  Raph has been 
> > extremely busy since he took over GhostScript and has been 
> unable to 
> > address ratifying the Version 1.0 release package of IJS 
> that my team 
> > has pulled together. Discussion on the changes for Version 1.0 have 
> > been reviewed on the IJS DL
> > and generally agreed upon.   I have enclosed the proposed
> > Version 1.0 IJS
> > release package for your review.   Assuming you agree with
> > the Version 1.0
> > modification, I would like to propose that HP and Epson
> > jointly support and request ratification by the IJS community
> > of the proposed Version 1.0
> > release package.   Please provide me any feed back on the
> > release package
> > and your comments on supporting ratification.
> >
> > Rgds,
> > Glen W. Petrie
> > Manager, Software Printing Solutions
> > Epson Imaging Technology Center
> > 150 River Oaks Parkway, Suite 200
> > San Jose, CA, 95134
> > Voice: 408.576.4131  Fax: 408.474.0511
> >
> 


From jchang at eitc.epson.com  Mon Aug 11 13:58:58 2003
From: jchang at eitc.epson.com (Jackie Chang)
Date: Mon, 11 Aug 2003 13:58:58 -0700
Subject: [Inkjet-list] RE: Prompting IJS Version 1.0
In-Reply-To: <A134E2426B46D711BB4B000347AE6E7C01028A26@xvan02.vcd.hp.com>
Message-ID: <NHBBKCMCMLMNOJFAOLOAGEBOCGAA.jchang@eitc.epson.com>

Hi:
Sorry that I didn't word it clearly on the "output of IJS server".  I mean
our customer wants to pipe the "printing data output produced by the IJS
server" to stdout.  An IJS server may act as a pre-processor of another
process.

This means that "OutputFD" can point to the same file table as stdout and
the IJS protocol can still use pipes over stdin/stdout.

I am not sure how I can use the same file table as the IPC channel and at
the same time as the data container of the actual printing (or pre-printing)
data produced by the IJS server.

Regards,
Jackie
-----Original Message-----
From: SUFFIELD,DAVID (HP-Vancouver,ex1) [mailto:david.suffield at hp.com]
Sent: Monday, August 11, 2003 12:19 PM
To: 'Jackie Chang'; 'Glen Petrie'
Cc: HEMSTREET,CHARLES (HP-Vancouver,ex1); inkjet-list at linuxprinting.org
Subject: RE: Prompting IJS Version 1.0

I'm not sure why we need the "ijssrv -f <client to server fd>,<server to
client fd>" option proposed in IJS 1.0.

Piping the ijs server output to stdout is the normal configuration for the
ijs client/server printing application (ie: ghostscript/hpijs). The current
IJS 0.34 interface works great for this configuration.

How does this work if the ijs client/server also uses stdin/stdout for IPC?
The key point is the "fd = dup(fileno(ijsdev->file))" call in gdevijs.c.

The dup guarantees that "OutputFD" does not use the same stdout file
descriptor, but fd will still use the same output path or file table
specified by stdout.

This means that "OutputFD" can point to the same file table as stdout and
the IJS protocol can still use pipes over stdin/stdout.

Remember file descriptors are just indexes into the kernel's open file
table. Stdin, stdout and stderr use file descriptors 0, 1 and 2. You can
make a file descriptor point to any open file.

-dave


> -----Original Message-----
> From: Jackie Chang [mailto:jchang at eitc.epson.com]
> Sent: Thursday, August 07, 2003 1:48 PM
> To: SUFFIELD,DAVID (HP-Vancouver,ex1); 'Glen Petrie'
> Cc: HEMSTREET,CHARLES (HP-Vancouver,ex1)
> Subject: RE: Prompting IJS Version 1.0
>
>
> Hi, David:
> Thanks for your feedback.  The reason for proposing IJS 1.0
> with command line option -f to specify the communication
> channels between IJS client and server is that we have
> customers are requesting to pipe the output of IJS server to stdout.
>
> 1. ijssrv
> 2. ijssrv -f <client to server fd>,<server to client fd>
> Yes, the option 1 is really a work-around for IJS servers
> that don't use option 2. Do you have any solution to solve
> this problem for DOS/Windows environment?
>
> How does the value of "OutputFD" get guaranteed not to equal
> stdout?  Does Ghostscript do the checking for "OutputFD" not
> to equal stdout? In gdevijs.c fd = dup(fileno(ijsdev->file));
>
> Where is the value of "ijsdev->file" get assigned?  Isn't
> that "OutputFD" can still be possible be assigned to stdout?
>
> Regards,
> Jackie
>
> -----Original Message-----
> From: SUFFIELD,DAVID (HP-Vancouver,ex1) [mailto:david.suffield at hp.com]
> Sent: Monday, July 28, 2003 2:56 PM
> To: 'Glen Petrie'
> Cc: 'Jackie Chang (E-mail)'; HEMSTREET,CHARLES (HP-Vancouver,ex1)
> Subject: RE: Prompting IJS Version 1.0
>
> Hi Glen,
> Thanks for reminding me. I did test your latest IJS 1.0
> implementation with hpijs using the following command.
>
> ./ijs_client_example -s hpijs -l
>
> This test does work. A IJS 1.0 client is backward compatible
> with IJS 0.34 server. I did not try any printing tests, but
> here are my initial thoughts.
>
> IJS 1.0 has the following options for invoking the IJS server.
>
> 1. ijssrv
> 2. ijssrv -f <client to server fd>,<server to client fd>
>
> With IJS 1.0 Option 1 has a 3 second initial timeout. Option
> 1 is not a good option because of the timeout. Option 2 will
> always be faster because it has no timeout. A smaller timeout
> would minimize the issue, but not solve it. Option 1 is
> really a work-around for IJS servers that don't use option 2.
>
> What problem are you trying to solve? I mention before that
> Stdin/stdout is not a problem with hpijs since "OutputFD" is
> guaranteed not to equal stdout. This does not mean that
> "OutputFD" cannot point to stdout by using another file
> descriptor. See the dup() in Ghostscript's gdevijs.c.
>
> -dave
>
>
> > -----Original Message-----
> > From: Glen Petrie [mailto:glen.petrie at eitc.epson.com]
> > Sent: Thursday, July 24, 2003 7:32 AM
> > To: 'SUFFIELD,DAVID (HP-Vancouver,ex1)'
> > Cc: 'Jackie Chang (E-mail)'; 'HEMSTREET,CHARLES
> (HP-Vancouver,ex1)';
> > Glen (E-mail)
> > Subject: RE: Prompting IJS Version 1.0
> >
> >
> > Hello David,
> >
> > I was wondering if had a change to review our latest
> comments and IJS
> > package.  Epson is very interested in prompting version 1.0
> of IJS and
> > would like to have HP's backing.
> >
> > Rgds,
> > Glen W. Petrie
> > Manager, Software Printing Solutions
> > Epson Imaging Technology Center
> > 150 River Oaks Parkway, Suite 200
> > San Jose, CA, 95134
> > Voice: 408.576.4131  Fax: 408.474.0511
> >
> > -----Original Message-----
> > From: Glen Petrie [mailto:glen.petrie at eitc.epson.com]
> > Sent: Tuesday, July 08, 2003 2:11 PM
> > To: 'SUFFIELD,DAVID (HP-Vancouver,ex1)'
> > Cc: Glen (E-mail); Jackie Chang (E-mail); 'HEMSTREET,CHARLES
> > (HP-Vancouver,ex1)'
> > Subject: RE: Prompting IJS Version 1.0
> >
> > David
> > Sorry for the late reply...
> >
> > Attached is the new IJS v1.0 proposed release package that includes
> > the patch for IJS client 1.0 to work with IJS server 0.34
> under Linux
> > and DOS.  (I would leave the patch for DOS in the package for
> > reference. Although, the patch for DOS is not very clean.)
> >
> > Ideally, IJS v1.0 specification should be backward
> compatible with IJS
> > v0.34.  We do have the patch for IJS client v1.0 to work with IJS
> > server v0.34 under Linux.  But we didn't put the patch in
> the previous
> > IJS v1.0 proposed release package since we are not sure what Raph
> > Levien wants to do with this issue.
> >
> > Basically, under Linux IJS client will call "select"
> function to test
> > the availability of input data (the initialization handshake string
> > from the IJS server).  If IJS client doesn't receive the
> > initialization handshake string from IJS server within 3
> seconds, IJS
> > client will send a SIGKILL signal to the IJS server process to
> > terminate the incompatible IJS server process, and
> re-invoke the IJS
> > server in the old way (IJS v0.34 spec).
> >
> > However, this patch will not work under DOS since the "select"
> > function is defined to be a Windows sockets function and
> will always
> > return SOCKET_ERROR value. So under DOS, IJS client will
> call "_fstat"
> > to get the input data size from the receiving channel.  If
> IJS client
> > doesn't receive the initialization handshake string from IJS server
> > within 20 loops, then IJS client will terminate the IJS server, and
> > re-invoke the IJS server in the old way (IJS v0.34 spec).
> >
> > There are 2 problems are encountered when implementing the
> patch for
> > DOS. 1. The IJS server process ID value returned back from the
> > ijs_exec_server
> > (ijs_exec_win.c) seems to be incorrect.  (The
> piProcInfo.dwProcessId
> > contains a big negative number.) 2. I can't find a clean way to
> > terminate the IJS server process under DOS. One of the MSDN
> knowledge
> > base articles states that "kill -f pid" can force terminate the pid
> > process. However, the "kill" system function doesn't appear to be a
> > standard system function under DOS. We will to future
> > investigation or seek help from DOS/Windows experts to solve
> > these problems.
> >
> > Please provide your comments on this solution and how we
> can proceed
> > forward in getting adoption from the community? Rgds, Glen
> W. Petrie
> > Manager, Software Printing Solutions Epson Imaging
> Technology Center
> > 150 River Oaks Parkway, Suite 200 San Jose, CA, 95134
> > Voice: 408.576.4131  Fax: 408.474.0511
> >
> > -----Original Message-----
> > From: SUFFIELD,DAVID (HP-Vancouver,ex1)
> [mailto:david.suffield at hp.com]
> > Sent: Thursday, June 26, 2003 4:59 PM
> > To: 'Glen Petrie'
> > Cc: HEMSTREET,CHARLES (HP-Vancouver,ex1)
> > Subject: RE: Prompting IJS Version 1.0
> >
> > Hi Glen,
> > I do have an issue with your proposed IJS 1.0 stdin/stdout change.
> > After looking at the code, I don't believe IJS 1.0 is backward
> > compatible with IJS 0.34. The README says the IJS client can be
> > invoked by either one of the following commands.
> >
> > ijssrv
> > ijssrv -f <client to server fd>,<server to client fd>
> >
> > But, ijs_exec_unix.c is hardcoded to support the "-f
> <client to server
> > fd>,<server to client fd>" syntax only when V0100 is defined.
> > This means
> > fd>the
> > stdin/stout change is a compile time option not a runtime
> option. IJS
> > 0.34 servers will not be compatible with IJS 1.0 clients.
> >
> > Stdin/stdout is not a problem with hpijs since "OutputFD" is
> > guaranteed not to equal stdout in the Ghostscript IJS client
> > gdevijs.c.
> >
> > The standardized Quality parameters should be ok as long as
> they are
> > optional.
> >
> > -dave
> >
> >
> > -----Original Message-----
> > From: Glen Petrie [mailto:glen.petrie at eitc.epson.com]
> > Sent: Wednesday, June 25, 2003 6:56 AM
> > To: 'Charles Hemstreet'; david_suffield at hp.com
> > Cc: Glen (E-mail)
> > Subject: Prompting IJS Version 1.0
> >
> >
> > Hello Charles and David,
> >
> > During last week FSG meeting in Portland, I discussed with you that
> > Epson was trying to work with Raph Levin on releasing
> Version 1.0 of
> > the IJS specification and reference implementation.  Raph has been
> > extremely busy since he took over GhostScript and has been
> unable to
> > address ratifying the Version 1.0 release package of IJS
> that my team
> > has pulled together. Discussion on the changes for Version 1.0 have
> > been reviewed on the IJS DL
> > and generally agreed upon.   I have enclosed the proposed
> > Version 1.0 IJS
> > release package for your review.   Assuming you agree with
> > the Version 1.0
> > modification, I would like to propose that HP and Epson
> > jointly support and request ratification by the IJS community
> > of the proposed Version 1.0
> > release package.   Please provide me any feed back on the
> > release package
> > and your comments on supporting ratification.
> >
> > Rgds,
> > Glen W. Petrie
> > Manager, Software Printing Solutions
> > Epson Imaging Technology Center
> > 150 River Oaks Parkway, Suite 200
> > San Jose, CA, 95134
> > Voice: 408.576.4131  Fax: 408.474.0511
> >
>



From gsview at ghostgum.com.au  Mon Aug 11 15:04:45 2003
From: gsview at ghostgum.com.au (Russell Lang)
Date: Tue, 12 Aug 2003 08:04:45 +1000
Subject: [Inkjet-list] RE: Prompting IJS Version 1.0
In-Reply-To: <NHBBKCMCMLMNOJFAOLOAGEBOCGAA.jchang@eitc.epson.com>
References: <A134E2426B46D711BB4B000347AE6E7C01028A26@xvan02.vcd.hp.com>
Message-ID: <3F389F9D.526.6E692AC6@localhost>

Jackie,

The following assumes IJS 0.34 and that OutputFD has been used.
The server is started with 3 open file descriptors. 0 = stdin, 
1=stdout, and x=OutputFD.  If your IJS server really needs the 
output raster to be written to stdout, then your server needs to 
reassign file descriptors.  As I understand it, you could use
  new_stdoutfd = dup(1);
  dup2(OutputFD, 1);
Then you need to tell IJS that the fd_to is new_stdoutfd.

This doesn't require any changes to the IJS protocol.
What it does require is a minor change to ijs_server_invoke in 
ijs_server.c to add the dup() above.  unistd_.h will also 
require adding a macro for Windows to redefine dup2 to _dup2.


Russell


On 11 Aug 2003 at 13:58, Jackie Chang wrote:

> Hi:
> Sorry that I didn't word it clearly on the "output of IJS server".  I mean
> our customer wants to pipe the "printing data output produced by the IJS
> server" to stdout.  An IJS server may act as a pre-processor of another
> process.
> 
> This means that "OutputFD" can point to the same file table as stdout and
> the IJS protocol can still use pipes over stdin/stdout.
> 
> I am not sure how I can use the same file table as the IPC channel and at
> the same time as the data container of the actual printing (or pre-printing)
> data produced by the IJS server.
> 
> Regards,
> Jackie
> -----Original Message-----
> From: SUFFIELD,DAVID (HP-Vancouver,ex1) [mailto:david.suffield at hp.com]
> Sent: Monday, August 11, 2003 12:19 PM
> To: 'Jackie Chang'; 'Glen Petrie'
> Cc: HEMSTREET,CHARLES (HP-Vancouver,ex1); inkjet-list at linuxprinting.org
> Subject: RE: Prompting IJS Version 1.0
> 
> I'm not sure why we need the "ijssrv -f <client to server fd>,<server to
> client fd>" option proposed in IJS 1.0.
> 
> Piping the ijs server output to stdout is the normal configuration for the
> ijs client/server printing application (ie: ghostscript/hpijs). The current
> IJS 0.34 interface works great for this configuration.
> 
> How does this work if the ijs client/server also uses stdin/stdout for IPC?
> The key point is the "fd = dup(fileno(ijsdev->file))" call in gdevijs.c.
> 
> The dup guarantees that "OutputFD" does not use the same stdout file
> descriptor, but fd will still use the same output path or file table
> specified by stdout.
> 
> This means that "OutputFD" can point to the same file table as stdout and
> the IJS protocol can still use pipes over stdin/stdout.
> 
> Remember file descriptors are just indexes into the kernel's open file
> table. Stdin, stdout and stderr use file descriptors 0, 1 and 2. You can
> make a file descriptor point to any open file.
> 
> -dave
> 
> 
> > -----Original Message-----
> > From: Jackie Chang [mailto:jchang at eitc.epson.com]
> > Sent: Thursday, August 07, 2003 1:48 PM
> > To: SUFFIELD,DAVID (HP-Vancouver,ex1); 'Glen Petrie'
> > Cc: HEMSTREET,CHARLES (HP-Vancouver,ex1)
> > Subject: RE: Prompting IJS Version 1.0
> >
> >
> > Hi, David:
> > Thanks for your feedback.  The reason for proposing IJS 1.0
> > with command line option -f to specify the communication
> > channels between IJS client and server is that we have
> > customers are requesting to pipe the output of IJS server to stdout.
> >
> > 1. ijssrv
> > 2. ijssrv -f <client to server fd>,<server to client fd>
> > Yes, the option 1 is really a work-around for IJS servers
> > that don't use option 2. Do you have any solution to solve
> > this problem for DOS/Windows environment?
> >
> > How does the value of "OutputFD" get guaranteed not to equal
> > stdout?  Does Ghostscript do the checking for "OutputFD" not
> > to equal stdout? In gdevijs.c fd = dup(fileno(ijsdev->file));
> >
> > Where is the value of "ijsdev->file" get assigned?  Isn't
> > that "OutputFD" can still be possible be assigned to stdout?
> >
> > Regards,
> > Jackie
> >
> > -----Original Message-----
> > From: SUFFIELD,DAVID (HP-Vancouver,ex1) [mailto:david.suffield at hp.com]
> > Sent: Monday, July 28, 2003 2:56 PM
> > To: 'Glen Petrie'
> > Cc: 'Jackie Chang (E-mail)'; HEMSTREET,CHARLES (HP-Vancouver,ex1)
> > Subject: RE: Prompting IJS Version 1.0
> >
> > Hi Glen,
> > Thanks for reminding me. I did test your latest IJS 1.0
> > implementation with hpijs using the following command.
> >
> > ./ijs_client_example -s hpijs -l
> >
> > This test does work. A IJS 1.0 client is backward compatible
> > with IJS 0.34 server. I did not try any printing tests, but
> > here are my initial thoughts.
> >
> > IJS 1.0 has the following options for invoking the IJS server.
> >
> > 1. ijssrv
> > 2. ijssrv -f <client to server fd>,<server to client fd>
> >
> > With IJS 1.0 Option 1 has a 3 second initial timeout. Option
> > 1 is not a good option because of the timeout. Option 2 will
> > always be faster because it has no timeout. A smaller timeout
> > would minimize the issue, but not solve it. Option 1 is
> > really a work-around for IJS servers that don't use option 2.
> >
> > What problem are you trying to solve? I mention before that
> > Stdin/stdout is not a problem with hpijs since "OutputFD" is
> > guaranteed not to equal stdout. This does not mean that
> > "OutputFD" cannot point to stdout by using another file
> > descriptor. See the dup() in Ghostscript's gdevijs.c.
> >
> > -dave
> >
> >
> > > -----Original Message-----
> > > From: Glen Petrie [mailto:glen.petrie at eitc.epson.com]
> > > Sent: Thursday, July 24, 2003 7:32 AM
> > > To: 'SUFFIELD,DAVID (HP-Vancouver,ex1)'
> > > Cc: 'Jackie Chang (E-mail)'; 'HEMSTREET,CHARLES
> > (HP-Vancouver,ex1)';
> > > Glen (E-mail)
> > > Subject: RE: Prompting IJS Version 1.0
> > >
> > >
> > > Hello David,
> > >
> > > I was wondering if had a change to review our latest
> > comments and IJS
> > > package.  Epson is very interested in prompting version 1.0
> > of IJS and
> > > would like to have HP's backing.
> > >
> > > Rgds,
> > > Glen W. Petrie
> > > Manager, Software Printing Solutions
> > > Epson Imaging Technology Center
> > > 150 River Oaks Parkway, Suite 200
> > > San Jose, CA, 95134
> > > Voice: 408.576.4131  Fax: 408.474.0511
> > >
> > > -----Original Message-----
> > > From: Glen Petrie [mailto:glen.petrie at eitc.epson.com]
> > > Sent: Tuesday, July 08, 2003 2:11 PM
> > > To: 'SUFFIELD,DAVID (HP-Vancouver,ex1)'
> > > Cc: Glen (E-mail); Jackie Chang (E-mail); 'HEMSTREET,CHARLES
> > > (HP-Vancouver,ex1)'
> > > Subject: RE: Prompting IJS Version 1.0
> > >
> > > David
> > > Sorry for the late reply...
> > >
> > > Attached is the new IJS v1.0 proposed release package that includes
> > > the patch for IJS client 1.0 to work with IJS server 0.34
> > under Linux
> > > and DOS.  (I would leave the patch for DOS in the package for
> > > reference. Although, the patch for DOS is not very clean.)
> > >
> > > Ideally, IJS v1.0 specification should be backward
> > compatible with IJS
> > > v0.34.  We do have the patch for IJS client v1.0 to work with IJS
> > > server v0.34 under Linux.  But we didn't put the patch in
> > the previous
> > > IJS v1.0 proposed release package since we are not sure what Raph
> > > Levien wants to do with this issue.
> > >
> > > Basically, under Linux IJS client will call "select"
> > function to test
> > > the availability of input data (the initialization handshake string
> > > from the IJS server).  If IJS client doesn't receive the
> > > initialization handshake string from IJS server within 3
> > seconds, IJS
> > > client will send a SIGKILL signal to the IJS server process to
> > > terminate the incompatible IJS server process, and
> > re-invoke the IJS
> > > server in the old way (IJS v0.34 spec).
> > >
> > > However, this patch will not work under DOS since the "select"
> > > function is defined to be a Windows sockets function and
> > will always
> > > return SOCKET_ERROR value. So under DOS, IJS client will
> > call "_fstat"
> > > to get the input data size from the receiving channel.  If
> > IJS client
> > > doesn't receive the initialization handshake string from IJS server
> > > within 20 loops, then IJS client will terminate the IJS server, and
> > > re-invoke the IJS server in the old way (IJS v0.34 spec).
> > >
> > > There are 2 problems are encountered when implementing the
> > patch for
> > > DOS. 1. The IJS server process ID value returned back from the
> > > ijs_exec_server
> > > (ijs_exec_win.c) seems to be incorrect.  (The
> > piProcInfo.dwProcessId
> > > contains a big negative number.) 2. I can't find a clean way to
> > > terminate the IJS server process under DOS. One of the MSDN
> > knowledge
> > > base articles states that "kill -f pid" can force terminate the pid
> > > process. However, the "kill" system function doesn't appear to be a
> > > standard system function under DOS. We will to future
> > > investigation or seek help from DOS/Windows experts to solve
> > > these problems.
> > >
> > > Please provide your comments on this solution and how we
> > can proceed
> > > forward in getting adoption from the community? Rgds, Glen
> > W. Petrie
> > > Manager, Software Printing Solutions Epson Imaging
> > Technology Center
> > > 150 River Oaks Parkway, Suite 200 San Jose, CA, 95134
> > > Voice: 408.576.4131  Fax: 408.474.0511
> > >
> > > -----Original Message-----
> > > From: SUFFIELD,DAVID (HP-Vancouver,ex1)
> > [mailto:david.suffield at hp.com]
> > > Sent: Thursday, June 26, 2003 4:59 PM
> > > To: 'Glen Petrie'
> > > Cc: HEMSTREET,CHARLES (HP-Vancouver,ex1)
> > > Subject: RE: Prompting IJS Version 1.0
> > >
> > > Hi Glen,
> > > I do have an issue with your proposed IJS 1.0 stdin/stdout change.
> > > After looking at the code, I don't believe IJS 1.0 is backward
> > > compatible with IJS 0.34. The README says the IJS client can be
> > > invoked by either one of the following commands.
> > >
> > > ijssrv
> > > ijssrv -f <client to server fd>,<server to client fd>
> > >
> > > But, ijs_exec_unix.c is hardcoded to support the "-f
> > <client to server
> > > fd>,<server to client fd>" syntax only when V0100 is defined.
> > > This means
> > > fd>the
> > > stdin/stout change is a compile time option not a runtime
> > option. IJS
> > > 0.34 servers will not be compatible with IJS 1.0 clients.
> > >
> > > Stdin/stdout is not a problem with hpijs since "OutputFD" is
> > > guaranteed not to equal stdout in the Ghostscript IJS client
> > > gdevijs.c.
> > >
> > > The standardized Quality parameters should be ok as long as
> > they are
> > > optional.
> > >
> > > -dave
> > >
> > >
> > > -----Original Message-----
> > > From: Glen Petrie [mailto:glen.petrie at eitc.epson.com]
> > > Sent: Wednesday, June 25, 2003 6:56 AM
> > > To: 'Charles Hemstreet'; david_suffield at hp.com
> > > Cc: Glen (E-mail)
> > > Subject: Prompting IJS Version 1.0
> > >
> > >
> > > Hello Charles and David,
> > >
> > > During last week FSG meeting in Portland, I discussed with you that
> > > Epson was trying to work with Raph Levin on releasing
> > Version 1.0 of
> > > the IJS specification and reference implementation.  Raph has been
> > > extremely busy since he took over GhostScript and has been
> > unable to
> > > address ratifying the Version 1.0 release package of IJS
> > that my team
> > > has pulled together. Discussion on the changes for Version 1.0 have
> > > been reviewed on the IJS DL
> > > and generally agreed upon.   I have enclosed the proposed
> > > Version 1.0 IJS
> > > release package for your review.   Assuming you agree with
> > > the Version 1.0
> > > modification, I would like to propose that HP and Epson
> > > jointly support and request ratification by the IJS community
> > > of the proposed Version 1.0
> > > release package.   Please provide me any feed back on the
> > > release package
> > > and your comments on supporting ratification.
> > >
> > > Rgds,
> > > Glen W. Petrie
> > > Manager, Software Printing Solutions
> > > Epson Imaging Technology Center
> > > 150 River Oaks Parkway, Suite 200
> > > San Jose, CA, 95134
> > > Voice: 408.576.4131  Fax: 408.474.0511
> > >
> >
> 
> _______________________________________________
> Inkjet-list mailing list
> Inkjet-list at linuxprinting.org
> http://www.linuxprinting.org/cgi-bin/mailman/listinfo/inkjet-list


Russell Lang                   gsview at ghostgum.com.au
Ghostgum Software Pty Ltd      http://www.ghostgum.com.au/




From jchang at eitc.epson.com  Tue Aug 12 09:35:09 2003
From: jchang at eitc.epson.com (Jackie Chang)
Date: Tue, 12 Aug 2003 09:35:09 -0700
Subject: [Inkjet-list] RE: Prompting IJS Version 1.0
In-Reply-To: <3F389F9D.526.6E692AC6@localhost>
Message-ID: <NHBBKCMCMLMNOJFAOLOAOECACGAA.jchang@eitc.epson.com>

Hi, Russell:
Your solution is great.

Thanks for your input,
Jackie

-----Original Message-----
From: Russell Lang [mailto:gsview at ghostgum.com.au]
Sent: Monday, August 11, 2003 3:05 PM
To: Jackie Chang
Cc: HEMSTREET,CHARLES HHP-Vancouver,ex1"; inkjet-list at linuxprinting.org;
'Glen Petrie'
Subject: Re: [Inkjet-list] RE: Prompting IJS Version 1.0

Jackie,

The following assumes IJS 0.34 and that OutputFD has been used.
The server is started with 3 open file descriptors. 0 = stdin,
1=stdout, and x=OutputFD.  If your IJS server really needs the
output raster to be written to stdout, then your server needs to
reassign file descriptors.  As I understand it, you could use
  new_stdoutfd = dup(1);
  dup2(OutputFD, 1);
Then you need to tell IJS that the fd_to is new_stdoutfd.

This doesn't require any changes to the IJS protocol.
What it does require is a minor change to ijs_server_invoke in
ijs_server.c to add the dup() above.  unistd_.h will also
require adding a macro for Windows to redefine dup2 to _dup2.


Russell


On 11 Aug 2003 at 13:58, Jackie Chang wrote:

> Hi:
> Sorry that I didn't word it clearly on the "output of IJS server".  I mean
> our customer wants to pipe the "printing data output produced by the IJS
> server" to stdout.  An IJS server may act as a pre-processor of another
> process.
>
> This means that "OutputFD" can point to the same file table as stdout and
> the IJS protocol can still use pipes over stdin/stdout.
>
> I am not sure how I can use the same file table as the IPC channel and at
> the same time as the data container of the actual printing (or
pre-printing)
> data produced by the IJS server.
>
> Regards,
> Jackie
> -----Original Message-----
> From: SUFFIELD,DAVID (HP-Vancouver,ex1) [mailto:david.suffield at hp.com]
> Sent: Monday, August 11, 2003 12:19 PM
> To: 'Jackie Chang'; 'Glen Petrie'
> Cc: HEMSTREET,CHARLES (HP-Vancouver,ex1); inkjet-list at linuxprinting.org
> Subject: RE: Prompting IJS Version 1.0
>
> I'm not sure why we need the "ijssrv -f <client to server fd>,<server to
> client fd>" option proposed in IJS 1.0.
>
> Piping the ijs server output to stdout is the normal configuration for the
> ijs client/server printing application (ie: ghostscript/hpijs). The
current
> IJS 0.34 interface works great for this configuration.
>
> How does this work if the ijs client/server also uses stdin/stdout for
IPC?
> The key point is the "fd = dup(fileno(ijsdev->file))" call in gdevijs.c.
>
> The dup guarantees that "OutputFD" does not use the same stdout file
> descriptor, but fd will still use the same output path or file table
> specified by stdout.
>
> This means that "OutputFD" can point to the same file table as stdout and
> the IJS protocol can still use pipes over stdin/stdout.
>
> Remember file descriptors are just indexes into the kernel's open file
> table. Stdin, stdout and stderr use file descriptors 0, 1 and 2. You can
> make a file descriptor point to any open file.
>
> -dave
>
>
> > -----Original Message-----
> > From: Jackie Chang [mailto:jchang at eitc.epson.com]
> > Sent: Thursday, August 07, 2003 1:48 PM
> > To: SUFFIELD,DAVID (HP-Vancouver,ex1); 'Glen Petrie'
> > Cc: HEMSTREET,CHARLES (HP-Vancouver,ex1)
> > Subject: RE: Prompting IJS Version 1.0
> >
> >
> > Hi, David:
> > Thanks for your feedback.  The reason for proposing IJS 1.0
> > with command line option -f to specify the communication
> > channels between IJS client and server is that we have
> > customers are requesting to pipe the output of IJS server to stdout.
> >
> > 1. ijssrv
> > 2. ijssrv -f <client to server fd>,<server to client fd>
> > Yes, the option 1 is really a work-around for IJS servers
> > that don't use option 2. Do you have any solution to solve
> > this problem for DOS/Windows environment?
> >
> > How does the value of "OutputFD" get guaranteed not to equal
> > stdout?  Does Ghostscript do the checking for "OutputFD" not
> > to equal stdout? In gdevijs.c fd = dup(fileno(ijsdev->file));
> >
> > Where is the value of "ijsdev->file" get assigned?  Isn't
> > that "OutputFD" can still be possible be assigned to stdout?
> >
> > Regards,
> > Jackie
> >
> > -----Original Message-----
> > From: SUFFIELD,DAVID (HP-Vancouver,ex1) [mailto:david.suffield at hp.com]
> > Sent: Monday, July 28, 2003 2:56 PM
> > To: 'Glen Petrie'
> > Cc: 'Jackie Chang (E-mail)'; HEMSTREET,CHARLES (HP-Vancouver,ex1)
> > Subject: RE: Prompting IJS Version 1.0
> >
> > Hi Glen,
> > Thanks for reminding me. I did test your latest IJS 1.0
> > implementation with hpijs using the following command.
> >
> > ./ijs_client_example -s hpijs -l
> >
> > This test does work. A IJS 1.0 client is backward compatible
> > with IJS 0.34 server. I did not try any printing tests, but
> > here are my initial thoughts.
> >
> > IJS 1.0 has the following options for invoking the IJS server.
> >
> > 1. ijssrv
> > 2. ijssrv -f <client to server fd>,<server to client fd>
> >
> > With IJS 1.0 Option 1 has a 3 second initial timeout. Option
> > 1 is not a good option because of the timeout. Option 2 will
> > always be faster because it has no timeout. A smaller timeout
> > would minimize the issue, but not solve it. Option 1 is
> > really a work-around for IJS servers that don't use option 2.
> >
> > What problem are you trying to solve? I mention before that
> > Stdin/stdout is not a problem with hpijs since "OutputFD" is
> > guaranteed not to equal stdout. This does not mean that
> > "OutputFD" cannot point to stdout by using another file
> > descriptor. See the dup() in Ghostscript's gdevijs.c.
> >
> > -dave
> >
> >
> > > -----Original Message-----
> > > From: Glen Petrie [mailto:glen.petrie at eitc.epson.com]
> > > Sent: Thursday, July 24, 2003 7:32 AM
> > > To: 'SUFFIELD,DAVID (HP-Vancouver,ex1)'
> > > Cc: 'Jackie Chang (E-mail)'; 'HEMSTREET,CHARLES
> > (HP-Vancouver,ex1)';
> > > Glen (E-mail)
> > > Subject: RE: Prompting IJS Version 1.0
> > >
> > >
> > > Hello David,
> > >
> > > I was wondering if had a change to review our latest
> > comments and IJS
> > > package.  Epson is very interested in prompting version 1.0
> > of IJS and
> > > would like to have HP's backing.
> > >
> > > Rgds,
> > > Glen W. Petrie
> > > Manager, Software Printing Solutions
> > > Epson Imaging Technology Center
> > > 150 River Oaks Parkway, Suite 200
> > > San Jose, CA, 95134
> > > Voice: 408.576.4131  Fax: 408.474.0511
> > >
> > > -----Original Message-----
> > > From: Glen Petrie [mailto:glen.petrie at eitc.epson.com]
> > > Sent: Tuesday, July 08, 2003 2:11 PM
> > > To: 'SUFFIELD,DAVID (HP-Vancouver,ex1)'
> > > Cc: Glen (E-mail); Jackie Chang (E-mail); 'HEMSTREET,CHARLES
> > > (HP-Vancouver,ex1)'
> > > Subject: RE: Prompting IJS Version 1.0
> > >
> > > David
> > > Sorry for the late reply...
> > >
> > > Attached is the new IJS v1.0 proposed release package that includes
> > > the patch for IJS client 1.0 to work with IJS server 0.34
> > under Linux
> > > and DOS.  (I would leave the patch for DOS in the package for
> > > reference. Although, the patch for DOS is not very clean.)
> > >
> > > Ideally, IJS v1.0 specification should be backward
> > compatible with IJS
> > > v0.34.  We do have the patch for IJS client v1.0 to work with IJS
> > > server v0.34 under Linux.  But we didn't put the patch in
> > the previous
> > > IJS v1.0 proposed release package since we are not sure what Raph
> > > Levien wants to do with this issue.
> > >
> > > Basically, under Linux IJS client will call "select"
> > function to test
> > > the availability of input data (the initialization handshake string
> > > from the IJS server).  If IJS client doesn't receive the
> > > initialization handshake string from IJS server within 3
> > seconds, IJS
> > > client will send a SIGKILL signal to the IJS server process to
> > > terminate the incompatible IJS server process, and
> > re-invoke the IJS
> > > server in the old way (IJS v0.34 spec).
> > >
> > > However, this patch will not work under DOS since the "select"
> > > function is defined to be a Windows sockets function and
> > will always
> > > return SOCKET_ERROR value. So under DOS, IJS client will
> > call "_fstat"
> > > to get the input data size from the receiving channel.  If
> > IJS client
> > > doesn't receive the initialization handshake string from IJS server
> > > within 20 loops, then IJS client will terminate the IJS server, and
> > > re-invoke the IJS server in the old way (IJS v0.34 spec).
> > >
> > > There are 2 problems are encountered when implementing the
> > patch for
> > > DOS. 1. The IJS server process ID value returned back from the
> > > ijs_exec_server
> > > (ijs_exec_win.c) seems to be incorrect.  (The
> > piProcInfo.dwProcessId
> > > contains a big negative number.) 2. I can't find a clean way to
> > > terminate the IJS server process under DOS. One of the MSDN
> > knowledge
> > > base articles states that "kill -f pid" can force terminate the pid
> > > process. However, the "kill" system function doesn't appear to be a
> > > standard system function under DOS. We will to future
> > > investigation or seek help from DOS/Windows experts to solve
> > > these problems.
> > >
> > > Please provide your comments on this solution and how we
> > can proceed
> > > forward in getting adoption from the community? Rgds, Glen
> > W. Petrie
> > > Manager, Software Printing Solutions Epson Imaging
> > Technology Center
> > > 150 River Oaks Parkway, Suite 200 San Jose, CA, 95134
> > > Voice: 408.576.4131  Fax: 408.474.0511
> > >
> > > -----Original Message-----
> > > From: SUFFIELD,DAVID (HP-Vancouver,ex1)
> > [mailto:david.suffield at hp.com]
> > > Sent: Thursday, June 26, 2003 4:59 PM
> > > To: 'Glen Petrie'
> > > Cc: HEMSTREET,CHARLES (HP-Vancouver,ex1)
> > > Subject: RE: Prompting IJS Version 1.0
> > >
> > > Hi Glen,
> > > I do have an issue with your proposed IJS 1.0 stdin/stdout change.
> > > After looking at the code, I don't believe IJS 1.0 is backward
> > > compatible with IJS 0.34. The README says the IJS client can be
> > > invoked by either one of the following commands.
> > >
> > > ijssrv
> > > ijssrv -f <client to server fd>,<server to client fd>
> > >
> > > But, ijs_exec_unix.c is hardcoded to support the "-f
> > <client to server
> > > fd>,<server to client fd>" syntax only when V0100 is defined.
> > > This means
> > > fd>the
> > > stdin/stout change is a compile time option not a runtime
> > option. IJS
> > > 0.34 servers will not be compatible with IJS 1.0 clients.
> > >
> > > Stdin/stdout is not a problem with hpijs since "OutputFD" is
> > > guaranteed not to equal stdout in the Ghostscript IJS client
> > > gdevijs.c.
> > >
> > > The standardized Quality parameters should be ok as long as
> > they are
> > > optional.
> > >
> > > -dave
> > >
> > >
> > > -----Original Message-----
> > > From: Glen Petrie [mailto:glen.petrie at eitc.epson.com]
> > > Sent: Wednesday, June 25, 2003 6:56 AM
> > > To: 'Charles Hemstreet'; david_suffield at hp.com
> > > Cc: Glen (E-mail)
> > > Subject: Prompting IJS Version 1.0
> > >
> > >
> > > Hello Charles and David,
> > >
> > > During last week FSG meeting in Portland, I discussed with you that
> > > Epson was trying to work with Raph Levin on releasing
> > Version 1.0 of
> > > the IJS specification and reference implementation.  Raph has been
> > > extremely busy since he took over GhostScript and has been
> > unable to
> > > address ratifying the Version 1.0 release package of IJS
> > that my team
> > > has pulled together. Discussion on the changes for Version 1.0 have
> > > been reviewed on the IJS DL
> > > and generally agreed upon.   I have enclosed the proposed
> > > Version 1.0 IJS
> > > release package for your review.   Assuming you agree with
> > > the Version 1.0
> > > modification, I would like to propose that HP and Epson
> > > jointly support and request ratification by the IJS community
> > > of the proposed Version 1.0
> > > release package.   Please provide me any feed back on the
> > > release package
> > > and your comments on supporting ratification.
> > >
> > > Rgds,
> > > Glen W. Petrie
> > > Manager, Software Printing Solutions
> > > Epson Imaging Technology Center
> > > 150 River Oaks Parkway, Suite 200
> > > San Jose, CA, 95134
> > > Voice: 408.576.4131  Fax: 408.474.0511
> > >
> >
>
> _______________________________________________
> Inkjet-list mailing list
> Inkjet-list at linuxprinting.org
> http://www.linuxprinting.org/cgi-bin/mailman/listinfo/inkjet-list


Russell Lang                   gsview at ghostgum.com.au
Ghostgum Software Pty Ltd      http://www.ghostgum.com.au/



From roger at whinlatter.uklinux.net  Mon Aug 11 11:23:19 2003
From: roger at whinlatter.uklinux.net (Roger Leigh)
Date: Mon, 11 Aug 2003 19:23:19 +0100
Subject: [Inkjet-list] CORRECTION: Proposed IJS v1.0 package available
In-Reply-To: <NHBBKCMCMLMNOJFAOLOACEBKCGAA.jchang@eitc.epson.com> (Jackie
 Chang's message of "Mon, 11 Aug 2003 09:41:15 -0700")
References: <NHBBKCMCMLMNOJFAOLOACEBKCGAA.jchang@eitc.epson.com>
Message-ID: <87ekzskq94.fsf@whinlatter.uklinux.net>

"Jackie Chang" <jchang at eitc.epson.com> writes:

> Hi, All:
> Sorry that I didn't provide the proposed IJS v1.0 specification in the PDF
> format since I don't have the original file of ijs_spec.pdf.

The original file is "ijs_spec.sgml" in the ijs package and CVS.  It's
written in DocBook/SGML.


Regards,
Roger

-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848 available on public keyservers


From eniac_exploit at yahoo.com.ar  Mon Aug 25 06:26:41 2003
From: eniac_exploit at yahoo.com.ar (german aracil boned)
Date: Mon, 25 Aug 2003 15:26:41 +0200
Subject: [Inkjet-list] new file system open source
Message-ID: <bid2tp$k8j$14@poblano.linuxprinting.org>

Hello

I'm Germ?n.
TL System is a free file system in database (firebird).
http://sourceforge.net/projects/tlsystem

It's my project

thank



From news-208-200-158-201.in-addr.net1plus.com_linuxprinting.inkjet.architecture at freecyberzone.com  Mon Sep  1 13:17:32 2003
From: news-208-200-158-201.in-addr.net1plus.com_linuxprinting.inkjet.architecture at freecyberzone.com (news-208-200-158-201.in-addr.net1plus.com_linuxprinting.inkjet.architecture at freecyberzone.com)
Date: Mon, 01 Sep 03 20:17:32 GMT
Subject: [Inkjet-list] 100msec Anti-S*P*A*M msg {49333}
Message-ID: <03090120173225@208-200-158-201.in-addr.net1plus.com>

{49333} S*P*A*M seeding msg - please ignore



From jchang at eitc.epson.com  Tue Sep 23 14:29:57 2003
From: jchang at eitc.epson.com (Jackie Chang)
Date: Tue, 23 Sep 2003 14:29:57 -0700
Subject: [Inkjet-list] Announcing Last Call for IJS v1.0 package
Message-ID: <NHBBKCMCMLMNOJFAOLOACEKGCGAA.jchang@eitc.epson.com>

Hi, All:
This is the announcement to begin the Last Call process for "IJS v1.0
Specification".  The Last Call will last for 4 weeks.

Epson has updated the IJS v1.0 specification according to the
feedback/comments on the Inkjet Print Community.  Also, Russell Lang's
OutputFD fix for Windows has been integrated into the sample code.

Please download the proposed IJS v1.0
package from http://www.eitcsv.com/sps/2003/ijs-v1.00-Sep092003.tar.gz

Please review the proposed IJS v1.0 specification document, and sample code
implementation.  We need your vote for adopting this proposed IJS v1.0
package as the official release of IJS v1.0 package.


Your feedback and help are needed to move the IJS forward.


From rlk at alum.mit.edu  Wed Sep 24 04:44:29 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Wed, 24 Sep 2003 07:44:29 -0400
Subject: [Inkjet-list] Announcing Last Call for IJS v1.0 package
In-Reply-To: <NHBBKCMCMLMNOJFAOLOACEKGCGAA.jchang@eitc.epson.com>
References: <NHBBKCMCMLMNOJFAOLOACEKGCGAA.jchang@eitc.epson.com>
Message-ID: <200309241144.h8OBiTVc024247@dsl092-065-009.bos1.dsl.speakeasy.net>

   From: "Jackie Chang" <jchang at eitc.epson.com>
   Date: Tue, 23 Sep 2003 14:29:57 -0700

   Hi, All:
   This is the announcement to begin the Last Call process for "IJS v1.0
   Specification".  The Last Call will last for 4 weeks.

   Epson has updated the IJS v1.0 specification according to the
   feedback/comments on the Inkjet Print Community.  Also, Russell Lang's
   OutputFD fix for Windows has been integrated into the sample code.

   Please download the proposed IJS v1.0
   package from http://www.eitcsv.com/sps/2003/ijs-v1.00-Sep092003.tar.gz

   Please review the proposed IJS v1.0 specification document, and sample code
   implementation.  We need your vote for adopting this proposed IJS v1.0
   package as the official release of IJS v1.0 package.

1) The sample code doesn't actually compile:

$ make
gcc -g -Wall -ansi -pedantic -Wmissing-prototypes   -c -o ijs.o ijs.c
gcc -g -Wall -ansi -pedantic -Wmissing-prototypes   -c -o ijs_client.o ijs_client.c
gcc -g -Wall -ansi -pedantic -Wmissing-prototypes   -c -o ijs_server.o ijs_server.c
ijs_server.c: In function `ijs_server_proc_begin_page':
ijs_server.c:698: warning: int format, pointer arg (arg 5)
make: *** No rule to make target `ijs_exec_unix.o', needed by `libijs.a'.  Stop.

2) I'm thinking more and more that "client" and "server" are really
   the wrong names here, because this really isn't a client-server
   architecture, but more of a front-end/back-end architecture.
   In a typical client-server scenario, the server responds to
   requests from clients.  In this case, the "server" is invoked by
   the "client" to perform a single batch-processing step.

   Also, the back end ("server") is not expected to be secure (see
   section 5.1), and there is no security on the protocol.  Therefore
   it is not safe to write a "server" that listens for requests in
   some way; the "client" is responsible for all security checking.
   In a front-end/back-end architecture this is expected.

I'll have more comments later.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton


From jchang at eitc.epson.com  Wed Sep 24 11:08:28 2003
From: jchang at eitc.epson.com (Jackie Chang)
Date: Wed, 24 Sep 2003 11:08:28 -0700
Subject: [Inkjet-list] Announcing Last Call for IJS v1.0 package
In-Reply-To: <200309241144.h8OBiTVc024247@dsl092-065-009.bos1.dsl.speakeasy.net>
Message-ID: <NHBBKCMCMLMNOJFAOLOAGEKMCGAA.jchang@eitc.epson.com>

Hi:
I have attached the updated Makefile.in file here to sync with the
modification that I edited to the Makefile and Makefile.linux.  Please
replace your Makefile.in with this attached Makefile.in.

Thanks for your comments

-----Original Message-----
From: Robert L Krawitz [mailto:rlk at alum.mit.edu]
Sent: Wednesday, September 24, 2003 4:44 AM
To: jchang at eitc.epson.com
Cc: inkjet-list at linuxprinting.org
Subject: Re: [Inkjet-list] Announcing Last Call for IJS v1.0 package


   From: "Jackie Chang" <jchang at eitc.epson.com>
   Date: Tue, 23 Sep 2003 14:29:57 -0700

   Hi, All:
   This is the announcement to begin the Last Call process for "IJS v1.0
   Specification".  The Last Call will last for 4 weeks.

   Epson has updated the IJS v1.0 specification according to the
   feedback/comments on the Inkjet Print Community.  Also, Russell Lang's
   OutputFD fix for Windows has been integrated into the sample code.

   Please download the proposed IJS v1.0
   package from http://www.eitcsv.com/sps/2003/ijs-v1.00-Sep092003.tar.gz

   Please review the proposed IJS v1.0 specification document, and sample
code
   implementation.  We need your vote for adopting this proposed IJS v1.0
   package as the official release of IJS v1.0 package.

1) The sample code doesn't actually compile:

$ make
gcc -g -Wall -ansi -pedantic -Wmissing-prototypes   -c -o ijs.o ijs.c
gcc -g -Wall -ansi -pedantic -Wmissing-prototypes   -c -o ijs_client.o
ijs_client.c
gcc -g -Wall -ansi -pedantic -Wmissing-prototypes   -c -o ijs_server.o
ijs_server.c
ijs_server.c: In function `ijs_server_proc_begin_page':
ijs_server.c:698: warning: int format, pointer arg (arg 5)
make: *** No rule to make target `ijs_exec_unix.o', needed by `libijs.a'.
Stop.

2) I'm thinking more and more that "client" and "server" are really
   the wrong names here, because this really isn't a client-server
   architecture, but more of a front-end/back-end architecture.
   In a typical client-server scenario, the server responds to
   requests from clients.  In this case, the "server" is invoked by
   the "client" to perform a single batch-processing step.

   Also, the back end ("server") is not expected to be secure (see
   section 5.1), and there is no security on the protocol.  Therefore
   it is not safe to write a "server" that listens for requests in
   some way; the "client" is responsible for all security checking.
   In a front-end/back-end architecture this is expected.

I'll have more comments later.

--
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile.in
Type: application/octet-stream
Size: 2606 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/printing-driver/attachments/20030924/1d45ec7e/attachment.obj 

From dsuffiel at dsufflnx.vcd.hp.com  Fri Oct  3 15:37:05 2003
From: dsuffiel at dsufflnx.vcd.hp.com (David Suffield)
Date: Fri, 03 Oct 2003 15:37:05 -0700
Subject: [Inkjet-list] HP Inkjet Linux Driver 1.5 Release
Message-ID: <3F7DFA11.7010100@dsufflnx.vcd.hp.com>

This HP Linux Inkjet Driver (HPIJS) release has the following changes.

1. Added support for the following printers.

    DeskJet 5600
    DeskJet 5100
    DeskJet 5800
    DeskJet 3600
    DeskJet 3500
    DeskJet 9600
    PSC 2300
    PSC 2400
    PSC 2500
    PSC 2170
    PSC 1300
    OfficeJet 5500
    OfficeJet 4100
    OfficeJet 6150
    Business InkJet 1100
    Photosmart 240
    Photosmart 140
    Photosmart 7960
    Photosmart 7760
    Photosmart 7660
    Photosmart 7260
    Photosmart 7268

2. Removed support for hpijs 0.97.
3. Corrected the model name for the cp1700.
4. Added DJ3600 device class.
5. Updated the foomatic PPD files and foomatic-rip.
6. Added $(DESTDIR) in Makefile.am to facilitate rpm builds. Special 
thanks to Robert van den Aker for this suggestion.

See hpinkjet.sourceforge.net and the hpijs_readme.html file for more 
information.





From rlk at alum.mit.edu  Sat Nov  1 17:55:50 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Sat, 1 Nov 2003 20:55:50 -0500
Subject: [Inkjet-list] ANNOUNCE: Gimp-Print 4.3.22
Message-ID: <200311020155.hA21toCh011906@dsl092-065-009.bos1.dsl.speakeasy.net>

Gimp-Print 4.3.22, released November 1, 2003, is a development
release of this package.  Like all development releases, this version
is considered unstable and should only be used by those individuals
tolerant of the likelihood of problems.  Individuals desiring a stable
release of Gimp-Print should use the latest 4.2 release.

Gimp-Print is a suite of printer drivers that may be used with most
common UNIX print spooling systems, including CUPS, lpr, LPRng, or
others.  These drivers provide high quality printing for UNIX
(including Macintosh OS X 10.2 and newer) and Linux systems in many
cases equal to or better than proprietary vendor-supplied drivers, and
can be used for many of the most demanding printing tasks.

This software includes the Print plug-in for the Gimp, and Ghostscript
and CUPS drivers, including Foomatic data.

The Print plugin for the Gimp requires the Gimp 1.2 (later versions of
the Gimp are not supported).  You may need to install a package named
"gimp-devel" or the like on many distributions.

The CUPS driver requires CUPS 1.1.15 or higher.  You may need to
install a package named "cups-devel" or the like on many
distributions.  We strongly recommend using CUPS with Gimp-Print as a
general-purpose printing solution.

We do not currently recommend using Foomatic, as the Foomatic data
generator included with Gimp-Print offers very limited capabilities.
This will be fixed in a future release.  The Foomatic data will work
with either Foomatic 2.x or 3.x.  Foomatic 3.x has additional
capabilities that this package detects and takes advantage of.

The IJS-based GhostScript plugin driver requires GNU Ghostscript 6.53
or later, ESP Ghostscript 7.05 or later, or APFL GhostScript 7.04 or
later.

Users of Macintosh OS X 10.2 and above can use this package, as the
printing system is based on CUPS, which is supported by Gimp-print.
Note that Macintosh OS X 10.0 and 10.1 (including 10.1.5) cannot use
this package.

Please read the README file for full instructions on installing this
package.


Gimp-Print 4.3.22 contains the following major changes over Gimp-Print
4.3.21:

1) This release offers further improvements in quality for most Epson
   printers.  All printers have been retuned, with particular
   improvements in the transitions between light and dark inks and
   between composite CMY and black.  In addition, green and blue hues
   have been improved significantly, and consistency across papers and
   between printers has been improved.

2) There have likely been some improvements in quality for other color
   inkjet printers (Canon, Lexmark, and HP) due to the parameters for
   Epson printers being copied into these drivers, but this is
   currently untested.

3) Even Tone dithering has been improved somewhat.  The transition
   between different drop sizes is now computed with the Even Tone
   algorithm, yielding better quality, and the error diffusion in this
   algorithm has also been improved, yielding better smoothness.

4) The parameters for the Epson Stylus C43 and C44 printers have been
   corrected, so these printers now print correctly.

5) Startup time (both for Gimp-Print programs as a whole and for
   individual pages) has been improved somewhat due to the XML files
   describing various components being loaded only when necessary.
   Some of the XML files are quite large, and loading them at startup
   is fairly time consuming (on the order of a second typically).  In
   addition, this will reduce problems in the future due to
   dependencies between the XML files now being resolved explicitly.

6) The Sony UP-DP10 lamination feature has been fixed.

7) Borderless capability for Olympus and Sony printers has been added.

8) Additional paper sizes for Olympus and Sony printers have been
   added.

9) A bug in the CUPS driver whereby a thin black line was sometimes
   printed at the very top of the page has been fixed.

10) The CUPS PPD files are not built if the CUPS driver is not built,
   unless --with-cups-ppds is supplied (previously --without-cups did
   not disable building the PPD files).

11) The test pattern generator has been substantially rewritten, with
   many syntactic and functional improvements.  In particular, it can
   now generate 8 and 16 bit inputs in both RGB and CMYK, and it is no
   longer limited to 7 channels.  It can also accept multiple input
   patterns in one file.

12) The Fujifilm CX-400 is now supported.

13) The Epson Stylus CX-6300, CX-6400, CX-8300, and CX-8400 are now
   supported.

14) The color code has been partially rewritten, and now permits
   16-bit RGB and grayscale inputs in addition to the CMYK inputs.
   The 16-bit RGB and gray/whitescale inputs are corrected by the
   driver, unlike the 16-bit CMYK input, which is raw.

15) The Epson Stylus Color 440, 640, 660, and 670 now position the
   paper correctly horizontally.

16) The head configurations for the Epson Stylus Color 400, 500, 600,
   800, and 1520 have been adjusted.

17) The paper positioning controls in the GIMP plugin have been
   rearranged slightly for better consistency.

18) The GIMP plugin now allows aligning an image to a fixed grid, with
   grid lines spaced according to the percentage of page size.  To
   move the image along this grid, use control-middle button.

19) Microweave is now a separate control for Epson Stylus printers
   that support it.  This simplifies the resolution lists for some
   printers, particularly the Stylus Pro printers.

20) The compiler options for gcc have been changed to permit inlining
   larger procedures.  This improves dither performance somewhat.

21) Horizontal image positioning on the Epson Stylus 640 and similar
   printers has been fixed (bug 819581).

22) All remaining vestiges of gimpprint-config have been removed.



From mike at cheapnet.net  Sat Nov 15 20:00:19 2003
From: mike at cheapnet.net (Mike Machado)
Date: Sat, 15 Nov 2003 20:00:19 -0800
Subject: [Inkjet-list] HP Photosmart 7760: Trying to get GIMP to print full bleed
Message-ID: <1068955219.2434.7.camel@woodstock>

I am trying to get my printer to do full bleed printing from GIMP. I
have CUPS all setup using the PPD from linuxprinting.org, and GIMP
prints just fine, but I cannot get it to do full bleed. When I put my
camera CF disk into the printer, and select 8 1/2 by 11, it prints full
bleed just fine. I am 99% sure this is just user error or lack of
knowledge. What is strange is that when I config GIMP to use the same
PPD file CUPS is set up with, I cannot change any of the options such as
Media Source, Media Type, Resolution or Ink Type. I can go into the CUPS
admin page and change it in the queue, but it would be nice to be able
to override this per print job. But I am not sure they are even taking
affect in CUPS, because I set the queue up to be full res, photo paper
and full bleed, but it still printed with borders around the image. Is
there some option in the GIMP lp command I can use to enable full bleed?
Or better yet, how to I allow GIMP to be able to select Media options
that are currently grayed out? Thanks!
-- 





From rlk at alum.mit.edu  Sat Nov 15 20:42:47 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Sat, 15 Nov 2003 23:42:47 -0500
Subject: [Inkjet-list] HP Photosmart 7760: Trying to get GIMP to print full bleed
In-Reply-To: <1068955219.2434.7.camel@woodstock> (mike@cheapnet.net)
References: <1068955219.2434.7.camel@woodstock>
Message-ID: <200311160442.hAG4glcs010775@dsl092-065-009.bos1.dsl.speakeasy.net>

   From: Mike Machado <mike at cheapnet.net>
   Date: Sat, 15 Nov 2003 20:00:19 -0800

   I am trying to get my printer to do full bleed printing from
   GIMP. I have CUPS all setup using the PPD from linuxprinting.org,
   and GIMP prints just fine, but I cannot get it to do full
   bleed. When I put my camera CF disk into the printer, and select 8
   1/2 by 11, it prints full bleed just fine. I am 99% sure this is
   just user error or lack of knowledge. What is strange is that when
   I config GIMP to use the same PPD file CUPS is set up with, I
   cannot change any of the options such as Media Source, Media Type,
   Resolution or Ink Type. I can go into the CUPS admin page and
   change it in the queue, but it would be nice to be able to override
   this per print job. But I am not sure they are even taking affect
   in CUPS, because I set the queue up to be full res, photo paper and
   full bleed, but it still printed with borders around the image. Is
   there some option in the GIMP lp command I can use to enable full
   bleed?  Or better yet, how to I allow GIMP to be able to select
   Media options that are currently grayed out? Thanks!

I'm redirecting this to gimp-print-devel at lists.sourceforge.net, since
this is most likely a Gimp-Print bug or limitation, not a user error.

BTW, if you're using CUPS, don't use the PPD files from
linuxprinting.org.  Gimp-Print builds its own PPD files on the fly;
those should be used in preference.  However, that's not likely to be
the issue here.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From mike at cheapnet.net  Sat Nov 15 21:56:16 2003
From: mike at cheapnet.net (Mike Machado)
Date: Sat, 15 Nov 2003 21:56:16 -0800
Subject: [Inkjet-list] HP Photosmart 7760: Trying to get GIMP to print
	full bleed
In-Reply-To: <200311160442.hAG4glcs010775@dsl092-065-009.bos1.dsl.speakeasy.net>
References: <1068955219.2434.7.camel@woodstock>
	 <200311160442.hAG4glcs010775@dsl092-065-009.bos1.dsl.speakeasy.net>
Message-ID: <1068962176.2434.30.camel@woodstock>

On Sat, 2003-11-15 at 20:42, Robert L Krawitz wrote:
>    From: Mike Machado <mike at cheapnet.net>
>    Date: Sat, 15 Nov 2003 20:00:19 -0800
> 
>    I am trying to get my printer to do full bleed printing from
>    GIMP. I have CUPS all setup using the PPD from linuxprinting.org,
>    and GIMP prints just fine, but I cannot get it to do full
>    bleed. When I put my camera CF disk into the printer, and select 8
>    1/2 by 11, it prints full bleed just fine. I am 99% sure this is
>    just user error or lack of knowledge. What is strange is that when
>    I config GIMP to use the same PPD file CUPS is set up with, I
>    cannot change any of the options such as Media Source, Media Type,
>    Resolution or Ink Type. I can go into the CUPS admin page and
>    change it in the queue, but it would be nice to be able to override
>    this per print job. But I am not sure they are even taking affect
>    in CUPS, because I set the queue up to be full res, photo paper and
>    full bleed, but it still printed with borders around the image. Is
>    there some option in the GIMP lp command I can use to enable full
>    bleed?  Or better yet, how to I allow GIMP to be able to select
>    Media options that are currently grayed out? Thanks!
> 
> I'm redirecting this to gimp-print-devel at lists.sourceforge.net, since
> this is most likely a Gimp-Print bug or limitation, not a user error.
> 

So you think its gimp-print not displaying options I should be able to
select based on what is in the PPD file? If thats the case, I had that
hunch, so I added "-o Quality=1200PhotoCMYKFullBleed" per the PPD file
of my printer in the GIMP "Setup Printer" dialog where the lpr command
is, and it still did not print full bleed. Wouldn't that mean its
possibly a hpijs problem not telling the printer to full bleed because I
am passing that option directly to CUPS?

When I enable full debug on CUPS, it appears to have what all the
documents I have read says is a correct gs command, setting FullBleed=1.

And just to make sure I am not crazy, in the "Position" section of the
GIMP print option window there are Right border and Bottom Border
options that whenever I try and change to 0, after I click another
option in that window go back to their defaults of 0.12 and 0.36
respectively. Could that be causing the problem?

> BTW, if you're using CUPS, don't use the PPD files from
> linuxprinting.org.  Gimp-Print builds its own PPD files on the fly;
> those should be used in preference.  However, that's not likely to be
> the issue here.

I followed the docs at http://www.linuxprinting.org/ppd-doc.html in the
"The Gimp" section. I also noted it said I should be able to select
Media Source after I added the right PPD, which as I have said above,
didn't happen. Perhaps its because the PPD for this printer does not
have individual options for Media, Type, Ink and Res, but there is just
one Combo option which sets the above 4 option in one option.

What would be the correct way to do this? Select Postscript Type II but
do not input a PPD file? My printer is not in the list the "Setup
Printer" gimp print options page.

One more sanity question, just where should I check or select the "Full
Bleed" option if everything was working right?


Thanks for all your time!
-- 





From rlk at alum.mit.edu  Sun Nov 16 05:56:30 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Sun, 16 Nov 2003 08:56:30 -0500
Subject: [Inkjet-list] HP Photosmart 7760: Trying to get GIMP to print
	full bleed
In-Reply-To: <1068962176.2434.30.camel@woodstock> (mike@cheapnet.net)
References: <1068955219.2434.7.camel@woodstock>
	 <200311160442.hAG4glcs010775@dsl092-065-009.bos1.dsl.speakeasy.net> <1068962176.2434.30.camel@woodstock>
Message-ID: <200311161356.hAGDuUfc014303@dsl092-065-009.bos1.dsl.speakeasy.net>

   From: Mike Machado <mike at cheapnet.net>
   Cc: inkjet-list at linuxprinting.org, gimp-print-devel at sourceforge.net
   Date: Sat, 15 Nov 2003 21:56:16 -0800

   On Sat, 2003-11-15 at 20:42, Robert L Krawitz wrote:
   >    From: Mike Machado <mike at cheapnet.net>
   >    Date: Sat, 15 Nov 2003 20:00:19 -0800
   > 
   >    I am trying to get my printer to do full bleed printing from
   >    GIMP. I have CUPS all setup using the PPD from linuxprinting.org,
   >    and GIMP prints just fine, but I cannot get it to do full
   >    bleed. When I put my camera CF disk into the printer, and select 8
   >    1/2 by 11, it prints full bleed just fine. I am 99% sure this is
   >    just user error or lack of knowledge. What is strange is that when
   >    I config GIMP to use the same PPD file CUPS is set up with, I
   >    cannot change any of the options such as Media Source, Media Type,
   >    Resolution or Ink Type. I can go into the CUPS admin page and
   >    change it in the queue, but it would be nice to be able to override
   >    this per print job. But I am not sure they are even taking affect
   >    in CUPS, because I set the queue up to be full res, photo paper and
   >    full bleed, but it still printed with borders around the image. Is
   >    there some option in the GIMP lp command I can use to enable full
   >    bleed?  Or better yet, how to I allow GIMP to be able to select
   >    Media options that are currently grayed out? Thanks!
   > 
   > I'm redirecting this to gimp-print-devel at lists.sourceforge.net, since
   > this is most likely a Gimp-Print bug or limitation, not a user error.

   So you think its gimp-print not displaying options I should be able
   to select based on what is in the PPD file? If thats the case, I
   had that hunch, so I added "-o Quality=1200PhotoCMYKFullBleed" per
   the PPD file of my printer in the GIMP "Setup Printer" dialog where
   the lpr command is, and it still did not print full bleed. Wouldn't
   that mean its possibly a hpijs problem not telling the printer to
   full bleed because I am passing that option directly to CUPS?

Hmm.  Are you using the HPIJS driver and trying to print from the
GIMP?  That's what I may have misinterpreted.  That sounds like a
problem with the Postscript driver in Gimp-Print.  That driver is
poorly maintained.  Can you send me the PPD file in question?

   When I enable full debug on CUPS, it appears to have what all the
   documents I have read says is a correct gs command, setting FullBleed=1.

   And just to make sure I am not crazy, in the "Position" section of the
   GIMP print option window there are Right border and Bottom Border
   options that whenever I try and change to 0, after I click another
   option in that window go back to their defaults of 0.12 and 0.36
   respectively. Could that be causing the problem?

The default margins are supposed to be .25" and .5" respectively.  So
that sounds like you're getting margins correctly, but those margins
are wrong.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From mike at cheapnet.net  Sun Nov 16 09:11:18 2003
From: mike at cheapnet.net (Mike Machado)
Date: Sun, 16 Nov 2003 09:11:18 -0800
Subject: [Inkjet-list] HP Photosmart 7760: Trying to get GIMP to print
	full bleed
In-Reply-To: <200311161356.hAGDuUfc014303@dsl092-065-009.bos1.dsl.speakeasy.net>
References: <1068955219.2434.7.camel@woodstock>
	 <200311160442.hAG4glcs010775@dsl092-065-009.bos1.dsl.speakeasy.net>
	 <1068962176.2434.30.camel@woodstock>
	 <200311161356.hAGDuUfc014303@dsl092-065-009.bos1.dsl.speakeasy.net>
Message-ID: <1069002677.9810.13.camel@woodstock>

On Sun, 2003-11-16 at 05:56, Robert L Krawitz wrote:

> 
>    So you think its gimp-print not displaying options I should be able
>    to select based on what is in the PPD file? If thats the case, I
>    had that hunch, so I added "-o Quality=1200PhotoCMYKFullBleed" per
>    the PPD file of my printer in the GIMP "Setup Printer" dialog where
>    the lpr command is, and it still did not print full bleed. Wouldn't
>    that mean its possibly a hpijs problem not telling the printer to
>    full bleed because I am passing that option directly to CUPS?
> 
> Hmm.  Are you using the HPIJS driver and trying to print from the
> GIMP?  That's what I may have misinterpreted.  That sounds like a
> problem with the Postscript driver in Gimp-Print.  That driver is
> poorly maintained.  Can you send me the PPD file in question?
> 

>From what I understood, the PPD files distributed at linuxprinting.org
for my printer only use hpijs. When I look at the gs command from the
CUPS debugging output, I do see -sDEVICE=ijs -sIjsServer=hpijs. I simply
downloaded the PPD from linuxprinting, put it in /usr/share/cups/model,
then when I added a printer in CUPS, I selected my printer from the
Model list.

In GIMP, I did not choose HPIJS anywhere. To setup GIMP, I simply
selected "PostScript Level 2" in the Printer Model box, and then put the
path to my PPD file in the PPD File box. The PPD file I am using in CUPS
and GIMP is the one below obtained from linuxprinting.org. The Command
in gimp is simply "lp -s -DHP", where HP is what I named my printer in
CUPS. I also had to remove the -oraw because it was trying to pass raw
postscript to my printer which didn't work.

Is there a better option I should select in the Printer Model option
from the GIMP Setup Printer page? I was trying to figure out how to add
to that list, but could not find where GIMP holds its printer
drivers/definitions, nor could I find any good documentation on it.
Perhaps if there is a better driver to use directly from GIMP, you can
point me at it and some docs on how to install it?


PPD File:

http://www.linuxprinting.org/ppd-o-matic.cgi?driver=hpijs&printer=HP-PhotoSmart_7760&show=0


Thanks again!

>    When I enable full debug on CUPS, it appears to have what all the
>    documents I have read says is a correct gs command, setting FullBleed=1.
> 

-- 





From david.suffield at hp.com  Mon Nov 17 11:30:42 2003
From: david.suffield at hp.com (SUFFIELD,DAVID (HP-Vancouver,ex1))
Date: Mon, 17 Nov 2003 14:30:42 -0500
Subject: [Inkjet-list] HP Photosmart 7760: Trying to get GIMP to print
	 full bleed
Message-ID: <A134E2426B46D711BB4B000347AE6E7C08823209@xvan02.vcd.hp.com>

In hpijs fullbleed support is only available for paper sizes Oufuku-Hagaki
or smaller. So, you will not get full bleed support for 8.5x11 paper size.
The PS 7760 does support large paper fullbleed, but the current release of
hpijs does not. We expect to address this issue in a future hpijs release. 

The PS 7760 is supported by the DJGenericVIP device class. See the Printable
Area section in http://hpinkjet.sourceforge.net/hpijs_readme.html for what
paper sizes have fullbleed support for this device class.

-dave 

> -----Original Message-----
> From: inkjet-list-admin at linuxprinting.org 
> [mailto:inkjet-list-admin at linuxprinting.org] On Behalf Of Mike Machado
> Sent: Saturday, November 15, 2003 9:56 PM
> To: Robert L Krawitz
> Cc: inkjet-list at linuxprinting.org; gimp-print-devel at sourceforge.net
> Subject: Re: [Inkjet-list] HP Photosmart 7760: Trying to get 
> GIMP to print full bleed
> 
> 
> On Sat, 2003-11-15 at 20:42, Robert L Krawitz wrote:
> >    From: Mike Machado <mike at cheapnet.net>
> >    Date: Sat, 15 Nov 2003 20:00:19 -0800
> > 
> >    I am trying to get my printer to do full bleed printing from
> >    GIMP. I have CUPS all setup using the PPD from linuxprinting.org,
> >    and GIMP prints just fine, but I cannot get it to do full
> >    bleed. When I put my camera CF disk into the printer, 
> and select 8
> >    1/2 by 11, it prints full bleed just fine. I am 99% sure this is
> >    just user error or lack of knowledge. What is strange is 
> that when
> >    I config GIMP to use the same PPD file CUPS is set up with, I
> >    cannot change any of the options such as Media Source, 
> Media Type,
> >    Resolution or Ink Type. I can go into the CUPS admin page and
> >    change it in the queue, but it would be nice to be able 
> to override
> >    this per print job. But I am not sure they are even taking affect
> >    in CUPS, because I set the queue up to be full res, 
> photo paper and
> >    full bleed, but it still printed with borders around the 
> image. Is
> >    there some option in the GIMP lp command I can use to enable full
> >    bleed?  Or better yet, how to I allow GIMP to be able to select
> >    Media options that are currently grayed out? Thanks!
> > 
> > I'm redirecting this to 
> gimp-print-devel at lists.sourceforge.net, since 
> > this is most likely a Gimp-Print bug or limitation, not a 
> user error.
> > 
> 
> So you think its gimp-print not displaying options I should 
> be able to select based on what is in the PPD file? If thats 
> the case, I had that hunch, so I added "-o 
> Quality=1200PhotoCMYKFullBleed" per the PPD file of my 
> printer in the GIMP "Setup Printer" dialog where the lpr 
> command is, and it still did not print full bleed. Wouldn't 
> that mean its possibly a hpijs problem not telling the 
> printer to full bleed because I am passing that option 
> directly to CUPS?
> 
> When I enable full debug on CUPS, it appears to have what all 
> the documents I have read says is a correct gs command, 
> setting FullBleed=1.
> 
> And just to make sure I am not crazy, in the "Position" 
> section of the GIMP print option window there are Right 
> border and Bottom Border options that whenever I try and 
> change to 0, after I click another option in that window go 
> back to their defaults of 0.12 and 0.36 respectively. Could 
> that be causing the problem?
> 
> > BTW, if you're using CUPS, don't use the PPD files from 
> > linuxprinting.org.  Gimp-Print builds its own PPD files on the fly; 
> > those should be used in preference.  However, that's not 
> likely to be 
> > the issue here.
> 
> I followed the docs at 
> http://www.linuxprinting.org/ppd-doc.html in > the "The Gimp" 
> section. I also noted it said I should be able to select 
> Media Source after I added the right PPD, which as I have 
> said above, didn't happen. Perhaps its because the PPD for 
> this printer does not have individual options for Media, 
> Type, Ink and Res, but there is just one Combo option which 
> sets the above 4 option in one option.
> 
> What would be the correct way to do this? Select Postscript 
> Type II but do not input a PPD file? My printer is not in the 
> list the "Setup Printer" gimp print options page.
> 
> One more sanity question, just where should I check or select 
> the "Full Bleed" option if everything was working right?
> 
> 
> Thanks for all your time!
> -- 
> 
> 
> 
> _______________________________________________
> Inkjet-list mailing list
> Inkjet-list at linuxprinting.org 
> http://www.linuxprinting.org/cgi-> bin/mailman/listinfo/inkjet-list
> 



From mike at cheapnet.net  Mon Nov 17 12:36:23 2003
From: mike at cheapnet.net (Mike Machado)
Date: Mon, 17 Nov 2003 12:36:23 -0800
Subject: [Inkjet-list] HP Photosmart 7760: Trying to get GIMP to print
	full bleed
In-Reply-To: <A134E2426B46D711BB4B000347AE6E7C08823209@xvan02.vcd.hp.com>
References: <A134E2426B46D711BB4B000347AE6E7C08823209@xvan02.vcd.hp.com>
Message-ID: <1069101383.21604.18.camel@mmachado>

Ok, that would explain it. I would have thought of that sooner of I knew
what Oufuku-Hagaki paper size was ;) I assumed it was at least 8.5x11
because my printer printed fullbleed from the CF slot. Thanks!

On Mon, 2003-11-17 at 11:30, SUFFIELD,DAVID (HP-Vancouver,ex1) wrote:
> In hpijs fullbleed support is only available for paper sizes Oufuku-Hagaki
> or smaller. So, you will not get full bleed support for 8.5x11 paper size.
> The PS 7760 does support large paper fullbleed, but the current release of
> hpijs does not. We expect to address this issue in a future hpijs release. 
> 
> The PS 7760 is supported by the DJGenericVIP device class. See the Printable
> Area section in http://hpinkjet.sourceforge.net/hpijs_readme.html for what
> paper sizes have fullbleed support for this device class.
> 
> -dave 
> 
> > -----Original Message-----
> > From: inkjet-list-admin at linuxprinting.org 
> > [mailto:inkjet-list-admin at linuxprinting.org] On Behalf Of Mike Machado
> > Sent: Saturday, November 15, 2003 9:56 PM
> > To: Robert L Krawitz
> > Cc: inkjet-list at linuxprinting.org; gimp-print-devel at sourceforge.net
> > Subject: Re: [Inkjet-list] HP Photosmart 7760: Trying to get 
> > GIMP to print full bleed
> > 
> > 
> > On Sat, 2003-11-15 at 20:42, Robert L Krawitz wrote:
> > >    From: Mike Machado <mike at cheapnet.net>
> > >    Date: Sat, 15 Nov 2003 20:00:19 -0800
> > > 
> > >    I am trying to get my printer to do full bleed printing from
> > >    GIMP. I have CUPS all setup using the PPD from linuxprinting.org,
> > >    and GIMP prints just fine, but I cannot get it to do full
> > >    bleed. When I put my camera CF disk into the printer, 
> > and select 8
> > >    1/2 by 11, it prints full bleed just fine. I am 99% sure this is
> > >    just user error or lack of knowledge. What is strange is 
> > that when
> > >    I config GIMP to use the same PPD file CUPS is set up with, I
> > >    cannot change any of the options such as Media Source, 
> > Media Type,
> > >    Resolution or Ink Type. I can go into the CUPS admin page and
> > >    change it in the queue, but it would be nice to be able 
> > to override
> > >    this per print job. But I am not sure they are even taking affect
> > >    in CUPS, because I set the queue up to be full res, 
> > photo paper and
> > >    full bleed, but it still printed with borders around the 
> > image. Is
> > >    there some option in the GIMP lp command I can use to enable full
> > >    bleed?  Or better yet, how to I allow GIMP to be able to select
> > >    Media options that are currently grayed out? Thanks!
> > > 
> > > I'm redirecting this to 
> > gimp-print-devel at lists.sourceforge.net, since 
> > > this is most likely a Gimp-Print bug or limitation, not a 
> > user error.
> > > 
> > 
> > So you think its gimp-print not displaying options I should 
> > be able to select based on what is in the PPD file? If thats 
> > the case, I had that hunch, so I added "-o 
> > Quality=1200PhotoCMYKFullBleed" per the PPD file of my 
> > printer in the GIMP "Setup Printer" dialog where the lpr 
> > command is, and it still did not print full bleed. Wouldn't 
> > that mean its possibly a hpijs problem not telling the 
> > printer to full bleed because I am passing that option 
> > directly to CUPS?
> > 
> > When I enable full debug on CUPS, it appears to have what all 
> > the documents I have read says is a correct gs command, 
> > setting FullBleed=1.
> > 
> > And just to make sure I am not crazy, in the "Position" 
> > section of the GIMP print option window there are Right 
> > border and Bottom Border options that whenever I try and 
> > change to 0, after I click another option in that window go 
> > back to their defaults of 0.12 and 0.36 respectively. Could 
> > that be causing the problem?
> > 
> > > BTW, if you're using CUPS, don't use the PPD files from 
> > > linuxprinting.org.  Gimp-Print builds its own PPD files on the fly; 
> > > those should be used in preference.  However, that's not 
> > likely to be 
> > > the issue here.
> > 
> > I followed the docs at 
> > http://www.linuxprinting.org/ppd-doc.html in > the "The Gimp" 
> > section. I also noted it said I should be able to select 
> > Media Source after I added the right PPD, which as I have 
> > said above, didn't happen. Perhaps its because the PPD for 
> > this printer does not have individual options for Media, 
> > Type, Ink and Res, but there is just one Combo option which 
> > sets the above 4 option in one option.
> > 
> > What would be the correct way to do this? Select Postscript 
> > Type II but do not input a PPD file? My printer is not in the 
> > list the "Setup Printer" gimp print options page.
> > 
> > One more sanity question, just where should I check or select 
> > the "Full Bleed" option if everything was working right?
> > 
> > 
> > Thanks for all your time!
> > -- 
> > 
> > 
> > 
> > _______________________________________________
> > Inkjet-list mailing list
> > Inkjet-list at linuxprinting.org 
> > http://www.linuxprinting.org/cgi-> bin/mailman/listinfo/inkjet-list
> > 
> 
> _______________________________________________
> Inkjet-list mailing list
> Inkjet-list at linuxprinting.org
> http://www.linuxprinting.org/cgi-bin/mailman/listinfo/inkjet-list




From rlk at alum.mit.edu  Fri Nov 21 19:28:14 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Fri, 21 Nov 2003 22:28:14 -0500
Subject: [Inkjet-list] ANNOUNCE: Gimp-Print 4.3.24
Message-ID: <200311220328.hAM3SEFh012267@dsl092-065-009.bos1.dsl.speakeasy.net>

NOTE: This is planned to be the last development release prior to
alpha for the next stable line, and it contains a number of major
enhancements.  Please test this thoroughly!


Gimp-Print 4.3.24, released November 21, 2003, is a development
release of this package.  Like all development releases, this version
is considered unstable and should only be used by those individuals
tolerant of the likelihood of problems.  Individuals desiring a stable
release of Gimp-Print should use the latest 4.2 release.

Gimp-Print is a suite of printer drivers that may be used with most
common UNIX print spooling systems, including CUPS, lpr, LPRng, or
others.  These drivers provide high quality printing for UNIX
(including Macintosh OS X 10.2 and newer) and Linux systems that in
many cases equal to or better than proprietary vendor-supplied
drivers, and can be used for many of the most demanding printing
tasks.

This software includes the Print plug-in for the Gimp, and Ghostscript
and CUPS drivers, including Foomatic data.

The Print plugin for the Gimp requires the Gimp 1.2 (later versions of
the Gimp are not supported).  You may need to install a package named
"gimp-devel" or the like on many distributions.

The CUPS driver requires CUPS 1.1.15 or higher.  You may need to
install a package named "cups-devel" or the like on many
distributions.  We strongly recommend using CUPS with Gimp-Print as a
general-purpose printing solution.

We do not currently recommend using Foomatic, as the Foomatic data
generator included with Gimp-Print offers very limited capabilities.
This will be fixed in a future release.  The Foomatic data will work
with either Foomatic 2.x or 3.x.  Foomatic 3.x has additional
capabilities that this package detects and takes advantage of.

The IJS-based GhostScript plugin driver requires GNU Ghostscript 6.53
or later, ESP Ghostscript 7.05 or later, or APFL GhostScript 7.04 or
later.

Users of Macintosh OS X 10.2 and above can use this package, as the
printing system is based on CUPS, which is supported by Gimp-print.
Note that Macintosh OS X 10.0 and 10.1 (including 10.1.5) cannot use
this package.  A precompiled OS X package should be available shortly
after the release of this package.

Please read the README file for full instructions on installing this
package.

Gimp-Print 4.3.24 contains the following major changes over Gimp-Print
4.3.23:

1) Additional dither algorithms based on EvenTone dithering have been
   added that show considerable promise as far as improving
   smoothness.

   The first variation is called Hybrid EvenTone.  This dither
   algorithm perturbs the dot positions slightly to break up some
   patterning seen in standard EvenTone dithering in solid regions of
   pale tones.  This very slightly reduces the smoothness of texture
   in exchange for largely eliminating this undesirable patterning.
   This algorithm is also expected to be more resistant to
   microbanding effects.

   The second variation is called UniTone.  This dither algorithm
   calculates the placement of all dots (except for yellow) using a
   single EvenTone pass, not just all of the dots of one color.  This
   technique improves the quality when multiple inks must be mixed,
   such as when color inks are used to produce gray.  It does so by
   ensuring that all dots are equally spaced.  Typically when printing
   neutral tones with EvenTone dithering the cyan, magenta, and yellow
   dots are positioned very close to each other, even though the
   individual cyan dots are well-positioned.  This causes the groups
   of dots to appear to be single, large dots.  UniTone dithering
   evens out the spacing between all dots, producing a smoother
   texture.

   UniTone dithering works best at improving output when the drops are
   already very small, which is usually at high resolutions.  With
   these small drops, the eye has difficulty distinguishing the color
   of the individual drops, so their color tends to be distinguished
   primarily by their darkness.  While cyan ink is lighter than black
   ink and magenta ink is lighter than cyan ink, these differences are
   not overwhelming and hence the eye does not perceive a difference
   between them.  With large drops, the eye perceives the color of the
   individual drops, and small spots dominated by one ink become
   apparent.

   As noted above, UniTone dithers yellow separately.  This is because
   the yellow ink is much lighter than any other ink, and the
   positions occupied by yellow drops appear as holes, reducing the
   quality of the print.  Even light cyan and light magenta inks
   appear to be significantly darker than yellow.

   Experiments conducted to date suggest that UniTone works very well
   on the Stylus C80 at high resolutions, when the printer is using 3
   picolitre drops.  On the Stylus Photo EX, at 1440x720 DPI, using 8
   picolitre drops, quality is improved significantly when printing in
   normal 6-color mode but quality is slightly worse in 4-color mode,
   as the drops are apparent.  At 720 DPI (using 12 picolitre drops),
   quality is improved in 6-color mode but degraded significantly in
   4-color mode.

   UniTone only functions when printing with more than one ink; when
   printing black ink only, it becomes standard EvenTone dithering.

   Finally, a Hybrid UniTone dither algorithm is provided, combining
   the principles of both of the above.

2) The package now works properly under OS X 10.2 (Jaguar) and 10.3
   (Panther).  A bug that prevented printing from applications from
   working properly (821992) has been fixed.  The specific problem was
   due to the fact that CUPS by default sets the input slot (media
   source) to Autoselect; this was not recognized correctly by the
   driver.  The current behavior is to treat the Autoselect option as
   the printer default.  This also resolves bug 627266.

3) The CUPS driver has been renamed rastertogimpprint.4.3, and the PPD
   generation program is now named cups-genppd.4.3.  This permits
   installation of multiple versions of Gimp-Print on a system
   (currently a 4.2 and a 4.3 version).  In the future, the CUPS
   programs will be suffixed by the major and minor version numbers.

4) The CUPS driver now enforces that the PPD file must match the exact
   version of Gimp-Print installed on the system.  Therefore, when
   installing the CUPS driver it is essential to upgrade your PPD
   files, either by means of Configure Printer or by means of the
   cups-genppdupdate.4.3 script supplied with Gimp-Print.  Failure to
   upgrade the PPD files causes the Gimp-Print driver to not run,
   printing a diagnostic message to the log.  This is being done to
   eliminate a common source of error that can yield unpredictable
   results or difficult-to-diagnose errors.

5) The Epson Stylus Color 600, 800, 850, 1520, and 3000 should now
   print correctly in grayscale/monochrome mode.

6) Preliminary support for the Epson Stylus Photo R300 and PM-G700,
   PM-D750, and PM-G800.  These printers are not tuned and quality is
   likely to be poor.  The Stylus Photo R300, PM-G700, and PM-D750
   drivers likely work; the PM-G800 driver may or may not work.

7) Direct printing to CD's is now supported experimentally on the
   Epson Stylus Photo 900, 950, 960, 2100, 2200, R300, and the
   PM-950C.  To use this, select the Print To CD media source (input
   slot) and either CD - 5 inch or CD - 3 inch media size.  This is
   currently not tuned, so it will require some experimentation to
   derive correct ink levels.  Most likely, the density setting should
   be reduced somewhat, as the surface of the CD's probably cannot
   absorb very much ink.

   The CUPS PPD files do not presently enforce the restriction on
   media size.  However, selecting a different media size will cause
   the job to error out early, during parameter verification.

8) The Epson Stylus Photo 2100/2200 now supports 1440x1440 DPI
   printing.  This mode only barely deposits enough ink to fill the
   page on most papers.  However, it prints as fast as 1440x720 DPI
   (although the calculation time is longer) and in some cases offers
   better quality than both 1440x720 and 2880x1440 DPI.

   Experiments have determined that this printer is very sensitive to
   the choice of dither algorithm, unidirectional vs. bidirectional
   printing, resolution, and weave pattern.  In general, it appears
   that this printer often prints better quality in bidirectional mode
   than unidirectional.  The Staggered weave pattern in combination
   with Hybrid EvenTone dithering may also yield better results;
   Ordered dithering often yields good results, too.

   We recommend that you experiment with settings to identify the
   settings that work best for you.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From roger at whinlatter.uklinux.net  Wed Dec  3 15:24:17 2003
From: roger at whinlatter.uklinux.net (Roger Leigh)
Date: Wed, 03 Dec 2003 23:24:17 +0000
Subject: [Inkjet-list] EPSON ESC/P and ESC/P2 font metrics
Message-ID: <87r7zljxi6.fsf@wrynose.whinlatter.uklinux.net>

Hi folks,

One thing I've been working on recently has been an groescp device for
the GNU groff typesetter, to allow printing to ESC/P printers
(primarily my old FX 80-compatible dot matrix printers).  This is a
fairly simple driver, based on a stripped-down version of the grotty
device, which is currently ASCII only, though I intend to allow
alternate charset selection in future versions.

Looking at the more advanced capabilities of the ESC/P2 language, it
should be possible to create a rather more sophisticated driver for
EPSON inkjets, impact and lasers supporting the ESC/P2 language.  This
would give us:

? Scalable and proportional fonts.
? Several typefaces
? Basic spot colour
? pic line art and other graphics can be rendered as a raster bitmap
  layer under the text, with the text overprinted on top.

This would be a rather more ambitious driver, which would take some
time to develop, though I may be able to do this at work [leaving more
of my (currently barely existent) spare time for Gimp-Print :-)]
However, what I need for this are the font metrics for the fonts in
the printer firmware.  Are these available?  Without them, groff can't
know how to place and fill text over the page.


Why am I doing this?  For work, I need a very fast way of producing
formatted reports and documentation on a variety of printers.  groff
is ideal for this, but outputting Postscript and then running through
gs and Gimp-Print (either gs/ijsgimpprint or espgs/rastertoprinter) is
unacceptably high for the small embedded system this will run on.
groff is nothing if not lightning fast, and making use of ESC/P2 as a
backend output option will be very efficient.  It's also a neat
idea--how many drivers out there actually *use* more than 5% of
ESC/P2's capabilities (outside its raster graphics support)?


Regards,
Roger

-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.



From mike at easysw.com  Thu Dec  4 06:50:05 2003
From: mike at easysw.com (Michael Sweet)
Date: Thu, 04 Dec 2003 09:50:05 -0500
Subject: [Inkjet-list] EPSON ESC/P and ESC/P2 font metrics
In-Reply-To: <87r7zljxi6.fsf@wrynose.whinlatter.uklinux.net>
References: <87r7zljxi6.fsf@wrynose.whinlatter.uklinux.net>
Message-ID: <3FCF499D.8010600@easysw.com>

Roger Leigh wrote:
> ...
> However, what I need for this are the font metrics for the fonts in
> the printer firmware.  Are these available?  Without them, groff can't
> know how to place and fill text over the page.

Epson might have these on their developer site:

     http://www.epsondevelopers.com/

> ...
> groff is nothing if not lightning fast, and making use of ESC/P2 as a
> backend output option will be very efficient.  It's also a neat
> idea--how many drivers out there actually *use* more than 5% of
> ESC/P2's capabilities (outside its raster graphics support)?

Not many, but there is a reason - many of Epson's current inkjet
printers do not provide text printing support... :(

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com




From roger at whinlatter.uklinux.net  Thu Dec  4 07:48:22 2003
From: roger at whinlatter.uklinux.net (Roger Leigh)
Date: Thu, 04 Dec 2003 15:48:22 +0000
Subject: [Inkjet-list] EPSON ESC/P and ESC/P2 font metrics
In-Reply-To: <3FCF499D.8010600@easysw.com> (Michael Sweet's message of "Thu,
 04 Dec 2003 09:50:05 -0500")
References: <87r7zljxi6.fsf@wrynose.whinlatter.uklinux.net>
	<3FCF499D.8010600@easysw.com>
Message-ID: <87u14g8tyx.fsf@wrynose.whinlatter.uklinux.net>

Michael Sweet <mike at easysw.com> writes:

> Roger Leigh wrote:
>> ...
>> However, what I need for this are the font metrics for the fonts in
>> the printer firmware.  Are these available?  Without them, groff can't
>> know how to place and fill text over the page.
>
> Epson might have these on their developer site:
>
>      http://www.epsondevelopers.com/

I've taken a look, but I can't see anything relevant.  I'll send them
a mail.

>> groff is nothing if not lightning fast, and making use of ESC/P2 as a
>> backend output option will be very efficient.  It's also a neat
>> idea--how many drivers out there actually *use* more than 5% of
>> ESC/P2's capabilities (outside its raster graphics support)?
>
> Not many, but there is a reason - many of Epson's current inkjet
> printers do not provide text printing support... :(

That's not so nice.  When did they start doing that?


-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.



From mike at easysw.com  Thu Dec  4 08:10:38 2003
From: mike at easysw.com (Michael Sweet)
Date: Thu, 04 Dec 2003 11:10:38 -0500
Subject: [Inkjet-list] EPSON ESC/P and ESC/P2 font metrics
In-Reply-To: <87u14g8tyx.fsf@wrynose.whinlatter.uklinux.net>
References: <87r7zljxi6.fsf@wrynose.whinlatter.uklinux.net>	<3FCF499D.8010600@easysw.com> <87u14g8tyx.fsf@wrynose.whinlatter.uklinux.net>
Message-ID: <3FCF5C7E.2050701@easysw.com>

Roger Leigh wrote:
> ...
>>Not many, but there is a reason - many of Epson's current inkjet
>>printers do not provide text printing support... :(
> 
> 
> That's not so nice.  When did they start doing that?

When they started making $20 printers and $40 ink cartridges.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com




From rlk at alum.mit.edu  Thu Dec  4 16:11:58 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Thu, 4 Dec 2003 19:11:58 -0500
Subject: [Inkjet-list] EPSON ESC/P and ESC/P2 font metrics
In-Reply-To: <3FCF5C7E.2050701@easysw.com> (mike@easysw.com)
References: <87r7zljxi6.fsf@wrynose.whinlatter.uklinux.net>	<3FCF499D.8010600@easysw.com> <87u14g8tyx.fsf@wrynose.whinlatter.uklinux.net> <3FCF5C7E.2050701@easysw.com>
Message-ID: <200312050011.hB50BwCH012749@dsl092-065-009.bos1.dsl.speakeasy.net>

   From: Michael Sweet <mike at easysw.com>
   Date: Thu, 04 Dec 2003 11:10:38 -0500

   Roger Leigh wrote:
   > ...
   >>Not many, but there is a reason - many of Epson's current inkjet
   >>printers do not provide text printing support... :(
   > 
   > That's not so nice.  When did they start doing that?

   When they started making $20 printers and $40 ink cartridges.

They stopped doing selectable fonts long before that.  The Stylus
Photo EX, for example, is a pure raster printer, although it will
print ASCII text at 360 DPI (not mixed with graphics) if you send it
to the printer.  Do some of the real cheapies not even do that?

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From roger at whinlatter.uklinux.net  Sat Dec  6 15:50:20 2003
From: roger at whinlatter.uklinux.net (Roger Leigh)
Date: Sat, 06 Dec 2003 23:50:20 +0000
Subject: [Inkjet-list] EPSON ESC/P and ESC/P2 font metrics
In-Reply-To: <3FCF499D.8010600@easysw.com> (Michael Sweet's message of "Thu,
 04 Dec 2003 09:50:05 -0500")
References: <87r7zljxi6.fsf@wrynose.whinlatter.uklinux.net>
	<3FCF499D.8010600@easysw.com>
Message-ID: <874qwdtsjn.fsf@wrynose.whinlatter.uklinux.net>

Michael Sweet <mike at easysw.com> writes:

> Roger Leigh wrote:
>> ...
>> However, what I need for this are the font metrics for the fonts in
>> the printer firmware.  Are these available?  Without them, groff can't
>> know how to place and fill text over the page.
>> ...
>> groff is nothing if not lightning fast, and making use of ESC/P2 as a
>> backend output option will be very efficient.  It's also a neat
>> idea--how many drivers out there actually *use* more than 5% of
>> ESC/P2's capabilities (outside its raster graphics support)?
>
> Not many, but there is a reason - many of Epson's current inkjet
> printers do not provide text printing support... :(

I've investgated this a little further:

At work, our software outputs ESC/P2 exclusively.  Our customers have
the option of an LQ300+ or any other ESC/P2-compatible dot matrix.
For higher quality, low volume output, we also support EPSON Stylus
inkjets, or for high quality/high volume and EPSON laser with ESC/P2
emulation.  At work, I've tested with an escp2-850, and I use the
basic typestyles, typefaces and raster modes without problems (the
output is reports and forms, generally plain text with bold, italics,
and barcodes printed using raster graphics (ESC *)).

I've tested my groff groescp driver with the escp-c60.  It's complete
pants.  Plaintext only, and all the control codes are stripped, even
simple stuff like ESC F, ESC 5, and ESC - SOH.  I get better output on
a 15 year old 9-pin!

A customer was having problems with our software and an escp-c80 or
c82 (I can't remember which offhand).  This could well be the problem
(I didn't realise they were so crippled when I ordered it).


Are /all/ new EPSON Stylus printers lacking full ESC/P2 support, or is
this just the low end?  I didn't think the C8x series were "low end".

My companies customers will not be amused when I tell them they have
to use a dot matrix, because current inkjets aren't intelligent
enough!  This looks like it could cause some real grief if ESC/P2 is
completely unsupported on all current models :-/


-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.



From rlk at alum.mit.edu  Sun Dec  7 06:41:44 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Sun, 7 Dec 2003 09:41:44 -0500
Subject: [Inkjet-list] EPSON ESC/P and ESC/P2 font metrics
In-Reply-To: <874qwdtsjn.fsf@wrynose.whinlatter.uklinux.net>
	(roger@whinlatter.uklinux.net)
References: <87r7zljxi6.fsf@wrynose.whinlatter.uklinux.net>
	<3FCF499D.8010600@easysw.com> <874qwdtsjn.fsf@wrynose.whinlatter.uklinux.net>
Message-ID: <200312071441.hB7EfiRL019091@dsl092-065-009.bos1.dsl.speakeasy.net>

   From: Roger Leigh <roger at whinlatter.uklinux.net>
   Date: Sat, 06 Dec 2003 23:50:20 +0000

   Michael Sweet <mike at easysw.com> writes:

   I've investgated this a little further:

   At work, our software outputs ESC/P2 exclusively.  Our customers
   have the option of an LQ300+ or any other ESC/P2-compatible dot
   matrix.  For higher quality, low volume output, we also support
   EPSON Stylus inkjets, or for high quality/high volume and EPSON
   laser with ESC/P2 emulation.  At work, I've tested with an
   escp2-850, and I use the basic typestyles, typefaces and raster
   modes without problems (the output is reports and forms, generally
   plain text with bold, italics, and barcodes printed using raster
   graphics (ESC *)).

   I've tested my groff groescp driver with the escp-c60.  It's
   complete pants.  Plaintext only, and all the control codes are
   stripped, even simple stuff like ESC F, ESC 5, and ESC - SOH.  I
   get better output on a 15 year old 9-pin!

   A customer was having problems with our software and an escp-c80 or
   c82 (I can't remember which offhand).  This could well be the
   problem (I didn't realise they were so crippled when I ordered it).

Even the Stylus Photo EX (and the other 6-color printers of that era)
are described as accepting "ESC/P Raster", with no reference to the
rest of ESC/P2.

   Are /all/ new EPSON Stylus printers lacking full ESC/P2 support, or
   is this just the low end?  I didn't think the C8x series were "low
   end".

   My companies customers will not be amused when I tell them they
   have to use a dot matrix, because current inkjets aren't
   intelligent enough!  This looks like it could cause some real grief
   if ESC/P2 is completely unsupported on all current models :-/

By and large, the inkjets are not true "ESC/P2" printers, they're
intended to be used purely as raster printers.  Interestingly enough,
though, both the C80 and C82 are documented as supporting "ESC/P,
ESC/P Raster, and Remote Mode" (the C70, which is documented in the
same manual as the C80, is described as "ESC/P Raster and Remote
Mode").  Whatever the case, I would be very surprised if any ESC/P2
code in the printer firmware gets much if any testing, simply because
that's not what the printer is intended for.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From mike at easysw.com  Sun Dec  7 06:49:02 2003
From: mike at easysw.com (Michael Sweet)
Date: Sun, 07 Dec 2003 09:49:02 -0500
Subject: [Inkjet-list] EPSON ESC/P and ESC/P2 font metrics
In-Reply-To: <874qwdtsjn.fsf@wrynose.whinlatter.uklinux.net>
References: <87r7zljxi6.fsf@wrynose.whinlatter.uklinux.net>	<3FCF499D.8010600@easysw.com> <874qwdtsjn.fsf@wrynose.whinlatter.uklinux.net>
Message-ID: <3FD33DDE.9030108@easysw.com>

Roger Leigh wrote:
> ...
> Are /all/ new EPSON Stylus printers lacking full ESC/P2 support, or is
> this just the low end?  I didn't think the C8x series were "low end".

AFAIK, text support is crippled in all new Epson inkjet printers.

> My companies customers will not be amused when I tell them they have
> to use a dot matrix, because current inkjets aren't intelligent
> enough!  This looks like it could cause some real grief if ESC/P2 is
> completely unsupported on all current models :-/

You might be able to whip something up that uses Freetype to
rasterize text at 360 dpi for reasonably fast printing.  The main
choice will be the ESC . or ESC i style raster printing, depending
on the printer.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mike at easysw.com
Printing Software for UNIX                       http://www.easysw.com




From roger at whinlatter.uklinux.net  Sun Dec  7 10:27:10 2003
From: roger at whinlatter.uklinux.net (Roger Leigh)
Date: Sun, 07 Dec 2003 18:27:10 +0000
Subject: [Inkjet-list] EPSON ESC/P and ESC/P2 font metrics
In-Reply-To: <3FD33DDE.9030108@easysw.com> (Michael Sweet's message of "Sun,
 07 Dec 2003 09:49:02 -0500")
References: <87r7zljxi6.fsf@wrynose.whinlatter.uklinux.net>
	<3FCF499D.8010600@easysw.com>
	<874qwdtsjn.fsf@wrynose.whinlatter.uklinux.net>
	<3FD33DDE.9030108@easysw.com>
Message-ID: <87isksxz41.fsf@wrynose.whinlatter.uklinux.net>

Michael Sweet <mike at easysw.com> writes:

> Roger Leigh wrote:
>> ...
>> Are /all/ new EPSON Stylus printers lacking full ESC/P2 support, or is
>> this just the low end?  I didn't think the C8x series were "low end".
>
> AFAIK, text support is crippled in all new Epson inkjet printers.

That's a real shame--I'm quite disappointed.  Writing an ESC/P2 driver
would have been fun.  The ESC/P2 output on the escp-850 was already
pretty good, and I hadn't even got started :-|

>> My companies customers will not be amused when I tell them they have
>> to use a dot matrix, because current inkjets aren't intelligent
>> enough!  This looks like it could cause some real grief if ESC/P2 is
>> completely unsupported on all current models :-/
>
> You might be able to whip something up that uses Freetype to
> rasterize text at 360 dpi for reasonably fast printing.  The main
> choice will be the ESC . or ESC i style raster printing, depending
> on the printer.

I'd use 360DPI, and not care about the banding (I've not noticed it
much at 360DPI much anyway).  If I need to to the rasterising
manually, I think I'd rather just output troff (-mm) and then use
either groescp for dot-matrix or grops for everything else.  I guess
if I use 360DPI ordered dither & line art I should get reasonable
speed from Gimp-Print, and I can always go to fast or veryfast
dithering if required (since it's 99% text, it should be acceptable
quality).


-- 
Roger Leigh

                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.



From rlk at alum.mit.edu  Sun Dec  7 14:57:51 2003
From: rlk at alum.mit.edu (Robert L Krawitz)
Date: Sun, 7 Dec 2003 17:57:51 -0500
Subject: [Inkjet-list] EPSON ESC/P and ESC/P2 font metrics
In-Reply-To: <87isksxz41.fsf@wrynose.whinlatter.uklinux.net>
	(roger@whinlatter.uklinux.net)
References: <87r7zljxi6.fsf@wrynose.whinlatter.uklinux.net>
	<3FCF499D.8010600@easysw.com>
	<874qwdtsjn.fsf@wrynose.whinlatter.uklinux.net>
	<3FD33DDE.9030108@easysw.com> <87isksxz41.fsf@wrynose.whinlatter.uklinux.net>
Message-ID: <200312072257.hB7Mvpf6016345@dsl092-065-009.bos1.dsl.speakeasy.net>

   From: Roger Leigh <roger at whinlatter.uklinux.net>
   Date: Sun, 07 Dec 2003 18:27:10 +0000

   Michael Sweet <mike at easysw.com> writes:

   I'd use 360DPI, and not care about the banding (I've not noticed it
   much at 360DPI much anyway).  If I need to to the rasterising
   manually, I think I'd rather just output troff (-mm) and then use
   either groescp for dot-matrix or grops for everything else.  I guess
   if I use 360DPI ordered dither & line art I should get reasonable
   speed from Gimp-Print, and I can always go to fast or veryfast
   dithering if required (since it's 99% text, it should be acceptable
   quality).

Make sure that you're using uncorrected colors (4.3/5.0) or line art
(4.2).  The color conversion can add significant time.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>      

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton



From till.kamppeter at gmx.net  Tue Dec  9 14:44:49 2003
From: till.kamppeter at gmx.net (Till Kamppeter)
Date: Tue, 09 Dec 2003 22:44:49 +0000
Subject: [Inkjet-list] EPSON ESC/P and ESC/P2 font metrics/[Foomatic]
 Printer Driver Developement
In-Reply-To: <mailman.1070535782.4105.inkjet-list@linuxprinting.org>
References: <mailman.1070535782.4105.inkjet-list@linuxprinting.org>
Message-ID: <3FD65061.1010307@gmx.net>

John, Roger, your projects (see both postings below) are very similar. I 
suggest that you both join forces to get such a driver.

See the threads

"Printer Driver Developement" on foomatic-devel,
http://www.linuxprinting.org/pipermail/foomatic-devel/2003q4/thread.html

and

"EPSON ESC/P and ESC/P2 font metrics" on inkjet-architecture,
http://www.linuxprinting.org/pipermail/inkjet-list/2003q4/thread.html

Probably we should continue the discussion in this joint thread.

    Till


john d hendrickson wrote on foomatic-devel:
 > Hi,
 >
 > If I get encouragement I might do a bit for 
epson/panasonic/ibm/okidata pin
 > impact printing.  (most of these support emulation of a few languages).
 >
 > I'd really like to hear from someone who's actually done something for
 > foo-matic first, though.
 >
 > What I have is the LQ-2500 and IBM X24 printer codes documentation 
and thorough
 > linux experience (not that I'm familiar with foo-matic style foo, or 
bor, or
 > phee for that matter).
 >
 > Why?  Because 'gs', cups, et all to a terrible job on pin printers 
(so does ms
 > windows).  Only the like of 'wp 5.1' really used these as intended: 
call them
 > "word perfect printers".
 >
 > Why?  becuase these printers to about 200 cps when printing font 
typed text and
 > text graphics - but like 15 cps when doing text.
 >
 > Of course pin printers are very reliable.  I'm not throwing mine 
away.	And I'd
 > be very willing to at least do preliminary coding for the two ESC-code
 > languages meantioned.
 >
 > I think its clear that one needs to go from postscript to lq-2500. 
For these
 > printers, text must be printed as text and images as images, without 
botching
 > things by making text into incoherent bits.
 >
 > It's also clear that some postscript converters, like 'gs', ruin the 
file by
 > making normal fonts curved or bitmapped graphics - before the print 
filter sees
 > it.  These are only for printing graphics.
 >
 > So, if one had a converter that wen't to postcript without converting 
text to
 > images (? I think groff does this?) then it is easily possible to 
print mixed
 > text and graphics on these printers at near Word Perfect quality - 
and at any
 > rate nice and at the speed intended.
 >
 > If you want - I can give you just a sort of code ready version (emulation
 > ready) version of lq2500.
 >
 > I don't look at e-mail too often - so don't expect immediate 
response.	I do
 > check e-mail and this site regularly, though not often.
 >
 >
 > Thanks,
 >
 > John


Roger Leigh wrote on inkjet-archutecture:
> Hi folks,
> 
> One thing I've been working on recently has been an groescp device for
> the GNU groff typesetter, to allow printing to ESC/P printers
> (primarily my old FX 80-compatible dot matrix printers).  This is a
> fairly simple driver, based on a stripped-down version of the grotty
> device, which is currently ASCII only, though I intend to allow
> alternate charset selection in future versions.
> 
> Looking at the more advanced capabilities of the ESC/P2 language, it
> should be possible to create a rather more sophisticated driver for
> EPSON inkjets, impact and lasers supporting the ESC/P2 language.  This
> would give us:
> 
> ? Scalable and proportional fonts.
> ? Several typefaces
> ? Basic spot colour
> ? pic line art and other graphics can be rendered as a raster bitmap
>   layer under the text, with the text overprinted on top.
> 
> This would be a rather more ambitious driver, which would take some
> time to develop, though I may be able to do this at work [leaving more
> of my (currently barely existent) spare time for Gimp-Print :-)]
> However, what I need for this are the font metrics for the fonts in
> the printer firmware.  Are these available?  Without them, groff can't
> know how to place and fill text over the page.
> 
> 
> Why am I doing this?  For work, I need a very fast way of producing
> formatted reports and documentation on a variety of printers.  groff
> is ideal for this, but outputting Postscript and then running through
> gs and Gimp-Print (either gs/ijsgimpprint or espgs/rastertoprinter) is
> unacceptably high for the small embedded system this will run on.
> groff is nothing if not lightning fast, and making use of ESC/P2 as a
> backend output option will be very efficient.  It's also a neat
> idea--how many drivers out there actually *use* more than 5% of
> ESC/P2's capabilities (outside its raster graphics support)?
> 
> 
> Regards,
> Roger
> 



From till.kamppeter at gmx.net  Wed Dec 10 08:42:57 2003
From: till.kamppeter at gmx.net (Till Kamppeter)
Date: Wed, 10 Dec 2003 16:42:57 +0000
Subject: [Inkjet-list] Re: [Foomatic] Printer Driver Developement
In-Reply-To: <20031210110321.76405.qmail@web12823.mail.yahoo.com>
References: <20031210110321.76405.qmail@web12823.mail.yahoo.com>
Message-ID: <3FD74D11.2080904@gmx.net>

[ Back-posting to the lists, please always use "Reply to all" when
   answering to list postings ]

John Hendrickson wrote:
> Hi,
> 
> Thanks for your input.
> 
> I will try that.
> 
> I am vaguely familiar with foomatic.  It is an altered PPD, capable of
> activating the script you meantioned.  A ppd can contain ESC sequences,
> but not enough to fill in the gaping whole.
> 

The PPD does not need to contain ESC sequences. It only needs to contain 
the info how to call your ps2escp script. ps2escp will then create an 
ESC/P data stream containing the ESC sequences. The actually used ESC 
sequences depend on the text formatting in the PostScript input data and 
on the user-supplied options.

> I am familiar with XML and xml drivers.
> 
> Question 1:
> Am I defining an XML language with a driver that interprets it, or is
> there an xml driver that I am working within (I know - get the README ;) 
> Is the xml for the PPD?  I don't see how xml is related to postscript or
> ESCP directly.
> 

The XML is the printer/driver database of Foomatic/linuxprinting.org. It 
describes the known printers, how well they work, with which drivers, 
the drivers, with their PostScript-to-printer's-language filter command 
lines, and the possible user-settable options and how the settings are 
applied to the filtering process. From this XML data for any given 
printer/driver combo a PPD file is generated by PPD-O-Matic, Foomatic's 
PPD generator.

> 
> Question 2:
> What do you use for postscript interpretation and emulation?
> 

PostScript is usually rendered by GhostScript, I don't know any 
alternative program.

> I like your idea of using postscript positions as text positions. 
> However, I'm unsure how to parse postscript reliably since postscript
> widely differs and can be code, do math, etc, etc...  I can guess that
> rendering the file, running the postscript code, yeilds the position if
> you know how to trap the emulator when gets to where and what on the page
> you are.
> 

Probably the best is to write a GhostScript driver which produces the 
ESC/P data. As the driver should not be a raster driver, but instead a 
sequence of instructions text, and embedded bitmaps, it will be similar 
to the "pxlmono"/"pxlcolor" GhostScript driver. You should have a look 
there. Perhaps you could alternatively make use of the "pswrite" driver 
of GhostScript which somehow simplifies the incoming PostScript.

> I do have a postcript 2 printer to toy with and log into, if I need that.
> 

You can use GhostScript as a PostScript interpreter for your tests.

> I know there are unix tools for getting text of postscript files and for
> getting embedded images from postscript files.  I had been thinking of how
> to clamp the positions as well.  My first though was: stick KISS -  stick
> with built-in fonts and use spacing for the rest.  Start with what works
> (or is required) and is first acheivable - then backfill features as new
> versions.
> 
> Now a printer runs postscript code and eeks out motor controls.  So
> perhaps postscript emulator which runs but eeks out ESCP is another angle
> to look at.
> 

See above for my GhostScript driver suggestion.

    Till