Re: cp1254 support for emf term

[Allin C. <cot...@wf...>]

On Wed, 9 Jan 2008, Ethan Merritt wrote:

> I don't think that works.
> According to the encoding tables on Wikipedia, CP1254 uses
> the encoding points 8x and 9x (x = anything from 0 to F) whereas
> iso8859-9 leaves these undefined.   

Yes, CP1254 and iso8859-9 are not identical; the former defines 
certain characters that are left undefined in the latter.

But in the context of emf.term, where we're mapping from these 
encodings onto Microsoft's TURKISH_CHARSET macro, I suppose it's
CP1254 that's "correct" and iso8859-9 that's just an 
approximation.

> I think if you want to treat these two encodings jointly, you 
> need to expand the glyph tables in .../term/PostScript/8859-9.ps 
> to include the ones used by CP1254.

Yes, but I'm assuming (perhaps unwisely) that people handling 
PostScript will be using ISO encodings rather than MS codepage 
stuff.  I'm not sure it's worthwhile to put CP encodings into the 
prologues in term/PostScript, though if somebody wants to do it I 
won't object.

To clarify just a little more: I think it's implicit that just 
because gnuplot recognizes "set encoding foo" as a valid command, 
that doesn't mean that every terminal will make any sense of 
encoding foo (although, within reason, the more terminal types 
that do so, the better).  What I'm suggesting here is that "set 
encoding CP1254" is a setting that, quite defensibly, could be 
acted upon only by emf term.

Allin Cottrell