Half a croissant, on a plate, with a sign in front of it saying '50c'
h a l f b a k e r y
Chewable.

idea: add, search, annotate, link, view, overview, recent, by name, random

meta: news, help, about, links, report a problem

account: browse anonymously, or get an account and write.

user:
pass:
register,


                           

Windows static-text-item "squishing"

Make text fit in Windows "static text" (and related) items
 
(0)
  [vote for,
against]

When a static text item in Windows is asked to display more text than will readily fit, Windows just shows the part that will fit, dividing this with little regard for making stuff visible or useful.

What I'd like to see would be an option (which could be enabled/disabled on a per-application level, with per-dialog overrides) which would force the computer to squish the text as needed to make it fit unless there was so much text that it would have to shrink below some minimum-size limit.

Editable text would generally not have to be squished because it can be selected and scrolled. Generally this is not possible with static text items, however; anything that falls off the right side or bottom simply can't be seen.

supercat, Nov 18 2002

[link]






       You mean like in .asp?
thumbwax, Nov 18 2002
  

       Well, I'd been thinking of in applications (for static text items or button labels, etc.) though the same feature in things like HTML tables and such would be good as well.
supercat, Nov 18 2002
  

       What if you stated table properties in percentage rather than fixed size? I, I, I feel like we're bonding ; )
thumbwax, Nov 18 2002
  

       [thumbwax]: Table sizes can be expressed in percentages, and dialog-box-control sizes are expressed in units which vary with the system-default text size. Unfortunately, the best laid plans of mice and men gang aft aglee, and proportions do not always hold as true as one might wish. For example, compare the length of the following two lines:   

       MMMMMMMMMMMMMMMMMM
This is a test. This is only a test.
  

       On my screen, the second line is about 17.2 M's long when text size is on "medium". When text size is set to "smallest", it's about 19. On "smaller", it's about 19.3. On "larger" it's about 16.6, and on "largest", it's about 17.8. If I define a table width in terms of "ems" [which are supposed to be about the width of the ltter M, though not always] whether or not the second line fits may depend upon the screen's font-size setting despite my best efforts to correct for that.   

       To be sure, sensibly-designed tables and dialogs which don't fit should be very close to fitting so as to require only a minimal amount of "scrunching". Such scrunching is probably preferable to having material which is simply unreadable.
supercat, Nov 19 2002
  

       Better to make the programmer responsible for getting it right to begin with. The problem is not with the control, but with how it's being used.
phoenix, Nov 19 2002
  

       // Better to make the programmer responsible for getting it right to begin with //   

       [phoenix], I don't want to bother you, but there's a crowd of pasty-faced geeks with pens in their shirt pockets outside, and they've got a hangman's noose...........
8th of 7, Nov 19 2002
  

       Heh. S'alright. I can keep them at bay with a granola bar.
phoenix, Nov 19 2002
  

       //Better to make the programmer responsible for getting it right to begin with. The problem is not with the control, but with how it's being used.//   

       Unless the programmer defines everything in terms of pixel dimensions, and either supplies all fonts or uses only system standard fonts, the relative sizes of objects may change from system to system. The problem is made much worse if a program is designed to operate in multiple languages.   

       To be sure, having the text on a particular control get 'scrunched' is going to be somewhat ugly, but having text overrun its allotted space will in most circumstances be even uglier.   

       Suppose there is a table with nine columns: one with row headings and nine which all hold similar types of data. The widest item in one table cell is slightly wider than the others (about the same number of characters, but more "m"'s and "w"'s and fewer "i"'s).   

       Is it better to (1) truncate the data in the cell; (2) make that column slightly wider than the rest, even though there is no logical significance giving extra width to that column; (3) split the cell item over two rows, causing one row of the table to be double-height, again for no meaningful reason; (4) do #2 but make all columns wider (hope the table still fits on screen); (5) do #3, but make all rows double-height (again, hope it still fits); (6) break the data in that cell into two rows, and put a scroll bar to the right of the cell (further eating up width); (7) have the programmer shrink the data in all cells so as to ensure that no combination of font sizes and typefaces will cause any width problems; (8) have the software automatically shrink the text in all cells so there are no width problems; or (9) have the software shrink the text in the cell that would otherwise overflow   

       Seems to me (9) is the nicest choice. And I have seen the approach taken on occasion in professionally-printed material. Ugly, to be sure, usually still better than many of the alternatives, and sometimes better than all.
supercat, Nov 19 2002
  

       So, by using Love Option #9, the Software would say "I can't let you do that SuperDave"
thumbwax, Nov 19 2002
  

       [thumbwax][rodstiger] Dimensioning everything in pixels is one way to avoid surprises (and using images is a way of doing that), to be sure, but it means that users with high-resolution displays may find your text too small and hard to read. Leaving lots of vacant space is another approach to avoiding having stuff not fit, but this often necessitates use of smaller fonts or more screen area than would otherwise be needed.   

       In designing dialog boxes and and web pages, it's nice to honor the user's requests regarding font-sizes and dimensioning. Unfortunately, the effects of such requests cannot always be entirely predicted. Given a choice between a table which fits on screen, but has one item squished by 5%, or one which is just a little too big because all the cells were expanded on account of one whose text was 4% too long, I'd tend to go with the former.   

       To be sure, the original idea had to do with Windows dialog controls; the same principles apply there. There is a control panel setting ("large fonts" or "small fonts") which well-behaved applications should honor. If the software is tested in one mode and controls fit, but they don't quite fit in the other mode (as can happenin either direction, since the dialog-scaling routines would scale control dimensions up by 33% for "large fonts" mode, and would scale nominal text size up by 33%, but may increase the actual size of the text by anywhere between about 25% and 50%.
supercat, Nov 19 2002
  

       The correct answer is:
a) make sure the column width(s) of the table are sufficient for the amount of data, and/or
b) make the column(s) resizable
  

       In either case, it's up to the programmer to do the right thing, not the control.
phoenix, Nov 19 2002
  

       [rt] As far as I'm concerned, if I specify style="width:640px", I expect the item to be precisely the width of an e.g. 640x480 .JPG file. To be sure, I wish more browsers (well, at least IE) would allow a 'scale up by two' option which would double the size of everything, including embedded images, but at present pictures generally have their size fixed--at least on screen--in device pixels.   

       BTW, one of the major problems with on-screen text is that all character widths are usually rounded to an integer number of pixels. This is done partially for performance reasons (caching is problematical if characters' alignment with regard to the pixel grid is variable), and partially because of monitors' "frequency response" characteristics. Sampling theory would suggest that a 96dpi monitor should be able to display any frequency of lines up to nyquist (48dpi). Unfortunately, sampling theory ignores the effects--good and bad--of aliasing on real-world computer displays. If a monitor is calibrated to e.g. 96dpi, there's no way to display a bunch of lines spaced at 38dpi without visible aliasing at 10dpi. This is because the monitor, given a 48dpi line pattern, will generate aliasing at 144dpi, 240dpi, [third and fifth harmonics], etc. These aliased frequencies are useful in some cases, but bad in others. Attempts at anti-aliasing can bring out the bad effects of harmonic aliasing.
supercat, Nov 19 2002
  

       waugsqueke had an idea about anti-aliasing once. Well, kinda.
What do you suppose is the lowest amount of mighty big "If" arguments/meta-tags one can place in a web page and still satisfy 99+% of the population?
thumbwax, Nov 20 2002
  
      
[annotate]
  


 

back: main index

business  computer  culture  fashion  food  halfbakery  home  other  product  public  science  sport  vehicle