2 ms·

I think it's a overflow issue. The print preview flows the text in some box on a page, and if you have lots of wide characters it gets cut off because they didn

by pak 16y ago

I think it's a overflow issue. The print preview flows the text in some box on a page, and if you have lots of wide characters it gets cut off because they didn't anticipate the max y-height 150 words can consume. The Times was a bit imprecise in how they used the kid's words to explain the bug (about par for their technical reporting, unfortunately). The way they write it, it sounds a lot like <textarea maxlength=1000></textarea>, but if you think more about the explanation of the wide characters and the "print preview" it can't be that. Overflow issues are actually not trivial to fix, as opposed to the claims some people are making here about "just count the words". Without allowing an excessive amount of space or allowing for more flexibility in the way it lays it out (flowing across multiple pages, etc.), it can be hard to estimate how much space to give for something as vague as a 150-word limit. If the Common App instead specified a 1000-character limit, the programmer/designer could take the widest character like "W" and determine the max y-height for 1000 W's.

thedz 16y ago
Maybe one way to approach this would be to have the box expand dynamically vertically until the max word count is reached. Then the text is always going to fit.
chc 16y ago
What you're actually saying here is: Overflow issues are not trivial to fix if the only approach you try is guessing how much space the user is likely to want and hoping you're right. That's because guesstimating a length is not really fixing the issue. The flexible layout algorithm you describe in your "Without…" clause is the right thing to do, and it's been a solved problem for decades now. Anyway, even if they don't want to fix the root problem, it would still be trivial to do better than they are doing now. Instead of passing the buck with their "I went over the print preview with a fine-tooth comb" checkbox, it would be pretty close to trivial to algorithmically check whether you're oversetting the type and throw an error along the lines of, "Hey, we didn't allow enough room in the form and aren't competent to make it work right. You'll need to fix this."

by pak 16y ago

thedz 16y ago

Maybe one way to approach this would be to have the box expand dynamically vertically until the max word count is reached. Then the text is always going to fit.

chc 16y ago

What you're actually saying here is: Overflow issues are not trivial to fix if the only approach you try is guessing how much space the user is likely to want and hoping you're right. That's because guesstimating a length is not really fixing the issue. The flexible layout algorithm you describe in your "Without…" clause is the right thing to do, and it's been a solved problem for decades now. Anyway, even if they don't want to fix the root problem, it would still be trivial to do better than they are doing now. Instead of passing the buck with their "I went over the print preview with a fine-tooth comb" checkbox, it would be pretty close to trivial to algorithmically check whether you're oversetting the type and throw an error along the lines of, "Hey, we didn't allow enough room in the form and aren't competent to make it work right. You'll need to fix this."