gimp-print-devel

Re: [Gimp-print-devel] Imprimante Epson

[Walker B. <fo...@wa...>]

I think Catalina is requiring Notarization not just dev signing . . . I’ve had to do this with all pkg installers of late. It's a PITA to say the least.

https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution <https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution>

Best,
Walker


> On Dec 9, 2019, at 3:52 PM, Robert Krawitz <rl...@al...> wrote:
> 
> On Mon, 9 Dec 2019 14:19:47 -0600, Matt Broughton wrote:
>>> On Dec 9, 2019, at 1:59 PM, Matt Broughton <wal...@ma...> wrote:
>>>> On Dec 9, 2019, at 12:00 PM, Solomon Peachy <pi...@sh...> wrote:
>>>> On Mon, Dec 09, 2019 at 11:14:56AM -0600, Matt Broughton wrote:
>>>>> As Steve mentioned, there is brew.  There are also macports.org and 
>>>>> finkproject.org.  They have been around longer than brew.  They both 
>>>>> support Catalina.  
>>>> 
>>>> I don't know if this has been considered in the past, but is packaging 
>>>> gutenprint within brew or macports technically feasible?
>>>> 
>>>> (And if it is, might it be a better approach than a standalone installer?)
>>>> 
>>>> - Solomon
>>> 
>>> I think most Mac users would just abandon Gutenprint.  They shout,
>>> curse, and/or ask what the heck are they referring to?  In my
>>> opinion, it is a pretty heavy burden.  I'm not sure of my
>>> terminology, but I have referred to it as installing a whole
>>> subsystem but without kernel or GUI.  I have used both of them in
>>> the past for a particular purpose and then dumped them.
>>> Personally, I don't think I would use macport.org or
>>> finkproject.com on an ongoing basis.  I would just buy cheap, throw
>>> away printers or use a linux install under virtual machine.  <
>>> /soapbox>
>> 
>> Solomon, I should have prefaced my comments on them being an
>> interesting solution.  Just putting ideas like that out on the list
>> may spark other ideas.  I am sure I was too reactionary to using
>> macports or fink based on my personal experience with therm.
>> 
>> Hmm.  I just took a look at the available ports for macports.  It
>> would seem to be somewhat doable. They do have some gimp-print
>> v4.2.7 drivers and gutenprint 5.3.3 GIMP plugin.  See
>> https://ports.macports.org/ports/category/print/
>> 
>> I would guess that they would need a maintainer.  Even at that,
>> there would be the problem of the complexity for the normal Mac
>> user.
> 
> I definitely don't think that we should use brew or macports as the
> distribution mechanism.  My point is to figure out/ask them what they
> are doing to get working packages on Catalina and go from there.
> -- 
> Robert Krawitz                                     <rl...@al...>
> 
> ***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
> Member of the League for Programming Freedom  --  http://ProgFree.org
> Project lead for Gutenprint   --    http://gimp-print.sourceforge.net
> 
> "Linux doesn't dictate how I work, I dictate how Linux works."
> --Eric Crampton
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] Imprimante Epson

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

On Mon, Dec 09, 2019 at 01:59:40PM -0600, Matt Broughton wrote:
> I think most Mac users would just abandon Gutenprint.  They shout, 
> curse, and/or ask what the heck are they referring to?  

If moving to macports/homebrew results in something that reduces our 
support/maintainence burden (eg wider OS platform support, simpler 
release process, and so forth) that might arguably be a net benefit.

Consider how much handholding we have to do already; it's no 
exaggeration to say that nearly all of the dyesub support requests I 
field come from Mac users who upgraded (well) beyond their printer 
maker's driver support, often bringing expectations of OEM-quality 
polish/tools and support.  (Most of the rest come from folks tend to 
relate to obsolete Gutenprint versions on the likes of Raspberry Pi 
systems)

Meanwhile, nearly every MacOS release has broken something about 
Gutenprint or its release/packaging process, and the next version 
post-Catalina is expected to completely drop support for traditional 
CUPS drivers altogether, making Gutenprint pretty much useless for Mac 
users until we manage to build a "printing application" instead.

It's ... a mess, and if macports/homebrew can make it easier for us, we 
should at least consider it..

> I would just buy cheap, throw away printers or use a linux install 
> under virtual machine.  < /soapbox>

Unfortunately, in the niche that Gutenprint occupies, there are no cheap 
throaway printers.  But yeah, I've recommend the VM approach (or the use 
of the likes of a Raspberry Pi) on multiple occasions.

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

Re: [Gimp-print-devel] Imprimante Epson

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

On Mon, 9 Dec 2019 14:19:47 -0600, Matt Broughton wrote:
>> On Dec 9, 2019, at 1:59 PM, Matt Broughton <wal...@ma...> wrote:
>>> On Dec 9, 2019, at 12:00 PM, Solomon Peachy <pi...@sh...> wrote:
>>> On Mon, Dec 09, 2019 at 11:14:56AM -0600, Matt Broughton wrote:
>>>> As Steve mentioned, there is brew.  There are also macports.org and 
>>>> finkproject.org.  They have been around longer than brew.  They both 
>>>> support Catalina.  
>>> 
>>> I don't know if this has been considered in the past, but is packaging 
>>> gutenprint within brew or macports technically feasible?
>>> 
>>> (And if it is, might it be a better approach than a standalone installer?)
>>> 
>>> - Solomon
>> 
>> I think most Mac users would just abandon Gutenprint.  They shout,
>> curse, and/or ask what the heck are they referring to?  In my
>> opinion, it is a pretty heavy burden.  I'm not sure of my
>> terminology, but I have referred to it as installing a whole
>> subsystem but without kernel or GUI.  I have used both of them in
>> the past for a particular purpose and then dumped them.
>> Personally, I don't think I would use macport.org or
>> finkproject.com on an ongoing basis.  I would just buy cheap, throw
>> away printers or use a linux install under virtual machine.  <
>> /soapbox>
>
> Solomon, I should have prefaced my comments on them being an
> interesting solution.  Just putting ideas like that out on the list
> may spark other ideas.  I am sure I was too reactionary to using
> macports or fink based on my personal experience with therm.
>
> Hmm.  I just took a look at the available ports for macports.  It
> would seem to be somewhat doable. They do have some gimp-print
> v4.2.7 drivers and gutenprint 5.3.3 GIMP plugin.  See
> https://ports.macports.org/ports/category/print/
>
> I would guess that they would need a maintainer.  Even at that,
> there would be the problem of the complexity for the normal Mac
> user.

