gimp-print-devel

Re: [Gimp-print-devel] Printer Applications - The new architecture for Gutenprint

[Robert K. <rl...@al...>]

On Tue, 1 Oct 2019 12:46:28 +0200, Till Kamppeter wrote:
> On 01/10/2019 04:55, Robert Krawitz wrote:
>>> SANE is not really needed here, as we do not want to do a
>>> wrapper/converter Printer Application as it was created in this
>>> year's Google Summer of Code but a native one. As PPDs get
>>> eliminated, SANE will also get eliminated.
>> 
>> Front ends maybe (just like our GIMP plugin will at best lose a lot of
>> its raison d'etre), but the backends won't.
>
> I mean that within the Printer Application the SANE frontend/backend
> interface is not necessarily needed. One could make the application
> directly talk to the scanner.

Sure; the Gutenprint GIMP plugin will also go away.  But a good
backend interface will surely make writing the scanner part of the
printing application easier.

> A PDF renderer is not needed at all by the Printer
> Application. There are driverless IPP printers around which do not
> understand PDF, they only accept one or more of the raster formats
> Apple Raster, PWG Raster, and/or PCLm.So you let your Printer
> Application emulate such a raster-only printer. Then you only need
> to convert the incoming raster data to the raster format of the
> actual printer using libgutenprint. No PDF interpreter and no fonts
> needed.

OK, good enough.

>>> My recommendation is to do the Printer Application for Gutenprint as
>>> a part of the Gutenprint project, even if we connect to scanner
>>> drivers with SANE in the beginning, as most of the driver part comes
>>> from Gutenprint and scanning should be sooner or later move over
>>> from SANE to Gutenprint.
>>>
>>> Also not all of these components need to be done at once. Most
>>> important is the printing support (part 1 and 2). The other
>>> components can be added later.
>> 
>> I agree with starting there.  But I'd much rather the scanning experts
>> do the scanning work.  If there has to be a single app for both
>> printing and scanning, maybe it would make more sense for that to be a
>> third project (or a joint project between SANE and Gutenprint).  We
>> can surely kick that particular can down the road for a while, though.
>> 
>
> I think joint Gutenprint/SANE project would be the best here.
>
> In the end you emulate an IPP multi-function device which does both
> printing and scanning.

Yes, that makes sense.  I should probably bring this up on the SANE
devel list at some point.
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

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

Re: [Gimp-print-devel] Samsung ML-1630W for macOS

[Robert K. <rl...@al...>]

On Tue, 1 Oct 2019 06:50:52 -0400, Solomon Peachy wrote:
> On Mon, Sep 30, 2019 at 10:33:29PM -0400, Robert Krawitz wrote:
>> Interesting.  But it's a bit of a mixed bag (a lot of their current
>> printers are not IPP-Everywhere), and if nobody else has
>> self-certified any printers, it's harder to say.
>
> I think if you look for "Airprint" or "Mopria" support instead of 
> "IPP-Everywhere" the list will get a bit longer.
>
> Eg all but the very first wifi-enabled SELPHY model supports AirPrint, 
> but only the most recent two models handle IPP-Everywhere.
>
> (Unfortunately, while Airprint and Mopria are built on top of IPP, 
>  they're not quite comptible with IPP-Everywhere, and the specs are 
>  proprietary...)

Which isn't really very useful for IPP-Everywhere :-(

>> I guess I'm a bit too familiar with Epson inkjets, which aren't (Epson
>> offers some software to provide IPP functionality, but that isn't
>> IPP-Everywhere).
>
> A bunch of Epsons are listed as Mopria certified, but they are 
> predominantly XP- or EP-/ET- series models -- home/consumer/office 
> targeted, and not the more specialized or commercial-focused units that 
> provide most of our joy...

Which again, isn't the same thing as IPP-Everywhere.
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

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

Re: [Gimp-print-devel] Samsung ML-1630W for macOS

[Solomon P. <pi...@sh...>]

On Mon, Sep 30, 2019 at 10:33:29PM -0400, Robert Krawitz wrote:
> Interesting.  But it's a bit of a mixed bag (a lot of their current
> printers are not IPP-Everywhere), and if nobody else has
> self-certified any printers, it's harder to say.

I think if you look for "Airprint" or "Mopria" support instead of 
"IPP-Everywhere" the list will get a bit longer.

Eg all but the very first wifi-enabled SELPHY model supports AirPrint, 
but only the most recent two models handle IPP-Everywhere.

(Unfortunately, while Airprint and Mopria are built on top of IPP, 
 they're not quite comptible with IPP-Everywhere, and the specs are 
 proprietary...)

> I guess I'm a bit too familiar with Epson inkjets, which aren't (Epson
> offers some software to provide IPP functionality, but that isn't
> IPP-Everywhere).

A bunch of Epsons are listed as Mopria certified, but they are 
predominantly XP- or EP-/ET- series models -- home/consumer/office 
targeted, and not the more specialized or commercial-focused units that 
provide most of our joy...

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
High Springs, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

Re: [Gimp-print-devel] Printer Applications - The new architecture for Gutenprint

[Till K. <til...@gm...>]

