gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Plot failure: "Visible pixel grid has a scan line longer than previous scan lines"

[Ethan A M. <me...@uw...>]

On Monday, 29 June 2020 16:37:12 PDT Dima Kogan wrote:
> Can somebody tell me what this means?
> 
> I'm plotting a grid of data as an image. And I have two identical plot
> commands, differing only in the data being plotted (attached). One
> works, and the other doesn't, throwing the error in the subject. Does
> anybody know what this means? It should work...

I have no idea what is happening.

"with image pixels" makes it work.
set xrange [0:4000] also makes it work.
But the two images show a different cbrange, which is worrisome.

	Ethan

Plot failure: "Visible pixel grid has a scan line longer than previous scan lines"

[Dima K. <gn...@di...>]

Can somebody tell me what this means?

I'm plotting a grid of data as an image. And I have two identical plot
commands, differing only in the data being plotted (attached). One
works, and the other doesn't, throwing the error in the subject. Does
anybody know what this means? It should work...

Re: Cloning errors - SOLVED

[Dima K. <gn...@di...>]

Ethan A Merritt <me...@uw...> writes:

> On Saturday, 27 June 2020 11:55:25 PDT Dima Kogan wrote:
>
>> From git's point of view this new master branch would be a fork that has
>> branched off at the time of the date fix: in 2006.
>
> What state would that leave the 5.2 and 5.4 stable branches in,
> that split off after 2006?  Do they see the same fix?
> Does the branch structure even survive?

Each git commit has a hash (a long hex sequence) that is used to
uniquely refer to it. A branch or a tag is just a convenient alias to a
specific hash.

If we go back to fix the date, then that commit gets a new hash AND ALL
DOWNSTREAM COMMITS get a new hash too. I.e. we made a fork. The original
hashes that we had before the fix are still there: the filter-branch
command creates a new sequence of commits, without deleting the old
ones.

What we do with that new sequences of commits is up to us. Since
branches are aliases to existing hashes, by creating a new sequence of
commits with a fixed date we haven't actually changed anything about
existing branches or tags. Each branch or tag we want to fix would need
to be fixed with filter-branch and then force-pushed to the server
(because this wouldn't be the usual append-only push). Probably the best
bet would be to leave all the old tags and branches alone, and to only
fix the under-development master branch. But that's a choice we make.


> Yeah, I don't think this particular glitch warrants a fork. I don't
> really see why a date typo is any worse than any other typo in the
> commit message - the structure and sequence of the commit chain is not
> affected.

I think I agree. It doesn't sound like many people are experiencing this
failure.

Re: Cloning errors - SOLVED

[Ethan A M. <me...@uw...>]

On Saturday, 27 June 2020 11:55:25 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> 
> >> It isn't particularly difficult to fix this for the master branch,
> >> but since this would be a history rewrite, the resulting tree would
> >> be a fork, effectively. There aren't a ton of people committing to
> >> this repo, so fixing it wouldn't be too disruptive. Strong feelings
> >> either way?
> >
> > Really? It's fixable? I thought you guys all told me it was basically
> > impossible to edit a commit log entry deep in the tree.
> 
> /I/ never told you anything about it :)
> 
> Commits are immutable. A fix would be to edit the offending commits to
> create new commits with a more reasonable date. Then everything in the
> future from those rewritten commits would be replayed to create a new
> master branch that doesn't have the tainted history.
> 
> From git's point of view this new master branch would be a fork that has
> branched off at the time of the date fix: in 2006.

What state would that leave the 5.2 and 5.4 stable branches in,
that split off after 2006?  Do they see the same fix?
Does the branch structure even survive?

> > What's the recipe for doing so?
> 
> "git filter-branch"

Thanks. I will read up on it.
 
> > 
> > FWIW there is at least one other date error in the history. But really
> > there are many places I'd go back to correct typos if it were
> > possible. I think git would be much improved by keeping the commit
> > messages in such a way that they could be edited later without
> > disruption.
> 
> You can go back and change whatever you like, but each time you do that,
> you're making a new fork. In my view it could be justified to fix a
> failure (like the one that started this thread), but not for anything
> else. Even in this case, it's not obviously justified: you need an old
> git and/or i686 AND the failure only shows up if you "git fsck"