I definitely don't think that we should use brew or macports as the
distribution mechanism.  My point is to figure out/ask them what they
are doing to get working packages on Catalina and go from there.
-- 
Robert Krawitz                                     <rl...@al...>

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

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

Re: [Gimp-print-devel] Imprimante Epson

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

I use macports and brew. I do it because it is much simpler than getting the source, fixing the build problems, and then installing. 

I agree with Matt I t’s not for the usual Mac User. I also agree the more input there is on a problem, the better the solution will be. 

Steve Letter
Sent from my Commodore PET

> On Dec 9, 2019, at 3:20 PM, Matt Broughton <wal...@ma...> wrote:
> 
> 
> 
>>> On Dec 9, 2019, at 1:59 PM, Matt Broughton <wal...@ma...> wrote:
>>> 
>>> 
>>> 
>>>> On Dec 9, 2019, at 12:00 PM, Solomon Peachy <pi...@sh...> wrote:
>>> 
>>> On Mon, Dec 09, 2019 at 11:14:56AM -0600, Matt Broughton wrote:
>>>> As Steve mentioned, there is brew.  There are also macports.org and 
>>>> finkproject.org.  They have been around longer than brew.  They both 
>>>> support Catalina.  
>>> 
>>> I don't know if this has been considered in the past, but is packaging 
>>> gutenprint within brew or macports technically feasible?
>>> 
>>> (And if it is, might it be a better approach than a standalone installer?)
>>> 
>>> - Solomon
>> 
>> I think most Mac users would just abandon Gutenprint.  They shout, curse, and/or ask what the heck are they referring to?  In my opinion, it is a pretty heavy burden.  I'm not sure of my terminology, but I have referred to it as installing a whole subsystem but without kernel or GUI.  I have used both of them in the past for a particular purpose and then dumped them.  Personally, I don't think I would use macport.org or finkproject.com on an ongoing basis.  I would just buy cheap, throw away printers or use a linux install under virtual machine.   < /soapbox>
>> 
>> Matt
> 
> Solomon, I should have prefaced my comments on them being an interesting solution.  Just putting ideas like that out on the list may spark other ideas.  I am sure I was too reactionary to using macports or fink based on my personal experience with therm.
> 
> Hmm.  I just took a look at the available ports for macports.  It would seem to be somewhat doable. They do have some gimp-print v4.2.7 drivers and gutenprint 5.3.3 GIMP plugin.
> See https://ports.macports.org/ports/category/print/
> 
> I would guess that they would need a maintainer.  Even at that, there would be the problem of the complexity for the normal Mac user.
> 
> Matt
> 
> 
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] Imprimante Epson

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

> On Dec 9, 2019, at 1:59 PM, Matt Broughton <wal...@ma...> wrote:
> 
> 
> 
>> On Dec 9, 2019, at 12:00 PM, Solomon Peachy <pi...@sh...> wrote:
>> 
>> On Mon, Dec 09, 2019 at 11:14:56AM -0600, Matt Broughton wrote:
>>> As Steve mentioned, there is brew.  There are also macports.org and 
>>> finkproject.org.  They have been around longer than brew.  They both 
>>> support Catalina.  
>> 
>> I don't know if this has been considered in the past, but is packaging 
>> gutenprint within brew or macports technically feasible?
>> 
>> (And if it is, might it be a better approach than a standalone installer?)
>> 
>> - Solomon
> 
> I think most Mac users would just abandon Gutenprint.  They shout, curse, and/or ask what the heck are they referring to?  In my opinion, it is a pretty heavy burden.  I'm not sure of my terminology, but I have referred to it as installing a whole subsystem but without kernel or GUI.  I have used both of them in the past for a particular purpose and then dumped them.  Personally, I don't think I would use macport.org or finkproject.com on an ongoing basis.  I would just buy cheap, throw away printers or use a linux install under virtual machine.   < /soapbox>
> 
> Matt

Solomon, I should have prefaced my comments on them being an interesting solution.  Just putting ideas like that out on the list may spark other ideas.  I am sure I was too reactionary to using macports or fink based on my personal experience with therm.

Hmm.  I just took a look at the available ports for macports.  It would seem to be somewhat doable. They do have some gimp-print v4.2.7 drivers and gutenprint 5.3.3 GIMP plugin.
See https://ports.macports.org/ports/category/print/

I would guess that they would need a maintainer.  Even at that, there would be the problem of the complexity for the normal Mac user.

Matt

Re: [Gimp-print-devel] Imprimante Epson

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

> On Dec 9, 2019, at 12:00 PM, Solomon Peachy <pi...@sh...> wrote:
> 
> On Mon, Dec 09, 2019 at 11:14:56AM -0600, Matt Broughton wrote:
>> As Steve mentioned, there is brew.  There are also macports.org and 
>> finkproject.org.  They have been around longer than brew.  They both 
>> support Catalina.  
> 
> I don't know if this has been considered in the past, but is packaging 
> gutenprint within brew or macports technically feasible?
> 
> (And if it is, might it be a better approach than a standalone installer?)
> 
> - Solomon

I think most Mac users would just abandon Gutenprint.  They shout, curse, and/or ask what the heck are they referring to?  In my opinion, it is a pretty heavy burden.  I'm not sure of my terminology, but I have referred to it as installing a whole subsystem but without kernel or GUI.  I have used both of them in the past for a particular purpose and then dumped them.  Personally, I don't think I would use macport.org or finkproject.com on an ongoing basis.  I would just buy cheap, throw away printers or use a linux install under virtual machine.   < /soapbox>