On 01/10/2019 04:55, Robert Krawitz wrote:
>> SANE is not really needed here, as we do not want to do a
>> wrapper/converter Printer Application as it was created in this
>> year's Google Summer of Code but a native one. As PPDs get
>> eliminated, SANE will also get eliminated.
> 
> Front ends maybe (just like our GIMP plugin will at best lose a lot of
> its raison d'etre), but the backends won't.
> 

I mean that within the Printer Application the SANE frontend/backend 
interface is not necessarily needed. One could make the application 
directly talk to the scanner.

>> 1. Inform client about the printer's capabilities on request
>> (get-printer-attributes). The information comes from the
>> libgutenprint library.
> 
> Right, which is where I've wanted to go all along (I remember some of
> those printing summits, back in the day when I actually would travel
> on business-ish).
> 
>> 2. Print: The conversion of incoming data (PWG/CUPS/Apple Raster)
>> into the printer's native code is also done with
>> libgutenprint. PDF/PostScript rendering and fonts are not needed at
>> all (by letting the IPP server REQUIRE only the three raster formats
>> and not accept PDF as input).
> 
> I certainly don't want to write a PDF renderer, although maybe poppler
> could be used for that purpose (but it has some licensing problems),
> but do all applications have a way to generate one of these raster
> formats?
> 

A PDF renderer is not needed at all by the Printer Application. There 
are driverless IPP printers around which do not understand PDF, they 
only accept one or more of the raster formats Apple Raster, PWG Raster, 
and/or PCLm.So you let your Printer Application emulate such a 
raster-only printer. Then you only need to convert the incoming raster 
data to the raster format of the actual printer using libgutenprint. No 
PDF interpreter and no fonts needed.

On a desktop system with your Printer Application running CUPS would 
pick up your emulated PPD printer, create a temporary queue and run a 
filter chain to turn the application's PDF output into one of the raster 
formats which the Printer Application needs.

>> 3. For scanning devices are probably only supported if they are
>> supported by a SANE driver. This code could be used also in our
>> Printer Application, preferably even without the SANE interface. The
>> code at least lells us the communication protocol for scanning on
>> Epson (Canon) scanners. In a first approach one could work as a SANE
>> client here and use the SANE drivers but ideally, one should extend
>> libgutenprint for listing scan capabilities and also providing the
>> scanner driver.
> 
> I don't know the internals of SANE, but I suspect trying to use the
> SANE backends without the framework would be a bit like using the
> Gutenprint family drivers without such.  Scanning's very different
> from printing, and SANE and Gutenprint have no shared development
> history so it's pretty unlikely that what we've done and what they
> done could be conveniently shoehorned together at a low level.
> 

Then probably it is perhaps the easiest approach to add a SANE fromtemd 
to the Printer Application and include the appropriate SANE backends 
which support Gutenprint-driven MF devices to the package.

>> 4. IPP System Service: This is the IPP standard to provide
>> configuration/maintenance/cleaning/firmware update interface in an
>> OS-independent way. escputil should go in here for example.
> 
> OK.
> 
>> 5. Web interface: As there are no GUI frontends for using the IPP
>> System Service yet, it is useful to also provide the
>> configuration/maintenance/cleaning options in a web interface.
> 
> So that means adding a web server...somewhere.
> 
>> My recommendation is to do the Printer Application for Gutenprint as
>> a part of the Gutenprint project, even if we connect to scanner
>> drivers with SANE in the beginning, as most of the driver part comes
>> from Gutenprint and scanning should be sooner or later move over
>> from SANE to Gutenprint.
>>
>> Also not all of these components need to be done at once. Most
>> important is the printing support (part 1 and 2). The other
>> components can be added later.
> 
> I agree with starting there.  But I'd much rather the scanning experts
> do the scanning work.  If there has to be a single app for both
> printing and scanning, maybe it would make more sense for that to be a
> third project (or a joint project between SANE and Gutenprint).  We
> can surely kick that particular can down the road for a while, though.
> 

I think joint Gutenprint/SANE project would be the best here.

In the end you emulate an IPP multi-function device which does both 
printing and scanning.

    Till

Re: [Gimp-print-devel] Printer Applications - The new architecture for Gutenprint

[Robert K. <rl...@al...>]

On Mon, 30 Sep 2019 13:07:38 +0200, Till Kamppeter wrote:
> [ Changed subject to not have something that important hiden under
>    Samsung 1630 ]
>
> On 28/09/2019 20:35, Robert Krawitz wrote:
>>> Yes, that is the way to go, also for non-Mac-OS-X systems we want to get rid of the 1980's hack. Therefore we are already working on this at OpenPrinting. Printer Applications (this is how these local IPP servers are called) will not only be able to replace classic printer drivers but also SANE scanner drivers (there is also an IPP driverless scanning standard) and even configuring the Printer Application and the Printer and also maintaining/cleaning/firmware-updating the printer (for all this there is IPP System Service). So a Printer Application can support a multi-function device with all its bells and whistles.
>> 
>> Perhaps there needs to be a separate project that builds a Printer
>> Application for both Gutenprint and SANE.  The two projects have both
>> developed for many years with no commonality at all between
>> architecture, much less code base, but both projects export a common
>> API (at least for basic operations, in our case -- we don't have a
>> common API for e. g. status readback and maintenance operations).
>> 
>> Till, are you in touch with the SANE people at all?
>
> SANE is not really needed here, as we do not want to do a
> wrapper/converter Printer Application as it was created in this
> year's Google Summer of Code but a native one. As PPDs get
> eliminated, SANE will also get eliminated.

