gnuplot-beta

wxt terminal - questions

[Ethan A M. <merritt@u.washington.edu>]

Two questions

(1) 
I've been poking about in the code, and so far as I can
see the code assumes that character strings passed to Pango
will be interpreted as UTF-8.  E.g. the following comment:

  /* pango needs a string encoded in utf-8. We use g_convert from glib.
   * gp_cairo_get_encoding() gives the encoding set via 'set enconding'
   * memory allocated for enhanced_text_utf8 is freed at the end of 
   * gp_cairo_enhanced_flush */
  string_utf8 = g_convert(string, -1, "UTF-8", gp_cairo_get_encoding(plot), NULL, NULL, NULL);

But this doesn't happen. My machines are normally set to a UTF-8 locale,
and all characters I type into gnuplot are UTF-8 encoded.  
But the multibyte characters are mangled when displayed in the wxt plot window.
The same strings are properly displayed in x11 (when set to multibyte mode)
and in gd (which by default uses UTF-8).  So I know they are correctly
stored inside gnuplot. What's going wrong in wxt?

(2)
I happened across a page of sample plots from another plotting program,
and was struck by how useful transparency can be in some cases.
In particular in the case of overlapping histograms
   http://sourceforge.net/project/screenshots.php?group_id=15494
I think it would be possible to support this in gd.trm and svg.trm,
but I'm not sure about any other terminals.   Do the Cairo graphics
primitives support an alpha channel, so that wxt.trm could use this also?


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: wxt terminal - questions

[Chris K <gnu...@li...>]

Ethan A Merritt wrote:
> Two questions
> 
> (1) 
> I've been poking about in the code, and so far as I can
> see the code assumes that character strings passed to Pango
> will be interpreted as UTF-8.  E.g. the following comment:
> 
>   /* pango needs a string encoded in utf-8. We use g_convert from glib.
>    * gp_cairo_get_encoding() gives the encoding set via 'set enconding'
>    * memory allocated for enhanced_text_utf8 is freed at the end of 
>    * gp_cairo_enhanced_flush */
>   string_utf8 = g_convert(string, -1, "UTF-8", gp_cairo_get_encoding(plot), NULL, NULL, NULL);
> 
> But this doesn't happen. My machines are normally set to a UTF-8 locale,
> and all characters I type into gnuplot are UTF-8 encoded.  
> But the multibyte characters are mangled when displayed in the wxt plot window.
> The same strings are properly displayed in x11 (when set to multibyte mode)
> and in gd (which by default uses UTF-8).  So I know they are correctly
> stored inside gnuplot. What's going wrong in wxt?
> 
> (2)
> I happened across a page of sample plots from another plotting program,
> and was struck by how useful transparency can be in some cases.
> In particular in the case of overlapping histograms
>    http://sourceforge.net/project/screenshots.php?group_id=15494
> I think it would be possible to support this in gd.trm and svg.trm,
> but I'm not sure about any other terminals.   Do the Cairo graphics
> primitives support an alpha channel, so that wxt.trm could use this also?
> 
> 

The filled example here
http://sourceforge.net/project/screenshots.php?group_id=15494&ssid=8404
does look good.

