[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:
<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
More information about the Ietf-languages
mailing list