CLIM mail archive
[Prev][Next][Index][Thread]

Re: TAB inside draw-text

    Date: Tue, 9 Nov 1993 13:16 EST
    From: chyde@BBN.COM


       Date: Tue, 9 Nov 1993 12:22 -0500
       From: Scott McKay <SWM@stony-brook.scrc.symbolics.com>
       cc: clim@BBN.COM

	   Date: Mon, 8 Nov 1993 10:09 EST
	   From: Jeff Morrill <jmorrill@BBN.COM>

	     Date: Mon, 8 Nov 93 9:27:54 EST
	     From: chyde@BBN.COM

	     I'm drawing some text that has #\TABs in it. but, they don't show up
	     on screen, their width is zero. is there a special extra control one
	     has to provide to get this to have some width?

	   Both TAB and RETURN don't seem to be processed correctly.
	   They both seem to be treated the same as #\space.

	   If you use FORMAT to generate the string in the first place,
	   then you might be able to use ~T to work around it.

       If you are using DRAW-TEXT[*] (as opposed to WRITE-STRING), it does
       not handle tabs and newlines.  Handling tabs and newlines requires
       maintaining cursor state, and DRAW-TEXT[*] does not maintain any such
       cursor state.

       This was true as far back as CLIM 1.0.

       (Actually, this was true as far back as (SEND WINDOW :DRAW-STRING ...)
       in Symbolics system 98, circa 1982.  Maybe earlier.)

    well, shoot. couldn't we get a default behavior that covers it in a
    simplistic way (i.e., substitute N #\space characters for a tab) ?

    I don't need anything too fancy. I could of course just use something
    besides draw-text, but that really cramps my style in creating a
    compound presentation...

Except for hooking into output recording, DRAW-TEXT[*] pretty much just
calls the host's version of whatever function scribbles glyphs out on
the display device.  Most of the window system-specific functions I know
of don't manage to handle newlines or tabs, and any non-printing glyph.

Doing what you want would require making either all of the low-level
MEDIUM-DRAW-TEXT* methods do the right thing, or we would need to make
DRAW-TEXT* itself "scan" the input string and repeatedly call the lower
level functions.  Either of these solutions will definitely require a
performance degradation.  I think it would be better to write your own
new DRAW-STRING[*] function that does exactly this, and then use that
function when it's appropriate.
Main Index | Thread Index