[WASTE-list] monospace text

[Marco Piovanelli]

On Fri, 11 May 2007 10:35:33 -0500,
Chinh Nguyen (cnguyen at stata.com) wrote:



>My app has a built-in text editor for editing programs and it uses  

>monospace, monostyle text.

>

>Is there a way to to set the inter character spacing so that each  

>character is of a non fractional pixel width?  I constrain window  

>resizes to columns (like Terminal.app) and that's no longer working  

>since the switch from WASTE 2 to WASTE 3.  It would also be useful  

>for tabbing because I tab based on characters and that's now broken too.


Is using a monospaced font like Courier not sufficient to get
uniform (and non-fractional) character widths?


>In terms of constraining to a line height, that works OK.  However,  

>when I scroll down (I scroll by line height and character width  

>rather than by pixel since my scrollbars track lines and columns, not  

>pixels), I always see the bottom 2 pixel rows of the previous line to  

>the top line of the page.


This is due to a new "feature" in WASTE 3.0.  Please read on.


>My destrect and viewrect are the same except the destrect is

>really wide since I don't use word wrap.

>

>Which also leads me to this.  In the WASTE sample, I see that in the  

>calculation of the text rect, there's an InsetRect() of 3 pixels.

>However, when you resize the window, you still see the text drawn up  

>to the edge of the scrollbars.  Why is that?  I do that same thing  

>with my editor and as a test, I commented out the InsetRect() and saw  

>that the text overwrites the scrollbars by you guessed it, 3 pixels.


WASTE 3.0 allows the text image to "bleed" outside of the destination
rectangle by a certain margin, to avoid the unsightly clipping of
(antialiased) glyphs, or the caret, near the edges of the destination
rectangle.  The default "bleed margin" is 3 pixels, but it can be
adjusted on a view-by-view basis.  Unfortunately, there is currently
no way to do this through the procedural API.  I'll fix this in the
next release.


>It's not that I want a 3 pixel gap next to my scrollbars, I'm just  

>wondering why it's necessary to subtract 3 pixels from the right and  

>bottom of the text rect.  I think this logic has been there since  

>older versions of WASTE.


The demo app has always added a three-pixel margin around the
destination rectangle, but previous versions of WASTE wouldn't
draw into the margin area.


>Also, in my Run Log I get the message:

>

>Exception thrown in function void WE3_File::OpenResFile(SInt8)  

>(WE3_File.cp, line 272); error code = -39

>

>when I WELoad() a text file.  I figure it's a harmless message  

>because the file opens just fine.


Yes, that is totally harmless.  WASTE is just attempting to
open the resource fork of the text file, looking for formatting
resources.  If there's no resource fork, it will just proceed
to load the plain text.


                                        -- marco

-- 
It's not the data universe only, it's human conversation.
They want to turn it into a one-way flow that they have entirely
monetized. I look at the collective human mind as a kind of
ecosystem. They want to clear cut it. They want to go into the
rainforest of human thought and mow the thing down.