Matt

Re: [Gimp-print-devel] Imprimante Epson

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

On Mon, Dec 09, 2019 at 11:14:56AM -0600, Matt Broughton wrote:
> As Steve mentioned, there is brew.  There are also macports.org and 
> finkproject.org.  They have been around longer than brew.  They both 
> support Catalina.  

I don't know if this has been considered in the past, but is packaging 
gutenprint within brew or macports technically feasible?

(And if it is, might it be a better approach than a standalone installer?)

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

Re: [Gimp-print-devel] Imprimante Epson

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

> On Dec 8, 2019, at 4:47 PM, Robert Krawitz <rl...@al...> wrote:
> 
> On Sun, 8 Dec 2019 13:48:24 -0600, Matt Broughton wrote:
>> 
>> 
>>> On Dec 8, 2019, at 1:36 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote:
>>> 
>>> As for an update, I hardened the missed files as the bot told me to and resubmitted. I am contacting support because the answer back makes no sense. I worked on submitting all day yesterday and my submission was not accepted. It kept complaining that I wasn’t  doing something that I was doing. (Including an Id for tracking)
>>> 
>>> I didn’t check, is there a new tarballs for me to build?
>>> 
>>> Steve Letter
>>> Sent from my Commodore PET
>>> 
>>>> On Dec 8, 2019, at 12:15 PM, Matt Broughton <wal...@ma...> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Dec 8, 2019, at 9:04 AM, Henri Menot via Gimp-print-devel <gim...@li...> wrote:
>>>>> 
>>>>>  Guten Print est ‘il mise à jour pour Mac osx 10.15 ?
>>>> 
>>>> The Gutenprint installers do not work on macos 10.5 Catalina. The Gutenprint team is aware of the problem and are working on a solution. Gutenprint does not have a timeline for resolution at this time. We will update this as appropriate.
>>>> 
>>>> Translation by Google:
>>>> Les programmes d'installation de Gutenprint ne fonctionnent pas sur macos 10.5 Catalina. L'équipe Gutenprint est consciente du problème et travaille sur une solution. Gutenprint n'a pas de calendrier de résolution pour le moment. Nous mettrons à jour cela le cas échéant.
>>>> 
>>>> Matt
>> 
>> Dropping OP.  I can't speak to new tarballs. I know nothing of what Apple wants.  When I read about notorization however, I wondered if Apple would  be able to handle the scripts "EPSON Utility...", uninstall-gutenpring.command, and possibly the libusb.bottle-sierra.tar.gz.  Those executables cannot be signed.  Does Apple look at those too or do they only look at the installer package?
> 
> I remember years ago that there was something, I think it was called
> "ports" or the like, that provided a lot of FOSS stuff for Macs.  Is
> that still around?  If so, what are they doing?

As Steve mentioned, there is brew.  There are also macports.org and finkproject.org.  They have been around longer than brew.  They both support Catalina.  I downloaded the macos installer packager from macports.  I downloaded the Catalina installer for macports.org.  I'm running macos Mojave (10.14.6).  I didn't see any outward appearances of what was done for Catalina.  I may not see Apple's notarization in Mojave by design.  The code signature looked to be in the same format with the same fields and there didn't seem to be any abnormal xattr designations.  All that means is that I can't see what/how Apple blessed it.

Matt

Re: [Gimp-print-devel] Imprimante Epson

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

On Sun, 8 Dec 2019 18:05:14 -0500, Steve Letter via Gimp-print-devel wrote:
> I guess you mean, how are they working around this?  It depends on how complex I suppose. There’s also brew, same idea. I will check them out. 
>
> Apple support is generally helpful though. Just sometimes it takes a while for me to communicate properly with them. 
>
> The last I got from them is that I have to submit the package before the disk image. No time now until Tuesday. 

So does this mean that in general there will be a delay between the
source release and the OS X release?  That strikes me as OK, as long
as we have some idea what the expectations are.

>> On Dec 8, 2019, at 5:47 PM, Robert Krawitz <rl...@al...> wrote:
>> 
>> On Sun, 8 Dec 2019 13:48:24 -0600, Matt Broughton wrote:
>>> 
>>> 
>>>>> On Dec 8, 2019, at 1:36 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote:
>>>> 
>>>> As for an update, I hardened the missed files as the bot told me to and resubmitted. I am contacting support because the answer back makes no sense. I worked on submitting all day yesterday and my submission was not accepted. It kept complaining that I wasn’t  doing something that I was doing. (Including an Id for tracking)
>>>> 
>>>> I didn’t check, is there a new tarballs for me to build?
>>>> 
>>>> Steve Letter
>>>> Sent from my Commodore PET
>>>> 
>>>>> On Dec 8, 2019, at 12:15 PM, Matt Broughton <wal...@ma...> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Dec 8, 2019, at 9:04 AM, Henri Menot via Gimp-print-devel <gim...@li...> wrote:
>>>>>> 
>>>>>>  Guten Print est ‘il mise à jour pour Mac osx 10.15 ?
>>>>> 
>>>>> The Gutenprint installers do not work on macos 10.5 Catalina. The Gutenprint team is aware of the problem and are working on a solution. Gutenprint does not have a timeline for resolution at this time. We will update this as appropriate.
>>>>> 
>>>>> Translation by Google:
>>>>> Les programmes d'installation de Gutenprint ne fonctionnent pas sur macos 10.5 Catalina. L'équipe Gutenprint est consciente du problème et travaille sur une solution. Gutenprint n'a pas de calendrier de résolution pour le moment. Nous mettrons à jour cela le cas échéant.
>>>>> 
>>>>> Matt
>>> 
>>> Dropping OP.  I can't speak to new tarballs. I know nothing of what Apple wants.  When I read about notorization however, I wondered if Apple would  be able to handle the scripts "EPSON Utility...", uninstall-gutenpring.command, and possibly the libusb.bottle-sierra.tar.gz.  Those executables cannot be signed.  Does Apple look at those too or do they only look at the installer package?
>> 
>> I remember years ago that there was something, I think it was called
>> "ports" or the like, that provided a lot of FOSS stuff for Macs.  Is
>> that still around?  If so, what are they doing?
-- 
Robert Krawitz                                     <rl...@al...>

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

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