Yeah, I don't think this particular glitch warrants a fork.
I don't really see why a date typo is any worse than any other typo
in the commit message - the structure and sequence of the commit
chain is not affected. 

> This is relatively straightforward. I can make a fixed master branch, if
> you'd like to look at it.

I'd rather learn about the process and experiment on my own.
I'm not sure that looking at the result of someone else's fix teaches
me everything needed.

	thanks,
		Ethan

Re: Cloning errors - SOLVED

[Dima K. <gn...@di...>]

Ethan A Merritt <me...@uw...> writes:

>> It isn't particularly difficult to fix this for the master branch,
>> but since this would be a history rewrite, the resulting tree would
>> be a fork, effectively. There aren't a ton of people committing to
>> this repo, so fixing it wouldn't be too disruptive. Strong feelings
>> either way?
>
> Really? It's fixable? I thought you guys all told me it was basically
> impossible to edit a commit log entry deep in the tree.

/I/ never told you anything about it :)

Commits are immutable. A fix would be to edit the offending commits to
create new commits with a more reasonable date. Then everything in the
future from those rewritten commits would be replayed to create a new
master branch that doesn't have the tainted history.

>From git's point of view this new master branch would be a fork that has
branched off at the time of the date fix: in 2006.


> What's the recipe for doing so?

"git filter-branch"

This is relatively straightforward. I can make a fixed master branch, if
you'd like to look at it.


> FWIW there is at least one other date error in the history. But really
> there are many places I'd go back to correct typos if it were
> possible. I think git would be much improved by keeping the commit
> messages in such a way that they could be edited later without
> disruption.

You can go back and change whatever you like, but each time you do that,
you're making a new fork. In my view it could be justified to fix a
failure (like the one that started this thread), but not for anything
else. Even in this case, it's not obviously justified: you need an old
git and/or i686 AND the failure only shows up if you "git fsck"

Re: Cloning errors - SOLVED

[Ethan A M. <me...@uw...>]

On Saturday, 27 June 2020 11:20:40 PDT Dima Kogan wrote:
> Colin Baxter <m4...@ya...> writes:
> 
> > If I comment-out the `fsckObjects = true' setting in my ~/.gitconfig
> > then I can pull the gnuplot repro successfully.
> 
> Ah, I can reproduce it now. Thanks for poking at it, Colin. On an older
> i686 box:
> 
>   $ git fsck
> 
>   Checking object directories: 100% (256/256), done.
>   error in commit f20ad5ffaa212876da3efb6a9a6f1ea3f8082734: badDateOverflow: invalid author/committer line - date causes integer overflow
>   error in commit 3cc239823f5447fdb739014e076463c8da6225dd: badDateOverflow: invalid author/committer line - date causes integer overflow
>   Checking objects: 100% (86573/86573), done.
> 
> Both of these commits are from 2006, but "git log" says "Date: Thu Jan 1
> 00:00:00 1970 +0000". On a more recent amd64 box I don't get "git fsck"
> to complain, but the commits are still there, and their date is more
> interesting: "Date: Sun Jul 27 02:03:19 2206 +0200".
> 
> It isn't particularly difficult to fix this for the master branch, but
> since this would be a history rewrite, the resulting tree would be a
> fork, effectively. There aren't a ton of people committing to this repo,
> so fixing it wouldn't be too disruptive. Strong feelings either way?

Really?   It's fixable?
I thought you guys all told me it was basically impossible to edit a commit log
entry deep in the tree.  What's the recipe for doing so?  

FWIW there is at least one other date error in the history.  But really there are
many places I'd go back to correct typos if it were possible.   I think git would be
much improved by keeping the commit messages in such a way that they could
be edited later without disruption.

	Ethan

Re: Cloning errors - SOLVED

[Dima K. <gn...@di...>]

Colin Baxter <m4...@ya...> writes:

> If I comment-out the `fsckObjects = true' setting in my ~/.gitconfig
> then I can pull the gnuplot repro successfully.

Ah, I can reproduce it now. Thanks for poking at it, Colin. On an older
i686 box:

  $ git fsck

  Checking object directories: 100% (256/256), done.
  error in commit f20ad5ffaa212876da3efb6a9a6f1ea3f8082734: badDateOverflow: invalid author/committer line - date causes integer overflow
  error in commit 3cc239823f5447fdb739014e076463c8da6225dd: badDateOverflow: invalid author/committer line - date causes integer overflow
  Checking objects: 100% (86573/86573), done.

