Menu
▾
▴
Re: README-Windows.txt
|
From: Tatsuro M. <tma...@ya...> - 2019-02-24 06:43:18
|
Dear Bastian I rearange the issue. Choice of default terminal on Windows Bastein's choice is "windows" I do not against it. Perhaps I personally set wxt which is also my choice in linux. From the next major release (perhaps 5.4), it is a good chance windows terminal will come back as default. Status of the qt terminal on Windows What I saw was almost was a timing issue not essential. But strange jitter plots only happen qt terminal on native windows. https://sourceforge.net/p/gnuplot/bugs/2138/ Issues with or without fontconfig The ticket "kerning in vertical text of cairo-based terminals " https://sourceforge.net/p/gnuplot/bugs/2048/ If I set PANGOCAIRO_BACKEND=fc, the behaviors are changed. I guess that differences in win32 and fontconfig for pangocairo backend is reltated. Bug report #2121 on font names with spaces (or hyphens) In my opinion, Ethan's modification solved the issue. windows terminal bug related to wgnuplot.ini This is unreporducible and happens as very rare case Thus we cannot easy to fix it. Deleting it or edit it by editor is to be described as a tip. Tatsuro > 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 >> >> > |
