[Suppress-Script] Initial list of 300 languages

Peter Constable petercon at microsoft.com
Sat Mar 11 20:30:52 CET 2006

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

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




  respectively. This approach yields a name indicative of the dictionary's 

* An alternative is to provide descriptive names for the instances. For 
  example, the two instances shown above might be named




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:

/EN-LATN-US /Localization findresource

If I'm missing something, please clarify.

Peter Constable

More information about the Ietf-languages mailing list