Both of these commits are from 2006, but "git log" says "Date: Thu Jan 1
00:00:00 1970 +0000". On a more recent amd64 box I don't get "git fsck"
to complain, but the commits are still there, and their date is more
interesting: "Date: Sun Jul 27 02:03:19 2206 +0200".

It isn't particularly difficult to fix this for the master branch, but
since this would be a history rewrite, the resulting tree would be a
fork, effectively. There aren't a ton of people committing to this repo,
so fixing it wouldn't be too disruptive. Strong feelings either way?

Re: Cloning errors - SOLVED

[Colin B. <m4...@ya...>]

If I comment-out the `fsckObjects = true' setting in my ~/.gitconfig
then I can pull the gnuplot repro successfully.

Thanks again.

Best wishes,

Colin.



Colin Baxter
URL: http://www.Colin-Baxter.com

Re: Cloning errors

[Colin B. <m4...@ya...>]

Dear Dima,
>>>>> Dima Kogan <gn...@di...> writes:

    > Colin Baxter <m4...@ya...> writes:
    >> The failing command is `git clone
    >> https://git.code.sf.net/p/gnuplot/gnuplot-main <RET>'

    > Hmmm. I tried on an older i686 build of Ubuntu (identical to
    > Debian in most ways), and it works ok. Old-ish git too:

    >   root@ubuntu-s-1vcpu-1gb-nyc1-01:~# dpkg -l git
    > ... 1:2.7.4-0ubuntu1.6 i386

    > We COULD fix the repo, but it's not obviously worth the trouble if
    > this isn't even clearly reproducible. Any theories about what
    > specifically is causing the trouble on your box? It's not the i686
    > or the older git, at least not on their own.

I've installed the latest git (Version 2.27.0) but I get the same
cloning errors. Time allowing, I'll investigate further.

Thank you very much for your help.

Best wishes,

Colin.

 
Colin Baxter
URL: http://www.Colin-Baxter.com

Re: Cloning errors

[Dima K. <gn...@di...>]

Colin Baxter <m4...@ya...> writes:

> The failing command is
> `git clone https://git.code.sf.net/p/gnuplot/gnuplot-main <RET>'

Hmmm. I tried on an older i686 build of Ubuntu (identical to Debian in
most ways), and it works ok. Old-ish git too:

  root@ubuntu-s-1vcpu-1gb-nyc1-01:~# dpkg -l git
  ... 1:2.7.4-0ubuntu1.6 i386

We COULD fix the repo, but it's not obviously worth the trouble if this
isn't even clearly reproducible. Any theories about what specifically is
causing the trouble on your box? It's not the i686 or the older git, at
least not on their own.

Re: Bug in 5.4.rc2

[Ethan A M. <me...@uw...>]

On Friday, 26 June 2020 12:42:04 PDT Dima Kogan wrote:
> The simplest patch is this:
> 
> diff --git a/src/plot2d.c b/src/plot2d.c
> index c81fc2344..a8e598359 100644
> --- a/src/plot2d.c
> +++ b/src/plot2d.c
> @@ -1097,7 +1097,7 @@ get_data(struct curve_points *current_plot)
>  	    coordval major_axis = (j >= 3) ? fabs(v[2]) : 0.0;
>  	    coordval minor_axis = (j >= 4) ? fabs(v[3]) : (j >= 3) ? fabs(v[2]) : 0.0;
>  	    coordval orientation = (j >= 5) ? v[4] : 0.0;
> -	    coordval flag = (major_axis > 0 && minor_axis > 0) ? 0.0 : DEFAULT_RADIUS;
> +	    coordval flag = (j >= 3) ? 0.0 : DEFAULT_RADIUS;
> 
>  	    if (j == 2)	/* FIXME: why not also for j == 3 or 4? */
>  		orientation = default_ellipse.o.ellipse.orientation;
> 
> I.e. we use the default ellipse style only if no axis sizes are given at
> all. If anything is given, we use it. Thoughts?

I think I like the other option better:
	zero means zero
	negative means use default from "set style ellipse"

But I also think you can achieve what you want without changing the code
at all, by setting the default ellipse to have 0 size.
Right?

I'm working on something else at the moment.
I'll get back to this afterwards.

	Ethan

Re: Bug in 5.4.rc2

[Dima K. <gn...@di...>]

The simplest patch is this:

diff --git a/src/plot2d.c b/src/plot2d.c
index c81fc2344..a8e598359 100644
--- a/src/plot2d.c
+++ b/src/plot2d.c
@@ -1097,7 +1097,7 @@ get_data(struct curve_points *current_plot)
 	    coordval major_axis = (j >= 3) ? fabs(v[2]) : 0.0;
 	    coordval minor_axis = (j >= 4) ? fabs(v[3]) : (j >= 3) ? fabs(v[2]) : 0.0;
 	    coordval orientation = (j >= 5) ? v[4] : 0.0;
-	    coordval flag = (major_axis > 0 && minor_axis > 0) ? 0.0 : DEFAULT_RADIUS;
+	    coordval flag = (j >= 3) ? 0.0 : DEFAULT_RADIUS;

 	    if (j == 2)	/* FIXME: why not also for j == 3 or 4? */
 		orientation = default_ellipse.o.ellipse.orientation;

I.e. we use the default ellipse style only if no axis sizes are given at
all. If anything is given, we use it. Thoughts?

Re: Bug in 5.4.rc2

[Dima K. <gn...@di...>]

Ethan A Merritt <me...@uw...> writes:

> On Friday, 26 June 2020 02:21:58 PDT Dima Kogan wrote:
>> Ethan A Merritt <me...@uw...> writes:
>>
>> > Sounds like your plot wants to use "with ellipses".
>>
>> OK, I'm using ellipses now. It does what I want. I just hit a corner
>> case, however that did a surprising thing. The corner case is this:
>>
>>   plot '-' notitle with ellipses
>>   0 0 0 0
>>
>> <snip>
>>
>> Thus here I would expect nothing
>> drawn, or maybe just a single dot drawn. Instead it draws an ellipse of
>> some arbitrary size, independent of the zoom level: it's an abstract
>> symbol.
>
> I can see why you would expect the size to go to zero or a dot if
> the axis length values reach 0.  That would be reasonable, but currently
> it interprets that as a request to use the default properties set by
>       set style ellipse ...
> which also seem reasonable.  Did it do something else?
>
>> Proposal: ellipses with axis lengths >= 0 are not abstract symbols, and
>> are drawn as the data dictates. axis lengths < 0 may be rendered as
>> symbols.
>>
>> Reasonable?
>
> Currently the code uses the absolute value of the axis lengths,
> so negative values have no special meaning.

Right. But that's an implementation detail. The data could potentially
contain size-0 ellipses, and they should be drawn as size-0 ellipses. If
we really want to have a mode where the default properties are used
instead, they should be accessed with size<0. But I don't actually think
that's useful: if the user is specifying an ellipse size, we should use
it.

Want a patch?

Re: Bug in 5.4.rc2

[Ethan A M. <me...@uw...>]

On Friday, 26 June 2020 02:21:58 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> 
> > Sounds like your plot wants to use "with ellipses".
> 
> OK, I'm using ellipses now. It does what I want. I just hit a corner
> case, however that did a surprising thing. The corner case is this:
> 
>   plot '-' notitle with ellipses
>   0 0 0 0
> 
> I'm plotting an ellipse at the origin with axis lengths 0. The
> previously stated purpose was to draw an ellipse with the described
> geometry against the graph coordinates, instead of drawing an abstract
> symbol, like "with circles" does.

I do not recognize that description.  Abstract symbol?
Sounds like a bug.  There is no special code in plot_circles() to
do something other than draw an arc of a circle.
What exactly did you provide as a plot command, and what did
the symbol look like?

> Thus here I would expect nothing
> drawn, or maybe just a single dot drawn. Instead it draws an ellipse of
> some arbitrary size, independent of the zoom level: it's an abstract
> symbol.

I can see why you would expect the size to go to zero or a dot if
the axis length values reach 0.  That would be reasonable, but currently
it interprets that as a request to use the default properties set by
      set style ellipse ...
which also seem reasonable.  Did it do something else?

> Proposal: ellipses with axis lengths >= 0 are not abstract symbols, and
> are drawn as the data dictates. axis lengths < 0 may be rendered as
> symbols.
> 
> Reasonable?

Currently the code uses the absolute value of the axis lengths,
so negative values have no special meaning.
What kind of symbols are you proposing,
and when would you use this rather than plotting `with points`?

	Ethan

	Ethan

Re: Bug in 5.4.rc2

[Dima K. <gn...@di...>]

Ethan A Merritt <me...@uw...> writes:

> Sounds like your plot wants to use "with ellipses".

OK, I'm using ellipses now. It does what I want. I just hit a corner
case, however that did a surprising thing. The corner case is this:

  plot '-' notitle with ellipses
  0 0 0 0

I'm plotting an ellipse at the origin with axis lengths 0. The
previously stated purpose was to draw an ellipse with the described
geometry against the graph coordinates, instead of drawing an abstract
symbol, like "with circles" does. Thus here I would expect nothing
drawn, or maybe just a single dot drawn. Instead it draws an ellipse of
some arbitrary size, independent of the zoom level: it's an abstract
symbol.

Proposal: ellipses with axis lengths >= 0 are not abstract symbols, and
are drawn as the data dictates. axis lengths < 0 may be rendered as
symbols.

Reasonable?

Re: Cloning errors

[Colin B. <m4...@ya...>]

Hello Dima,
>>>>> Dima Kogan <gn...@di...> writes:

    > Hi. Yes, that's probably what's happening. What I meant to ask
    > though, was the exact "git clone" command that's failing. What
    > repo are you pulling down? I tried some older git builds on i686,
    > and they all work fine with the gnuplot repo. Maybe I'm not
    > cloning exactly the thing you were cloning?

Sorry about the misunderstanding.

The failing command is
`git clone https://git.code.sf.net/p/gnuplot/gnuplot-main <RET>'

