Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please implement a "Print on Form" feature in CUPS #65

Closed
michaelrsweet opened this issue May 2, 2003 · 7 comments
Closed

Please implement a "Print on Form" feature in CUPS #65

michaelrsweet opened this issue May 2, 2003 · 7 comments
Labels
enhancement New feature or request wontfix This will not be worked on
Milestone

Comments

@michaelrsweet
Copy link
Collaborator

Version: -feature
CUPS.org User: pipitas


General Feature Request:

           CUPS is missing an option to "print on forms". This 
       print option is more and more in demand in the Windows
       world. (It is used to print business letters without
       bothering to insert the business paper into the
       printer, etc...

Suggestion: For non-PostScript printers it could be implemented
----------- with the help of the CUPS raster file format.

Questions: is it possible to write a "filter" which layers two
---------- CUPS raster pages upon each other (just like if you
           layed to transparencies with pictures upon each other)?

           Would it be very CPU intensive?

     Idea: if it is not too complicated, it could be a very 
     ----- powerful method to print on "templates" or "forms"....

Rationale: the feature to be able to print on forms is in high
---------- and still rising demand in the Windows world. I have
           now also had the first investigations from Linux users
           (small businesses, running everything on Linux).

More ideas: It should be possible to print with a commandline like
----------- "lp -o makeform=my_business_paper -o..." This job would
be to CUPS raster and saved in a special "forms"
directory (forever or until deletion). This file could
be used as a form to be merged with future printjobs
by doing

       "lp -d printername -o useform=my_business_paper -o 

       printfile". This would make the "printfile" print onto 
       the "my_business_paper" form.

       Other commands could be "lpform --list" to list all 
       available forms, "lpform --delete=formname" to delete
       certain forms, etc.

Advantages: Any printable fileformat and any application could
----------- be used as a master form or form generating software....
Forms could be more than one page.... Everybody could
easily update his forms... A "preview" program (*) could generating
possibly also be developed... It could serve as one good
method to print personalized/serialized letters...

Disadvantages: Would work with all non-PostScript printers, but would
-------------- not work with PostScript printers (unless there was an
new backend filter which would do a "cupsrastertops"
conversion.

Unknown Vars: I have now idea how CPU-expensive this would be (to
------------- merge two CUPS raster files).

Business
opportunities: these are considerable, I think. Such a forms
-------------- generating function in ESP Print Pro and CUPS could
be a real killer application. It could help
tremendeously to establish ESP Print Pro and CUPS as
print servers in Windows environments (as long as these
keep existing... ;-)

It probably all depends on the fact how computational-intensive
the merging of two CUPS raster files is, and how difficult it is
to write. But here I have not the slightest idea -- my gut feeling
is good, because the basic idea seems to be so simple...... (and
Moore's law promises us double the CPU power within 18 months ;-)

Cheers,
Kurt

P.S.: BTW, would it be very difficult to make Gimp display a screen
representation of CUPS raster? (Or is there another easy
way to implement a CUPS raster previewer?)

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

Forms are something we plan on supporting, although the general mechanism will be based on PostScript - PostScript form files will be applied to the output prior to rasterization.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: h.blischke

If you look at my alternate pstops filter (see the links), you will see an enhanced page label feature driven by the BeginPage and EndPage features of PostScript. It will incorporate a PostScript procedure the name of which is equal to the page label string (otherwise pstops falls back to the default). This procedure surely may contain a form definition and a call of execform from within BeginPage.
Moreover, this approach allows the forms selection dependent on then page count -- e.g. usually the 2nd and following pages of a business form are different from the first page.

If you are intested, I could post an example we currently
use as a watermark.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

Begin/EndPage procedures are not available on Level 1 printers (which we still support), and they still won't be suitable for supporting arbitrary page overlays that differ from page-to-page.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: martin.kayser.keuco

I`am searching for this feature too.

I think important is:

  • cpu usage should not be to high
  • 2nd page and the following business letter pages are different
  • it should work on none postscript printers too
  • windows user should be able to print out of every application, but for the first part office programs would be enough

As this topic as more than one year old is there a chance that it will be realized in the near future?

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

Pushing this to CUPS 1.3...

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: chap

I'm not sure why you think BeginPage and EndPage cannot support
arbitrary per-page behavior - some ideas at
http://www.anastigmatix.net/postscript/PageNest.html and
http://bugs.ghostscript.com/show_bug.cgi?id=430175, esp. the fancy examples.

True enough, BeginPage/EndPage are not in Level 1, but Level 2 has been
out for 16 years now and is supported by gs which is already used as a
filter. That means there can be support already for L2/L3 jobs on L1
printers by filtering, just as is done for entirely non-PS printers, and
if that would allow one simple consistent way to do per-page behavior
then maybe it is an option worth considering.

@michaelrsweet
Copy link
Collaborator Author

CUPS.org User: mike

Sorry, we have decided this issue will not be addressed in a CUPS release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant