gimp-print-devel

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

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

On every PPD that has these PageSizes:

  **FAIL**  Bad UTF-8 "ru" translation string for option PageSize, choice w297h666_l.
  **FAIL**  Bad UTF-8 "ru" translation string for option PageSize, choice w277h538_l.


 - 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 Wed, 4 Dec 2019 06:44:14 -0500, Solomon Peachy wrote:
>
> On every PPD that has these PageSizes:
>
>   **FAIL**  Bad UTF-8 "ru" translation string for option PageSize, choice w297h666_l.
>   **FAIL**  Bad UTF-8 "ru" translation string for option PageSize, choice w277h538_l.

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.

I think it's probably a string length issue, but some of the English
strings themselves look too long.
-- 
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.

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

[Protea W. J. <aik...@gm...>]

On Wed, Dec 4, 2019 at 10:09 PM Robert Krawitz <rl...@al...> wrote:
>
> On Wed, 4 Dec 2019 06:44:14 -0500, Solomon Peachy wrote:
> >
> > On every PPD that has these PageSizes:
> >
> >   **FAIL**  Bad UTF-8 "ru" translation string for option PageSize, choice w297h666_l.
> >   **FAIL**  Bad UTF-8 "ru" translation string for option PageSize, choice w277h538_l.
>
> 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.
>
> I think it's probably a string length issue, but some of the English
> strings themselves look too long.

Could be that one part of the code is calculating or comparing string
length in characters, and another part in bytes?
Any multibyte functions that should be used here (I know this often is
a difficulty in PHP, for example).
Gernot Hassenpflug

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

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

On Wed, Dec 04, 2019 at 11:33:18PM +0900, Protea Wines Japan wrote:
> Could be that one part of the code is calculating or comparing string
> length in characters, and another part in bytes?

Yup, the RU strings tripping the errors are 49 characters taking up 88 
bytes.  CUPS has a hardcoded upper limit of 80 characters for these 
strings.

As an aside, the PPD spec doesn't seem to explicitly mention a limit for 
translation strings (beyond the per-line limit of 255 bytes) so it 
appears that this is a CUPS implementation detail.

If you disable strict conformance checks, CUPS will accept the PPD but 
truncate the string at 80 bytes, possibly resulting in illegal UTF-8.

 - 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

[Protea W. J. <aik...@gm...>]

On Thu, Dec 5, 2019 at 12:35 AM Solomon Peachy <pi...@sh...> wrote:
>
> On Wed, Dec 04, 2019 at 11:33:18PM +0900, Protea Wines Japan wrote:
> > Could be that one part of the code is calculating or comparing string
> > length in characters, and another part in bytes?
>
> Yup, the RU strings tripping the errors are 49 characters taking up 88
> bytes.  CUPS has a hardcoded upper limit of 80 characters for these
> strings.

Ouch .Implied bytes here I guess, if the spec was for 1-byte chars?

> As an aside, the PPD spec doesn't seem to explicitly mention a limit for
> translation strings (beyond the per-line limit of 255 bytes) so it
> appears that this is a CUPS implementation detail.

Yuck.

> If you disable strict conformance checks, CUPS will accept the PPD but
> truncate the string at 80 bytes, possibly resulting in illegal UTF-8.

Yes, nasty. In PHP, he mb_ functions are the solution, online there
are plenty of howto's on cutting off correctly in UTF-8, but messy. I
assume we are talking about C code here? Any chance of some library or
function that can handle cutting off correctly?

Gernot Hassenpflug

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

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

On Thu, Dec 05, 2019 at 12:49:54AM +0900, Protea Wines Japan wrote:
> > Yup, the RU strings tripping the errors are 49 characters taking up 88
> > bytes.  CUPS has a hardcoded upper limit of 80 characters for these
> > strings.

(Bah, even I can't get bytes/characters correct in a single paragraph..)

> Ouch .Implied bytes here I guess, if the spec was for 1-byte chars?

Yeah, the spec just treats them as opaque byte sequences.

> Yes, nasty. In PHP, he mb_ functions are the solution, online there
> are plenty of howto's on cutting off correctly in UTF-8, but messy. I
> assume we are talking about C code here? Any chance of some library or
> function that can handle cutting off correctly?

It's a minor PITA, but when we generate the PPDs we can properly 
truncate the strings based on PPD_MAX_TEXT.

But truncated strings aren't desireable for the user; the bit chopped 
off might be the only part that differs from other strings.

I think the only sane short-term approach is to adopt a policy to keep 
all translated strings under 80 bytes.

 - 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

[Johannes M. <js...@su...>]

Hello,

On Dec 4 11:30 Solomon Peachy wrote (excerpt):
> On Thu, Dec 05, 2019 at 12:49:54AM +0900, Protea Wines Japan wrote:
>>> Yup, the RU strings tripping the errors are 49 characters taking up 88
>>> bytes.  CUPS has a hardcoded upper limit of 80 characters for these
>>> strings.
>
> (Bah, even I can't get bytes/characters correct in a single paragraph..)
>
>> Ouch .Implied bytes here I guess, if the spec was for 1-byte chars?
>
> Yeah, the spec just treats them as opaque byte sequences.
>
>> Yes, nasty. In PHP, he mb_ functions are the solution, online there
>> are plenty of howto's on cutting off correctly in UTF-8, but messy. I
>> assume we are talking about C code here? Any chance of some library or
>> function that can handle cutting off correctly?
>
> It's a minor PITA, but when we generate the PPDs we can properly
> truncate the strings based on PPD_MAX_TEXT.
>
> But truncated strings aren't desireable for the user; the bit chopped
> off might be the only part that differs from other strings.
>
> 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!

Only plain 7-bit ASCII "just works" simple and fail-safe.
Making UTF-8 "just work" is neither simple nor fail-safe
(except "just work" means to "just abort" when there is
  any string that is not a valid UTF-8 byte sequence ;-)

If a truncated string (e.g. in a print job option value)
is no longer a valid UTF-8 byte sequence, CUPS may reject
the whole print job in "strict conformance" mode" or
CUPS may alter invalid values to some arbitrary fallback
in "relaxed conformance" mode so that the job may print
but with different printout result as what was intended.

Cf.
https://github.com/apple/cups/issues/5143
and
https://github.com/apple/cups/issues/5186


Kind Regards
Johannes Meixner
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5 - 90409 Nuernberg - Germany
(HRB 36809, AG Nuernberg) GF: Felix Imendoerffer

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

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

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...

Cheers,

 - 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:
>
> --===============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

[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: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:
> 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

[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 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 Sat, Dec 07, 2019 at 10:37:57AM -0500, Robert Krawitz wrote:
> 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.

Putting aside the system integration implementation details, IMO the fun 
part is the "auto launch upon printer attachment" bit. For printers that 
rely on the dyesub backend, there's a comprehensive list of USB VID/PIDs 
it captures, but how do we arbitrate between multiple printer 
applications that could handle the same printer (eg PCL models supported 
by both hplip and gutenprint?)

Lots of joy coming down the pipe, yes..

 - 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 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