Front ends maybe (just like our GIMP plugin will at best lose a lot of
its raison d'etre), but the backends won't.

> 1. Inform client about the printer's capabilities on request
> (get-printer-attributes). The information comes from the
> libgutenprint library.

Right, which is where I've wanted to go all along (I remember some of
those printing summits, back in the day when I actually would travel
on business-ish).

> 2. Print: The conversion of incoming data (PWG/CUPS/Apple Raster)
> into the printer's native code is also done with
> libgutenprint. PDF/PostScript rendering and fonts are not needed at
> all (by letting the IPP server REQUIRE only the three raster formats
> and not accept PDF as input).

I certainly don't want to write a PDF renderer, although maybe poppler
could be used for that purpose (but it has some licensing problems),
but do all applications have a way to generate one of these raster
formats?

> 3. For scanning devices are probably only supported if they are
> supported by a SANE driver. This code could be used also in our
> Printer Application, preferably even without the SANE interface. The
> code at least lells us the communication protocol for scanning on
> Epson (Canon) scanners. In a first approach one could work as a SANE
> client here and use the SANE drivers but ideally, one should extend
> libgutenprint for listing scan capabilities and also providing the
> scanner driver.

I don't know the internals of SANE, but I suspect trying to use the
SANE backends without the framework would be a bit like using the
Gutenprint family drivers without such.  Scanning's very different
from printing, and SANE and Gutenprint have no shared development
history so it's pretty unlikely that what we've done and what they
done could be conveniently shoehorned together at a low level.

> 4. IPP System Service: This is the IPP standard to provide
> configuration/maintenance/cleaning/firmware update interface in an
> OS-independent way. escputil should go in here for example.

OK.

> 5. Web interface: As there are no GUI frontends for using the IPP
> System Service yet, it is useful to also provide the
> configuration/maintenance/cleaning options in a web interface.

So that means adding a web server...somewhere.

> My recommendation is to do the Printer Application for Gutenprint as
> a part of the Gutenprint project, even if we connect to scanner
> drivers with SANE in the beginning, as most of the driver part comes
> from Gutenprint and scanning should be sooner or later move over
> from SANE to Gutenprint.
>
> Also not all of these components need to be done at once. Most
> important is the printing support (part 1 and 2). The other
> components can be added later.

I agree with starting there.  But I'd much rather the scanning experts
do the scanning work.  If there has to be a single app for both
printing and scanning, maybe it would make more sense for that to be a
third project (or a joint project between SANE and Gutenprint).  We
can surely kick that particular can down the road for a while, though.
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

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

Re: [Gimp-print-devel] Samsung ML-1630W for macOS

[Robert K. <rl...@al...>]

On Mon, 30 Sep 2019 13:54:53 -0400, Solomon Peachy wrote:
> On Sat, Sep 28, 2019 at 11:36:22AM -0400, Robert Krawitz wrote:
>> As an aside, I see a lot of claims that essentially all modern
>> printers are "driverless".  I don't understand where that claim comes
>> from.  I'm not aware of any inkjet printers, for example, that support
>> PWG raster or PDF.
>
> There's a pretty long list of self-certified IPP-Everywhere inkjets 
> listed on the PWG's web site.  (It looks like only HP has submitted 
> stuff though..)
>
> They're all consumer/office-focused models.

Interesting.  But it's a bit of a mixed bag (a lot of their current
printers are not IPP-Everywhere), and if nobody else has
self-certified any printers, it's harder to say.

I guess I'm a bit too familiar with Epson inkjets, which aren't (Epson
offers some software to provide IPP functionality, but that isn't
IPP-Everywhere).
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

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

[Gimp-print-devel] Ricoh Savin C9025 Printer- Trying to Connect to Mac with OS Mojave

[Office <Of...@mp...>]

I am having difficulties getting the printer to work. I have done it on my older mac but can't get it to work on my new macbook.

Please help






[cid:0a28e708-3e23-4edf-99c7-0fbb9580fb4f]

Sasha Struthers

Office Administrator | 323. 581. 6600

314 W. 58th Street Unit 200 Los Angeles, Ca 90037

of...@mp...

Re: [Gimp-print-devel] Samsung ML-1630W for macOS

[Solomon P. <pi...@sh...>]

On Sat, Sep 28, 2019 at 11:36:22AM -0400, Robert Krawitz wrote:
> As an aside, I see a lot of claims that essentially all modern
> printers are "driverless".  I don't understand where that claim comes
> from.  I'm not aware of any inkjet printers, for example, that support
> PWG raster or PDF.

There's a pretty long list of self-certified IPP-Everywhere inkjets 
listed on the PWG's web site.  (It looks like only HP has submitted 
stuff though..)

They're all consumer/office-focused models.

Of the dyesub models I'm familiar with, only the most recent Canon 
SELPHY models (CP1200 or newer) claim IPP Everywhere support, over both 
WiFi and USB.  I haven't checked to see if they're being honest.

Several HiTi models have wifi support, but they only mention working 
with specific cloud-centric mobile apps.  HiTi makes no mention of 
Airprint, Mopria, IPP, or any other standard-ish protocols.

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
High Springs, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

[Gimp-print-devel] Printer Applications - The new architecture for Gutenprint

[Till K. <til...@gm...>]

[ Changed subject to not have something that important hiden under
   Samsung 1630 ]

