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
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Russell S. <rj...@ne...> - 2022-08-25 11:17:10
|
On 19/8/22 15:49, Russell Shaw wrote: > I found the ET-2850 works ok with the ET-2750 driver Hi, I found the printer has duplexing but the driver has not. In gimp-print-source/src/xml/escp2/model/model_134.xml, it has: <margins duplex="duplex">9 9 27 27</margins> Where do i find what these numbers mean ? Where do i find what is allowed in any of the xml files ? <http://gimp-print.sourceforge.net/xsd/gp.xsd-1.0> is an out of date link. |
|
From: Robin S. <ro...@le...> - 2022-08-19 17:02:47
|
Good afternoon, I am getting banding in areas of gradual luminance gradient when printing with Gutenprint, as described below. OpenSUSE Tumbleweed KDE, plasma version 5.25.4 Kernel 5.19.1-1-default (64 bit) Gutenprint version 5.2.15 CUPS version 2.4.2 Epson Surecolor P600 printer In order to obtain accurate colours with the printer, I have custom ICC profiles created by the suppliers of the photo papers I use. The suppliers' templates (patch files) are printed from Darktable v4.0 in the normal way by turning off all colour management in Gutenprint and Darktable. The resultant ICC profiles are very good for colour accuracy. However, where a print has an area of gradually changing luminance, visible banding occurs. This is most obvious in desaturated regions; it also happens in more saturated areas but is much less marked. Darktable's soft proofing displays exactly the same banding. I have created two simple monochrome images with linear luminance gradients and taken screenshots of the results in Darktable with soft proofing on and off respectively. The results are attached. I have so far had 5 custom profiles created from three different suppliers. All of them show the banding to a greater or lesser extent. The same image files printed on Windows computers and the same model of printer, using the Epson driver and custom profiles for that combination do not show any banding. The conclusion must be that the custom profiles created via Darktable and Gutenprint/CUPS are somehow faulty, i.e. the patch files have not been created correctly. I also occasionally use Qimage Ultimate v2023.100, a Windows program running under WINE. The ICC profiles created via Darktable produce prints (and soft proofs) in Qimage which are virtually indistinguishable from those in Darktable, i.e. the ICC profiles are fully interchangeable between Darktable and Qimage. Furthermore, if I print the colour patches from Qimage instead of from Darktable, the results are exactly the same. This leads me to believe that the problem cannot lie with either Darktable or Qimage, since the colour patches are printed independently and give identical results. I cannot compare with images printed directly from GIMP as the ICC profiles created with Darktable or with Qimage are not interchangeable with GIMP - the colours are no longer accurate. I do not know why. Perhaps I should also mention that prior to using Gutenprint I worked with TurboPrint and results from this show no banding at all. The only common factor is therefore Gutenprint/CUPS, hence I can only conclude that this is very likely to be a Gutenprint bug. Kind regards, Robin Simmons |
|
From: Russell S. <rj...@ne...> - 2022-08-19 05:49:41
|
I found the ET-2850 works ok with the ET-2750 driver |
|
From: Superma <Su...@we...> - 2022-08-18 10:15:24
|
Dear all, I try to make my brother MFC-J6720DW printer running with CUPS on my NEXTCLOUDPI Rasperry. I have already tried with the following print drivers: * Brother MFC-9600 * Generic IPP Everywhere Printer * Brother MFC-6550MC * Brother MFC-8300 * Brother MFC-9500 * Brother DCP-1200 * Brother MFC-9840CDW BR-Script3 Everytime I am getting the same / following result: 1. Print Test Page 2. Testpage is shown on the spool queue: 3. Printer is starting and showing "Receving Data" 4. Printer goes back to standby without printing anything 5. Printjob is removed from the queue: Im am having: * * * What else can I do? Do I need a separate printer driver file? Thank you very much for your help. Manuel |
|
From: Russell S. <rj...@ne...> - 2022-08-17 13:50:57
|
On 17/8/22 12:41, Russell Shaw wrote: > Hi, > > I wanted to get this printer but can't find anyone that has tried the Ecotank > ET-2800 series. > > The Ecotank ET-2700 series is on the supported-list. > > <https://www.epson.com.au/products/ecotank/ET-2850.asp> > > <https://www.epson.com.au/products/ecotank/ET-2750.asp> > > > The gutenprinted supported ET-2750 has: > > EcoTank ET-2750 C11CG22501 > PRINTING METHOD On-demand Inkjet (piezoelectric) > NOZZLE CONFIGURATION 180 nozzles Black, 59 nozzles each colour > (Cyan, Yellow, Magenta) > MINIMUM INK DROPLET VOLUME 3 Picolitres > 5760 x 1440 optimised dpi with (with Variable Sized Droplet Technology) > > > The ET-2850 has: > > RODUCT CODE C11CJ63501 > PRINTING TECHNOLOGY 4-Colour (CMYK), drop-on > demand MicroPiezo® inkjet technology > MAXIMUM PRINT RESOLUTION 5,760 x 1,440 dpi > > > The resolution is the same, but the epson specs don't state the nozzle > configuration for the ET-2850. > > Both use the same T502 ink. > > > I suppose it's luck whether it'll work or not ? I found at the end of the manual that the 2850 has the same nozzle configuration as the 2750. <https://download.epson-europe.com/pub/download/6463/epson646360eu.pdf> |
|
From: Robert K. <rl...@al...> - 2022-08-17 03:11:36
|
On 8/10/22 16:53, Bradley Parks wrote: > 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? Hi, We do not have anybody working on HP printers at this point in time, so it's not going to be supported unless someone steps up to do the work and testing. |
|
From: Robert K. <rl...@al...> - 2022-08-17 03:11:24
|
On 8/9/22 17:24, Marcos Llumiquinga wrote: > 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. There haven't been any security fixes, so it's not essential that you upgrade if your printer is working properly. Still, be aware that 5.2.13 is quite old. |
|
From: Russell S. <rj...@ne...> - 2022-08-17 03:03:45
|
Hi, I wanted to get this printer but can't find anyone that has tried the Ecotank ET-2800 series. The Ecotank ET-2700 series is on the supported-list. <https://www.epson.com.au/products/ecotank/ET-2850.asp> <https://www.epson.com.au/products/ecotank/ET-2750.asp> The gutenprinted supported ET-2750 has: EcoTank ET-2750 C11CG22501 PRINTING METHOD On-demand Inkjet (piezoelectric) NOZZLE CONFIGURATION 180 nozzles Black, 59 nozzles each colour (Cyan, Yellow, Magenta) MINIMUM INK DROPLET VOLUME 3 Picolitres 5760 x 1440 optimised dpi with (with Variable Sized Droplet Technology) The ET-2850 has: RODUCT CODE C11CJ63501 PRINTING TECHNOLOGY 4-Colour (CMYK), drop-on demand MicroPiezo® inkjet technology MAXIMUM PRINT RESOLUTION 5,760 x 1,440 dpi The resolution is the same, but the epson specs don't state the nozzle configuration for the ET-2850. Both use the same T502 ink. I suppose it's luck whether it'll work or not ? |
|
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 |
137 messages has been excluded from this view by a project administrator.