--------- Begin screen output -----
Cloning into 'gnuplot-main'...
remote: Enumerating objects: 86573, done.
Counting objects: 100% (86573/86573), done.
remote: Compressing objects: 100% (18752/18752), done.
error: object f20ad5ffaa212876da3efb6a9a6f1ea3f8082734: badDateOverflow: invalid author/committer line - date causes integer overflow
Error in object
fatal: index-pack failed
--------- End screen output --------

Hope this helps.

As a test, I've added by head the Newsgroup name to this email, so if
successful this message will also appear in the news list.

Best wishes,

Colin.

Colin Baxter
URL: http://www.Colin-Baxter.com

Re: Cloning errors

[Dima K. <gn...@di...>]

Colin Baxter <m4...@ya...> writes:

> For some reason, my replies get rejected by
> gnu...@li....

It requires that the From: address is subscribed to the list, which
could be tripping you up.

I'm having trouble reproducing. Can you please post the exact command
that's failing? Thanks.

Re: Cloning errors

[Colin B. <m4...@ya...>]

>>>>> Tait  <gnu...@t4...> writes:

    > Curious; I don't get that error. What version of git are you
    > using, on what OS?

For some reason, my replies get rejected by
gnu...@li.... This follow-up is therefore my reply. 

I'm using git version 2.9.5 on 3.16.0-11-686-pae #1 SMP Debian 3.16.84-1
(2020-06-09) i686 GNU/Linux. I see the latest git is 2.27.0 so perhaps I
should upgrade; however, gnuplot is the first git repository that's
given the error.


Best wishes,


>>>>> Colin Baxter <m4...@ya...> writes:

    > Hello,

    > Git cloning https://git.code.sf.net/p/gnuplot/.... fails with

    > remote: Compressing objects: 100% (18752/18752), done.  error:
    > object f20ad5ffaa212876da3efb6a9a6f1ea3f8082734: badDateOverflow:
    > invalid author/committer line - date causes integer overflow
    > fatal: Error in object fatal: index-pack failed

    > Best wishes,


    > Colin Baxter URL: http://www.Colin-Baxter.com
    > ---------------------------------------------------------------------
    > GnuPG fingerprint: 68A8 799C 0230 16E7 BF68 2A27 BBFA 2492 91F5
    > 41C8 ---------------------------------------------------------------------



    > _______________________________________________ gnuplot-beta
    > mailing list gnu...@li... Membership
    > management via:
    > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Cloning errors

[Tait <gnu...@t4...>]

Curious; I don't get that error. What version of git are you
using, on what OS?

