[Printing-architecture] [Gimp-print-devel] Common Printing Dialog: PPD extension specs updated
Till Kamppeter
till.kamppeter at gmail.com
Mon Aug 4 15:41:49 PDT 2008
Roger Leigh wrote:
> Well, the problem here is simple. The program fails as expected
> because you *don't have a valid locale* for the testcase to use:
>
> // Initial setlocale call must succeed, or else we're still in a C
> // locale, and gettext won't translate at all.
> const char *l1 = setlocale(LC_ALL, "en_GB.ISO-8859-1");
>
> Do you have a valid en_GB.ISO-8859-1 locale? If not, then change this
> to a different locale (e.g. "" to use your en_US locale), or generate
> the locale. To do the test as I requested above however, you *must*
> start off in a non-UTF-8 locale to verify that the UTF-8 transcoding
> is working properly, or else the test is not useful, though it will
> verify we can do lookups while using "invalid" locales.
>
> What results do you get if you fix this?
Now the results are better.
I did
sudo locale-gen en_US.ISO-8859-15
(locale must be listed in /usr/share/i18n/SUPPORTED)
edited gettext-test.c to have a line
const char *l1 = setlocale(LC_ALL, "en_US.ISO-8859-15");
and all the rest like before.
Then I get as screen output:
setlocale1: en_US.ISO-8859-15
setlocale2: (null)
setlocale3: en_US.ISO-8859-15
domain: /home/till/gutenprint/cvs/HEAD/x
codset (null)->UTF-8
selected-domain: gutenprint
lookup: Foto aus fünf Farben gemischt
dlookup: Foto aus fünf Farben gemischt
So in this case translations work and encoding works. st.out is
attached. So this means that the system needs at least one non-C locale
and the PPD generator has to find and select it.
Till
More information about the Printing-architecture
mailing list