All of lore.kernel.org
 help / color / mirror / Atom feed
* [Printing-architecture] Moving CUPS filters to OpenPrinting
@ 2011-10-27 18:07 Till Kamppeter
  2011-10-27 18:38 ` Daniel Dressler
  2011-10-28 15:52 ` Tobias Hoffmann
  0 siblings, 2 replies; 5+ messages in thread
From: Till Kamppeter @ 2011-10-27 18:07 UTC (permalink / raw)
  To: Open Printing

Hi,

Mike Sweet intends to remove the filters which are not used by Mac OS X 
from the CUPS upstream package:

http://www.cups.org/str.php?L3930

We have agreed on this on the last OpenPrinting Summit and the filters 
will be continued and hosted by OpenPrinting. In addition, the filters 
for the PDF printing workflow will not be adopted by CUPS but joined 
with the CUPS filters we overtake.

All Linux distributions would have to include this new CUPS filters 
package then to get CUPS continuing to work and have the same feature 
set as before.

Due to the fact that this package will use the PDF workflow by default 
and that all major desktop applications send their print jobs already in 
PDF, this will complete the implementation of PDF as standard print job 
format. See also my updated web page:

https://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdfasstandardprintjobformat

By this, we also do not need to get a copyright/license agreement 
between the developers of the PDF filters and Apple.

We can start hosting the CUPS filters as soon as our BZR repositories 
for OpenPrinting will be back. In the CUPS project these filters are 
already separated into their own branch, we only need to import them 
from their SVN into our BZR.

We also need a name for the package. Should we call it simply 
"cups-filters"? Or "op-cups-filters"? Or do we rename Foomatic to 
openprinting and have the packages

- openprinting-db
- openprinting-db-nonfree
- openprinting-db-engine
- openprinting-rip
- openprinting-cups-filters

Note that we keep foomatic-rip/openprinting-rip separate from the CUPS 
filters as this filter is a universal filter which also works with many 
other printing systems.

Another decision to make is whether we really should maintain all the 
filters which get over to us from CUPS or whether we should discontinue 
some. The filter set will contain "imageto..." and "textto..." filters 
which are not made use of by the usual desktop applications, they send 
all PDF (and some send PostScript). Alternatively, these filters could 
be made optional.

    Till

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Printing-architecture] Moving CUPS filters to OpenPrinting
  2011-10-27 18:07 [Printing-architecture] Moving CUPS filters to OpenPrinting Till Kamppeter
@ 2011-10-27 18:38 ` Daniel Dressler
  2011-10-28 14:45   ` Petrie, Glen
  2011-10-28 15:52 ` Tobias Hoffmann
  1 sibling, 1 reply; 5+ messages in thread
From: Daniel Dressler @ 2011-10-27 18:38 UTC (permalink / raw)
  To: Till Kamppeter; +Cc: Open Printing

[-- Attachment #1: Type: text/plain, Size: 3524 bytes --]

Hello

I think we should keep foomatic-* as is, if only to avoid user confusion.

Overall openprinting-cups-filters is a good name and can be extended to an
optional package easily, e.g. openprinting-cups-filters-extra, cannot really
go wrong with it.

The only downsides I can think of is that it is verbose and just a bit,
plain.

There is another source of options, in line with CUPS, CPD, CMPD we could
call it CFS* ( Common Filter Set ) or CPF ( Common Printing Filters ) or
CCUPSFS (Common Common Unix Printing Spooler Filter Set).

But perhaps my favourite: CUFS ( Common Unix Filter Set), it may not mention
the cups specific nature of the filters but what we lose in description we
make up for in branding, it is a pronounceable word!**

Daniel

*Already taken =\
**In English at least.



2011/10/27 Till Kamppeter <till.kamppeter@gmail.com>

> Hi,
>
> Mike Sweet intends to remove the filters which are not used by Mac OS X
> from the CUPS upstream package:
>
> http://www.cups.org/str.php?**L3930 <http://www.cups.org/str.php?L3930>
>
> We have agreed on this on the last OpenPrinting Summit and the filters will
> be continued and hosted by OpenPrinting. In addition, the filters for the
> PDF printing workflow will not be adopted by CUPS but joined with the CUPS
> filters we overtake.
>
> All Linux distributions would have to include this new CUPS filters package
> then to get CUPS continuing to work and have the same feature set as before.
>
> Due to the fact that this package will use the PDF workflow by default and
> that all major desktop applications send their print jobs already in PDF,
> this will complete the implementation of PDF as standard print job format.
> See also my updated web page:
>
> https://www.linuxfoundation.**org/collaborate/workgroups/**openprinting/**
> pdfasstandardprintjobformat<https://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdfasstandardprintjobformat>
>
> By this, we also do not need to get a copyright/license agreement between
> the developers of the PDF filters and Apple.
>
> We can start hosting the CUPS filters as soon as our BZR repositories for
> OpenPrinting will be back. In the CUPS project these filters are already
> separated into their own branch, we only need to import them from their SVN
> into our BZR.
>
> We also need a name for the package. Should we call it simply
> "cups-filters"? Or "op-cups-filters"? Or do we rename Foomatic to
> openprinting and have the packages
>
> - openprinting-db
> - openprinting-db-nonfree
> - openprinting-db-engine
> - openprinting-rip
> - openprinting-cups-filters
>
> Note that we keep foomatic-rip/openprinting-rip separate from the CUPS
> filters as this filter is a universal filter which also works with many
> other printing systems.
>
> Another decision to make is whether we really should maintain all the
> filters which get over to us from CUPS or whether we should discontinue
> some. The filter set will contain "imageto..." and "textto..." filters which
> are not made use of by the usual desktop applications, they send all PDF
> (and some send PostScript). Alternatively, these filters could be made
> optional.
>
>   Till
> ______________________________**_________________
> Printing-architecture mailing list
> Printing-architecture@lists.**linux-foundation.org<Printing-architecture@lists.linux-foundation.org>
> https://lists.linuxfoundation.**org/mailman/listinfo/printing-**
> architecture<https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture>
>

[-- Attachment #2: Type: text/html, Size: 4102 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Printing-architecture] Moving CUPS filters to OpenPrinting
  2011-10-27 18:38 ` Daniel Dressler
@ 2011-10-28 14:45   ` Petrie, Glen
  2011-10-28 14:57     ` Petrie, Glen
  0 siblings, 1 reply; 5+ messages in thread
From: Petrie, Glen @ 2011-10-28 14:45 UTC (permalink / raw)
  To: Daniel Dressler, Till Kamppeter; +Cc: Open Printing

[-- Attachment #1: Type: text/plain, Size: 4932 bytes --]

Hi,

 

I agree with Daniel comment on foomatic-*

 

While "openprinting-cups-filters" is descriptive; wouldn't
"op-cups-filters" be sufficient?

 

For the "other name" discussion, I am not sure they are really "common";
they are really just the set supported by OpenPrinting.   You say are
""""extra"""" or """"extended"""". 

 

Some other ideas

CEFS = CUPS Extended Filter Set

OCFS = OpenPrinting CUPS Filter Set 

COFS= CUPS OpenPrinting Filter Set

         = Common OpenPrinting Filter Set

 

But I am ok with "op-cups-filters"

 

For the discussion of "dropping filters" -

1.  Is the intent is stop supporting?  If so, then there should one
filter set that contains all of "abandoned" filters.  At least someone
would have access to the filter; even though reasonability for ensuring
the work with the latest CUPS is up to the person downloading this set
of filters and not any other entity.

2.  How many filters would suggest dropping?  If the number is small (<
10 say), then the burden to continue to support them may be low;
however, if the larger, can a list be generated of the suggested filters
to be dropped.  The list is then distributed on printing email lists, so
that people can provide a feedback on the candidate filters to be
dropped. 

 

glen

________________________________

From: printing-architecture-bounces@lists.linux-foundation.org
[mailto:printing-architecture-bounces@lists.linux-foundation.org] On
Behalf Of Daniel Dressler
Sent: Thursday, October 27, 2011 11:38 AM
To: Till Kamppeter
Cc: Open Printing
Subject: Re: [Printing-architecture] Moving CUPS filters to OpenPrinting

 

Hello

I think we should keep foomatic-* as is, if only to avoid user
confusion. 

Overall openprinting-cups-filters is a good name and can be extended to
an optional package easily, e.g. openprinting-cups-filters-extra, cannot
really go wrong with it.

The only downsides I can think of is that it is verbose and just a bit,
plain.

There is another source of options, in line with CUPS, CPD, CMPD we
could call it CFS* ( Common Filter Set ) or CPF ( Common Printing
Filters ) or CCUPSFS (Common Common Unix Printing Spooler Filter Set).

But perhaps my favourite: CUFS ( Common Unix Filter Set), it may not
mention the cups specific nature of the filters but what we lose in
description we make up for in branding, it is a pronounceable word!**

Daniel

*Already taken =\
**In English at least.




2011/10/27 Till Kamppeter <till.kamppeter@gmail.com>

Hi,

Mike Sweet intends to remove the filters which are not used by Mac OS X
from the CUPS upstream package:

http://www.cups.org/str.php?L3930

We have agreed on this on the last OpenPrinting Summit and the filters
will be continued and hosted by OpenPrinting. In addition, the filters
for the PDF printing workflow will not be adopted by CUPS but joined
with the CUPS filters we overtake.

All Linux distributions would have to include this new CUPS filters
package then to get CUPS continuing to work and have the same feature
set as before.

Due to the fact that this package will use the PDF workflow by default
and that all major desktop applications send their print jobs already in
PDF, this will complete the implementation of PDF as standard print job
format. See also my updated web page:

https://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdfa
sstandardprintjobformat

By this, we also do not need to get a copyright/license agreement
between the developers of the PDF filters and Apple.

We can start hosting the CUPS filters as soon as our BZR repositories
for OpenPrinting will be back. In the CUPS project these filters are
already separated into their own branch, we only need to import them
from their SVN into our BZR.

We also need a name for the package. Should we call it simply
"cups-filters"? Or "op-cups-filters"? Or do we rename Foomatic to
openprinting and have the packages

- openprinting-db
- openprinting-db-nonfree
- openprinting-db-engine
- openprinting-rip
- openprinting-cups-filters

Note that we keep foomatic-rip/openprinting-rip separate from the CUPS
filters as this filter is a universal filter which also works with many
other printing systems.

Another decision to make is whether we really should maintain all the
filters which get over to us from CUPS or whether we should discontinue
some. The filter set will contain "imageto..." and "textto..." filters
which are not made use of by the usual desktop applications, they send
all PDF (and some send PostScript). Alternatively, these filters could
be made optional.

  Till
_______________________________________________
Printing-architecture mailing list
Printing-architecture@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture

 


[-- Attachment #2: Type: text/html, Size: 25263 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Printing-architecture] Moving CUPS filters to OpenPrinting
  2011-10-28 14:45   ` Petrie, Glen
@ 2011-10-28 14:57     ` Petrie, Glen
  0 siblings, 0 replies; 5+ messages in thread
From: Petrie, Glen @ 2011-10-28 14:57 UTC (permalink / raw)
  To: Petrie, Glen, Daniel Dressler, Till Kamppeter; +Cc: Open Printing

[-- Attachment #1: Type: text/plain, Size: 5779 bytes --]

There may be some confusion on my comments at the end of my last email.
The "dropped filters" are not the one's CUPS will drop but the one Till
would like to drop.  After reviewing the web site again, I see the
number of filters may be small overall; so it now becomes of question if
Till (or others helping Till) have sufficient time to maintain the
filters.  Perhaps Till should make the decision, since it will more
directly affects him.

 

Glen

 

 

 

________________________________

From: printing-architecture-bounces@lists.linux-foundation.org
[mailto:printing-architecture-bounces@lists.linux-foundation.org] On
Behalf Of Petrie, Glen
Sent: Friday, October 28, 2011 7:45 AM
To: Daniel Dressler; Till Kamppeter
Cc: Open Printing
Subject: Re: [Printing-architecture] Moving CUPS filters to OpenPrinting

 

Hi,

 

I agree with Daniel comment on foomatic-*

 

While "openprinting-cups-filters" is descriptive; wouldn't
"op-cups-filters" be sufficient?

 

For the "other name" discussion, I am not sure they are really "common";
they are really just the set supported by OpenPrinting.   You say are
""""extra"""" or """"extended"""". 

 

Some other ideas

CEFS = CUPS Extended Filter Set

OCFS = OpenPrinting CUPS Filter Set 

COFS= CUPS OpenPrinting Filter Set

         = Common OpenPrinting Filter Set

 

But I am ok with "op-cups-filters"

 

For the discussion of "dropping filters" -

1.  Is the intent is stop supporting?  If so, then there should one
filter set that contains all of "abandoned" filters.  At least someone
would have access to the filter; even though reasonability for ensuring
the work with the latest CUPS is up to the person downloading this set
of filters and not any other entity.

2.  How many filters would suggest dropping?  If the number is small (<
10 say), then the burden to continue to support them may be low;
however, if the larger, can a list be generated of the suggested filters
to be dropped.  The list is then distributed on printing email lists, so
that people can provide a feedback on the candidate filters to be
dropped. 

 

glen

________________________________

From: printing-architecture-bounces@lists.linux-foundation.org
[mailto:printing-architecture-bounces@lists.linux-foundation.org] On
Behalf Of Daniel Dressler
Sent: Thursday, October 27, 2011 11:38 AM
To: Till Kamppeter
Cc: Open Printing
Subject: Re: [Printing-architecture] Moving CUPS filters to OpenPrinting

 

Hello

I think we should keep foomatic-* as is, if only to avoid user
confusion. 

Overall openprinting-cups-filters is a good name and can be extended to
an optional package easily, e.g. openprinting-cups-filters-extra, cannot
really go wrong with it.

The only downsides I can think of is that it is verbose and just a bit,
plain.

There is another source of options, in line with CUPS, CPD, CMPD we
could call it CFS* ( Common Filter Set ) or CPF ( Common Printing
Filters ) or CCUPSFS (Common Common Unix Printing Spooler Filter Set).

But perhaps my favourite: CUFS ( Common Unix Filter Set), it may not
mention the cups specific nature of the filters but what we lose in
description we make up for in branding, it is a pronounceable word!**

Daniel

*Already taken =\
**In English at least.



2011/10/27 Till Kamppeter <till.kamppeter@gmail.com>

Hi,

Mike Sweet intends to remove the filters which are not used by Mac OS X
from the CUPS upstream package:

http://www.cups.org/str.php?L3930

We have agreed on this on the last OpenPrinting Summit and the filters
will be continued and hosted by OpenPrinting. In addition, the filters
for the PDF printing workflow will not be adopted by CUPS but joined
with the CUPS filters we overtake.

All Linux distributions would have to include this new CUPS filters
package then to get CUPS continuing to work and have the same feature
set as before.

Due to the fact that this package will use the PDF workflow by default
and that all major desktop applications send their print jobs already in
PDF, this will complete the implementation of PDF as standard print job
format. See also my updated web page:

https://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdfa
sstandardprintjobformat

By this, we also do not need to get a copyright/license agreement
between the developers of the PDF filters and Apple.

We can start hosting the CUPS filters as soon as our BZR repositories
for OpenPrinting will be back. In the CUPS project these filters are
already separated into their own branch, we only need to import them
from their SVN into our BZR.

We also need a name for the package. Should we call it simply
"cups-filters"? Or "op-cups-filters"? Or do we rename Foomatic to
openprinting and have the packages

- openprinting-db
- openprinting-db-nonfree
- openprinting-db-engine
- openprinting-rip
- openprinting-cups-filters

Note that we keep foomatic-rip/openprinting-rip separate from the CUPS
filters as this filter is a universal filter which also works with many
other printing systems.

Another decision to make is whether we really should maintain all the
filters which get over to us from CUPS or whether we should discontinue
some. The filter set will contain "imageto..." and "textto..." filters
which are not made use of by the usual desktop applications, they send
all PDF (and some send PostScript). Alternatively, these filters could
be made optional.

  Till
_______________________________________________
Printing-architecture mailing list
Printing-architecture@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture

 


[-- Attachment #2: Type: text/html, Size: 28138 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Printing-architecture] Moving CUPS filters to OpenPrinting
  2011-10-27 18:07 [Printing-architecture] Moving CUPS filters to OpenPrinting Till Kamppeter
  2011-10-27 18:38 ` Daniel Dressler
@ 2011-10-28 15:52 ` Tobias Hoffmann
  1 sibling, 0 replies; 5+ messages in thread
From: Tobias Hoffmann @ 2011-10-28 15:52 UTC (permalink / raw)
  To: Till Kamppeter; +Cc: Open Printing

Till Kamppeter wrote:
> Another decision to make is whether we really should maintain all the 
> filters which get over to us from CUPS or whether we should 
> discontinue some. The filter set will contain "imageto..." and 
> "textto..." filters which are not made use of by the usual desktop 
> applications, they send all PDF (and some send PostScript). 
> Alternatively, these filters could be made optional.
Regarding texttops/texttopdf:
As both of them depend on common code (in general: you can drive both a 
PS and a PDF output-backend with a common api), it makes much sense to 
maintain them together, especially as there is some stuff I would have 
changed in texttops when creating texttopdf, but didn't, to keep them 
independent.
OTHO: It's not would quite clear to me, whether PS-based workflows will 
have any future. If we just wait for them to be replaced by PDF, we'd 
better decide to only keep the filters working for some more time.

I'd further say that the ability to directly print text files should 
stay, even though most features of textto{pdf,ps} (e.g. pretty printing) 
are almost never used(?). Also, to circumvent some nontrivial issues the 
current code uses some unpleasant glyph-stretching.
I wonder what Mac OS X does with plain text submitted for print directly 
(e.g. via command-line), when they don't use textto* ?

  Tobias

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2011-10-28 15:52 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-10-27 18:07 [Printing-architecture] Moving CUPS filters to OpenPrinting Till Kamppeter
2011-10-27 18:38 ` Daniel Dressler
2011-10-28 14:45   ` Petrie, Glen
2011-10-28 14:57     ` Petrie, Glen
2011-10-28 15:52 ` Tobias Hoffmann

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.