On 28/09/2019 20:35, Robert Krawitz wrote:
>> Yes, that is the way to go, also for non-Mac-OS-X systems we want to get rid of the 1980's hack. Therefore we are already working on this at OpenPrinting. Printer Applications (this is how these local IPP servers are called) will not only be able to replace classic printer drivers but also SANE scanner drivers (there is also an IPP driverless scanning standard) and even configuring the Printer Application and the Printer and also maintaining/cleaning/firmware-updating the printer (for all this there is IPP System Service). So a Printer Application can support a multi-function device with all its bells and whistles.
> 
> Perhaps there needs to be a separate project that builds a Printer
> Application for both Gutenprint and SANE.  The two projects have both
> developed for many years with no commonality at all between
> architecture, much less code base, but both projects export a common
> API (at least for basic operations, in our case -- we don't have a
> common API for e. g. status readback and maintenance operations).
> 
> Till, are you in touch with the SANE people at all?
> 

SANE is not really needed here, as we do not want to do a 
wrapper/converter Printer Application as it was created in this year's 
Google Summer of Code but a native one. As PPDs get eliminated, SANE 
will also get eliminated.

The application will run an IPP server, like the "ippserver" in

https://github.com/istopwg/ippsample

The server should especially do the following actions:


1. Inform client about the printer's capabilities on request 
(get-printer-attributes). The information comes from the libgutenprint 
library.

2. Print: The conversion of incoming data (PWG/CUPS/Apple Raster) into 
the printer's native code is also done with libgutenprint. 
PDF/PostScript rendering and fonts are not needed at all (by letting the 
IPP server REQUIRE only the three raster formats and not accept PDF as 
input).

3. For scanning devices are probably only supported if they are 
supported by a SANE driver. This code could be used also in our Printer 
Application, preferably even without the SANE interface. The code at 
least lells us the communication protocol for scanning on Epson (Canon) 
scanners. In a first approach one could work as a SANE client here and 
use the SANE drivers but ideally, one should extend libgutenprint for 
listing scan capabilities and also providing the scanner driver.

4. IPP System Service: This is the IPP standard to provide 
configuration/maintenance/cleaning/firmware update interface in an 
OS-independent way. escputil should go in here for example.

5. Web interface: As there are no GUI frontends for using the IPP System 
Service yet, it is useful to also provide the 
configuration/maintenance/cleaning options in a web interface.


My recommendation is to do the Printer Application for Gutenprint as a 
part of the Gutenprint project, even if we connect to scanner drivers 
with SANE in the beginning, as most of the driver part comes from 
Gutenprint and scanning should be sooner or later move over from SANE to 
Gutenprint.

Also not all of these components need to be done at once. Most important 
is the printing support (part 1 and 2). The other components can be 
added later.

    Till

Re: [Gimp-print-devel] Printer

[Fst <fst...@ho...>]

Thanks for the info. I’m not that tech savvy to know where the settings are.

> On Sep 29, 2019, at 11:46 AM, Gernot Hassenpflug <aik...@gm...> wrote:
> 
>> On Sun, Sep 29, 2019 at 11:54 AM Fst <fst...@ho...> wrote:
>> 
>> Any suggestions how to make colors come out better. This is a photo printer and prints and colors are way off. Thanks for the help
> 
> Hi Fst,
> Canon printers in general do not have any colour calibration.
> Only thing I can suggest is to play with the various densities to
> change the colors for your printer, and save those settings.
> If you want to do it properly, you will need to be able to compile
> gutenprint, perform lots of tests, and adjust the color matrices for
> hue, saturation and lightness. This may differ depending on media type
> and on the resolution mode used.
> 
> Best regards,
> Gernot Hassenpflug
>>>> On Sep 27, 2019, at 5:25 PM, Gernot Hassenpflug <aik...@gm...> wrote:
>>>> 
>>>> On Sat, Sep 28, 2019 at 6:14 AM Fst <fst...@ho...> wrote:
>>>> 
>>>> Hey guys nice work. How do I get printer units for canon Pro 9000. Thanks again!!!
>>> Hello,
>>> The Canon Pro 9000 is already supported in gutenprint (to some degree).
>>> What is your actual problem? What are "printer units"?
>>> Regards,
>>> Gernot Hassenpflug

Re: [Gimp-print-devel] Printer

[Daniel W. <d...@ni...>]

Hi, you have to setup a printer color profile. There are a lot of 
professional shops which offers the service. You get color targets from 
them, you print these without any color correction and send the targets 
in. They do the profile for you and you install it in your system. 
Afterwards use the profile on the printer. In KDE or Gnome there are 
built in color correction managers, which i would recommend. Afterwards 
Colors are perfect. You need one profile on every different paper and 
printer. Always use the same printer driver settings as you printed the 
targets. I have gone through this process the last 2 years, because i 
changed my workflow completely to darktable and gimp. I print on the 
Epson SC-P800, with Refill ink. Perfect Results.
If you are in Germany i could recommend farbenwerk.de
Daniel.

Am 2019-09-29 04:54, schrieb Fst:
> Any suggestions how to make colors come out better. This is a photo
> printer and prints and colors are way off. Thanks for the help
> 
>> On Sep 27, 2019, at 5:25 PM, Gernot Hassenpflug <aik...@gm...> 
>> wrote:
>> 
>>> On Sat, Sep 28, 2019 at 6:14 AM Fst <fst...@ho...> wrote:
>>> 
>>> Hey guys nice work. How do I get printer units for canon Pro 9000. 
>>> Thanks again!!!
>> Hello,
>> The Canon Pro 9000 is already supported in gutenprint (to some 
>> degree).
>> What is your actual problem? What are "printer units"?
>> Regards,
>> Gernot Hassenpflug
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] Printer

