Axel Dörfler wrote:
Then bring it on! :-)If we get CUPS, I don't think keeping backwards compatibility is important at all, BTW. However, I'm not really familiar with the current architecture, so I probably don't see the improvements a new one would give us :-)
Well, the short description is as follows:The print_server is currently only aware of some global C functions in transport/printer addons which makes keeping data around between calls, and just general life span of data a bit problematic. This is done due to R5 compatibility, in Dano Be already fixed most of that by having a proper C++ hierarchy for printer drivers (Generic printer driver class, bitmap printer driver class, and vector printer driver class).
Most printer addons are currently using shared code which tries to implement a similar model as Dano did, but it has grown organicly and should not be at that level. Since we don't seem to have much out-of-tree printer drivers (that are useful) anyway, it would be fairly easy to pull that up to a higher level and make print_server aware of that model.
I think this would help a lot getting the ghostscript backends to work, but is not a requirement. Again, we don't really want CUPS, we want the printer drivers from Ghostscript and the printer specifications from foomatic, CUPS is just the glue (equal to our current print_server and transport addons, only slightly more advanced features like network printer sharing and such).
If anyone has any strong opinions about the printing architecture, please speak up to. Don't want to be doing a monologue here :)
begin:vcard fn:Ithamar Adema n:Adema;Ithamar org:Team Embedded V.O.F. adr:;;Presidentstraat 7;Almere;Flevoland;1312 AN;The Netherlands email;internet:ithamar.adema@xxxxxxxxxxxxxxxx title:Partner tel;work:+31 (0)6 11562202 tel;fax:+31 (0)36 7115448 tel;cell:+31 (0)6 11562202 note;quoted-printable:Skype: ir.adema=0D=0A= x-mozilla-html:FALSE url:http://www.team-embedded.com version:2.1 end:vcard