Cloning into 'gnuplot-main'...
remote: Enumerating objects: 86573, done.
remote: Counting objects: 100% (86573/86573), done.
remote: Compressing objects: 100% (18752/18752), done.
remote: Total 86573 (delta 70470), reused 83123 (delta 67685)
Receiving objects: 100% (86573/86573), 24.98 MiB | 8.77 MiB/s, done.
Resolving deltas: 100% (70470/70470), done.

But that said, the referenced commit does clearly have an
invalid date:
  tree 31bef65a8811b246449435d6334cd03b80364528
  parent 8d0b9267c9f623c99a2f949652180e2e07845847
  author Timothee Lecomte <tim...@en...> 7465328412 +0200
  committer Timothee Lecomte <tim...@en...> 1154067612 +0200
  
  Reword the warning about problems with piping /dev/null with mouse support...
  
  ...to reflect 4.2 behaviour.

If I've calculated correctly, 7465328412 would be about July,
2206. In any case, it and others (like 3cc23982) are part of
history now, so I can't understand why git doesn't warn by
default instead of treating it as fatal.

I'm guessing this only affects old versions. There was a config
option to turn it down to a warning, which I assume would let
you clone successfully:
  https://github.com/c3e/grundgesetz-dev/issues/28


Colin Baxter <m4...@ya...> said (on 2020/06/25):
> Hello,
> 
> Git cloning https://git.code.sf.net/p/gnuplot/.... fails with
> 
> remote: Compressing objects: 100% (18752/18752), done.        
> error: object f20ad5ffaa212876da3efb6a9a6f1ea3f8082734: badDateOverflow: invalid author/committer line - date causes integer overflow
> fatal: Error in object
> fatal: index-pack failed
> 
> Best wishes,
> 
> 
> Colin Baxter

Cloning errors

[Colin B. <m4...@ya...>]

Hello,

Git cloning https://git.code.sf.net/p/gnuplot/.... fails with

remote: Compressing objects: 100% (18752/18752), done.        
error: object f20ad5ffaa212876da3efb6a9a6f1ea3f8082734: badDateOverflow: invalid author/committer line - date causes integer overflow
fatal: Error in object
fatal: index-pack failed

Best wishes,


Colin Baxter
URL: http://www.Colin-Baxter.com
---------------------------------------------------------------------
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8
---------------------------------------------------------------------

Re: bug in 5.4rc2 X11 terminal

[Dima K. <gn...@di...>]

Ethan A Merritt <me...@uw...> writes:

> On Wednesday, 24 June 2020 10:20:48 PDT Dima Kogan wrote:
>> So I really would like to keep this working reasonably. If we currently
>> have a unicode problem that makes tic mark labels render improperly, an
>> easy "fix" would be to not feed unicode to the x11 terminal.
>
> That is exactly what "set encoding XXX" does, for any XXX that is not utf8.
>
> Or did you mean that <x11 terminal + non-ascii encoding> would be
> a special case when generating tic labels?
> We generally try to keep terminal-specific tests out of the core code,
> but we do have tests for TeX-based terminals so it's not an absolute
> prohibition.

I meant that if we have a known issue where utf8 breaks tic labels with
the x11 terminal, then we can do the "set encoding xxx" internally,
without making the user work around the bug.


> For a long time now utf8 has been the default on linux. So I would
> expect that most linux users would have to deal with this when using
> the x11 terminal with their default locale.

Yes, but I can't reproduce it. I tried today to take away my local
ascii-only setting, and it still seems to work. I even tried to "set
encoding utf8", and my tic labels STILL look ok. And I use gnuplot a LOT
on all sorts of boxes, and I've never seen this. So I would guess that
this isn't an issue that gnuplot has with the default settings for most
people.

Pieter-Tjerk: do you have any theories about what it is about your setup
that triggered this problem?

Re: bug in 5.4rc2 X11 terminal

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

On Wed, 24 Jun 2020, Ethan A Merritt wrote:

> For a long time now utf8 has been the default on linux.
> So I would expect that most linux users would have to deal with this
> when using the x11 terminal with their default locale.

It "just works" here. Xterm using utf8, gnuplot using utf8 (as 
everything should!). So the multiplication signs come out right on 
the axes if I do, e.g.,

set term x11
plot sin(x)*1.0e-5

The only slightly odd thing is what "show encoding" produces:

         nominal character encoding is default
         however LC_CTYPE in current locale is en_US.utf8