[Gernot H. <aik...@gm...>]

On Sun, Sep 29, 2019 at 11:54 AM Fst <fst...@ho...> wrote:
>
> Any suggestions how to make colors come out better. This is a photo printer and prints and colors are way off. Thanks for the help

Hi Fst,
Canon printers in general do not have any colour calibration.
Only thing I can suggest is to play with the various densities to
change the colors for your printer, and save those settings.
If you want to do it properly, you will need to be able to compile
gutenprint, perform lots of tests, and adjust the color matrices for
hue, saturation and lightness. This may differ depending on media type
and on the resolution mode used.

Best regards,
Gernot Hassenpflug
> > On Sep 27, 2019, at 5:25 PM, Gernot Hassenpflug <aik...@gm...> wrote:
> >
> >> On Sat, Sep 28, 2019 at 6:14 AM Fst <fst...@ho...> wrote:
> >>
> >> Hey guys nice work. How do I get printer units for canon Pro 9000. Thanks again!!!
> > Hello,
> > The Canon Pro 9000 is already supported in gutenprint (to some degree).
> > What is your actual problem? What are "printer units"?
> > Regards,
> > Gernot Hassenpflug

Re: [Gimp-print-devel] Epson ET-M1140 Ecotank

[Solomon P. <pi...@sh...>]

On Sun, Sep 29, 2019 at 07:15:40AM -0500, Matt Broughton wrote:
> Oops.  That should have read -- it was not possible to add the 
> dependencies to the Mac OS X system to allow Gutenprint to compile and 
> work.

IIRC the underlying reason we dropped PPC support is that Apple dropped 
PPC from their development tooling, as well as other 
packaging/requirement changes that meant we couldn't simultaneously 
support old (ancient?) versions of OSX and their current releases.

We'd have had to keep an old OSX system around to build for older 
releases, and a new one for the latest systesm.  Plus maintain multiple 
sets of packaging scripts/etc.

Now, none of that was inherently insurmountable.. but it did represent a 
non-trival amount of effort that we simply weren't able to 
undertake.  Heck, we can barely keep up with modern Apple.  :)

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
High Springs, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

Re: [Gimp-print-devel] Epson ET-M1140 Ecotank

[Matt B. <wal...@ma...>]

> On Sep 29, 2019, at 7:06 AM, Matt Broughton <wal...@ma...> wrote:
> 
> 
> 
>> On Sep 28, 2019, at 8:10 PM, Robert Krawitz <rl...@al... <mailto:rl...@al...>> wrote:
>> 
>> On Fri, 27 Sep 2019 22:19:43 +0300, te...@yl... <mailto:te...@yl...> wrote:
>>> Hi,
>>> 
>>> I can beta testing Gutenprint with Epson ET-M1140 Ecotank,
>>> but needed OS X 10.5 version, it can be 64-bit, because
>>> my machine is Apple Powermac G5 Quadcore 2.5Ghz PPC and maximum
>>> OS for this machine is Mac OS X 10.5. Although I like more
>>> Mac OS X 10.4 (Tiger).
>>> 
>>> Is there any generic escp2 support, where to start testing?
>>> 
>>> Some hints how to make 64-bit application for OS X 10.5 (and even OS X  
>>> 10.4 PPC) in intel macs:
>>> 
>>> How to make PPC support for Xcode 4:
>>> https://github.com/thinkyhead/Legacy-XCode-Scripts <https://github.com/thinkyhead/Legacy-XCode-Scripts>
>>> 
>>> and if needed:
>>> == G5-Related Flags for GCC ===
>>> -mcpu=970
>>> This allows the compiler to use instructions only available on the G5  
>>> (also known as 970) processor.
>>> 
>>> -mtune=970
>>> This tells the compiler to tune code as optimally as it can for the  
>>> G5. This flag can be safely used by itself on code that may run on  
>>> processors other than the G5, because code compatibility is not changed.
>>> 
>>> -mpowerpc64
>>> In combination with the above flags, this flag tells the compiler to  
>>> enable the G5's native 64-bit long long support for greatly enhanced  
>>> performance when working with long longs. At times, the  
>>> -force_cpusubtype_ALL flag may also be needed.
>> 
>> Hi,
>> 
>> Unfortunately, we do not have any PPC-based Macintosh systems or the
>> ability to build for OS X prior to 10.6.
>> -- 
>> Robert Krawitz                                     <rl...@al... <mailto:rl...@al...>>
>> 
>> ***  MIT Engineers   A Proud Tradition   http://mitathletics.com <http://mitathletics.com/>  ***
>> Member of the League for Programming Freedom  --  http://ProgFree.org <http://progfree.org/>
>> Project lead for Gutenprint   --    http://gimp-print.sourceforge.net <http://gimp-print.sourceforge.net/>
>> 
>> "Linux doesn't dictate how I work, I dictate how Linux works."
>> --Eric Crampton
>> 
> 
> If I remember correctly, there was a change in Gutenprint and Mac OS X did not have one or more of the dependencies.  Also, it was not possible those dependencies to  compile Gutenprint and make Gutenprint work.

Oops.  That should have read -- it was not possible to add the dependencies to the Mac OS X system to allow Gutenprint to compile and work.

