Menu
▾
▴
gnuplot-beta
|
From: Russell L. <gs...@gh...> - 2005-02-03 10:40:15
Attachments:
win32prn.c
|
Developers, The file src/win/wprinter.c contains some old code for sending printer specific output to a printer in DumpPrinter(). The 16-bit code is probably still Ok, but probably not much used these days. The 32-bit code was written by me to work on Win32s and the full Win32. Win32s had some limitations with printing - the old 16-bit APIs are not available, nor are the 32-bit APIs. The current Win32 code uses the GDI Escape to try to sneak the data through the printer driver. It should be safe to assume the Win32s isn't used any more. So we should be able to replace the old Win32 printing code with something based on the attached code. In a slightly different form, this code has been used by GSview and Ghostscript for many years. Note that although the function gp_printfile_win32 has an argument named "port", it really is the printer queue name, not the port name. Some of the existing code to select a printer queue is still needed. Let me know if you need some assistance with this. I'm not on the gnuplot developer mailing list. Russell Lang gs...@gh... Ghostgum Software Pty Ltd http://www.ghostgum.com.au/ |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-02-04 14:14:29
|
Russell Lang wrote: Welcome back! It's been quite a while since we heard from you. It's good to see you still remember gnuplot after all these years. > The file src/win/wprinter.c contains some old code for sending > printer specific output to a printer in DumpPrinter(). The 16-bit > code is probably still Ok, but probably not much used these days. That would be putting it mildly. As of the current release version, 4.0, the 16-bit version no longer even compiles. And the 32-bit version is known to have various problems. Apparently, it never worked on Win9x at all. Neither the "print this" menu entry in the graph context menu, nor the 'set output 'PRN:' method. > So we should be able to replace the old Win32 printing code with > something based on the attached code. In a slightly different form, > this code has been used by GSview and Ghostscript for many years. I suspect just about anything would work better than the current stuff. As a matter of fact, I sometimes think it's time to rewrite the entire Windows-specific part of gnuplot from scratch, given that with Win32 it's possible to have gnuplot behave the same way X11 gnuplot does. In particular, I would really like to get rid of the home-grown terminal emulator and all the problems and limitations it causes. |
|
From: Russell L. <gs...@gh...> - 2005-02-05 09:41:17
|
Hans-Bernhard, > That would be putting it mildly. As of the current release version, > 4.0, the 16-bit version no longer even compiles. So do you want all 16-bit code removed? > And the 32-bit version is known to have various problems. Apparently, > it never worked on Win9x at all. Neither the "print this" menu entry in > the graph context menu, nor the 'set output 'PRN:' method. Neither of these should have been broken in the move to 32-bit. Note that it is "set output PRN", not "set output PRN:". > As a matter of fact, I sometimes think it's time to rewrite the entire > Windows-specific part of gnuplot from scratch, given that with Win32 > it's possible to have gnuplot behave the same way X11 gnuplot does. In > particular, I would really like to get rid of the home-grown terminal > emulator and all the problems and limitations it causes. Doing it on one thread may be a little tricky. Do you want gnuplot to provide the command line editing, or do you want the default Windows command line editor? If gnuplot provides it, then we might be able to do it on a single thread. If you use the Windows console to provide line editing, then we might have to use two threads. The first thread is the console and the main gnuplot code. The second thread handles the image window. A small amount of synchronisation code is required to lock the image window data structures as each new plot is drawn. This is the method I have used in ghostscript. The code is probably simpler than a single thread version. Russell Lang gs...@gh... Ghostgum Software Pty Ltd http://www.ghostgum.com.au/ |
|
From: <br...@ph...> - 2005-02-07 08:29:04
|
[Russell: you may want to subscribe to gnuplot-beta, to avoid the lag created by me having to approve each of your messages to the list through SF.net's Mailman web interface.] Russell Lang wrote: >> That would be putting it mildly. As of the current release >> version, 4.0, the 16-bit version no longer even compiles. > So do you want all 16-bit code removed? Not per se. If it falls off the table as part of some major renovation, I can accept that, but there's not (yet) a good reason to kill that code just because we can. >> And the 32-bit version is known to have various problems. >> Apparently, it never worked on Win9x at all. Neither the "print >> this" menu entry in the graph context menu, nor the 'set output >> 'PRN:' method. > Neither of these should have been broken in the move to 32-bit. AFAIK, they were broken by differences between Win9x and Windows NT. I.e. they only failed on 9x --- a rather unusual thing, really. Usually, it's the tougher restrictions of the NT family that break code, not the loose ones on 9x. [...] >> particular, I would really like to get rid of the home-grown >> terminal emulator and all the problems and limitations it causes. > Doing it on one thread may be a little tricky. May be. I'm quite sure it won't be any trickier than the home-grown terminal emulation already is. Other than that, I'd say we use whatever does the job. The main issue to keep an eye on would be the mouse feedback stuff. I.e. the main input loop of gnuplot now needs to listen to *two* input streams: the command input (console, redirection or some script file), and the mouse feedback. That's about the only thing that was easier in the existing Windows version than in X11. The X11 synchronization details (select(), <stdio.h> buffering, blocking pipes, ...) took us most of three years to (somewhat) finally sort out. > Do you want gnuplot to provide the command line editing, or do you > want the default Windows command line editor? I got an experimental version going around August 2003, which has gnuplot's -DREADLINE set, i.e. gnuplot does the command-line editing, Windows just giving us keystrokes. It's not completely done (i.e. the wtext.c window still shows up, but is non-functional), but it's at least marginally usable. |
