Re: pm3d for emf terminal and point types

[Dr. J. Z. <joh...@ze...>]

On Sat, Dec 09, 2006 at 09:37:51PM +0100, Johannes Zellner wrote:
> On Thu, Dec 07, 2006 at 09:26:17AM -0800, Ethan Merritt wrote:
> > On Thursday 07 December 2006 03:42 am, Dr. Johannes Zellner wrote:
> > >
> > > - I just implemented pm3d for emf which was really easy, as
> > > everything was already prepared.
> > > - I implemented for the emf terminal the point types as suggested in
> > >   term/README.
> > >
> > > is it ok to commit these changes to CVS?
> > 
> > Sound good to me.
> > 
> > Do you understand emf well enough to add enhanced text mode
> > support as well?  I have never found decent emf documentation,
> > and so have not been able to figure out how to trigger some
> > of the necessary operations.
> > 
> > Another item on my emf wishlist is allowing UTF-8 character sets.
> > If I understand the comments in the code correctly, it used to
> > allow this but someone decided to revert it to handle single byte
> > encodings only.  It's not clear to me whether this was intended
> > to fix a known problem, or was done for some other reason.
> 
> I don't understand emf at all ;-)
> But I was smart enough to understand the existing code in emf.trm.
> 
> UTF-8 would be nice IMHO as well as some sort of enhanced text.
> I found
> 
>     http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dnargdi/html/msdn_enhmeta.asp
> 
> a 13 year old techical article from microsoft. Maybe the file emfwr.cxx
> from openoffice could also serve as documentation of the format. I will
> very likely not have the time to do any coding myself.

well, I had a quick look at unicode for emf. Apparently emf can only do
UTF-16 (little endian). Implementing this is really easy when using
iconv to convert to UTF-16LE. The drawbacks are:

1. will loose some characters, e.g. when converting UTF-8 to UTF-16.

2. would it work on windows? The manual page for iconv says that it
conforms to POSIX.1-2001.

3. needs some option to tell the emf driver which conversion should took
place, e.g. something like

    set term emf unicode recodefrom "UTF-8"

which switches on UTF-16LE emf output and and should recode strings from
UTF-8 to UTF-16LE.

This gives me the idea of rather having a terminal independent recode
option like

    set recode "from encoding" "to encoding"

which recodes all strings before passing them to the terminal driver.
This would make it possible to have an encoding in the gnuplot input
file which is different from what is expected by the terminal driver.
In the emf case, the sequence of commands could then look like this:

a) for writing a 16 bit UTF-16LE emf file (input file is UTF-8 encoded):

    set recode "UTF-8" "UTF-16LE"
    set term emf unicode # turn on 16 bit UTF-16 for emf

b) for writing a 8 bit latin1 emf file (input file is UTF-8 encoded):

    set recode "UTF-8" "LATIN1"
    set term emf nounicode # turn OFF unicode --> write 1-byte iso-latin1

c) and using the same UTF-8 input file for postscript:

    set recode "UTF-8" "LATIN1"
    set term post # which doesn't handle UTF-8

Any comments?

-- 
Johannes