Re: [Gimp-print-devel] Imprimante Epson

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

I guess you mean, how are they working around this?  It depends on how complex I suppose. There’s also brew, same idea. I will check them out. 

Apple support is generally helpful though. Just sometimes it takes a while for me to communicate properly with them. 

The last I got from them is that I have to submit the package before the disk image. No time now until Tuesday. 

Steve Letter
Sent from my Commodore PET

> On Dec 8, 2019, at 5:47 PM, Robert Krawitz <rl...@al...> wrote:
> 
> On Sun, 8 Dec 2019 13:48:24 -0600, Matt Broughton wrote:
>> 
>> 
>>>> On Dec 8, 2019, at 1:36 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote:
>>> 
>>> As for an update, I hardened the missed files as the bot told me to and resubmitted. I am contacting support because the answer back makes no sense. I worked on submitting all day yesterday and my submission was not accepted. It kept complaining that I wasn’t  doing something that I was doing. (Including an Id for tracking)
>>> 
>>> I didn’t check, is there a new tarballs for me to build?
>>> 
>>> Steve Letter
>>> Sent from my Commodore PET
>>> 
>>>> On Dec 8, 2019, at 12:15 PM, Matt Broughton <wal...@ma...> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Dec 8, 2019, at 9:04 AM, Henri Menot via Gimp-print-devel <gim...@li...> wrote:
>>>>> 
>>>>>  Guten Print est ‘il mise à jour pour Mac osx 10.15 ?
>>>> 
>>>> The Gutenprint installers do not work on macos 10.5 Catalina. The Gutenprint team is aware of the problem and are working on a solution. Gutenprint does not have a timeline for resolution at this time. We will update this as appropriate.
>>>> 
>>>> Translation by Google:
>>>> Les programmes d'installation de Gutenprint ne fonctionnent pas sur macos 10.5 Catalina. L'équipe Gutenprint est consciente du problème et travaille sur une solution. Gutenprint n'a pas de calendrier de résolution pour le moment. Nous mettrons à jour cela le cas échéant.
>>>> 
>>>> Matt
>> 
>> Dropping OP.  I can't speak to new tarballs. I know nothing of what Apple wants.  When I read about notorization however, I wondered if Apple would  be able to handle the scripts "EPSON Utility...", uninstall-gutenpring.command, and possibly the libusb.bottle-sierra.tar.gz.  Those executables cannot be signed.  Does Apple look at those too or do they only look at the installer package?
> 
> I remember years ago that there was something, I think it was called
> "ports" or the like, that provided a lot of FOSS stuff for Macs.  Is
> that still around?  If so, what are they doing?
> -- 
> Robert Krawitz                                     <rl...@al...>
> 
> ***  MIT Engineers   A Proud Tradition   http://mitathletics.com  ***
> Member of the League for Programming Freedom  --  http://ProgFree.org
> Project lead for Gutenprint   --    http://gimp-print.sourceforge.net
> 
> "Linux doesn't dictate how I work, I dictate how Linux works."
> --Eric Crampton
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] Imprimante Epson

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

They will be signed. There are hoops to jump through though. In particular they have to be placed in a different location. 

Steve Letter
Sent from my Commodore PET

> On Dec 8, 2019, at 2:48 PM, Matt Broughton <wal...@ma...> wrote:
> 
> 
> 
>> On Dec 8, 2019, at 1:36 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote:
>> 
>> As for an update, I hardened the missed files as the bot told me to and resubmitted. I am contacting support because the answer back makes no sense. I worked on submitting all day yesterday and my submission was not accepted. It kept complaining that I wasn’t  doing something that I was doing. (Including an Id for tracking)
>> 
>> I didn’t check, is there a new tarballs for me to build?
>> 
>> Steve Letter
>> Sent from my Commodore PET
>> 
>>>> On Dec 8, 2019, at 12:15 PM, Matt Broughton <wal...@ma...> wrote:
>>> 
>>> 
>>> 
>>>> On Dec 8, 2019, at 9:04 AM, Henri Menot via Gimp-print-devel <gim...@li...> wrote:
>>>> 
>>>>  Guten Print est ‘il mise à jour pour Mac osx 10.15 ?
>>> 
>>> The Gutenprint installers do not work on macos 10.5 Catalina. The Gutenprint team is aware of the problem and are working on a solution. Gutenprint does not have a timeline for resolution at this time. We will update this as appropriate.
>>> 
>>> Translation by Google:
>>> Les programmes d'installation de Gutenprint ne fonctionnent pas sur macos 10.5 Catalina. L'équipe Gutenprint est consciente du problème et travaille sur une solution. Gutenprint n'a pas de calendrier de résolution pour le moment. Nous mettrons à jour cela le cas échéant.
>>> 
>>> Matt
> 
> Dropping OP.  I can't speak to new tarballs. I know nothing of what Apple wants.  When I read about notorization however, I wondered if Apple would  be able to handle the scripts "EPSON Utility...", uninstall-gutenpring.command, and possibly the libusb.bottle-sierra.tar.gz.  Those executables cannot be signed.  Does Apple look at those too or do they only look at the installer package?
> 
> Matt

Re: [Gimp-print-devel] Imprimante Epson

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