--
Matt Broughton

Re: [Gimp-print-devel] Epson ET-M1140 Ecotank

[Matt B. <wal...@ma...>]

> On Sep 28, 2019, at 8:10 PM, Robert Krawitz <rl...@al...> wrote:
> 
> On Fri, 27 Sep 2019 22:19:43 +0300, te...@yl... <mailto:te...@yl...> wrote:
>> Hi,
>> 
>> I can beta testing Gutenprint with Epson ET-M1140 Ecotank,
>> but needed OS X 10.5 version, it can be 64-bit, because
>> my machine is Apple Powermac G5 Quadcore 2.5Ghz PPC and maximum
>> OS for this machine is Mac OS X 10.5. Although I like more
>> Mac OS X 10.4 (Tiger).
>> 
>> Is there any generic escp2 support, where to start testing?
>> 
>> Some hints how to make 64-bit application for OS X 10.5 (and even OS X  
>> 10.4 PPC) in intel macs:
>> 
>> How to make PPC support for Xcode 4:
>> https://github.com/thinkyhead/Legacy-XCode-Scripts
>> 
>> and if needed:
>> == G5-Related Flags for GCC ===
>> -mcpu=970
>> This allows the compiler to use instructions only available on the G5  
>> (also known as 970) processor.
>> 
>> -mtune=970
>> This tells the compiler to tune code as optimally as it can for the  
>> G5. This flag can be safely used by itself on code that may run on  
>> processors other than the G5, because code compatibility is not changed.
>> 
>> -mpowerpc64
>> In combination with the above flags, this flag tells the compiler to  
>> enable the G5's native 64-bit long long support for greatly enhanced  
>> performance when working with long longs. At times, the  
>> -force_cpusubtype_ALL flag may also be needed.
> 
> Hi,
> 
> Unfortunately, we do not have any PPC-based Macintosh systems or the
> ability to build for OS X prior to 10.6.
> -- 
> Robert Krawitz                                     <rl...@al... <mailto:rl...@al...>>
> 
> ***  MIT Engineers   A Proud Tradition   http://mitathletics.com <http://mitathletics.com/>  ***
> Member of the League for Programming Freedom  --  http://ProgFree.org <http://progfree.org/>
> Project lead for Gutenprint   --    http://gimp-print.sourceforge.net <http://gimp-print.sourceforge.net/>
> 
> "Linux doesn't dictate how I work, I dictate how Linux works."
> --Eric Crampton
> 

If I remember correctly, there was a change in Gutenprint and Mac OS X did not have one or more of the dependencies.  Also, it was not possible those dependencies to  compile Gutenprint and make Gutenprint work.
--
Matt Broughton

Re: [Gimp-print-devel] Printer

[Fst <fst...@ho...>]

Any suggestions how to make colors come out better. This is a photo printer and prints and colors are way off. Thanks for the help 

> On Sep 27, 2019, at 5:25 PM, Gernot Hassenpflug <aik...@gm...> wrote:
> 
>> On Sat, Sep 28, 2019 at 6:14 AM Fst <fst...@ho...> wrote:
>> 
>> Hey guys nice work. How do I get printer units for canon Pro 9000. Thanks again!!!
> Hello,
> The Canon Pro 9000 is already supported in gutenprint (to some degree).
> What is your actual problem? What are "printer units"?
> Regards,
> Gernot Hassenpflug

Re: [Gimp-print-devel] Epson ET-M1140 Ecotank

[Robert K. <rl...@al...>]

On Fri, 27 Sep 2019 22:19:43 +0300, te...@yl... wrote:
> Hi,
>
> I can beta testing Gutenprint with Epson ET-M1140 Ecotank,
> but needed OS X 10.5 version, it can be 64-bit, because
> my machine is Apple Powermac G5 Quadcore 2.5Ghz PPC and maximum
> OS for this machine is Mac OS X 10.5. Although I like more
> Mac OS X 10.4 (Tiger).
>
> Is there any generic escp2 support, where to start testing?
>
> Some hints how to make 64-bit application for OS X 10.5 (and even OS X  
> 10.4 PPC) in intel macs:
>
> How to make PPC support for Xcode 4:
> https://github.com/thinkyhead/Legacy-XCode-Scripts
>
> and if needed:
> == G5-Related Flags for GCC ===
> -mcpu=970
> This allows the compiler to use instructions only available on the G5  
> (also known as 970) processor.
>
> -mtune=970
> This tells the compiler to tune code as optimally as it can for the  
> G5. This flag can be safely used by itself on code that may run on  
> processors other than the G5, because code compatibility is not changed.
>
> -mpowerpc64
> In combination with the above flags, this flag tells the compiler to  
> enable the G5's native 64-bit long long support for greatly enhanced  
> performance when working with long longs. At times, the  
> -force_cpusubtype_ALL flag may also be needed.

Hi,

Unfortunately, we do not have any PPC-based Macintosh systems or the
ability to build for OS X prior to 10.6.
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

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

Re: [Gimp-print-devel] Samsung ML-1630W for macOS

[Steve L. <sle...@ya...>]

Sorry for the blank message. I was trying to say that we don’t have the resources to support PPC Macs.  

Steve Letter
Sent from my Commodore PET

