h a l f b a k e r yI didn't say you were on to something, I said you were on something.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
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.
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
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. |
|
| |
What if you stated table properties in percentage rather than fixed size? I, I, I feel like we're bonding ; ) |
|
| |
[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. |
|
| |
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. |
|
| |
// 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........... |
|
| |
Heh. S'alright. I can keep them at bay with a granola bar. |
|
| |
//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. |
|
| |
So, by using Love Option #9, the Software would say "I can't let you do that SuperDave" |
|
| |
[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%. |
|
| |
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. |
|
| |
[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. |
|
| |
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? |
|
| |