On Sun, 8 Dec 2019 13:48:24 -0600, Matt Broughton wrote:
>
>
>> On Dec 8, 2019, at 1:36 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote:
>> 
>> As for an update, I hardened the missed files as the bot told me to and resubmitted. I am contacting support because the answer back makes no sense. I worked on submitting all day yesterday and my submission was not accepted. It kept complaining that I wasn’t  doing something that I was doing. (Including an Id for tracking)
>> 
>> I didn’t check, is there a new tarballs for me to build?
>> 
>> Steve Letter
>> Sent from my Commodore PET
>> 
>>> On Dec 8, 2019, at 12:15 PM, Matt Broughton <wal...@ma...> wrote:
>>> 
>>> 
>>> 
>>>> On Dec 8, 2019, at 9:04 AM, Henri Menot via Gimp-print-devel <gim...@li...> wrote:
>>>> 
>>>>   Guten Print est ‘il mise à jour pour Mac osx 10.15 ?
>>> 
>>> The Gutenprint installers do not work on macos 10.5 Catalina. The Gutenprint team is aware of the problem and are working on a solution. Gutenprint does not have a timeline for resolution at this time. We will update this as appropriate.
>>> 
>>> Translation by Google:
>>> Les programmes d'installation de Gutenprint ne fonctionnent pas sur macos 10.5 Catalina. L'équipe Gutenprint est consciente du problème et travaille sur une solution. Gutenprint n'a pas de calendrier de résolution pour le moment. Nous mettrons à jour cela le cas échéant.
>>> 
>>> Matt
>
> Dropping OP.  I can't speak to new tarballs. I know nothing of what Apple wants.  When I read about notorization however, I wondered if Apple would  be able to handle the scripts "EPSON Utility...", uninstall-gutenpring.command, and possibly the libusb.bottle-sierra.tar.gz.  Those executables cannot be signed.  Does Apple look at those too or do they only look at the installer package?

I remember years ago that there was something, I think it was called
"ports" or the like, that provided a lot of FOSS stuff for Macs.  Is
that still around?  If so, what are they doing?
-- 
Robert Krawitz                                     <rl...@al...>

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

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

Re: [Gimp-print-devel] Imprimante Epson

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

> On Dec 8, 2019, at 1:36 PM, Steve Letter via Gimp-print-devel <gim...@li...> wrote:
> 
> As for an update, I hardened the missed files as the bot told me to and resubmitted. I am contacting support because the answer back makes no sense. I worked on submitting all day yesterday and my submission was not accepted. It kept complaining that I wasn’t  doing something that I was doing. (Including an Id for tracking)
> 
> I didn’t check, is there a new tarballs for me to build?
> 
> Steve Letter
> Sent from my Commodore PET
> 
>> On Dec 8, 2019, at 12:15 PM, Matt Broughton <wal...@ma...> wrote:
>> 
>> 
>> 
>>> On Dec 8, 2019, at 9:04 AM, Henri Menot via Gimp-print-devel <gim...@li...> wrote:
>>> 
>>>   Guten Print est ‘il mise à jour pour Mac osx 10.15 ?
>> 
>> The Gutenprint installers do not work on macos 10.5 Catalina. The Gutenprint team is aware of the problem and are working on a solution. Gutenprint does not have a timeline for resolution at this time. We will update this as appropriate.
>> 
>> Translation by Google:
>> Les programmes d'installation de Gutenprint ne fonctionnent pas sur macos 10.5 Catalina. L'équipe Gutenprint est consciente du problème et travaille sur une solution. Gutenprint n'a pas de calendrier de résolution pour le moment. Nous mettrons à jour cela le cas échéant.
>> 
>> Matt

Dropping OP.  I can't speak to new tarballs. I know nothing of what Apple wants.  When I read about notorization however, I wondered if Apple would  be able to handle the scripts "EPSON Utility...", uninstall-gutenpring.command, and possibly the libusb.bottle-sierra.tar.gz.  Those executables cannot be signed.  Does Apple look at those too or do they only look at the installer package?

Matt

Re: [Gimp-print-devel] Imprimante Epson

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

As for an update, I hardened the missed files as the bot told me to and resubmitted. I am contacting support because the answer back makes no sense. I worked on submitting all day yesterday and my submission was not accepted. It kept complaining that I wasn’t  doing something that I was doing. (Including an Id for tracking)

I didn’t check, is there a new tarballs for me to build?

Steve Letter
Sent from my Commodore PET

> On Dec 8, 2019, at 12:15 PM, Matt Broughton <wal...@ma...> wrote:
> 
> 
> 
>> On Dec 8, 2019, at 9:04 AM, Henri Menot via Gimp-print-devel <gim...@li...> wrote:
>> 
>>    Guten Print est ‘il mise à jour pour Mac osx 10.15 ?
> 
> The Gutenprint installers do not work on macos 10.5 Catalina. The Gutenprint team is aware of the problem and are working on a solution. Gutenprint does not have a timeline for resolution at this time. We will update this as appropriate.
> 
> Translation by Google:
> Les programmes d'installation de Gutenprint ne fonctionnent pas sur macos 10.5 Catalina. L'équipe Gutenprint est consciente du problème et travaille sur une solution. Gutenprint n'a pas de calendrier de résolution pour le moment. Nous mettrons à jour cela le cas échéant.
> 
> Matt
> 
> 
> 
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

Re: [Gimp-print-devel] Imprimante Epson

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

> On Dec 8, 2019, at 9:04 AM, Henri Menot via Gimp-print-devel <gim...@li...> wrote:
> 
> 	Guten Print est ‘il mise à jour pour Mac osx 10.15 ?

The Gutenprint installers do not work on macos 10.5 Catalina. The Gutenprint team is aware of the problem and are working on a solution. Gutenprint does not have a timeline for resolution at this time. We will update this as appropriate.

Translation by Google:
Les programmes d'installation de Gutenprint ne fonctionnent pas sur macos 10.5 Catalina. L'équipe Gutenprint est consciente du problème et travaille sur une solution. Gutenprint n'a pas de calendrier de résolution pour le moment. Nous mettrons à jour cela le cas échéant.

Matt

Re: [Gimp-print-devel] 'make check' failing due to RU translation

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

