> 1) pdf driver: that's a great new driver -- I really love that addition!
[...]
> somehow, other pdf tools can inform acroread to set the page setup to
"landscape",
> so printing is ok without twiddling with page setup settings first.
Well, knowing the fact that other programs can manage this doesn't exactly
help us implement
it for ourselves... We would need to know *how* they do it.
> 2) readline(?), SIGTSTP, and gnuplot_x11 communication (and libreadline?)
As far as I can see, at least a significant part of that problem lies with
libreadline itself. gnuplot
should probably catch SIGTSTP and do something with it, though.
> 3) I'm just starting to use gnuplot on M$ Win-XY for my first time.
> obviously it's great too, but by default I'm hardly missing the
> possibility to use shell commands in plot "datafile" using
>
> plot "< some command"
>
> but by default PIPES config is not set for windows builds :-(
That's because it has a side effect which the average Windows user would
quite certainly be quite irritated about: it opens an extra console window
if started from
outside a console. The average Windowser would perceive that as a bug of
the program, not
as a feature --- I've been there and got quite a collection of mails about
it, when I accidentally put
a similar behaviour in the first distribution of the 3.7.3 W32 build...
I've been contemplating a more Unix-ish Win32 version, i.e. a console
application that still has a
GUI graph window --- I had long thought this was utterly impossible to do,
but it appears I may have
been wrong. I made some inroads, but haven't quite reached a usable overall
result yet.
OTOH, I don't see what's stopping you from building your own w32 version
with -DPIPES=1
enabled...
> I've read your comments about PIPES in config/makefile.mgw
> but for me (Windows novice) it's unclear if this is a problem
> for _all_ windows versions (e.g. would WinXP be any better?).
The problem doesn't depend on the version of Windows --- it's a fundamental
difference in the
way Unix and Windows work. X11 programs have a plain stdin and stdout
channel, just like
console ones, whereas Windows GUI apps don't. This was even worse in Win16,
which wgnuplot
was originally made for, and which made that silly home-grown terminal
emulator a necessity.
> right now I still hope (dream?) that it'll be possible to use MSYS
> to allow "real" shell commands in plot "< ..."
What exactly is "MSYS"? Anyway: if you miss Unix-ish behaviour real bad, I
would suggest
you get yourself cygwin (including X11) installed ;->
|