Re: dvi ps
On my outdated laptop, I use GS to create bit-map files, and a very basic anti-aliasing zooming PBM-viewer to display them (which I wrote). This is based on SVGALIB, so it should work under emulation with GGI (?right?). Probably. If it doesn't do anything nasty, the wrapper should work. The other thing about GhostScript is that it does some special things when directed to write to a window under X that it doesn't normally do for other drivers, like anti-aliasing. Hmm - I'd assume it will do the same on targets that can accomodate the output. pgm should suffice. A GGI-based GV-replacement will be on my wish-list too, I have just thought about this a bit, and here is what I came up with: 1. Writing a GGI driver for ghostscript isn't quite trivial, as we should add a little "feedback" like allowing the "return for next page" to come from the GGI visual instead of some maybe backgrounded terminal the thing was started from. If someone knows how to do this, he's very welcome. However: 2. Writing a GGI application that _drives_ a standard ghostscript and displays the results should be pretty much _trivial_ depending on how much extra functionality you want to have. I have looked at the output that is produced, if you output -sDEVICE=pgmraw to a pipe: It is a simple concatenation of pgms. Now if we write a very simple application that will run ghostscript in a pipe, feeding it with the files the app got in its command line arguments and catching the output and rendering it into a memory-visual, we are almost done. All we need then is a bit of input stuff that will allow to scroll around in the result and allow to change ghostscript parameters for rerunning ghostscript (e.g. for zooming). If we want color, we just render to ppmraw. The loader code is pretty generic, and I have code for loading p?m files, if someone needs it. I'd say the functions: scroll-left/-right/-up/-down next-page change-zoom-factor (+/-/explicit set) should be trivial and usually almost all that is needed. It might be nice, if we could "post-zoom" (operating on the already obtained picture) to allow to simply render at high resolution and still quickly get overview pages without rerunning ghostscript. Other stuff like manifying glasses, going backwards etc. would be a bit trickier, though there are simple but slow solutions using ghostscript. I suppose that gv solves these problems by making use of the document structure stuff, as it only works on those files ... so ... Anyone here to take that programming challenge ? As said, it's pretty trivial. I'd expect it to be well below 1000 lines of code, I'd estimate 200 or 300 for a first version that works nicely, without the really tricky stuff. If noone does, I will eventually do it, as I'd definitely like to view ps right from the commandline ... (and other stuff that can be filtered to ps, like pdf, dvi etc.) CU, ANdy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: dvi ps
* Jim Peters ([EMAIL PROTECTED]) [000123 03:36]: On my outdated laptop, I use GS to create bit-map files, and a very basic anti-aliasing zooming PBM-viewer to display them (which I wrote). This is based on SVGALIB, so it should work under emulation with GGI (?right?). It's not as painful as it sounds, even on a 486. I can send the source if you're interested. Sure, send it to me. You could also look at the pbm gs driver code (gdevpbm I thinh). Since you know how pbm works, I think it would be a simple task for you to modify the pbm gs driver to output to a ggi target... Who knows? Anyway, vgalib emulation on my laptop never worked. There's something with vgagl, I don't know. Maybe I should give it another try. A GGI-based GV-replacement will be on my wish-list too, once I get GGI more incorporated into my setup, plus of course a GGI-based web-browser. Then I can throw X away too ! A GGI replacement for the X library (display opening pixel text drawing routines) would do the trick automatically. But that's a big task, and afaik not on the wish list of anyone with time to do that :( I too am waiting the day I can do without X. Alt-Fn works wonders, but I still need to see dvi, ps, and do secure transactions in sites with frames... Cheers, -- Cesar Augusto Rorato Crusius o__ o__ o__ o__ o__ Stanford University ,/'_ ,/'_ ,/'_ ,/'_ ,/'_ e-mail:[EMAIL PROTECTED](_)\(_) (_)\(_) (_)\(_) (_)\(_) (_)\(_) www.stanford.edu/~crusius HE WHO SACRIFICES FUNCTIONALITY FOR EASE OF USE LOSES BOTH AND DESERVES NEITHER
Re: dvi ps
* teunis ([EMAIL PROTECTED]) [000119 22:24]: Hi! I have a system where svgalib doesn't work very well, and I use the console a lot. In fact, I only use X (XGGI) to read dvi ps files. Is there any ghostscript ggi driver on the plans? Anybody working or thinking on working on a dvi viewer (hacks on tmview, for example?) PS: I can't really see too many probs with building one... but I've never looked at the problem *sigh* I tried to hack tmview but it would take way too long for my current schedule. I contacted the author and *he* said it would take too long... Oh well. Building a gs driver shouldn't be difficult *at all* for anyone who did build any other gs driver before (I didn't :( , and it would be very useful, after all one could gs --device=ggi any ps file, and a dvi can be psed easily. One could use it to browse ps files with lynx! I also tried to look at the gs drivers but there were too many options, and since my time is short I would end up producing crap code. Oh well again. Cheers, -- Cesar Augusto Rorato Crusius o__ o__ o__ o__ o__ Stanford University ,/'_ ,/'_ ,/'_ ,/'_ ,/'_ e-mail:[EMAIL PROTECTED](_)\(_) (_)\(_) (_)\(_) (_)\(_) (_)\(_) www.stanford.edu/~crusius HE WHO SACRIFICES FUNCTIONALITY FOR EASE OF USE LOSES BOTH AND DESERVES NEITHER
dvi ps
Hi! I have a system where svgalib doesn't work very well, and I use the console a lot. In fact, I only use X (XGGI) to read dvi ps files. Is there any ghostscript ggi driver on the plans? Anybody working or thinking on working on a dvi viewer (hacks on tmview, for example?) cheers, -- Cesar Augusto Rorato Crusius o__ o__ o__ o__ o__ Stanford University ,/'_ ,/'_ ,/'_ ,/'_ ,/'_ e-mail:[EMAIL PROTECTED](_)\(_) (_)\(_) (_)\(_) (_)\(_) (_)\(_) www.stanford.edu/~crusius HE WHO SACRIFICES FUNCTIONALITY FOR EASE OF USE LOSES BOTH AND DESERVES NEITHER
