[Suppress-Script] Initial list of 300 languages

[McDonald, Ira]

Hi Peter,

Nothing at ALL to do with PostScript or any other printer
definition language - it's about EXTERNAL tagging of
languages for existing or new documents sent to printers.

Please see my reply in a moment to Randy.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com

> -----Original Message-----
> From: ietf-languages-bounces at alvestrand.no
> [mailto:ietf-languages-bounces at alvestrand.no]On Behalf Of Peter
> Constable
> Sent: Saturday, March 11, 2006 2:31 PM
> To: ietf-languages at iana.org
> Subject: RE: [Suppress-Script] Initial list of 300 languages 
> 
> 
> > From: ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-
> > bounces at alvestrand.no] On Behalf Of McDonald, Ira
> 
> 
> > No network printer now in existence currently supports 'script'
> > subtags.  If you send a document (e.g., PostScript) to a network
> > printer with an external language tag of 'en-Latn-US' (e.g., in
> > the IPP 'document-natural-language' attribute), you're going to be
> > sadly surprised to have it rejected entirely or else rendered per
> > that printer's default natural language (e.g., 'ru', Russian),
> > that is to say with some very odd-looking glyphs.
> 
> While I don't disagree with the general concern, I don't 
> understand this particular evidence. 
> 
> (This might turn into a tangential discussion about the 
> Postscript language, of which I admit I know little; if so, I 
> don't intend a long digression.) 
> 
> I wasn't aware that there were network printers that knew 
> anything about tags like "en-US". Looking at the Postscript 
> Supplement documentation, I find that localization resources 
> contain entries in which language and country are recorded as 
> separate data categories, as in these examples from p. 72:
> 
> << /Language /EN
>    /Country /US
>    /CharSet /ISO-646-ISV
> >>
> 
> << /Language /JA
>    /Country null
>    /CharSet /JIS-...
> >>
> 
> The doc'n does go on to indicate (implicitly stated by 
> example) that the two can be combined in a localization 
> resource name, but also that this is not required:
> 
> <quote>
> Each Localization instance has a unique name. Although no 
> specific naming
> scheme is enforced, the following guidelines are recommended:
> 
> * Instances can be named by concatenating the values of the 
> three dictionary 
>   entries, separated by hyphens. For example, the two 
> instances shown above 
>   would be named
> 
>      /EN-US-ISO-646-ISV
> 
>   and
> 
>      /JA-JIS-...
> 
>   respectively. This approach yields a name indicative of the 
> dictionary's 
>   contents.
> 
> * An alternative is to provide descriptive names for the 
> instances. For 
>   example, the two instances shown above might be named
> 
>      /AmericanEnglish
> 
>   and
> 
>      /Japanese
> </quote>
> 
> It seems to me, then, that a resource name "/EN-LATN-US" 
> would be syntactically conformant, even if not explicitly 
> recommended, since no naming scheme is enforced. Thus, the 
> following ought to work:
> 
> (%Console%)
> /EN-LATN-US /Localization findresource
> setdevparams
> 
> 
> If I'm missing something, please clarify.
> 
> Peter Constable
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>