> On Sep 28, 2019, at 7:49 AM, Steve Letter via Gimp-print-devel <gim...@li...> wrote:
> 
> 
> 
> Steve Letter
> 
>> On Sep 25, 2019, at 10:01 AM, Solomon Peachy <pi...@sh...> wrote:
>> 
>>> On Wed, Sep 25, 2019 at 03:37:20PM +0200, Benjamin Viertel wrote:
>>> So, I can perfectly understand your dislike of the current Apple 
>>> environment but I assure you it won't be Apple's benefits but the 
>>> benefits of users that like to use older stuff (like the printer, 
>>> which is actually not THAT old).
>> 
>> It's not just my personal dislike of Apple -- The next major CUPS 
>> release will remove all support for PPD-based "CUPS Drivers".  This 
>> means that Gutenprint will cease to function on future MacOS releases.
>> 
>> You may want to consider grabbing a cheap Raspberry Pi and setting it up 
>> to be a print server; that will expose your printer as an IPP device and 
>> pretty much any client other than Windows will JustWork(tm) without any 
>> client-side drivers installed..
>> 
>> - Solomon
>> -- 
>> Solomon Peachy                   pizza at shaftnet dot org
>> High Springs, FL                          ^^ (email/xmpp) ^^
>> Quidquid latine dictum sit, altum videtur.
>> _______________________________________________
>> Gimp-print-devel mailing list
>> Gim...@li...
>> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] Samsung ML-1630W for macOS

[Robert K. <rl...@al...>]

On Sat, 28 Sep 2019 10:25:51 +0200, Till Kamppeter wrote:
> On 28/09/2019 04:28, Robert Krawitz wrote:
>>> It's not just my personal dislike of Apple -- The next major CUPS
>>> release will remove all support for PPD-based "CUPS Drivers".  This
>>> means that Gutenprint will cease to function on future MacOS releases.
>> 
>> Well, we're going to need to bite the bullet and provide our own IPP
>> server implementation wrapped around Gutenprint, which is really a
>> much more sensible way of doing things.  PPD files are basically a
>> 1980's hack that have stuck around entirely too long.
>> 
>
> Yes, that is the way to go, also for non-Mac-OS-X systems we want to get rid of the 1980's hack. Therefore we are already working on this at OpenPrinting. Printer Applications (this is how these local IPP servers are called) will not only be able to replace classic printer drivers but also SANE scanner drivers (there is also an IPP driverless scanning standard) and even configuring the Printer Application and the Printer and also maintaining/cleaning/firmware-updating the printer (for all this there is IPP System Service). So a Printer Application can support a multi-function device with all its bells and whistles.

Perhaps there needs to be a separate project that builds a Printer
Application for both Gutenprint and SANE.  The two projects have both
developed for many years with no commonality at all between
architecture, much less code base, but both projects export a common
API (at least for basic operations, in our case -- we don't have a
common API for e. g. status readback and maintenance operations).

Till, are you in touch with the SANE people at all?
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

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

Re: [Gimp-print-devel] Samsung ML-1630W for macOS

[Robert K. <rl...@al...>]

On Sat, 28 Sep 2019 08:46:15 -0400, Solomon Peachy wrote:
> On Fri, Sep 27, 2019 at 10:50:21PM -0400, Robert Krawitz wrote:
>> BTW, quite aside from PPD files, there are other advantages to being
>> an IPP server.  Think about the possibility of a containerized
>> Gutenprint that we really could continuously release every time we add
>> a new printer (and it passes a somewhat more robust set of tests than
>> we currently use, of course).
>
> Oh, there are significant advantagaes to moving to a 
> fully-vertically-integrated IPP approach -- as well as the release model 
> you describe, under the hood we gain a saner job/page model, option 
> lists that can be dependent on the printer's runtime configuration, far 
> richer status reporting, and more usable mechanisms for accessing 
> "bonus" functionality.  But the migration path from where we are now is 
> not so much a path as a near-vertical cliff face.  :)

It's a big collection of projects, that's for sure.  There's the UI --
we might be able to use the libgutenprintui as a POC -- in addition to
IPP server.

> Still, I've been slowly working towards this goal with the dyesub 
> family, with the backends seeing a lot of structual rework so that they 
> can operate in both the loosely-coupled legacy CUPS model as well as 
> (what I think) is necessary for a tightly-coupled, always-on IPP 
> printing application.   

We'll want to fold escputil functionality into the Epson driver as
well.

> Baby steps..

Yes.  If we want to do what Till mentioned in his message (GSoC
project), we're going to need to determine what we need to do (and not
destroy capabilities that some people need, like DeviceN
functionality).  I'm sure that you and I have only scratched the
surface.

------

As an aside, I see a lot of claims that essentially all modern
printers are "driverless".  I don't understand where that claim comes
from.  I'm not aware of any inkjet printers, for example, that support
PWG raster or PDF.
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

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

Re: [Gimp-print-devel] Samsung ML-1630W for macOS

[Solomon P. <pi...@sh...>]

On Fri, Sep 27, 2019 at 10:50:21PM -0400, Robert Krawitz wrote:
> BTW, quite aside from PPD files, there are other advantages to being
> an IPP server.  Think about the possibility of a containerized
> Gutenprint that we really could continuously release every time we add
> a new printer (and it passes a somewhat more robust set of tests than
> we currently use, of course).

Oh, there are significant advantagaes to moving to a 
fully-vertically-integrated IPP approach -- as well as the release model 
you describe, under the hood we gain a saner job/page model, option 
lists that can be dependent on the printer's runtime configuration, far 
richer status reporting, and more usable mechanisms for accessing 
"bonus" functionality.  But the migration path from where we are now is 
not so much a path as a near-vertical cliff face.  :)

