Aw: Re: README-Windows.txt

Dear Tatsuro,

I am a bit confused about your mail as it - in my view - adresses many
different somewhat independent topics. I will try to provide information
on all of them below.


* Choice of default terminal on Windows

The current default terminal on Windows is 'wxt'.  As far as I remember 
it's been like that since the initial commit of the wxt terminal to CVS
in 2006.  It has been a rather stable and reliable terminal since then.  
It is cross-platform and has pdf/png siblings which guarantee simlar-
looking output.  On Windows, it can produce EMF data, which is nice
for exchange e.g. with office programs. Also printing works. It's not 
an "outboard" driver, which means that there are no interprocess 
communnication problems, but support for "persist" is not available in
the same sense as on other platforms. (No "fork" on  Windows)

The previous default (and only visual) terminal was "windows". That
had fallen behind in terms of features (and speed) at that time when wxt
was introduced. With the Direct2D backend that has certainly changed. 
It is clearly faster than wxt and qt (which does not currently use the 
D2D interface, although Qt supports that). It exports EMF and bitmap 
data to  the clipboard. Export to PDF can be done via the Windows PDF 
printer, but no pdf/png export from command line (yet). Graphs can be 
embedded in the main window.  

"qt" is the default on most other platforms. It is cross-platform, but does
not (yet) have pdf/png counterparts. (But you can do save as pdf/png/...)
It is an "outboard" driver, i.e. persist works the same way on Windows
as it does on other platforms. It is fast and supports printing.
qt still has a few issues on Windows, see below.

Users are given a choice to change GNUTERM and hence the default terminal
during installation.  One's preferences certainly depend on your needs and
opinion. My choice is "windows". As for the default, I would only consider 
"windows" or "wxt" at this time.


* Status of the qt terminal on Windows

qt is quite usable on Windows. It is definitively not "broken". It does
have some quirks, though.  One of them is related to fontconfig. For 
whatever reason, the experience with fontconfig on Windows with gnuplot
has its difficulties: it reinitializes its cache very often, leading to
a simingly indefinitely delayed opening of the window (wxt used with 
fontconfig) or an error message ("slow font initialisation" - qt). This 
is unsatisfactory and cannot be the "default" behaviour. So far I could
not identify a remidy. We are certainly open to patches! Another issue
is Bug #1081: Qt: resizing makes plot "tremble/​shake" which still 
persists on Windows at least. Also we still have issues with detecting
the loss of communication with the outboard driver (or vice versa) in
some cases.

If there are more issues with "qt" (which warrant to call it "broken)
please let us know, so we can fix these issues.


* Issues with or without fontconfig

There's no single fontconfig library on Windows. Every applications ships
its own version. There are reports on the net of interference between 
these different versions, but I am not sure that this is our problem. The
font cache init is slow and for gnuplot does not run in the background,
but delays user interaction.  This leads to timeouts (qt) or windows
not appearing for a long time (wxt).  We got a number of "gnuplot hangs"
reports when wxt used fontconfig by default. So we changed that.

I sould note that fontconfig is somewhat redundant on Windows. There
are other "native" means to find fonts on Windows. No need to maintain
a separate list - at least not for what concerns gnuplot.

Several solutions are possible, maybe in combination:
- We could try to reduce the caching problem by "fixing" our fontconfig 
setup files (in case that's the issue).
- We could init the fontconfig cache during installation of gnuplot.
  I have seen that for other installers on Windows.
- We could have fontconfig do the cache init in the background or when
  gnuplot is idle.
- We could detect when fontconfig (re-)inits its cache and provide the 
  user with that information ("Please wait - looking for fonts"). If 
  that is possible.
- We could avoid to use fontconfig on Windows, i.e. ask Qt to use the 
  native font API on Windows (if that is supported).

We should move further discussion to the bug tracker.  Help with 
fontconfig and Qt is very welcome, as I do not know much about either 
of them.


* Bug report #2121 on font names with spaces (or hyphens)

Given the above, I personally would not recommend to use fontconfig with
gnuplot on Windows. But it's a work-around. So maybe a question for the 
FAQ. 
Ethan has added support for font-names-in-quotes to git in response
to this bug report which is a cross-platform and cross-terminal solution.
(Another proposed solution was to uniformly convert dashes to spaces in
font name before sending them to the terminal.)


* windows terminal bug related to wgnuplot.ini

> > Sometimes wgnuplot.ini will break and plot window will  be strage.
> > In the case, one can reset broken setting by deleting wgnuplot.ini.

I don't remember having to delete wgnuplot.ini in 20 years or so of using 
gnuplot on Windows.  Instead of adding that to README, we should much rather
have a proper bug report, including examples of those ini files and - if 
possible - info on how to reproduce the failure. It should be fixed in the 
code asap.
One should note that "wgnuplot.ini" is only used by the wgnuplot text window
and the "windows" terminal.

  Bastian


> > In the bug #2121, Bastian wrote, we can select pango-cairo backend : win32, 
> > 
> > fc (fontconfig).
> > 
> > The bug #2048, the behaviors seems to be different depending on backend.
> > 
> > Will the selection backend to be wrietten in README-Windows.txt?
> > 
> > Sometimes wgnuplot.ini will break and plot window will  be strage.
> > In the case, one can reset broken setting by deleting wgnuplot.ini.
> > 
> > I think that this is prefferablly described in README-Windows.txt.]
> > 
> > Tatsuro
> 
> After some discussion BBS in Japan, I put  README-Windows.txt to Files/5.2.6.
> 
> The original question is why wxt terminal is default.
> On native windows qt is broken and is is not recommeded.
> 
> However, there is no descrition for this topic.
> 
> I will open a bug ticket that is for additional information for gnuplot on windows
> on this weekend.
> 
> Tatsuro
> 
>