On Fri, 6 Dec 2019 19:30:33 -0500, Solomon Peachy wrote:
> On Fri, Dec 06, 2019 at 07:07:42PM -0500, Robert Krawitz wrote:
>> I'm doing that as I find them.  Unfortunately, email to the maintainer
>> of the Ukrainian translation bounced, and I know there's at least one
>> string in the Finnish translation that's bad.
>
> I take it it's been a while since you synchronzied translations?

OK, thanks to Pavlo Marinov's hard work, everything's finally fixed.

I also fixed some problems in the test itself having to do with
parallelization and cleaning up warnings that cannot entirely be
suppressed without postprocessing.
-- 
Robert Krawitz                                     <rl...@al...>

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

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

[Gimp-print-devel] Imprimante Epson

[Henri M. <dur...@ic...>]

	Guten Print est ‘il mise à jour pour Mac osx 10.15 ?

	Merci de votre réponse.

Re: [Gimp-print-devel] 'make check' failing due to RU translation

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

On Fri, 6 Dec 2019 19:30:33 -0500, Solomon Peachy wrote:
> On Fri, Dec 06, 2019 at 07:07:42PM -0500, Robert Krawitz wrote:
>> I'm doing that as I find them.  Unfortunately, email to the maintainer
>> of the Ukrainian translation bounced, and I know there's at least one
>> string in the Finnish translation that's bad.
>
> I take it it's been a while since you synchronzied translations?

Yes, but it might also be the newest version of cupstestppd (in 2.2.7)
that's more finicky.  I'm switching it to the -r (relaxed) mode which
turns off things that I presume CUPS can handle, which solves a lot of
the problems.

>> Another possibility would be to check that the translation strings fit
>> and to not translate messages that don't.  That has its own problems,
>> but it might be one way to save the day.  But we'd definitely need to
>> keep a list of the problems.
>
> This sounds sane, especially since this can be easily isolated to the 
> cups code and its private stp_i18n_lookup() code.. (I wonder if it will 
> break anything to emit WARNINGs out stderr when we hit these at 
> runtime?)

It's a bit harder than it sounds, because some of the strings are
composite (most of the Fine Adjustment ones are combinations of some
other option and Fine Adjustment).  Anyway, with relaxed mode I just
have about 7 or 8 that are causing a problem, all in the Russian
translation which was very recently updated.

>> There's no point in going there.  They want to get rid of PPD files
>> altogether.  I'm all for *that*, but in the meantime we have to keep
>> things working, and as you say, there's the compatibility issue.
>
> Yeah, my ticket got closed almost immediately.  :)

I think that this point Mike wouldn't fix anything short of a security
hole in the PPD code, and I really can't say I disagree with him on
that.

> (Meanwhile, I'm still chipping away at stuff in the backend in an 
>  attempt to make it amenable to daemonization.  This brave new printer 
>  application has to start somewhere...)

Not to mention the plethora of system control frameworks out there.
systemd may be the most common standard for user-focused Linux
distributions, but it's not completely standard even there (look at
the battle taking place in Debian).  Then we have other UNIX versions
including MacOS, the possibility that some embedded Linux
distributions for use in routers (which might also be print servers)
might not be using systemd at all.
-- 
Robert Krawitz                                     <rl...@al...>

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

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

Re: [Gimp-print-devel] 'make check' failing due to RU translation

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

On Fri, Dec 06, 2019 at 07:07:42PM -0500, Robert Krawitz wrote:
> I'm doing that as I find them.  Unfortunately, email to the maintainer
> of the Ukrainian translation bounced, and I know there's at least one
> string in the Finnish translation that's bad.

I take it it's been a while since you synchronzied translations?

> Another possibility would be to check that the translation strings fit
> and to not translate messages that don't.  That has its own problems,
> but it might be one way to save the day.  But we'd definitely need to
> keep a list of the problems.

This sounds sane, especially since this can be easily isolated to the 
cups code and its private stp_i18n_lookup() code.. (I wonder if it will 
break anything to emit WARNINGs out stderr when we hit these at 
runtime?)

> There's no point in going there.  They want to get rid of PPD files
> altogether.  I'm all for *that*, but in the meantime we have to keep
> things working, and as you say, there's the compatibility issue.

Yeah, my ticket got closed almost immediately.  :)

(Meanwhile, I'm still chipping away at stuff in the backend in an 
 attempt to make it amenable to daemonization.  This brave new printer 
 application has to start somewhere...)

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

Re: [Gimp-print-devel] 'make check' failing due to RU translation

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

On Thu, 5 Dec 2019 11:33:53 -0500, Solomon Peachy wrote:
> On Wed, Dec 04, 2019 at 08:08:48AM -0500, Robert Krawitz wrote:
>> I saw.  I discussed it with the Russian team, but it's not very
>> apparent why it looks like only the Russian translation has this
>> problem, or why it's happening at all.
>
> So far I've found four strings that trigger errors, because their UTF-8 
> character sequences take up over 80 bytes:
>
>   Japanese Western-style envelope #4 landscape  (50c/88b)
>   Japanese Western-style envelope #6 landscape  (50c/88b)
>   Shrink (print the whole page)                 (47c/88b)
>   Expand (use maximum page area)                (61c/115b)

And there's another problem here -- the synthesized fine adjustment
options.  Those names never appear in full anywhere; we just glom them
together with a space in between.
-- 
Robert Krawitz                                     <rl...@al...>

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

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

Re: [Gimp-print-devel] 'make check' failing due to RU translation

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

On Thu, 5 Dec 2019 11:33:53 -0500, Solomon Peachy wrote:
> On Wed, Dec 04, 2019 at 08:08:48AM -0500, Robert Krawitz wrote:
>> I saw.  I discussed it with the Russian team, but it's not very
>> apparent why it looks like only the Russian translation has this
>> problem, or why it's happening at all.
>
> So far I've found four strings that trigger errors, because their UTF-8 
> character sequences take up over 80 bytes:
>
>   Japanese Western-style envelope #4 landscape  (50c/88b)
>   Japanese Western-style envelope #6 landscape  (50c/88b)
>   Shrink (print the whole page)                 (47c/88b)
>   Expand (use maximum page area)                (61c/115b)