Still, I've been slowly working towards this goal with the dyesub 
family, with the backends seeing a lot of structual rework so that they 
can operate in both the loosely-coupled legacy CUPS model as well as 
(what I think) is necessary for a tightly-coupled, always-on IPP 
printing application.   

Baby steps..

 - Solomon
-- 
Solomon Peachy			       pizza at shaftnet dot org
High Springs, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.

Re: [Gimp-print-devel] Samsung ML-1630W for macOS

[Steve L. <sle...@ya...>]

Steve Letter

> On Sep 25, 2019, at 10:01 AM, Solomon Peachy <pi...@sh...> wrote:
> 
>> On Wed, Sep 25, 2019 at 03:37:20PM +0200, Benjamin Viertel wrote:
>> So, I can perfectly understand your dislike of the current Apple 
>> environment but I assure you it won't be Apple's benefits but the 
>> benefits of users that like to use older stuff (like the printer, 
>> which is actually not THAT old).
> 
> It's not just my personal dislike of Apple -- The next major CUPS 
> release will remove all support for PPD-based "CUPS Drivers".  This 
> means that Gutenprint will cease to function on future MacOS releases.
> 
> You may want to consider grabbing a cheap Raspberry Pi and setting it up 
> to be a print server; that will expose your printer as an IPP device and 
> pretty much any client other than Windows will JustWork(tm) without any 
> client-side drivers installed..
> 
> - Solomon
> -- 
> Solomon Peachy                   pizza at shaftnet dot org
> High Springs, FL                          ^^ (email/xmpp) ^^
> Quidquid latine dictum sit, altum videtur.
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] Samsung ML-1630W for macOS

[Till K. <til...@gm...>]

On 28/09/2019 04:28, Robert Krawitz wrote:
>> It's not just my personal dislike of Apple -- The next major CUPS
>> release will remove all support for PPD-based "CUPS Drivers".  This
>> means that Gutenprint will cease to function on future MacOS releases.
> 
> Well, we're going to need to bite the bullet and provide our own IPP
> server implementation wrapped around Gutenprint, which is really a
> much more sensible way of doing things.  PPD files are basically a
> 1980's hack that have stuck around entirely too long.
> 

Yes, that is the way to go, also for non-Mac-OS-X systems we want to get 
rid of the 1980's hack. Therefore we are already working on this at 
OpenPrinting. Printer Applications (this is how these local IPP servers 
are called) will not only be able to replace classic printer drivers but 
also SANE scanner drivers (there is also an IPP driverless scanning 
standard) and even configuring the Printer Application and the Printer 
and also maintaining/cleaning/firmware-updating the printer (for all 
this there is IPP System Service). So a Printer Application can support 
a multi-function device with all its bells and whistles.

For the quick convert of classic drivers into Printer Applications 
(printing only) there was a GSoC project this year:

https://gist.github.com/dheeraj135/852733a6944d2f7ede670fe9d3d0ac6a

I had also a mini conference on Linux Plumber's this year about this:

https://lwn.net/SubscriberLink/798916/300a5c0bc4caa815/

In the next GSoC scanning implementations are planned. Making a Printer 
Application of GutenPrint was also one of my ideas for a GSoC project in 
2020.

    Till

Re: [Gimp-print-devel] Samsung ML-1630W for macOS

[Robert K. <rl...@al...>]

On Wed, 25 Sep 2019 10:01:50 -0400, Solomon Peachy wrote:
> On Wed, Sep 25, 2019 at 03:37:20PM +0200, Benjamin Viertel wrote:
>> So, I can perfectly understand your dislike of the current Apple 
>> environment but I assure you it won't be Apple's benefits but the 
>> benefits of users that like to use older stuff (like the printer, 
>> which is actually not THAT old).
>
> It's not just my personal dislike of Apple -- The next major CUPS 
> release will remove all support for PPD-based "CUPS Drivers".  This 
> means that Gutenprint will cease to function on future MacOS releases.

BTW, quite aside from PPD files, there are other advantages to being
an IPP server.  Think about the possibility of a containerized
Gutenprint that we really could continuously release every time we add
a new printer (and it passes a somewhat more robust set of tests than
we currently use, of course).
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

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

Re: [Gimp-print-devel] Samsung ML-1630W for macOS

[Robert K. <rl...@al...>]

On Wed, 25 Sep 2019 10:01:50 -0400, Solomon Peachy wrote:
> On Wed, Sep 25, 2019 at 03:37:20PM +0200, Benjamin Viertel wrote:
>> So, I can perfectly understand your dislike of the current Apple 
>> environment but I assure you it won't be Apple's benefits but the 
>> benefits of users that like to use older stuff (like the printer, 
>> which is actually not THAT old).
>
> It's not just my personal dislike of Apple -- The next major CUPS 
> release will remove all support for PPD-based "CUPS Drivers".  This 
> means that Gutenprint will cease to function on future MacOS releases.

Well, we're going to need to bite the bullet and provide our own IPP
server implementation wrapped around Gutenprint, which is really a
much more sensible way of doing things.  PPD files are basically a
1980's hack that have stuck around entirely too long.
-- 
Robert Krawitz                                     <rl...@al...>

***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
Member of the League for Programming Freedom  --  http://ProgFree.org
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

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