Re: [Gimp-print-devel] RFC: New release and abandoning MacOS?

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

> On Jun 29, 2023, at 9:27 AM, Matt Broughton <wal...@ma...> wrote:
> 
>> 
>> On Jun 28, 2023, at 8:19 PM, Solomon Peachy <pi...@sh... <mailto:pi...@sh...>> wrote:
>> 
>> On Wed, Jun 28, 2023 at 07:44:55PM -0500, Matt Broughton wrote:
>>> I am not sure I know all of the macOS issues or how difficult it would 
>>> be to accomodate them.  I do know that the v5.3.x macOS releases are a 
>>> show stopper for printers that can print on CDs or DVDs. No Printer 
>>> Features can be seen in the GUI.  Even trying to see the Printer 
>>> Features will crash some applications. PPDs can be modified to resolve 
>>> this issue.  Alternatively, genppd.c can be modified.  I have a 
>>> modified genppd.c we used for testing that fixes the issue.
>> 
>> Since this is due to a PPD construct, I assume this problem happens with 
>> remote network printers (set up to use a PPD instead of IPP) as well as 
>> locally-attached ones?
> 
> I believe that is correct.
> 
>> 
>> Meanwhile, what's the technical argument against merging this change?
> 
> It isn't a technical argument.  It is a feature issue.  The problem under macOS is using custom CD sizes.  That is where the user can manually enter a value in the print window that isn't contained in the spin box.  The PPD needs to have the following lines removed--
> 
> *CustomStpCDOuterDiameter True: "pop"
> *ParamCustomStpCDOuterDiameter Value/Value: 1 points 184 340
>  
> *CustomStpCDInnerDiameter True: "pop"
> *ParamCustomStpCDInnerDiameter Value/Value: 1 points 45 121
>  
> *CustomStpCDXAdjustment True: "pop"
> *ParamCustomStpCDXAdjustment Value/Value: 1 points -30 30
>  
> *CustomStpCDYAdjustment True: "pop"
> *ParamCustomStpCDYAdjustment Value/Value: 1 points -30 30
> 
> Implementing the change globally takes away an important feature for non-macOS users.  There was no decision on how to deal with this.  It didn't seem palatable to test for Apple platform in the source code.
> 
> Matt

I'm going to bring this up again in light of v5.3.5-pre1 being released.  Would there be any interest in making a change in genppd.c to alleviate a macos bug?  I know macos is officially deprecated, but there will always be those that compile it for themselves.  It would be helpful to have the fix in the repository.

At the least, the fix can be memorialized on the list.  The fix for macos is to do away with a custom option for printing on CD/DVDs.

diff --git a/Users/matt/GutenGit/gimp-print-source/src/cups/genppd.c b/Users/matt/Downloads/genppd.c
index 194cf42..0c7e2ce 100644
--- a/Users/matt/GutenGit/gimp-print-source/src/cups/genppd.c
+++ b/Users/matt/Downloads/genppd.c
@@ -987,6 +987,7 @@ print_one_option(gpFile fp, stp_vars_t *v, const stp_string_list_t *po,
       print_close_ui = 0;
       gpprintf(fp, "*CloseUI: *Stp%s\n\n", desc->name);
 
+#if 0
       /*
        * Add custom option code and value parameter...
        */
@@ -995,7 +996,7 @@ print_one_option(gpFile fp, stp_vars_t *v, const stp_string_list_t *po,
       gpprintf(fp, "*ParamCustomStp%s Value/%s: 1 points %d %d\n\n",
               desc->name, _("Value"), (int) desc->bounds.dimension.lower,
               (int) desc->bounds.dimension.upper);
-
+#endif
       break;
     case STP_PARAMETER_TYPE_INT:
       gpprintf(fp, "*OPOptionHints Stp%s: \"input spinbox\"\n", lparam->name);

When we found this fix, it was felt that the custom option was important to keep wherever possible.  Using something like 
#ifdef __APPLE__ 
was not favored, but nothing was ever resolved.  If genppd.c could be modified and a conditional #ifdef __APPLE__ addition, or something else) is palatable, it would be appreciated.  I'm not a coder, so I can't give the exact code needed.

The v5.3.5-pre1 release does build nicely from the command line on machines of both architectures (macos 12.5 x86_64 and macos 14.5 arm64).  The `make check` was took about 8 hours, but everything passed.

Matt