You can subscribe to this list here.
2000 |
Jan
(111) |
Feb
(412) |
Mar
(133) |
Apr
(187) |
May
(377) |
Jun
(355) |
Jul
(129) |
Aug
(316) |
Sep
(412) |
Oct
(258) |
Nov
(260) |
Dec
(228) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(291) |
Feb
(497) |
Mar
(341) |
Apr
(105) |
May
(127) |
Jun
(97) |
Jul
(348) |
Aug
(195) |
Sep
(353) |
Oct
(516) |
Nov
(454) |
Dec
(99) |
2002 |
Jan
(125) |
Feb
(232) |
Mar
(222) |
Apr
(160) |
May
(147) |
Jun
(97) |
Jul
(199) |
Aug
(275) |
Sep
(411) |
Oct
(355) |
Nov
(371) |
Dec
(326) |
2003 |
Jan
(314) |
Feb
(181) |
Mar
(166) |
Apr
(90) |
May
(192) |
Jun
(137) |
Jul
(91) |
Aug
(57) |
Sep
(59) |
Oct
(67) |
Nov
(202) |
Dec
(158) |
2004 |
Jan
(67) |
Feb
(81) |
Mar
(142) |
Apr
(124) |
May
(190) |
Jun
(245) |
Jul
(124) |
Aug
(199) |
Sep
(182) |
Oct
(92) |
Nov
(285) |
Dec
(173) |
2005 |
Jan
(111) |
Feb
(74) |
Mar
(90) |
Apr
(275) |
May
(133) |
Jun
(106) |
Jul
(215) |
Aug
(142) |
Sep
(131) |
Oct
(135) |
Nov
(75) |
Dec
(76) |
2006 |
Jan
(173) |
Feb
(96) |
Mar
(127) |
Apr
(226) |
May
(227) |
Jun
(83) |
Jul
(101) |
Aug
(122) |
Sep
(118) |
Oct
(27) |
Nov
(76) |
Dec
(58) |
2007 |
Jan
(204) |
Feb
(137) |
Mar
(115) |
Apr
(50) |
May
(135) |
Jun
(111) |
Jul
(57) |
Aug
(40) |
Sep
(36) |
Oct
(36) |
Nov
(77) |
Dec
(145) |
2008 |
Jan
(159) |
Feb
(52) |
Mar
(77) |
Apr
(59) |
May
(80) |
Jun
(105) |
Jul
(119) |
Aug
(225) |
Sep
(58) |
Oct
(173) |
Nov
(64) |
Dec
(94) |
2009 |
Jan
(61) |
Feb
(13) |
Mar
(70) |
Apr
(115) |
May
(48) |
Jun
(50) |
Jul
(34) |
Aug
(74) |
Sep
(30) |
Oct
(95) |
Nov
(132) |
Dec
(12) |
2010 |
Jan
(40) |
Feb
(22) |
Mar
(10) |
Apr
(5) |
May
(10) |
Jun
(73) |
Jul
(73) |
Aug
(74) |
Sep
(117) |
Oct
(33) |
Nov
(34) |
Dec
(41) |
2011 |
Jan
(42) |
Feb
(38) |
Mar
(60) |
Apr
(6) |
May
(26) |
Jun
(52) |
Jul
(16) |
Aug
(21) |
Sep
(49) |
Oct
(48) |
Nov
(64) |
Dec
(121) |
2012 |
Jan
(112) |
Feb
(81) |
Mar
(92) |
Apr
(37) |
May
(57) |
Jun
(142) |
Jul
(65) |
Aug
(43) |
Sep
(33) |
Oct
(81) |
Nov
(130) |
Dec
(63) |
2013 |
Jan
(63) |
Feb
(32) |
Mar
(80) |
Apr
(48) |
May
(44) |
Jun
(79) |
Jul
(86) |
Aug
(91) |
Sep
(43) |
Oct
(95) |
Nov
(130) |
Dec
(117) |
2014 |
Jan
(283) |
Feb
(206) |
Mar
(90) |
Apr
(57) |
May
(105) |
Jun
(66) |
Jul
(87) |
Aug
(30) |
Sep
(54) |
Oct
(125) |
Nov
(45) |
Dec
(36) |
2015 |
Jan
(58) |
Feb
(51) |
Mar
(59) |
Apr
(75) |
May
(70) |
Jun
(52) |
Jul
(58) |
Aug
(72) |
Sep
(184) |
Oct
(157) |
Nov
(91) |
Dec
(90) |
2016 |
Jan
(89) |
Feb
(61) |
Mar
(57) |
Apr
(86) |
May
(46) |
Jun
(63) |
Jul
(71) |
Aug
(60) |
Sep
(207) |
Oct
(139) |
Nov
(76) |
Dec
(68) |
2017 |
Jan
(112) |
Feb
(91) |
Mar
(138) |
Apr
(79) |
May
(36) |
Jun
(20) |
Jul
(105) |
Aug
(71) |
Sep
(51) |
Oct
(114) |
Nov
(148) |
Dec
(79) |
2018 |
Jan
(118) |
Feb
(107) |
Mar
(111) |
Apr
(127) |
May
(60) |
Jun
(63) |
Jul
(49) |
Aug
(18) |
Sep
(134) |
Oct
(68) |
Nov
(91) |
Dec
(27) |
2019 |
Jan
(41) |
Feb
(63) |
Mar
(37) |
Apr
(42) |
May
(44) |
Jun
(81) |
Jul
(53) |
Aug
(21) |
Sep
(62) |
Oct
(55) |
Nov
(41) |
Dec
(57) |
2020 |
Jan
(14) |
Feb
(29) |
Mar
(33) |
Apr
(20) |
May
(19) |
Jun
(9) |
Jul
(5) |
Aug
(23) |
Sep
(30) |
Oct
(29) |
Nov
(58) |
Dec
(139) |
2021 |
Jan
(62) |
Feb
(117) |
Mar
(13) |
Apr
(17) |
May
(23) |
Jun
(28) |
Jul
(7) |
Aug
(29) |
Sep
(56) |
Oct
(21) |
Nov
(36) |
Dec
(14) |
2022 |
Jan
(10) |
Feb
(28) |
Mar
(18) |
Apr
(19) |
May
(18) |
Jun
(3) |
Jul
(14) |
Aug
(11) |
Sep
(12) |
Oct
(4) |
Nov
|
Dec
(5) |
2023 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
(2) |
Jun
(8) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2024 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
(51) |
Aug
(31) |
Sep
(10) |
Oct
(14) |
Nov
(12) |
Dec
(14) |
2025 |
Jan
(17) |
Feb
(5) |
Mar
(30) |
Apr
(2) |
May
(4) |
Jun
(9) |
Jul
(5) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Steve L. <sle...@ya...> - 2021-02-02 16:06:00
|
> On Feb 1, 2021, at 9:33 PM, Matt Broughton <wal...@ma...> wrote: > > > >> On Feb 1, 2021, at 11:53 AM, Steve Letter <sle...@ya...> wrote: >> >> On Monday, February 1, 2021, 12:05:13 PM EST, Matt Broughton <wal...@ma...> wrote: >> >> >> >> >> > On Feb 1, 2021, at 10:57 AM, Steve Letter <sle...@ya...> wrote: >> > >> > >> >> On Feb 1, 2021, at 11:01 AM, Matt Broughton <wal...@ma...> wrote: >> >> >> >> Success!! With macos 10.14.6 Mojave. Install log looks clean, queue PPDs are updated, and it prints. I checked a couple of binaries for the architectures included. Both x86-64 and arm64 are listed. The output of the `file` command looks a bit more wordier than before, but I'm not going to quibble. >> >> >> >> file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon >> >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] >> >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture x86_64): Mach-O 64-bit executable x86_64 >> >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture arm64): Mach-O 64-bit executable arm64 >> >> >> >> I have my new test machine almost set up, so now I can test Lion 10.7 thru High Sierra 10.13 plus Mojave on my current MacBook Pro. I will check with at least Lion 10.7. >> >> >> >> Matt >> >> >> > >> > I tested on 10.9 Mavericks, 10.14 Mojave, 10.15 Catalina and 11.1 BigSur (on Silicon, M1) on an unsupported printer that prints, although not quite correctly. >> >> I do want to test it on 10.7 Lion to make sure there are no install errors. It may not be able to handle the arm64 portion. I know that at least once they just stripped off the part the OS didn’t understand. >> >> Matt >> >> Sent from my iPad >> >> >> Of course! I was just adding additional information. The more testing the better! > > Installs fine on Lion 10.7.5. Both x86_64 and arm64 get installed. Prints fine to my Epson WorkForce 1100. > > Matt > So now I need to get more familiar with autotools to make some changes in configuring, a few changes in my build script, get the changes into git and I will be ready to do an official build. I haven’t gotten any other feedback from the other 30 something downloads, I guess that’s good news. If we want to do an official build before I finish the above, I can easily reproduce the hacked build. And by the way, there are bugs in the M1 tool chain so I am currently building on x86 (10.15) with the latest Xcode command line tools. |
From: Matt B. <wal...@ma...> - 2021-02-02 02:34:10
|
> On Feb 1, 2021, at 11:53 AM, Steve Letter <sle...@ya...> wrote: > > On Monday, February 1, 2021, 12:05:13 PM EST, Matt Broughton <wal...@ma... <mailto:wal...@ma...>> wrote: > > > > > > On Feb 1, 2021, at 10:57 AM, Steve Letter <sle...@ya... <mailto:sle...@ya...>> wrote: > > > > > >> On Feb 1, 2021, at 11:01 AM, Matt Broughton <wal...@ma... <mailto:wal...@ma...>> wrote: > >> > >> Success!! With macos 10.14.6 Mojave. Install log looks clean, queue PPDs are updated, and it prints. I checked a couple of binaries for the architectures included. Both x86-64 and arm64 are listed. The output of the `file` command looks a bit more wordier than before, but I'm not going to quibble. > >> > >> file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon > >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] > >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture x86_64): Mach-O 64-bit executable x86_64 > >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture arm64): Mach-O 64-bit executable arm64 > >> > >> I have my new test machine almost set up, so now I can test Lion 10.7 thru High Sierra 10.13 plus Mojave on my current MacBook Pro. I will check with at least Lion 10.7. > >> > >> Matt > >> > > > > I tested on 10.9 Mavericks, 10.14 Mojave, 10.15 Catalina and 11.1 BigSur (on Silicon, M1) on an unsupported printer that prints, although not quite correctly. > > I do want to test it on 10.7 Lion to make sure there are no install errors. It may not be able to handle the arm64 portion. I know that at least once they just stripped off the part the OS didn’t understand. > > Matt > > Sent from my iPad > > > Of course! I was just adding additional information. The more testing the better! Installs fine on Lion 10.7.5. Both x86_64 and arm64 get installed. Prints fine to my Epson WorkForce 1100. Matt |
From: Steve L. <sle...@ya...> - 2021-02-01 17:53:59
|
On Monday, February 1, 2021, 12:05:13 PM EST, Matt Broughton <wal...@ma...> wrote: > On Feb 1, 2021, at 10:57 AM, Steve Letter <sle...@ya...> wrote: > > >> On Feb 1, 2021, at 11:01 AM, Matt Broughton <wal...@ma...> wrote: >> >> Success!! With macos 10.14.6 Mojave. Install log looks clean, queue PPDs are updated, and it prints. I checked a couple of binaries for the architectures included. Both x86-64 and arm64 are listed. The output of the `file` command looks a bit more wordier than before, but I'm not going to quibble. >> >> file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture x86_64): Mach-O 64-bit executable x86_64 >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture arm64): Mach-O 64-bit executable arm64 >> >> I have my new test machine almost set up, so now I can test Lion 10.7 thru High Sierra 10.13 plus Mojave on my current MacBook Pro. I will check with at least Lion 10.7. >> >> Matt >> > > I tested on 10.9 Mavericks, 10.14 Mojave, 10.15 Catalina and 11.1 BigSur (on Silicon, M1) on an unsupported printer that prints, although not quite correctly. I do want to test it on 10.7 Lion to make sure there are no install errors. It may not be able to handle the arm64 portion. I know that at least once they just stripped off the part the OS didn’t understand. Matt Sent from my iPad Of course! I was just adding additional information. The more testing the better! |
From: Matt B. <wal...@ma...> - 2021-02-01 17:05:24
|
> On Feb 1, 2021, at 10:57 AM, Steve Letter <sle...@ya...> wrote: > > >> On Feb 1, 2021, at 11:01 AM, Matt Broughton <wal...@ma...> wrote: >> >> Success!! With macos 10.14.6 Mojave. Install log looks clean, queue PPDs are updated, and it prints. I checked a couple of binaries for the architectures included. Both x86-64 and arm64 are listed. The output of the `file` command looks a bit more wordier than before, but I'm not going to quibble. >> >> file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture x86_64): Mach-O 64-bit executable x86_64 >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture arm64): Mach-O 64-bit executable arm64 >> >> I have my new test machine almost set up, so now I can test Lion 10.7 thru High Sierra 10.13 plus Mojave on my current MacBook Pro. I will check with at least Lion 10.7. >> >> Matt >> > > I tested on 10.9 Mavericks, 10.14 Mojave, 10.15 Catalina and 11.1 BigSur (on Silicon, M1) on an unsupported printer that prints, although not quite correctly. I do want to test it on 10.7 Lion to make sure there are no install errors. It may not be able to handle the arm64 portion. I know that at least once they just stripped off the part the OS didn’t understand. Matt Sent from my iPad |
From: Steve L. <sle...@ya...> - 2021-02-01 16:58:09
|
> On Feb 1, 2021, at 11:01 AM, Matt Broughton <wal...@ma...> wrote: > > Success!! With macos 10.14.6 Mojave. Install log looks clean, queue PPDs are updated, and it prints. I checked a couple of binaries for the architectures included. Both x86-64 and arm64 are listed. The output of the `file` command looks a bit more wordier than before, but I'm not going to quibble. > > file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon > /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] > /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture x86_64): Mach-O 64-bit executable x86_64 > /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture arm64): Mach-O 64-bit executable arm64 > > I have my new test machine almost set up, so now I can test Lion 10.7 thru High Sierra 10.13 plus Mojave on my current MacBook Pro. I will check with at least Lion 10.7. > > Matt > I tested on 10.9 Mavericks, 10.14 Mojave, 10.15 Catalina and 11.1 BigSur (on Silicon, M1) on an unsupported printer that prints, although not quite correctly. |
From: Matt B. <wal...@ma...> - 2021-02-01 16:56:49
|
> On Jan 29, 2021, at 6:16 PM, ma...@so... wrote: > > Hello, > > i need your know how -i have two old printer tektronix phaser 750 and > xerox dc12 via splash 620 - do you have a tool, where i can create a > printer driver or a driver? .. > > ..costs? ..my mac system ist 10.13.6 high seria > > THANKS > > regards > > Mit freundlichen Grüßen aus dem schönen Mühltal! > > Sylvia Gohlke > > Solutions! > > Kirchstraße 1 - D-64367 Mühltal > Telefon +49 (0) 61 51 - 50 11 - 916 > Telefax +49 (0) 61 51 - 50 11 - 918 > > www.solutions-darmstadt.de > > Einzelkauffrau > Finanzamt Darmstadt I am one of the Mac people here. I’m afraid that I am not familiar with fiery servers. Perhaps someone else is. The best recommendation I have is to try the printing section on the Apple Discussion boards. They have some very knowledgeable volunteers there that might be able to help you. Matt Sent from my iPad |
From: Matt B. <wal...@ma...> - 2021-02-01 16:01:30
|
> On Feb 1, 2021, at 7:11 AM, Steve Letter via Gimp-print-devel <gim...@li...> wrote: > > >>> Michael, >>> >>> I tried so many things I was certain I had tried that. So certain I started to write an email about how that didn’t work. But then I thought I’d better make damn sure I had tried it so I did. >>> >>> And man do I feel stupid. Of course that was the answer. I have uploaded the new disk image (built from the same files as pre1) to >>> >>> https://sourceforge.net/projects/gimp-print/files/snapshots/gutenprint-5.3.4-pre2.dmg/download >>> >>> I am still hacking, I haven’t produced a scripted build yet but I will once we are satisfied it is building correctly. >>> >>> Steve Letter >>> Sent from my Symbolics Lisp Machine using zmail. >>> >>>> On Jan 31, 2021, at 5:02 PM, Michael Sweet <ms...@ms...> wrote: >>>> >>>> Steve, >>>> >>>> You might need to list -lcupsimage before -lcups, in case the linker is using the definition from libcups first... >>>> >>>> >>>>> On Jan 31, 2021, at 2:51 PM, Steve Letter via Gimp-print-devel <gim...@li... <mailto:gim...@li...>> wrote: >>>>> >>>>> As suggested by Michael I linked libcupsimage.dylib but still got the message in the log file, >>>>> dyld: Symbol not found: _cupsRasterOpen >>>>> Referenced from: /usr/libexec/cups/filter/rastertogutenprint.5.3 >>>>> Expected in: /usr/lib/libcups.2.dylib >>>>> >>>>> I verified that libcupsimage was linked in (with otool -L) >>>>> >>>>> otool -L /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/rastertogutenprint.5.3 >>>>> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/rastertogutenprint.5.3: >>>>> /usr/lib/libcups.2.dylib (compatibility version 2.0.0, current version 2..14.0) >>>>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1) >>>>> /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7..0.0) >>>>> /usr/lib/libcupsimage.2.dylib (compatibility version 2.0.0, current version 2.3.0) >>>>> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1770.255.0) >>>>> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) >>>>> >>>>> and that _cupsRasterOpen was indeed in libcupsimage >>>>> Stephens-MacBook-Pro:cups sletter$ nm /usr/lib/libcupsimage.2.dylib | grep _cupsRasterOpen >>>>> 00000000000035b8 T _cupsRasterOpen >>>>> 00000000000035e3 T _cupsRasterOpenIO >>>>> >>>>> Obviously there is something in my build that must be making the filter believe that _cupsRasterOpen is in libcups. I thought I’d ask here for help before I go to the Apple developers group to ask what I have wrong. >>>>> >>>>> Steve Letter Success!! With macos 10.14.6 Mojave. Install log looks clean, queue PPDs are updated, and it prints. I checked a couple of binaries for the architectures included. Both x86-64 and arm64 are listed. The output of the `file` command looks a bit more wordier than before, but I'm not going to quibble. file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture x86_64): Mach-O 64-bit executable x86_64 /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtocanon (for architecture arm64): Mach-O 64-bit executable arm64 I have my new test machine almost set up, so now I can test Lion 10.7 thru High Sierra 10.13 plus Mojave on my current MacBook Pro. I will check with at least Lion 10.7. Matt |
From: Steve L. <sle...@ya...> - 2021-02-01 13:11:53
|
>> Michael, >> >> I tried so many things I was certain I had tried that. So certain I started to write an email about how that didn’t work. But then I thought I’d better make damn sure I had tried it so I did. >> >> And man do I feel stupid. Of course that was the answer. I have uploaded the new disk image (built from the same files as pre1) to >> >> https://sourceforge.net/projects/gimp-print/files/snapshots/gutenprint-5.3.4-pre2.dmg/download >> >> I am still hacking, I haven’t produced a scripted build yet but I will once we are satisfied it is building correctly. >> >> Steve Letter >> Sent from my Symbolics Lisp Machine using zmail. >> >>>> On Jan 31, 2021, at 5:02 PM, Michael Sweet <ms...@ms...> wrote: >>>> >>> Steve, >>> >>> You might need to list -lcupsimage before -lcups, in case the linker is using the definition from libcups first... >>> >>> >>>> On Jan 31, 2021, at 2:51 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote: >>>> >>>> As suggested by Michael I linked libcupsimage.dylib but still got the message in the log file, >>>> dyld: Symbol not found: _cupsRasterOpen >>>> Referenced from: /usr/libexec/cups/filter/rastertogutenprint.5.3 >>>> Expected in: /usr/lib/libcups.2.dylib >>>> >>>> I verified that libcupsimage was linked in (with otool -L) >>>> >>>> otool -L /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/rastertogutenprint.5.3 >>>> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/rastertogutenprint.5.3: >>>> /usr/lib/libcups.2.dylib (compatibility version 2.0.0, current version 2..14.0) >>>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1) >>>> /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7..0.0) >>>> /usr/lib/libcupsimage.2.dylib (compatibility version 2.0.0, current version 2.3.0) >>>> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1770.255.0) >>>> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) >>>> >>>> and that _cupsRasterOpen was indeed in libcupsimage >>>> Stephens-MacBook-Pro:cups sletter$ nm /usr/lib/libcupsimage.2.dylib | grep _cupsRasterOpen >>>> 00000000000035b8 T _cupsRasterOpen >>>> 00000000000035e3 T _cupsRasterOpenIO >>>> >>>> Obviously there is something in my build that must be making the filter believe that _cupsRasterOpen is in libcups. I thought I’d ask here for help before I go to the Apple developers group to ask what I have wrong. >>>> >>>> Steve Letter >>>> >>>> _______________________________________________ >>>> Gimp-print-devel mailing list >>>> Gim...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel >>> >>> ________________________ >>> Michael Sweet >>> >>> >>> |
From: Michael S. <ms...@ms...> - 2021-01-31 22:03:06
|
Steve, You might need to list -lcupsimage before -lcups, in case the linker is using the definition from libcups first... > On Jan 31, 2021, at 2:51 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote: > > As suggested by Michael I linked libcupsimage.dylib but still got the message in the log file, > dyld: Symbol not found: _cupsRasterOpen > Referenced from: /usr/libexec/cups/filter/rastertogutenprint.5.3 > Expected in: /usr/lib/libcups.2.dylib > > I verified that libcupsimage was linked in (with otool -L) > > otool -L /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/rastertogutenprint.5.3 > /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/rastertogutenprint.5.3: > /usr/lib/libcups.2.dylib (compatibility version 2.0.0, current version 2.14.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1) > /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) > /usr/lib/libcupsimage.2.dylib (compatibility version 2.0.0, current version 2.3.0) > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1770.255.0) > /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) > > and that _cupsRasterOpen was indeed in libcupsimage > Stephens-MacBook-Pro:cups sletter$ nm /usr/lib/libcupsimage.2.dylib | grep _cupsRasterOpen > 00000000000035b8 T _cupsRasterOpen > 00000000000035e3 T _cupsRasterOpenIO > > Obviously there is something in my build that must be making the filter believe that _cupsRasterOpen is in libcups. I thought I’d ask here for help before I go to the Apple developers group to ask what I have wrong. > > Steve Letter > > _______________________________________________ > Gimp-print-devel mailing list > Gim...@li... > https://lists.sourceforge.net/lists/listinfo/gimp-print-devel ________________________ Michael Sweet |
From: Steve L. <sle...@ya...> - 2021-01-31 19:52:23
|
As suggested by Michael I linked libcupsimage.dylib but still got the message in the log file, dyld: Symbol not found: _cupsRasterOpen Referenced from: /usr/libexec/cups/filter/rastertogutenprint.5.3 Expected in: /usr/lib/libcups.2.dylib I verified that libcupsimage was linked in (with otool -L) otool -L /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/rastertogutenprint.5.3 /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/rastertogutenprint.5.3: /usr/lib/libcups.2.dylib (compatibility version 2.0.0, current version 2.14.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libcupsimage.2.dylib (compatibility version 2.0.0, current version 2.3.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1770.255.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) and that _cupsRasterOpen was indeed in libcupsimage Stephens-MacBook-Pro:cups sletter$ nm /usr/lib/libcupsimage.2.dylib | grep _cupsRasterOpen 00000000000035b8 T _cupsRasterOpen 00000000000035e3 T _cupsRasterOpenIO Obviously there is something in my build that must be making the filter believe that _cupsRasterOpen is in libcups. I thought I’d ask here for help before I go to the Apple developers group to ask what I have wrong. Steve Letter |
From: Matt B. <wal...@ma...> - 2021-01-30 16:24:30
|
> On Jan 28, 2021, at 6:33 PM, Teresa Tsang <ter...@ho...> wrote: > > hello developers > > i am having problem trying to install my really old HP laser jet 6L printer to my macbook air that runs on MacOS Sierra 10.12.6. It’s not detecting my printer at all, could you please help me > > Kind Regards > > Teresa How do you have your printer connected to your MacBook Air? The LaserJet 6L has only a parallel port and the MacBook Air only has a Thunderbolt/USB4 input. That's quite a difference in port connectors. Have you ever had your printer connected to a Mac computer before and had it working? Matt |
From: Anne-Marie <ann...@gm...> - 2021-01-30 11:43:08
|
Hello, Thanks for your great work! I’ve an old Selphy CP800 that I would like to use with my Mac book pro but it will not print. It adds the printer alright with your driver but then it hangs there. I’ve read this is was a common problem years ago but was ressolved then. Do you know how to ressolve this? Thank you, Anne-Marie van Dongen {-----------------------------} A.M. van Dongen 20, rue Juliette Dodu 75010 Paris France + 33 7 81 80 65 73 |
From: <ma...@so...> - 2021-01-29 12:57:25
|
Hello, i need your know how -i have two old printer tektronix phaser 750 and xerox dc12 via splash 620 - do you have a tool, where i can create a printer driver or a driver? .. ..costs? ..my mac system ist 10.13.6 high seria THANKS regards Mit freundlichen Grüßen aus dem schönen Mühltal! Sylvia Gohlke Solutions! Kirchstraße 1 - D-64367 Mühltal Telefon +49 (0) 61 51 - 50 11 - 916 Telefax +49 (0) 61 51 - 50 11 - 918 www.solutions-darmstadt.de Einzelkauffrau Finanzamt Darmstadt - 007 822 00013 |
From: Teresa T. <ter...@ho...> - 2021-01-29 00:34:13
|
hello developers i am having problem trying to install my really old HP laser jet 6L printer to my macbook air that runs on MacOS Sierra 10.12.6. It’s not detecting my printer at all, could you please help me Kind Regards Teresa |
From: Robert K. <rl...@al...> - 2021-01-27 18:05:27
|
On 1/27/21 11:55 AM, Burkhalter, Carmen Lisa wrote: > Your software worked on Canon MP970 beautifully. Thank you!!!! Excellent, glad we could be of assistance! |
From: Burkhalter, C. L. <cbu...@un...> - 2021-01-27 17:29:41
|
Your software worked on Canon MP970 beautifully. Thank you!!!! Carmen |
From: Steve L. <sle...@ya...> - 2021-01-25 03:41:07
|
Yeah, I got them confused. I used to do AI back in the 80’s and used emacs for quite a long time on UNIX. I learned LISP before I learned C, and FORTRAN before LISP. I was programming in C when cfront made an appearance. I switched to vi when I was managing UNIX systems as emacs wasn’t always available. I switched to C++ for a time but went back to C when I got into embedded. I started on Macintosh ( power systems) when Apple stock was 15 cents a share. I started developing on Linux in the later 90’s, converting a large suite of software from IRIX to Linux. I also did a small amount of DOS based PC programming and later reverse engineering Windows. I started embedded in 2003, finally using my electrical background with my development skills. Steve Letter > On Jan 24, 2021, at 3:32 PM, Robert Krawitz <rl...@al...> wrote: > > On 1/24/21 12:01 PM, Steve Letter wrote: >> Steve Letter >> Sent from my Symbolics Lisp Machine using rmail. > > Uh...Lisp Machines (both Symbolics and LMI/CADR) had Zmail IIRC. Rmail was later written (and I had > a hand in it for a while in the mid 1980's) for GNU Emacs. Rmail (which I used until quite > recently) is more based on Babyl (at least interface-wise) than Zmail. |
From: Robert K. <rl...@al...> - 2021-01-24 20:33:07
|
On 1/24/21 12:01 PM, Steve Letter wrote: > Steve Letter > Sent from my Symbolics Lisp Machine using rmail. Uh...Lisp Machines (both Symbolics and LMI/CADR) had Zmail IIRC. Rmail was later written (and I had a hand in it for a while in the mid 1980's) for GNU Emacs. Rmail (which I used until quite recently) is more based on Babyl (at least interface-wise) than Zmail. |
From: Steve L. <sle...@ya...> - 2021-01-24 17:02:25
|
Michael, Thanks. I will make that change as soon as I return home today. Steve Letter Sent from my Symbolics Lisp Machine using rmail. > On Jan 24, 2021, at 11:40 AM, Michael Sweet <ms...@ms...> wrote: > > Robert, > >> On Jan 24, 2021, at 11:14 AM, Robert Krawitz <rl...@al...> wrote: >> >>> On 1/24/21 10:47 AM, Matt Broughton wrote: >>> >>> >>>> On Jan 18, 2021, at 9:02 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote: >>>> >>>> Successfully built a Universal package on my M1 Mac. I had to package it on my x86 system due to bugs on the M1. It packaged well and signed fine. >>>> >>>> However, it failed to run properly on my Intel Mac running 10.14, Mojave but did on the M1 (natively). I am installing 10.15 and will try building on it to see if I can properly build a universal package on it. >>>> >>>> Steve Letter >>>> Sent from my Symbolics Lisp Machine using rmail. >>> >>> I also failed to print from 10.14 Mojave. The files have the correct architecture: >>> >>> Borodin:~ matt$ file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtoepson >>> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtoepson: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] >>> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtoepson (for architecture x86_64): Mach-O 64-bit executable x86_64 >>> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtoepson (for architecture arm64): Mach-O 64-bit executable arm64 >>> Borodin:~ matt$ >>> >>> I am attaching a portion of the CUPS error log from where Gutenprint sets its parameters through the crash of the print job. The most important part seems to be: >> >> That looks to be the important point here; it looks like there has been a change to libcups. You >> probably want to look in /usr/lib and see if there are any other libcups* files around, and if one >> of them contains that symbol. > > > In macOS 10.15 (CUPS 2.3) the cupsRaster functions are provided in both libcups and libcupsimage. The reason for this is that libcupsimage has basically only had the cupsRaster functions since CUPS 1.4, and going forward things are supposed to be consolidated in a single application library... > > When you build on a newer macOS you need to include -lcupsimage to ensure that the right linkage is in place for older versions of macOS. It would be nice if cups-config still include -lcupsimage on macOS (and I'll see if I can get Apple to make that change), but for now Gutenprint will need to include -lcupsimage on macOS all on its own. > > ________________________ > Michael Sweet > > > > _______________________________________________ > Gimp-print-devel mailing list > Gim...@li... > https://lists.sourceforge.net/lists/listinfo/gimp-print-devel |
From: Michael S. <ms...@ms...> - 2021-01-24 16:40:25
|
Robert, > On Jan 24, 2021, at 11:14 AM, Robert Krawitz <rl...@al...> wrote: > > On 1/24/21 10:47 AM, Matt Broughton wrote: >> >> >>> On Jan 18, 2021, at 9:02 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote: >>> >>> Successfully built a Universal package on my M1 Mac. I had to package it on my x86 system due to bugs on the M1. It packaged well and signed fine. >>> >>> However, it failed to run properly on my Intel Mac running 10.14, Mojave but did on the M1 (natively). I am installing 10.15 and will try building on it to see if I can properly build a universal package on it. >>> >>> Steve Letter >>> Sent from my Symbolics Lisp Machine using rmail. >> >> I also failed to print from 10.14 Mojave. The files have the correct architecture: >> >> Borodin:~ matt$ file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtoepson >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtoepson: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtoepson (for architecture x86_64): Mach-O 64-bit executable x86_64 >> /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtoepson (for architecture arm64): Mach-O 64-bit executable arm64 >> Borodin:~ matt$ >> >> I am attaching a portion of the CUPS error log from where Gutenprint sets its parameters through the crash of the print job. The most important part seems to be: > > That looks to be the important point here; it looks like there has been a change to libcups. You > probably want to look in /usr/lib and see if there are any other libcups* files around, and if one > of them contains that symbol. In macOS 10.15 (CUPS 2.3) the cupsRaster functions are provided in both libcups and libcupsimage. The reason for this is that libcupsimage has basically only had the cupsRaster functions since CUPS 1.4, and going forward things are supposed to be consolidated in a single application library... When you build on a newer macOS you need to include -lcupsimage to ensure that the right linkage is in place for older versions of macOS. It would be nice if cups-config still include -lcupsimage on macOS (and I'll see if I can get Apple to make that change), but for now Gutenprint will need to include -lcupsimage on macOS all on its own. ________________________ Michael Sweet |
From: Robert K. <rl...@al...> - 2021-01-24 16:14:43
|
On 1/24/21 10:47 AM, Matt Broughton wrote: > > >> On Jan 18, 2021, at 9:02 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote: >> >> Successfully built a Universal package on my M1 Mac. I had to package it on my x86 system due to bugs on the M1. It packaged well and signed fine. >> >> However, it failed to run properly on my Intel Mac running 10.14, Mojave but did on the M1 (natively). I am installing 10.15 and will try building on it to see if I can properly build a universal package on it. >> >> Steve Letter >> Sent from my Symbolics Lisp Machine using rmail. > > I also failed to print from 10.14 Mojave. The files have the correct architecture: > > Borodin:~ matt$ file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtoepson > /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtoepson: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] > /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtoepson (for architecture x86_64): Mach-O 64-bit executable x86_64 > /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtoepson (for architecture arm64): Mach-O 64-bit executable arm64 > Borodin:~ matt$ > > I am attaching a portion of the CUPS error log from where Gutenprint sets its parameters through the crash of the print job. The most important part seems to be: That looks to be the important point here; it looks like there has been a change to libcups. You probably want to look in /usr/lib and see if there are any other libcups* files around, and if one of them contains that symbol. > D [24/Jan/2021:09:08:12 -0600] [Job 1457] Gutenprint: End options > D [24/Jan/2021:09:08:12 -0600] [Job 1457] dyld: lazy symbol binding failed: Symbol not found: _cupsRasterOpen > D [24/Jan/2021:09:08:12 -0600] [Job 1457] Referenced from: /usr/libexec/cups/filter/rastertogutenprint.5.3 > D [24/Jan/2021:09:08:12 -0600] [Job 1457] Expected in: /usr/lib/libcups.2.dylib > D [24/Jan/2021:09:08:12 -0600] [Job 1457] dyld: Symbol not found: _cupsRasterOpen > D [24/Jan/2021:09:08:12 -0600] [Job 1457] Referenced from: /usr/libexec/cups/filter/rastertogutenprint.5.3 > D [24/Jan/2021:09:08:12 -0600] [Job 1457] Expected in: /usr/lib/libcups.2.dylib > D [24/Jan/2021:09:08:12 -0600] [Job 1457] PID 2290 (/usr/libexec/cups/filter/rastertogutenprint.5.3) crashed on signal 6. > D [24/Jan/2021:09:08:12 -0600] [Job 1457] Sent 0 bytes... > D [24/Jan/2021:09:08:12 -0600] [Job 1457] STATE: +cups-waiting-for-job-completed > D [24/Jan/2021:09:08:12 -0600] cupsdMarkDirty(P----) |
From: Matt B. <wal...@ma...> - 2021-01-24 15:47:25
|
> On Jan 18, 2021, at 9:02 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote: > > Successfully built a Universal package on my M1 Mac. I had to package it on my x86 system due to bugs on the M1. It packaged well and signed fine. > > However, it failed to run properly on my Intel Mac running 10.14, Mojave but did on the M1 (natively). I am installing 10.15 and will try building on it to see if I can properly build a universal package on it. > > Steve Letter > Sent from my Symbolics Lisp Machine using rmail. I also failed to print from 10.14 Mojave. The files have the correct architecture: Borodin:~ matt$ file /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtoepson /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtoepson: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtoepson (for architecture x86_64): Mach-O 64-bit executable x86_64 /Library/Printers/Gutenprint.printerDriver/Contents/MacOS/commandtoepson (for architecture arm64): Mach-O 64-bit executable arm64 Borodin:~ matt$ I am attaching a portion of the CUPS error log from where Gutenprint sets its parameters through the crash of the print job. The most important part seems to be: D [24/Jan/2021:09:08:12 -0600] [Job 1457] Gutenprint: End options D [24/Jan/2021:09:08:12 -0600] [Job 1457] dyld: lazy symbol binding failed: Symbol not found: _cupsRasterOpen D [24/Jan/2021:09:08:12 -0600] [Job 1457] Referenced from: /usr/libexec/cups/filter/rastertogutenprint.5.3 D [24/Jan/2021:09:08:12 -0600] [Job 1457] Expected in: /usr/lib/libcups.2.dylib D [24/Jan/2021:09:08:12 -0600] [Job 1457] dyld: Symbol not found: _cupsRasterOpen D [24/Jan/2021:09:08:12 -0600] [Job 1457] Referenced from: /usr/libexec/cups/filter/rastertogutenprint.5.3 D [24/Jan/2021:09:08:12 -0600] [Job 1457] Expected in: /usr/lib/libcups.2.dylib D [24/Jan/2021:09:08:12 -0600] [Job 1457] PID 2290 (/usr/libexec/cups/filter/rastertogutenprint.5.3) crashed on signal 6. D [24/Jan/2021:09:08:12 -0600] [Job 1457] Sent 0 bytes... D [24/Jan/2021:09:08:12 -0600] [Job 1457] STATE: +cups-waiting-for-job-completed D [24/Jan/2021:09:08:12 -0600] cupsdMarkDirty(P----) Matt |
From: Matt B. <wal...@ma...> - 2021-01-23 02:17:42
|
> On Jan 22, 2021, at 3:02 PM, Matt Broughton <wal...@ma...> wrote: > > On Jan 22, 2021, at 1:39 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote: >> >> I uploaded a build, universal for both Intel Macs and M1 Macs to Snapshots. I specifically need people to test Solomon’s drivers for libusb. I need information on installing also. >> >> I have NOT fixed the Snow Leopard 10.6 problem, believe I have fixed the 10.15 (Catalina) install problem. I also think I understand the 10.6 install problem. Mat and I have discussed it and I researched a bit. Seems the default Hash algorithm changed from SHA1 to SHA256. When signing I can pick the algorithm to use. I prefer to write off Snow Leopard and continue to build with the current algorithm but wish feedback from the community. >> >> Steve Letter, chief cook and bottle was he. > > Yes, it does seem to be some sort of problem with the hash. I am slowly building my test facilities on my mac mini. I was able to install OS X `10.7.0. That wouldn't let me install Gutenprint 5.3.3. It said right off that the "digital certificate is not valid" The only option was to Close. Closing also quit the installer. To make matters more confusing, I couldn't install the 7.1 update or any of the combo updates due to certificates not being valid. Somehow it was showing that Apple's certificate was good only through 2009. OS X 7 was released in 2011. > > I am in the process of making a new bootable installer for whatever the last version of OS X 10.7. I did note that there was a supplement update right at the end having to do with correcting an issue with install certificates. All that said, the original install of OS X 10.7.0 was from the build DVD issued by the Apple Seed Program. > > Mac OS X 10.8.x was fine. > > More as I get a good working install of the last version of 10.7.x > > Matt Follow up for Mac OS X 7.5.5. Gutenprint install and runs nicely for my Epson WorkForce 1100. The issues I had before with not being able to upgrade or install Gutenprint may have to do with the date I received the Lion install DVD and the date and time I downloaded the updater. I read about such problems with installers on the older Mac systems. Matt |
From: Matt B. <wal...@ma...> - 2021-01-22 21:02:24
|
On Jan 22, 2021, at 1:39 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote: > > I uploaded a build, universal for both Intel Macs and M1 Macs to Snapshots. I specifically need people to test Solomon’s drivers for libusb. I need information on installing also. > > I have NOT fixed the Snow Leopard 10.6 problem, believe I have fixed the 10.15 (Catalina) install problem. I also think I understand the 10.6 install problem. Mat and I have discussed it and I researched a bit. Seems the default Hash algorithm changed from SHA1 to SHA256. When signing I can pick the algorithm to use. I prefer to write off Snow Leopard and continue to build with the current algorithm but wish feedback from the community. > > Steve Letter, chief cook and bottle was he. Yes, it does seem to be some sort of problem with the hash. I am slowly building my test facilities on my mac mini. I was able to install OS X `10.7.0. That wouldn't let me install Gutenprint 5.3.3. It said right off that the "digital certificate is not valid" The only option was to Close. Closing also quit the installer. To make matters more confusing, I couldn't install the 7.1 update or any of the combo updates due to certificates not being valid. Somehow it was showing that Apple's certificate was good only through 2009. OS X 7 was released in 2011. I am in the process of making a new bootable installer for whatever the last version of OS X 10.7. I did note that there was a supplement update right at the end having to do with correcting an issue with install certificates. All that said, the original install of OS X 10.7.0 was from the build DVD issued by the Apple Seed Program. Mac OS X 10.8.x was fine. More as I get a good working install of the last version of 10.7.x Matt |
From: Steve L. <sle...@ya...> - 2021-01-22 19:43:48
|
Download the universal disk image at: https://sourceforge.net/projects/gimp-print/files/snapshots/gutenprint-5.3.4-pre1.dmg/download Steve Letter |