There are a lot more than that.  I tried writing a .po file scanner.
Aside from the fact that there's a lot of noise (help strings and
such), it's still very easy to miss something in the exception rules.

> IMO the most prudent path forwared is to ask the translators to shrink 
> these down under 80 bytes.

I'm doing that as I find them.  Unfortunately, email to the maintainer
of the Ukrainian translation bounced, and I know there's at least one
string in the Finnish translation that's bad.

Another possibility would be to check that the translation strings fit
and to not translate messages that don't.  That has its own problems,
but it might be one way to save the day.  But we'd definitely need to
keep a list of the problems.

> I don't know if it's worth writing a test to scrub the translations for 
> max length, as these limits only apply to stuff that land in PPD 
> files, and the existing PPD tests catch them (albeit ineffeciently).

"Inefficiently" is putting it rather too mildly.  cupstestppd does
have a number of flags, but some warnings (like page size tags not
matching the standards) can't be turned off in at least the version I
have.  I was thinking of vendoring it in, but it uses all kinds of
private interfaces, and the really big problem is that the routine to
open a PPD file barfs if there are certain errors (including -- you
guessed it -- too long strings) and just reports the first thing.

> I've opened a CUPS bug ticket to ask about the feasiblity of rasing the 
> limit to something larger than 80 bytes, but that won't help with 
> existing CUPS deployments...

There's no point in going there.  They want to get rid of PPD files
altogether.  I'm all for *that*, but in the meantime we have to keep
things working, and as you say, there's the compatibility issue.
-- 
Robert Krawitz                                     <rl...@al...>

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

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

Re: [Gimp-print-devel] 'make check' failing due to RU translation

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

On Thu, 5 Dec 2019 11:02:27 -0500, Solomon Peachy wrote:
> On Thu, Dec 05, 2019 at 10:14:18AM +0100, Johannes Meixner wrote:
>> > I think the only sane short-term approach is to adopt a policy to keep
>> > all translated strings under 80 bytes.
>> 
>> Careful with truncating UTF-8 strings!
>
> Yeah, I'm well aware of the consequences of dumb truncation resulting in 
> invalid UTF-8 sequences.  :)
>
> IMO truncation is the wrong approach anyway, as the stuff truncated 
> might be all that distinguishes one string from another...

I've asked the translators of the languages in question to shorten the
translations.

If worst comes to worst, I suppose we could code genppd to not emit
the translations if they exceed 80 bytes.  Hopefully the translators
will take care of it.
-- 
Robert Krawitz                                     <rl...@al...>

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

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

Re: [Gimp-print-devel] 'make check' failing due to RU translation

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

On Thu, 5 Dec 2019 11:33:53 -0500, Solomon Peachy wrote:
>
> --===============2212316881524675934==
> Content-Type: multipart/signed; micalg=pgp-sha1;
> 	protocol="application/pgp-signature"; boundary="i3lJ51RuaGWuFYNw"
> Content-Disposition: inline
>
> --i3lJ51RuaGWuFYNw
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Wed, Dec 04, 2019 at 08:08:48AM -0500, Robert Krawitz wrote:
>> I saw.  I discussed it with the Russian team, but it's not very
>> apparent why it looks like only the Russian translation has this
>> problem, or why it's happening at all.
>
> So far I've found four strings that trigger errors, because their UTF-8 
> character sequences take up over 80 bytes:
>
>   Japanese Western-style envelope #4 landscape  (50c/88b)
>   Japanese Western-style envelope #6 landscape  (50c/88b)
>   Shrink (print the whole page)                 (47c/88b)
>   Expand (use maximum page area)                (61c/115b)
>
> IMO the most prudent path forwared is to ask the translators to shrink 
> these down under 80 bytes.
>
> I don't know if it's worth writing a test to scrub the translations for 
> max length, as these limits only apply to stuff that land in PPD 
> files, and the existing PPD tests catch them (albeit ineffeciently).
>
> I've opened a CUPS bug ticket to ask about the feasiblity of rasing the 
> limit to something larger than 80 bytes, but that won't help with 
> existing CUPS deployments...

I've found the following exceptions, all in the Russian and Ukrainian
translations:

Bad translation 'Hextone Gray 5 Density Scale' in ru.po at src/main/print-escp2.c:802: 85 / 46 bytes
Bad translation 'Hextone Gray 4 Density Scale' in ru.po at src/main/print-escp2.c:826 src/main/print-escp2.c:827: 85 / 46 bytes
Bad translation 'Hextone Gray 3 Density Scale' in ru.po at src/main/print-escp2.c:850 src/main/print-escp2.c:851: 85 / 46 bytes
Bad translation 'Hextone Gray 2 Density Scale' in ru.po at src/main/print-escp2.c:874 src/main/print-escp2.c:875: 85 / 46 bytes
Bad translation 'Hextone Gray 1 Density Scale' in ru.po at src/main/print-escp2.c:898: 85 / 46 bytes
Bad translation 'Minimum Drying Time Per Scan' in ru.po at src/main/print-escp2.c:954: 85 / 44 bytes
Bad translation 'Printer Generates Copies Natively' in ru.po at src/main/print-dyesub.c:10368 src/main/print-pcl.c:1616: 97 / 51 bytes
Bad translation 'Expand (use maximum page area)' in ru.po at src/cups/genppd.c:1651 src/cups/genppd.c:1923: 116 / 61 bytes
Bad translation 'Roll Feed (borderless with single cut)' in ru.po at src/xml/xmli18n-tmp.h:815: 83 / 45 bytes
Bad translation 'Premium Presentation Paper Matte' in ru.po at src/xml/xmli18n-tmp.h:2035: 84 / 44 bytes
Bad translation 'Premium Semigloss Photo Paper' in ru.po at src/xml/xmli18n-tmp.h:2787: 104 / 54 bytes
Bad translation 'Premium Glossy Photo Paper 170 wt' in ru.po at src/xml/xmli18n-tmp.h:1873: 86 / 48 bytes
Bad translation 'Premium Glossy Photo Paper 250 wt' in ru.po at src/xml/xmli18n-tmp.h:1874: 86 / 48 bytes
Bad translation 'Japanese Western-style envelope #4 landscape' in ru.po at src/xml/xmli18n-tmp.h:3104: 89 / 48 bytes
Bad translation 'Japanese Western-style envelope #6 landscape' in ru.po at src/xml/xmli18n-tmp.h:3106: 89 / 48 bytes
Bad translation 'Generic PCL 6 Tabl Printer wide margin' in ru.po at src/xml/xmli18n-tmp.h:5298: 103 / 57 bytes
Bad translation 'Generic PCL Color wide margin' in ru.po at src/xml/xmli18n-tmp.h:5301: 87 / 48 bytes
Bad translation 'Generic PCL Color LF wide margin' in ru.po at src/xml/xmli18n-tmp.h:5302: 91 / 52 bytes
Bad translation 'Generic PCL Color Tabl wide margin' in ru.po at src/xml/xmli18n-tmp.h:5303: 117 / 64 bytes
Bad translation 'Printer Image Lightness Adjustment' in uk.po at src/main/print-dyesub.c:1864: 83 / 43 bytes
Bad translation 'Printer Image Advance Adjustment' in uk.po at src/main/print-dyesub.c:1870: 81 / 42 bytes
Bad translation 'One Color Raw Enhanced Gloss' in uk.po at src/xml/xmli18n-tmp.h:137 src/xml/xmli18n-tmp.h:159: 84 / 43 bytes
Bad translation 'Six Color Enhanced Gloss Raw' in uk.po at src/xml/xmli18n-tmp.h:141 src/xml/xmli18n-tmp.h:163: 86 / 44 bytes
Bad translation 'Seven Color Enhanced Gloss Raw' in uk.po at src/xml/xmli18n-tmp.h:142 src/xml/xmli18n-tmp.h:164: 84 / 43 bytes
Bad translation 'Premium Semigloss Photo Paper 170 wt' in uk.po at src/xml/xmli18n-tmp.h:1877: 81 / 44 bytes
Bad translation 'Premium Semigloss Photo Paper 250 wt' in uk.po at src/xml/xmli18n-tmp.h:1878: 81 / 44 bytes

-- 
Robert Krawitz                                     <rl...@al...>

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

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

Re: [Gimp-print-devel] 'make check' failing due to RU translation

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

On Thu, 5 Dec 2019 11:33:53 -0500, Solomon Peachy wrote:
>
> --===============2212316881524675934==
> Content-Type: multipart/signed; micalg=pgp-sha1;
> 	protocol="application/pgp-signature"; boundary="i3lJ51RuaGWuFYNw"
> Content-Disposition: inline
>
> --i3lJ51RuaGWuFYNw
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Wed, Dec 04, 2019 at 08:08:48AM -0500, Robert Krawitz wrote:
>> I saw.  I discussed it with the Russian team, but it's not very
>> apparent why it looks like only the Russian translation has this
>> problem, or why it's happening at all.
>
> So far I've found four strings that trigger errors, because their UTF-8 
> character sequences take up over 80 bytes:
>
>   Japanese Western-style envelope #4 landscape  (50c/88b)
>   Japanese Western-style envelope #6 landscape  (50c/88b)
>   Shrink (print the whole page)                 (47c/88b)
>   Expand (use maximum page area)                (61c/115b)
>
> IMO the most prudent path forwared is to ask the translators to shrink 
> these down under 80 bytes.
>
> I don't know if it's worth writing a test to scrub the translations for 
> max length, as these limits only apply to stuff that land in PPD 
> files, and the existing PPD tests catch them (albeit ineffeciently).
>
> I've opened a CUPS bug ticket to ask about the feasiblity of rasing the 
> limit to something larger than 80 bytes, but that won't help with 
> existing CUPS deployments...

There are a lot more than those four.  At the very least I've found:

Generic PCL 6 Tabl Printer wide margin
Generic PCL Color LF wide margin
Generic PCL Color Tabl wide margin
Generic PCL Color wide margin
Japanese Western-style envelope #4 landscape
Japanese Western-style envelope #6 landscape
One Color Raw Enhanced Gloss
Premium Glossy Photo Paper 170 wt
Premium Glossy Photo Paper 250 wt
Premium Presentation Paper Matte
Premium Semigloss Photo Paper 170 wt
Premium Semigloss Photo Paper 250 wt
Premium Semigloss Photo Paper
Roll Feed (borderless with single cut)
Seven Color Enhanced Gloss Raw
Six Color Enhanced Gloss Raw

-- 
Robert Krawitz                                     <rl...@al...>

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

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

Re: [Gimp-print-devel] 'make check' failing due to RU translation

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

On Wed, Dec 04, 2019 at 08:08:48AM -0500, Robert Krawitz wrote:
> I saw.  I discussed it with the Russian team, but it's not very
> apparent why it looks like only the Russian translation has this
> problem, or why it's happening at all.

So far I've found four strings that trigger errors, because their UTF-8 
character sequences take up over 80 bytes:

  Japanese Western-style envelope #4 landscape  (50c/88b)
  Japanese Western-style envelope #6 landscape  (50c/88b)
  Shrink (print the whole page)                 (47c/88b)
  Expand (use maximum page area)                (61c/115b)

IMO the most prudent path forwared is to ask the translators to shrink 
these down under 80 bytes.

I don't know if it's worth writing a test to scrub the translations for 
max length, as these limits only apply to stuff that land in PPD 
files, and the existing PPD tests catch them (albeit ineffeciently).

I've opened a CUPS bug ticket to ask about the feasiblity of rasing the 
limit to something larger than 80 bytes, but that won't help with 
existing CUPS deployments...

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