Menu
▾
▴
gimp-print-devel
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
(4) |
Sep
(4) |
Oct
(8) |
Nov
(1) |
Dec
|
|
From: Matt <wal...@ma...> - 2022-08-17 00:59:05
|
<html><head></head><body dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 10, 2022, at 3:53 PM, Bradley Parks <<a href="mailto:bra...@co..." class="">bra...@co...</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="elementToProof" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">Gutenprint,</div><div class="elementToProof" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;"><br class=""></div><div class="elementToProof" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">Do you have a driver for Mac OS 12.3 for the HP Officejet 150 Mobile All-in-one Printer?</div><div class="elementToProof" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">If not, might you have one in future?</div><div class="elementToProof" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">If not, could you recommend a source?</div><div class="elementToProof" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;"><br class=""></div><div class="elementToProof" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">This is kind of important so thank you in advance for your reply.</div><div class="elementToProof" style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">B. Parks</div></div></blockquote><br class=""></div><div>Gutenprint does not support the HP OfficeJet 150. The printer uses a command language, PCL 3 GUI, that Gutenprint does not support. It is not likely to be supported in the future.</div><div>Matt</div><br class=""></div></body></html> |
|
From: Bradley P. <bra...@co...> - 2022-08-10 23:27:45
|
Gutenprint, Do you have a driver for Mac OS 12.3 for the HP Officejet 150 Mobile All-in-one Printer? If not, might you have one in future? If not, could you recommend a source? This is kind of important so thank you in advance for your reply. B. Parks 303-588-0388 |
|
From: Marcos L. <mll...@gm...> - 2022-08-09 21:25:11
|
Good afternoon, Marcos Llumiquinga writes to you. I currently have Gutenprint v5.2.13 installed on my computer. My printer so far is working fine. I would like to know if it is necessary to update to the latest version or if I can stay in the current version that I have. I look forward to your prompt response and collaboration. |
|
From: Elke W. <klo...@we...> - 2022-07-26 08:56:38
|
Guten Tag, ich bin über AVM auf Ihre Arbeit aufmerksam geworden. Ich arbeite mit iMac mit dem M1-Prozessor und wollte meinen vorhandenen Drucker weiter nutzen. Ich hatte ihn auch schon über AirDrop im Netzwerk, aber jetzt nach einer Deränderung in der FritzBox geht es nicht mehr. Das installierte System Mac OS Catalina 12.4 und die anderen Komponenten gehen nicht zusammen. Das macht mich verrückt, ich will nur weiter drucken können. Leider kann ich keinen Treiber extern für den o.g. Drucker finden obwohl Ihre Liste schon endlos lang ist. Haben Sie eine Idee wie es gehen kann ohne einen intakten Drucker zu entsorgen? Ach ja, ich bin 71 Jahre weiblich und mein eigener Admin und manchmal zweifle ich schon an mir. Einen erfolgreichen Tag wünsche ich uns allen und sende Ihnen freundliche Grüße Elke Weißbach |
|
From: Robert K. <rl...@al...> - 2022-07-21 01:09:03
|
On 7/17/22 04:13, Matsumura, George wrote: > On 7/16/22 17:01, Robert Krawitz wrote: >> The model count == 0 patch looks unproblematic, although you removed a blank line unnecessarily. >> Could you regenerate it without that inadvertent change? > > Unless I am mistaken, it seems that a blank line was added rather than > removed. I added this line in order to provide visual clarity, > especially with the if statement right above it, but it can be removed > if that would be desirable. I'd prefer not to make an unnecessary change, although it's harmless. >> The prefix defined patch is a bit more complex; in particular, you've removed a number of cases. >> Those changes don't look a priori wrong, but I'd like to make sure this gets well tested. What >> testing have you done on it? > > Thank you very much for asking. I apologize in that in the process of > testing, I found that the quoting on one of the lines for the first > patch was slightly off, as well as the AC_SUBST statements. I have > attached an updated patch. > > So far, I have tested on Void Linux and NetBSD with various combinations > of configure flags I could think of, especially for the cases dealt with > by the specific code that was removed, although I doubtless have given > insufficient attention to some cases. If you have any ideas on how I > could make these tests more comprehensive, I would be glad to know. > > Thank you for your patience. I'll take a look at it. |
|
From: Matsumura, G. <gm9...@oh...> - 2022-07-17 08:13:37
|
On 7/16/22 17:01, Robert Krawitz wrote:
> The model count == 0 patch looks unproblematic, although you removed a blank line unnecessarily.
> Could you regenerate it without that inadvertent change?
Unless I am mistaken, it seems that a blank line was added rather than
removed. I added this line in order to provide visual clarity,
especially with the if statement right above it, but it can be removed
if that would be desirable.
> The prefix defined patch is a bit more complex; in particular, you've removed a number of cases.
> Those changes don't look a priori wrong, but I'd like to make sure this gets well tested. What
> testing have you done on it?
Thank you very much for asking. I apologize in that in the process of
testing, I found that the quoting on one of the lines for the first
patch was slightly off, as well as the AC_SUBST statements. I have
attached an updated patch.
So far, I have tested on Void Linux and NetBSD with various combinations
of configure flags I could think of, especially for the cases dealt with
by the specific code that was removed, although I doubtless have given
insufficient attention to some cases. If you have any ideas on how I
could make these tests more comprehensive, I would be glad to know.
Thank you for your patience.
Regards,
George |
|
From: Robert K. <rl...@al...> - 2022-07-16 23:17:40
|
On 7/16/22 16:50, Matsumura, George wrote:
> On 7/16/22 12:35, Robert Krawitz wrote:
>> Use caution with links and attachments.
>>
>> On 7/16/22 06:31, Matsumura, George wrote:
>>> Greetings,
>>>
>>> In order to solve the mentioned issues, I was able to create the
>>> attached prefix_defines.patch which moves the expansion of the ${prefix}
>>> and ${exec_prefix} variables to build time through make as opposed to
>>> configure time through autoconf. This is in accordance with the
>>> suggestion here:
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gnu.org%2Fsoftware%2Fautoconf%2Fmanual%2Fautoconf-2.67%2Fhtml_node%2FInstallation-Directory-Variables.html&data=05%7C01%7Cgm960420%40ohio.edu%7Cd5739f5c4e0849c0cc9d08da6759f501%7Cf3308007477c4a70888934611817c55a%7C0%7C0%7C637935933315176710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wGuU%2BC4NHgTFiYTVdXWLI7IrRjhH9eIohyppPYlsB0Y%3D&reserved=0
>>
>> George,
>>
>> Could you regenerate these patches with 'git format-patch' so that the authorship will be properly
>> preserved? Thanks!
>
> Certainly. Thank you for reviewing them.
The model count == 0 patch looks unproblematic, although you removed a blank line unnecessarily.
Could you regenerate it without that inadvertent change?
The prefix defined patch is a bit more complex; in particular, you've removed a number of cases.
Those changes don't look a priori wrong, but I'd like to make sure this gets well tested. What
testing have you done on it?
|
|
From: Matsumura, G. <gm9...@oh...> - 2022-07-16 20:51:23
|
On 7/16/22 12:35, Robert Krawitz wrote:
> Use caution with links and attachments.
>
> On 7/16/22 06:31, Matsumura, George wrote:
>> Greetings,
>>
>> In order to solve the mentioned issues, I was able to create the
>> attached prefix_defines.patch which moves the expansion of the ${prefix}
>> and ${exec_prefix} variables to build time through make as opposed to
>> configure time through autoconf. This is in accordance with the
>> suggestion here:
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gnu.org%2Fsoftware%2Fautoconf%2Fmanual%2Fautoconf-2.67%2Fhtml_node%2FInstallation-Directory-Variables.html&data=05%7C01%7Cgm960420%40ohio.edu%7Cd5739f5c4e0849c0cc9d08da6759f501%7Cf3308007477c4a70888934611817c55a%7C0%7C0%7C637935933315176710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wGuU%2BC4NHgTFiYTVdXWLI7IrRjhH9eIohyppPYlsB0Y%3D&reserved=0
>
> George,
>
> Could you regenerate these patches with 'git format-patch' so that the authorship will be properly
> preserved? Thanks!
Certainly. Thank you for reviewing them.
Regards,
George |
|
From: Robert K. <rl...@al...> - 2022-07-16 18:52:11
|
On 7/16/22 06:31, Matsumura, George wrote:
> Greetings,
>
> In order to solve the mentioned issues, I was able to create the
> attached prefix_defines.patch which moves the expansion of the ${prefix}
> and ${exec_prefix} variables to build time through make as opposed to
> configure time through autoconf. This is in accordance with the
> suggestion here:
> https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Installation-Directory-Variables.html
George,
Could you regenerate these patches with 'git format-patch' so that the authorship will be properly
preserved? Thanks!
|
|
From: Robert K. <rl...@al...> - 2022-07-16 18:46:02
|
On 7/16/22 06:31, Matsumura, George wrote:
> Greetings,
>
> In order to solve the mentioned issues, I was able to create the
> attached prefix_defines.patch which moves the expansion of the ${prefix}
> and ${exec_prefix} variables to build time through make as opposed to
> configure time through autoconf. This is in accordance with the
> suggestion here:
> https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Installation-Directory-Variables.html
>
> Specifically, this guideline was followed:
>
> "In order to support these features, it is essential that
> datarootdir remains defined as ‘${prefix}/share’, so that its value
> can be expanded based on the current value of prefix.
>
> A corollary is that you should not use these variables except in
> makefiles. For instance, instead of trying to evaluate datadir in
> configure and hard-coding it in makefiles using e.g.,
> ‘AC_DEFINE_UNQUOTED([DATADIR], ["$datadir"], [Data directory.])’,
> you should add -DDATADIR='$(datadir)' to your makefile's definition
> of CPPFLAGS (AM_CPPFLAGS if you are also using Automake)."
>
> This approach is somewhat similar to that which existed in gutenprint
> before commit b6043e. I wasn't sure if there was a particular reason why
> this method was undesirable/removed at the time.
>
> As a consequence of my build of gutenprint not being able to find the
> modules, I hit the segfault described here:
> https://sourceforge.net/p/gimp-print/bugs/732/
> The attached no_modules_segfault.patch alters this behaviour so that
> stp_printer_model_count is called instead of stp_list_get_length,
> leading to an informative warning being printed in the case of no
> modules instead of a segmentation fault. This is consistent with usage
> in the rest of the code.
>
> Thank you for reading this, and any consideration of these changes would
> be very much appreciated. I apologize for any mistakes I made in
> creating the patches. If there is anything I can do to improve them,
> please let me know.
Thanks. I'll take a look at things.
|
|
From: Matsumura, G. <gm9...@oh...> - 2022-07-16 10:47:43
|
Greetings,
In order to solve the mentioned issues, I was able to create the
attached prefix_defines.patch which moves the expansion of the ${prefix}
and ${exec_prefix} variables to build time through make as opposed to
configure time through autoconf. This is in accordance with the
suggestion here:
https://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Installation-Directory-Variables.html
Specifically, this guideline was followed:
"In order to support these features, it is essential that
datarootdir remains defined as ‘${prefix}/share’, so that its value
can be expanded based on the current value of prefix.
A corollary is that you should not use these variables except in
makefiles. For instance, instead of trying to evaluate datadir in
configure and hard-coding it in makefiles using e.g.,
‘AC_DEFINE_UNQUOTED([DATADIR], ["$datadir"], [Data directory.])’,
you should add -DDATADIR='$(datadir)' to your makefile's definition
of CPPFLAGS (AM_CPPFLAGS if you are also using Automake)."
This approach is somewhat similar to that which existed in gutenprint
before commit b6043e. I wasn't sure if there was a particular reason why
this method was undesirable/removed at the time.
As a consequence of my build of gutenprint not being able to find the
modules, I hit the segfault described here:
https://sourceforge.net/p/gimp-print/bugs/732/
The attached no_modules_segfault.patch alters this behaviour so that
stp_printer_model_count is called instead of stp_list_get_length,
leading to an informative warning being printed in the case of no
modules instead of a segmentation fault. This is consistent with usage
in the rest of the code.
Thank you for reading this, and any consideration of these changes would
be very much appreciated. I apologize for any mistakes I made in
creating the patches. If there is anything I can do to improve them,
please let me know.
Regards,
George
On 7/1/22 21:30, Matsumura, George wrote:
> Greetings,
>
> My build of Gutenprint, built through Void Linux's standardized build
> process, was unable to find the module directories due to PKGMODULEDIR
> being defined in config.h as:
> #define PKGMODULEDIR "${exec_prefix}/lib64/gutenprint/5.3/modules"
>
> Since the C processor cannot expand exec_prefix, it remains in the path
> at runtime and cannot be resolved.
>
> Attached is the config.summary from the build. In particular, the
> following flag passed to configure seemed to be responsible:
> --libdir=\${exec_prefix}/lib64
>
> There seems to be a specific case in configure.ac for when libdir is
> defined as \${exec_prefix}/lib, but this would not cover my case.
>
> This seems to be similar to the problem described here:
> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Defining-Directories.html
>
> Is there a recommended way to patch configure.ac so that such an option
> works correctly? The above reference suggests either moving definitions
> to compile-time options in Makefile.am, which, looking at the repository
> history, seems to have been done in gutenprint in the past, or using an
> additional macro to resolve the pathname.
>
> Thank you for reading this and in advance for any reply.
>
> Regards,
> George
|
|
From: Osvander C. F. <osv...@gm...> - 2022-07-07 10:45:33
|
Bom dia (Good morning); Seria possível vocês do Gutenprint adicionarem a impressora (Epson L3150) na relações de drivers. Eu ficaria muito grato. Atencipo meus agradecimentos. It would be possible for you from Gutenprint to add the printer (Epson L3150) in the drivers list. I would be very grateful. I accept my thanks. Osvander Franco. |
|
From: Robert K. <rl...@al...> - 2022-07-07 02:09:25
|
On 7/4/22 19:23, Michael Sweet via Gimp-print-devel wrote:
> FWIW, CUPS has always manually expanded things because autoconf doesn't (and this is actually documented by the current version of the autoconf docos...)
>
> The "explanation" is that they expect software to do the expansion and support variables like this. 🙄
Interesting. That behavior seems...counterintuitive to me.
>> On Jul 4, 2022, at 6:42 PM, Robert Krawitz <rl...@al...> wrote:
>>
>> On 7/1/22 23:30, Matsumura, George wrote:
>>> Greetings,
>>>
>>> My build of Gutenprint, built through Void Linux's standardized build
>>> process, was unable to find the module directories due to PKGMODULEDIR
>>> being defined in config.h as:
>>> #define PKGMODULEDIR "${exec_prefix}/lib64/gutenprint/5.3/modules"
>>>
>>> Since the C processor cannot expand exec_prefix, it remains in the path
>>> at runtime and cannot be resolved.
>>>
>>> Attached is the config.summary from the build. In particular, the
>>> following flag passed to configure seemed to be responsible:
>>> --libdir=\${exec_prefix}/lib64
>>
>> That definitely isn't valid; configure doesn't perform any expansion of its own, but rather takes
>> what was provided on its command line.
>>
>> Why is it using
>>
>> --libdir=\${exec_prefix}/lib64
>>
>> rather than expanding it out?
>>
>>> There seems to be a specific case in configure.ac for when libdir is
>>> defined as \${exec_prefix}/lib, but this would not cover my case.
>>>
>>> This seems to be similar to the problem described here:
>>> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Defining-Directories.html
>>>
>>> Is there a recommended way to patch configure.ac so that such an option
>>> works correctly? The above reference suggests either moving definitions
>>> to compile-time options in Makefile.am, which, looking at the repository
>>> history, seems to have been done in gutenprint in the past, or using an
>>> additional macro to resolve the pathname.
>>>
>>> Thank you for reading this and in advance for any reply.
|
|
From: Michael S. <ms...@ms...> - 2022-07-04 23:40:24
|
FWIW, CUPS has always manually expanded things because autoconf doesn't (and this is actually documented by the current version of the autoconf docos...)
The "explanation" is that they expect software to do the expansion and support variables like this. 🙄
> On Jul 4, 2022, at 6:42 PM, Robert Krawitz <rl...@al...> wrote:
>
> On 7/1/22 23:30, Matsumura, George wrote:
>> Greetings,
>>
>> My build of Gutenprint, built through Void Linux's standardized build
>> process, was unable to find the module directories due to PKGMODULEDIR
>> being defined in config.h as:
>> #define PKGMODULEDIR "${exec_prefix}/lib64/gutenprint/5.3/modules"
>>
>> Since the C processor cannot expand exec_prefix, it remains in the path
>> at runtime and cannot be resolved.
>>
>> Attached is the config.summary from the build. In particular, the
>> following flag passed to configure seemed to be responsible:
>> --libdir=\${exec_prefix}/lib64
>
> That definitely isn't valid; configure doesn't perform any expansion of its own, but rather takes
> what was provided on its command line.
>
> Why is it using
>
> --libdir=\${exec_prefix}/lib64
>
> rather than expanding it out?
>
>> There seems to be a specific case in configure.ac for when libdir is
>> defined as \${exec_prefix}/lib, but this would not cover my case.
>>
>> This seems to be similar to the problem described here:
>> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Defining-Directories.html
>>
>> Is there a recommended way to patch configure.ac so that such an option
>> works correctly? The above reference suggests either moving definitions
>> to compile-time options in Makefile.am, which, looking at the repository
>> history, seems to have been done in gutenprint in the past, or using an
>> additional macro to resolve the pathname.
>>
>> Thank you for reading this and in advance for any reply.
>>
>> Regards,
>> George
>
>
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
>
________________________
Michael Sweet
|
|
From: Robert K. <rl...@al...> - 2022-07-04 23:15:59
|
On 7/1/22 23:30, Matsumura, George wrote:
> Greetings,
>
> My build of Gutenprint, built through Void Linux's standardized build
> process, was unable to find the module directories due to PKGMODULEDIR
> being defined in config.h as:
> #define PKGMODULEDIR "${exec_prefix}/lib64/gutenprint/5.3/modules"
>
> Since the C processor cannot expand exec_prefix, it remains in the path
> at runtime and cannot be resolved.
>
> Attached is the config.summary from the build. In particular, the
> following flag passed to configure seemed to be responsible:
> --libdir=\${exec_prefix}/lib64
That definitely isn't valid; configure doesn't perform any expansion of its own, but rather takes
what was provided on its command line.
Why is it using
--libdir=\${exec_prefix}/lib64
rather than expanding it out?
> There seems to be a specific case in configure.ac for when libdir is
> defined as \${exec_prefix}/lib, but this would not cover my case.
>
> This seems to be similar to the problem described here:
> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Defining-Directories.html
>
> Is there a recommended way to patch configure.ac so that such an option
> works correctly? The above reference suggests either moving definitions
> to compile-time options in Makefile.am, which, looking at the repository
> history, seems to have been done in gutenprint in the past, or using an
> additional macro to resolve the pathname.
>
> Thank you for reading this and in advance for any reply.
>
> Regards,
> George
|
|
From: Matsumura, G. <gm9...@oh...> - 2022-07-02 04:53:58
|
Greetings,
My build of Gutenprint, built through Void Linux's standardized build
process, was unable to find the module directories due to PKGMODULEDIR
being defined in config.h as:
#define PKGMODULEDIR "${exec_prefix}/lib64/gutenprint/5.3/modules"
Since the C processor cannot expand exec_prefix, it remains in the path
at runtime and cannot be resolved.
Attached is the config.summary from the build. In particular, the
following flag passed to configure seemed to be responsible:
--libdir=\${exec_prefix}/lib64
There seems to be a specific case in configure.ac for when libdir is
defined as \${exec_prefix}/lib, but this would not cover my case.
This seems to be similar to the problem described here:
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Defining-Directories.html
Is there a recommended way to patch configure.ac so that such an option
works correctly? The above reference suggests either moving definitions
to compile-time options in Makefile.am, which, looking at the repository
history, seems to have been done in gutenprint in the past, or using an
additional macro to resolve the pathname.
Thank you for reading this and in advance for any reply.
Regards,
George |
|
From: Matsumura, G. <gm9...@oh...> - 2022-07-02 04:03:53
|
Greetings,
My build of Gutenprint, built through Void Linux's standardized build
process, was unable to find the module directories due to PKGMODULEDIR
being defined in config.h as:
#define PKGMODULEDIR "${exec_prefix}/lib64/gutenprint/5.3/modules"
Since the C processor cannot expand exec_prefix, it remains in the path
at runtime and cannot be resolved.
Attached is the config.summary from the build. In particular, the
following flag passed to configure seemed to be responsible:
--libdir=\${exec_prefix}/lib64
There seems to be a specific case in configure.ac for when libdir is
defined as \${exec_prefix}/lib, but this would not cover my case.
This seems to be similar to the problem described here:
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/html_node/Defining-Directories.html
Is there a recommended way to patch configure.ac so that such an option
works correctly? The above reference suggests either moving definitions
to compile-time options in Makefile.am, which, looking at the repository
history, seems to have been done in gutenprint in the past, or using an
additional macro to resolve the pathname.
Thank you for reading this and in advance for any reply.
Regards,
George |
|
From: Matt <wal...@ma...> - 2022-06-18 19:16:14
|
> On Jun 15, 2022, at 10:18 AM, Piwi <pi...@gm...> wrote: > > > Hello, > > I've installed your drivers on my new MacBook Pro M1. While the selection is impressive, there is no Samsung ML-1660 among it. > I attempted generic drivers, but to no avail. Would it be possible to add this printer to the driver pack? Is there an alternative just for this model? > > If the response is no for these two questions, I would like to lend my help if possible. I'm a software engineer lacking in side projects, and working on this one driver could be a fun challenge. > Do you accept PR somewhere? Or is there a more involved process to it? The Samsung ML-1660 uses the SPL printer language which Gutenprint does not support. The SPL printer language is Samsung’s proprietary language for some of their printers. Matt Sent from my iPad |
|
From: Piwi <pi...@gm...> - 2022-06-15 01:13:23
|
Hello, I've installed your drivers on my new MacBook Pro M1. While the selection is impressive, there is no Samsung ML-1660 among it. I attempted generic drivers, but to no avail. Would it be possible to add this printer to the driver pack? Is there an alternative just for this model? If the response is no for these two questions, I would like to lend my help if possible. I'm a software engineer lacking in side projects, and working on this one driver could be a fun challenge. Do you accept PR somewhere? Or is there a more involved process to it? Thank you, Simon St-Pierre @ Fujitsu Inc. |
|
From: Robert K. <rl...@al...> - 2022-06-03 04:51:39
|
On 5/25/22 09:42, Егумнов Илья wrote: > Good afternoon! is it possible to optimize your printer driver for HP PageWide series printers? So that you can print from a roll. For payment of course. Hi, I'm not familiar with this printer, and currently nobody has stepped forward to maintain the PCL driver. So unless someone wants to volunteer to do the work, we're not going to be able to do that. |
|
From: Solomon P. <pi...@sh...> - 2022-05-28 17:23:22
|
On Fri, May 27, 2022 at 11:12:38AM +0000, Patrick Massen via Gimp-print-devel wrote:
> i have unbutu linux and trying to install gunteprint for a Mitshibishi
> cp9550-dw-s.But unfortunately it does not work or i did something
> stupid.I have already make and install make done and later i read that
> ifirst had to look if the configure is ok. Could you help me further?
> I am not a programmer but i try my best :)
>
> Release: gutenprint 5.0.0 generated on 22 Jul 2006
This is _very_ old, please download a newer snapshot if you are goig to
compile from source.
That said, current Ubuntu releases have a sufficiently updated
Gutenprint such that the Mitsubishi CP9550DW-S is expected to work out
of the box.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
Live Oak, FL speachy (libra.chat)
|
|
From: Patrick M. <pat...@ya...> - 2022-05-27 11:12:46
|
Dear Sir i have unbutu linux and trying to install gunteprint for a Mitshibishi cp9550-dw-s.But unfortunately it does not work or i did something stupid.I have already make and install make done and later i read that ifirst had to look if the configure is ok. Could you help me further? I am not a programmer but i try my best :) Release: gutenprint 5.0.0 generated on 22 Jul 2006 Features: Build CUPS: no, installing in /usr Build Ghostscript IJS driver: no Build Foomatic data: no Build enhanced Print plugin for the GIMP: no Build EPSON Stylus utility: yes Build test programs: yes Build testpattern generator: yes Installation summary: Installation prefix: /usr/local Data directory: /usr/local/share/gutenprint Library directory: /usr/local/lib/gutenprint XML data directory: /usr/local/share/gutenprint/5.0.0/xml Module directory: /usr/local/lib/gutenprint/5.0.0/modules Install sample images: yes General configuration: Compiler options: -g -O2 -Wall -Wcast-align -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Wwrite-strings -Werror-implicit-function-declaration -Winline -finline-limit=1048576 Build static libraries: yes Build shared libraries: yes Maintainer mode: no Generate profiling information: no Generate debugging symbols: no Use modules: static Use readline libraries: yes |
|
From: Егумнов И. <eg...@ya...> - 2022-05-25 13:43:05
|
Good afternoon! is it possible to optimize your printer driver for HP PageWide series printers? So that you can print from a roll. For payment of course. -- С уважением, Егумнов mailto:eg...@ya... |
|
From: Solomon P. <pi...@sh...> - 2022-05-24 13:25:10
|
On Tue, May 24, 2022 at 12:04:35PM +0200, Moritz Gräßler - SelfieMate wrote: > Hello dear Gimp-Print Team, I am running a Raspberry PI print server > with your software. I would like to use the DNP QW410 and Citizen > CZ-01 printer with it. Is it possible to realize this? Yep, both are supported with current code. IIRC all advertised features of the QW410/CZ-01 are supported. I don't know what OS/version you're using on your RPi, but these instructions should do the trick: https://www.peachyphotos.com/blog/stories/building-modern-gutenprint/ (Given your choice of printer, you can stop after performing the "restart CUPS" step..) > PS: Do you accept donations? Gutenprint as a project does not -- we've released it as Free Software in the hope it is useful to others, with no expectations of compensation. That said, I've personally accepted donations to help fund the acquisition of additional dye-submlimation printers and media kits to aid Gutenprint development: https://www.peachyphotos.com/blog/stories/dye-sublimation-photo-printers-and-linux/ Best of luck, - Solomon -- Solomon Peachy pizza at shaftnet dot org (email&xmpp) @pizza:shaftnet dot org (matrix) High Springs, FL speachy (libra.chat) |
|
From: Moritz G. - S. <ch...@se...> - 2022-05-24 10:20:00
|
Hello dear Gimp-Print Team, I am running a Raspberry PI print server with your software. I would like to use the DNP QW410 and Citizen CZ-01 printer with it. Is it possible to realize this? Greetings and thanks for your help. PS: Do you accept donations? Moritz Gräßler Geschäftsführer Mobil: 0170/4948065 Mail: ch...@se... Online: www.selfiemate.de |
137 messages has been excluded from this view by a project administrator.