I'm not sure what the first line means, or what the force of the 
"however" is.

Allin Cottrell

Re: bug in 5.4rc2 X11 terminal

[Ethan A M. <me...@uw...>]

On Wednesday, 24 June 2020 10:20:48 PDT Dima Kogan wrote:
> Ethan A Merritt <me...@uw...> writes:
> 
> > Back when people cared about x11, the tools and fonts necessary to set
> > up utf8 support were maintained, albeit difficult to use. Now I cannot
> > get it to work at all. I imagine it is still possible but I cannot
> > point to a recipe for how to do it.
> >
> > I think the best advice is "don't use the x11 terminal".
> 
> Yeah, that's too bad, but I think we can do better than that advice
> suggests.
> 
> I use the x11 terminal almost exclusively for one reason: it's
> dramatically faster and lighter than all the alternatives. The
> difference is very noticeable when X-forwarding or when repeatedly
> replotting (interactively rotating a 3D plot, using feedgnuplot
> --stream, etc).
> 
> So I really would like to keep this working reasonably. If we currently
> have a unicode problem that makes tic mark labels render improperly, an
> easy "fix" would be to not feed unicode to the x11 terminal.

That is exactly what "set encoding XXX" does, for any XXX that is not utf8.

Or did you mean that <x11 terminal + non-ascii encoding> would be
a special case when generating tic labels? 
We generally try to keep terminal-specific tests out of the core code,
but we do have tests for TeX-based terminals so it's not an absolute
prohibition.

> If somebody
> has the time and motivation to fix it properly, that'd be awesome of
> course, but just sending ascii across would solve the 99% case in the
> meantime.
> 
> But I can't reproduce the issue in this report, and until that happens,
> there's nothing to "fix".

For a long time now utf8 has been the default on linux.
So I would expect that most linux users would have to deal with this
when using the x11 terminal with their default locale.  

	Ethan

Re: bug in 5.4rc2 X11 terminal

[Dima K. <gn...@di...>]

Ethan A Merritt <me...@uw...> writes:

> Back when people cared about x11, the tools and fonts necessary to set
> up utf8 support were maintained, albeit difficult to use. Now I cannot
> get it to work at all. I imagine it is still possible but I cannot
> point to a recipe for how to do it.
>
> I think the best advice is "don't use the x11 terminal".

Yeah, that's too bad, but I think we can do better than that advice
suggests.

I use the x11 terminal almost exclusively for one reason: it's
dramatically faster and lighter than all the alternatives. The
difference is very noticeable when X-forwarding or when repeatedly
replotting (interactively rotating a 3D plot, using feedgnuplot
--stream, etc).

So I really would like to keep this working reasonably. If we currently
have a unicode problem that makes tic mark labels render improperly, an
easy "fix" would be to not feed unicode to the x11 terminal. If somebody
has the time and motivation to fix it properly, that'd be awesome of
course, but just sending ascii across would solve the 99% case in the
meantime.

But I can't reproduce the issue in this report, and until that happens,
there's nothing to "fix".

Re: bug in 5.4rc2 X11 terminal

[Ethan A M. <me...@uw...>]

On Wednesday, 24 June 2020 09:04:32 PDT Dima Kogan wrote:
> Pieter-Tjerk de Boer <p.t...@ut...> writes:
> 
> > So, somehow, Debian's native gnuplot sets encoding to default even in
> > the C.UTF-8 locale, while 5.4rc2 only does that in the C locale.
> >
> > Thanks for the help; this provides me with sufficient ways to
> > circumvent the problem.
> 
> For what it's worth, my local environment is set to use C instead of
> UTF-8, which is probably why things consistently work here.
> 
> I tried to set the locale environment in various ways to reproduce the
> issue you saw, and I can't. IF gnuplot 5.4 has this issue with the x11
> terminal (requiring the user to explicitly turn off unicode), then I
> think we should fix it in some way.
> 
> But I can't reproduce the problem, so maybe there isn't anything to fix?
> Can anybody else see this issue?

Back when people cared about x11, the tools and fonts necessary to
set up utf8 support were maintained, albeit difficult to use.
Now I cannot get it to work at all.  I imagine it is still possible but
I cannot point to a recipe for how to do it.

I think the best advice is "don't use the x11 terminal".

	Ethan