Yes, Cairo is very very happy with RGBA for Alpha channel transparency
information. ( http://cairographics.org/samples/operator_atop.html )

I assume the trick is : how do you specify transparency with gnuplot?

-- 
Chris
#292 http://highclearing.com/index.php/archives/2006/04/07/4991#comment-8388

Re: wxt terminal - questions

[<tim...@en...>]

> Two questions
>
> (1)
> I've been poking about in the code, and so far as I can
> see the code assumes that character strings passed to Pango
> will be interpreted as UTF-8.  E.g. the following comment:
>
>   /* pango needs a string encoded in utf-8. We use g_convert from glib.
>    * gp_cairo_get_encoding() gives the encoding set via 'set enconding'
>    * memory allocated for enhanced_text_utf8 is freed at the end of
>    * gp_cairo_enhanced_flush */
>   string_utf8 =3D g_convert(string, -1, "UTF-8",
> gp_cairo_get_encoding(plot), NULL, NULL, NULL);
>
> But this doesn't happen. My machines are normally set to a UTF-8 locale=
,
> and all characters I type into gnuplot are UTF-8 encoded.
> But the multibyte characters are mangled when displayed in the wxt plot
> window.
> The same strings are properly displayed in x11 (when set to multibyte
> mode)
> and in gd (which by default uses UTF-8).  So I know they are correctly
> stored inside gnuplot. What's going wrong in wxt?

Thanks for digging on this side.

Let me explain how it works currently :
- if the user has used "set encoding ..." where "..." is something
different from "default", the terminal converts from this encoding to utf=
8
- otherwise, it falls back to iso8859-1. That's why the terminal doesn't
show your multibyte-utf8 characters.

I can implement the following :
- if the user has used "set encoding ..." where "..." is something
different from "default", the terminal converts from this encoding to utf=
8
- otherwise, use the 'locale' to determine the input charset, and assume
this is the input encoding for the conversion to utf8.

However, I am still not clear on one thing :
If you launch the demo 'charset.dem' :
- with the current code, the wxt terminal will show all characters as
iso8859-1 encoded.
- with the new code falling back to the 'locale' charset, and if your
locale charset is UTF-8, you won't see the last four lines, as the utf8
specification doesn't allow 8 bits characters where the upper bit is 1
(see http://en.wikipedia.org/wiki/UTF-8 for details on this specification=
)

At the same time, the X11 terminal will show these lines !!! So my
question is : what is the X11 terminal doing ?? Ethan, can you check on
your box ?


>
> (2)
> I happened across a page of sample plots from another plotting program,
> and was struck by how useful transparency can be in some cases.
> In particular in the case of overlapping histograms
>    http://sourceforge.net/project/screenshots.php?group_id=3D15494
> I think it would be possible to support this in gd.trm and svg.trm,
> but I'm not sure about any other terminals.   Do the Cairo graphics
> primitives support an alpha channel, so that wxt.trm could use this als=
o?
>

Chris has already answered, and I can only confirm. Cairo has definetely
been designed with alpha transparency in mind.


Regards,

Timoth=E9e

Re: wxt terminal - questions

[Ethan A M. <merritt@u.washington.edu>]

On Sunday 16 April 2006 08:35 pm, Timoth=C3=A9e Lecomte wrote:

> I can implement the following :
> - if the user has used "set encoding ..." where "..." is something
> different from "default", the terminal converts from this encoding to utf8
> - otherwise, use the 'locale' to determine the input charset, and assume
> this is the input encoding for the conversion to utf8.

Or at the least, if 'locale' reports any flavor of utf8 then do not do
any conversion.

> However, I am still not clear on one thing :
> If you launch the demo 'charset.dem' :
> - with the current code, the wxt terminal will show all characters as
> iso8859-1 encoded.

Correct.

> - with the new code falling back to the 'locale' charset, and if your
> locale charset is UTF-8, you won't see the last four lines [upper bit set]
>=20
> At the same time, the X11 terminal will show these lines !!! So my
> question is : what is the X11 terminal doing ??

The X terminal chooses an iso-8859-1 font by default unless you tell
it explicitly to use a multibyte font.  If you say
	set term x11 font "mbfont:verdana"
then as you predict, the last four lines of charset.dem are blank.
However, in this mode it handles utf-8 characters properly.

I should add a "utf8.dem" as well.
Here's a quick version, and a screen shot from=20

    set term x11 font "mbfont:sazanami mincho,vera,20"
    load 'utf8.dem'

> Chris has already answered, and I can only confirm. Cairo has definetely
> been designed with alpha transparency in mind.

Great.  But that's not a project for 4.2.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: wxt terminal - questions

[<tim...@en...>]

> On Sunday 16 April 2006 08:35 pm, Timoth=C3=A9e Lecomte wrote:
>
>> I can implement the following :
>> - if the user has used "set encoding ..." where "..." is something
>> different from "default", the terminal converts from this encoding to
>> utf8
>> - otherwise, use the 'locale' to determine the input charset, and assu=
me
>> this is the input encoding for the conversion to utf8.
>
> Or at the least, if 'locale' reports any flavor of utf8 then do not do
> any conversion.
>
>> However, I am still not clear on one thing :
>> If you launch the demo 'charset.dem' :
>> - with the current code, the wxt terminal will show all characters as
>> iso8859-1 encoded.
>
> Correct.
>
>> - with the new code falling back to the 'locale' charset, and if your
>> locale charset is UTF-8, you won't see the last four lines [upper bit
>> set]
>>
>> At the same time, the X11 terminal will show these lines !!! So my
>> question is : what is the X11 terminal doing ??
>
> The X terminal chooses an iso-8859-1 font by default unless you tell
> it explicitly to use a multibyte font.  If you say
> 	set term x11 font "mbfont:verdana"
> then as you predict, the last four lines of charset.dem are blank.
> However, in this mode it handles utf-8 characters properly.

Ok, I understand.

I have implemented the behaviour described above : using the locale to
determine the charset. I just added one other detail : when using the
Symbol font, the terminal will assume you're using iso_8859_1, because
you'll have to use non-utf8 characters. For example, in the demo, the
integral character in \362, which is not a valid utf8 character. If the
terminal tries to read the string in utf8, it would fail here and would
not draw this character.

>
> I should add a "utf8.dem" as well.

Good idea !

Re: wxt terminal - questions

[Ethan M. <merritt@u.washington.edu>]

On Monday 17 April 2006 09:11 am, Timoth=E9e Lecomte wrote:

> I have implemented the behaviour described above : using the locale to
> determine the charset.=20


> I just added one other detail : when using the=20
> Symbol font, the terminal will assume you're using iso_8859_1, because
> you'll have to use non-utf8 characters.

What is "the" Symbol font, in this case? =20

The Adobe "Symbol" font, which is what most of the other drivers find by
default, is not an iso8859-1 encoding.  It is "Adobe-specific", which
causes headaches with libgd and libfreetype. =20

The Microsoft "symbol.ttf" font, on the other hand, claims to be encoding
"microsoft-symbol".

The symbol font entries in the screenshot I sent yesterday were
actual UTF-8 encoded characters.

I am uncertain how all of this will play out in practice when I'm
typing from the terminal, or running a gnuplot script.  But I guess
we'll find out.


> For example, in the demo, the=20
> integral character in \362, which is not a valid utf8 character. If the
> terminal tries to read the string in utf8, it would fail here and would
> not draw this character.

Ah. I see. So you're thinking about character data entered as octal
constants, as in charset.dem.   OK, I suppose if the user intends some
particular encoding for octal data, he should give an explicit=20
"set encoding <foo>".  Failing that, iso8859-1   (or 8859-15) is as
good a default as any.



=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA