[[Explain motivation ([cron], possible sneer at [Java], portability, ...]] [LV] Can someone go into the technical details of what parts of [Tk] require a display and what parts do not? For instance, if one were to write a C app which created a [canvas], placed things onto the canvas, configured various colors, text, etc., then commanded the canvas to create [PostScript], would a display be necessary for any of this? According to [Robert Heller] in a [comp.lang.tcl] posting, the canvas postscript generating code uses various bits and pieces of Xlib, relating to things like colors, fonts, and conversions of 'image' type data to something that can be converted to postscript. ---- [[Explain alternatives: * utility X server * [Xvfb] * [VNC] * TclDG [http://www.usenix.org/publications/library/proceedings/tcl96/full_papers/ellson/] * Image [http://pages.infinit.net/cclients/] * Xbit [http://www.geocities.com/SiliconValley/Hills/5586/home.html] * [gdtclft] * [[explain use of "ssh -X ..."]] * [xwd] * [TclMagick] * Investigate use of http://netpbm.sf.net/ to generate/transform graphics. * [Pixane] * Pure Tcl solutions. An example [DKF] offered is #! /usr/local/bin/tclsh8.3 puts "Content-Type: image/x-portable-graymap" puts "" puts "P2" ;# ASCII PGM "magic number" puts "10 10" ;# width and height puts "18" ;# Max grey value for {set i 0} {$i<10} {incr i} { set line "" for {set j 0} {$j<10} {incr j} { lappend line [expr {$i+$j}] } puts $line } exit [AM] Here is a little variation on this - it produces a PPM file (type "P6"): # Create a simple PPM file (type: P6) # global width global height set width 200 set height 200 set total_length [expr {$width*$height*3}] set image [binary format "a$total_length" ""] proc setpixel {imageName i j r g b} { upvar $imageName image global width global height set posb [expr {3*$width*$j+3*$i}] set pose [expr {3*$width*$j+3*$i+2}] set image [string replace $image $posb $pose [format %s%s%s $r $g $b]] } for { set i 0 } { $i < $width } { incr i } { setpixel image $i $i \uff \uff \uff } for { set i 0 } { $i < $width } { incr i } { setpixel image $i 10 \uff \u0 \u0 } set outfile [open "image.ppm" "w"] puts $outfile "P6" puts $outfile $width puts $outfile $height puts $outfile "255 $image" close $outfile ---- A small and incomplete TGA image reader which reads a file into a format that can then later be fairly easily manipulated without the requirement of Tk. The format is compatible with one of the accepted (albeit undocumented) formats for Tk photos. See: [TGA image reader]. ---- See also "[strimj - string image routines]" and "[barchart]". [GIF] has code snippets for writing image files in pure Tcl. ---- [[Do something about Tk's "-nodisplay" ...]] ---- [DKF]: Another way would be to split the image master stuff out of Tk into its own package which could be loaded from Tcl [http://sourceforge.net/tracker/?func=detail&aid=783802&group_id=12997&atid=362997]. Note that the image display code would have to remain in Tk, but that's quite reasonable IMHO. 12 Sept 2003 [Mike Tuxford]: Now this is '''exactly''' what I'd like to see but is far beyond my abilities to accomplish, and I don't feel particularly comfortable making a call for others to do it, because it's something I am unqualified and unable to contribute to. [AM] I have started to build a Tcl-only package that will manipulate images via the above algorithm. It is slow, but when I replace the culprit (setpixel) with a C implementation, it should be quite acceptable :). At the moment, it is merely an exercise - see if it can be made practical. Most probably the isolation of Img is more important. [DKF]: FWIW, I'm working on improving the performance of the setting of pixels of photos in 8.5, but it is not a very high priority thing. (Alas, pay-work comes first...) [dzach] 2006-8-27: Splitting Tk sounds like a great idea that could lead to a native solution to [Image manipulation without Tk]. Has there been any progress on this issue since 2003? I know, progress doesn't grow on trees, and I should propably follow Mike Tuxford's words above, but abstracting a display-less part of Tk, especially the Tk widgets, and providing a mapping mechanism to it from the real world, could lead to the development of other very interesting device drivers, besides getting the benefit of rendering graphics on different devices/formats. For instance, a hardwired panel where the canvas would be represented by an LCD touch screen display, a series of (hardwired)buttons that drive the new abstract Button class, a potentiometer that maps to a scale widget, all readily interchangable with their software Tk widget counterpart. A Tool Command Language coming back to its origins and readily embedable to harware devices. Isn't this the Tcl/Tk 10.0 wishlist page? ---- [Arts and crafts of Tcl-Tk programming] - [Category Graphics] - [Category Image Processing]