DSPRelated.com
Forums

Sampling: What Nyquist Didn't Say, and What to Do About It

Started by Tim Wescott December 20, 2010
On a sunny day (Tue, 21 Dec 2010 12:11:41 -0700) it happened D Yuniskis
<not.going.to.be@seen.com> wrote in <ieqtk7$rel$1@speranza.aioe.org>:

>OTOH, when reading a paperback (or columnar text), it seems like >my eyes just *dart* right and left and spend most of their time >moving smoothly down the page.
What I cannot stand is text with embedded pictures, where the text 'flows' around the picture. I means what those DTP programs sometimes produce, and then they use variable spacing between the WORDS to get even line length... terrible. _____ In this picture you | pic | see the cat | of | jump on the table | cat | on the next page _____ the cat is shown eating the mouse
On 2010-12-21, D Yuniskis <not.going.to.be@seen.com> wrote:

>> I prefer long lines, reads much better. >> >> Then you're in a small minority. Cognative research shows that long >> lines are harder to read for pretty much everybody else. > > Agreed -- though I may have some "inherent" issue with "minimizing > head/eye motion" (e.g., my workstations are designed so I don't have > to move my head to see different monitors). > > Short lines (e.g., 2 or 3 column format) read *much* quicker (IMO) > than long ones. Just the difference between a paperback and a > "hard-bound" tome alone is significant (though I wonder if that isn't > because the actual *physical* width of the text is smaller?).
The research that I've read over the years indicates that both physical width (specifically the angle subtended by the line), and the number of characters had an effect.
> With short line lengths, you never lose sight of the left edge > of the column. So, moving to the next line requires less > visual (subconscious) "hunting".
Right. The longer the line, the harder it is to jump to the beginning of the next line without getting "lost" or making false starts on the wrong line. -- Grant
On a sunny day (Tue, 21 Dec 2010 19:12:35 GMT) it happened Jan Panteltje
<pNaOnStPeAlMtje@yahoo.com> wrote in <iequ7b$m90$1@news.datemas.de>:

PS
I prefer it this way:
 http://panteltje.com/panteltje/pic/gm_pic/

Hi Grant,

On 12/21/2010 12:13 PM, Grant Edwards wrote:
> On 2010-12-21, D Yuniskis<not.going.to.be@seen.com> wrote: > >>> I prefer long lines, reads much better. >>> >>> Then you're in a small minority. Cognative research shows that long >>> lines are harder to read for pretty much everybody else. >> >> Agreed -- though I may have some "inherent" issue with "minimizing >> head/eye motion" (e.g., my workstations are designed so I don't have >> to move my head to see different monitors). >> >> Short lines (e.g., 2 or 3 column format) read *much* quicker (IMO) >> than long ones. Just the difference between a paperback and a >> "hard-bound" tome alone is significant (though I wonder if that isn't >> because the actual *physical* width of the text is smaller?). > > The research that I've read over the years indicates that both > physical width (specifically the angle subtended by the line), and the > number of characters had an effect.
The former seems to coincide with my experience. I had assumed it "trumped" the latter. (?) I would have to think about how/why "character count" would be significant (barring the obvious correlation that, for a given "angle", more characters means *smaller* characters).
>> With short line lengths, you never lose sight of the left edge >> of the column. So, moving to the next line requires less >> visual (subconscious) "hunting". > > Right. The longer the line, the harder it is to jump to the beginning > of the next line without getting "lost" or making false starts on the > wrong line.
Setting the type "ragged right" actually helps with readability. But, it doesn't "look pretty". DTP is a lot more "art" than one would think. You *assume* it's just a matter of getting everything to fit on the page and making it "look pretty". In fact, making something that is "easy to read" (i.e., so that it doesn't interfere with the *content*) can be very difficult. Knuth (?) commented that once you start designing fonts, it is hard NOT to look at EVERY font that you encounter with a critical eye. I.e., you stop seeing things as "words on paper" but, instead, start inspecting individual glyphs, kerning, etc. The same is true of DTP -- you look at why someone opted for "big caps", or outdents, or... Always fun to see newbies using dozens of "fonts", colors, etc. Starts to read like: "LeAvE $1,o0o,00o iN a PapuR bAg uNDer tHe BRidgE at 5tH & MaIn iF yOu EVeR wANt tO sEe yOuR..." :>
On 12/21/2010 12:12 PM, Jan Panteltje wrote:
> On a sunny day (Tue, 21 Dec 2010 12:11:41 -0700) it happened D Yuniskis > <not.going.to.be@seen.com> wrote in<ieqtk7$rel$1@speranza.aioe.org>: > >> OTOH, when reading a paperback (or columnar text), it seems like >> my eyes just *dart* right and left and spend most of their time >> moving smoothly down the page. > > What I cannot stand is text with embedded pictures, where the text > 'flows' around the picture.
Too often, this is done for "artistic effect" -- without good reason. It's as if the person designing the publication just "discovered" some feature and is now playing with it (the same holds true of abusing typefaces, etc.) OTOH, there are times when it can be very advantageous to flow text around a picture -- if the alternative is *breaking* the text for an insignificant (small) picture. E.g., in a newsletter I put together for a local library, I was describing a gizmo gifted to the library that would allow them to hang/display works of art from local artists. The "hanger" onto which individual items are hung is insignificant. But, to describe how the "system" worked, it was necessary to include a photo of it. I included it *exactly* like your example below as this gave it *only* the space it "deserved" yet allowed it to be included. For an example of this, see the center of page 4 at http://www.fkbcl.org/f/Spring_2009_Newsletter.pdf also note the fancy photos! The software that does this is BFM as far as I am concerned! I'm sure there is a "simple" explanation for how it works but it always amazes me how "one click simple" it is to use! Though I need to learn how better to *take* the photos that it pieces together -- i.e., the room depicted in the cover photo is rectangular! :< For an example of the advantage of including photos at high resolution, zoom in on the individual pictures of the artworks on page 4 -- you can even see the texture of the "stucco" walls! (for an example of NOT using high resolution imiages, repeat the exercise for the book covers on page 5!) [note to Tim (OP): decide if it is worthwhile for your articles to open with a ToC (bookmarks) on the left, as in this example, or not. E.g., I've found that opening a document in "facing pages" mode is usually a *bad* idea -- as the document "always" starts with a recto page ... *wasting* half of the screen! You can also see that *only* the fonts used in the publication are embedded in it -- *AND* that the "special" fonts (e.g., the "display" font used for article titles) are *deliberately* included -- since I didn't expect most systems to have those available] Note that the way you layout a technical publication differs from the way you layout something like this newsletter. Different audiences, different emotional connections (in this case, trying to create interest *in* the library)
> I means what those DTP programs sometimes > produce, and then they use variable spacing between the WORDS > to get even line length... terrible.
Things are much better with modern DTP tools. In years past, to pad a line to full length, you had to insert *whole* spaces. For fixed width fonts (e.g., courier), this can be "like fingernails scraping on a chalkboard". Note that most tools will also play games balancing column lengths (if you so choose). Some will even use *variable* line SPACING to achieve this!
> In this picture you | pic | > see the cat | of | > jump on the table | cat | > on the next page _____ > the cat is shown eating the mouse
On a sunny day (Tue, 21 Dec 2010 13:21:46 -0700) it happened D Yuniskis
<not.going.to.be@seen.com> wrote in <ier1nk$5b1$1@speranza.aioe.org>:

>OTOH, there are times when it can be very advantageous to >flow text around a picture -- if the alternative is >*breaking* the text for an insignificant (small) picture. > >E.g., in a newsletter I put together for a local library, >I was describing a gizmo gifted to the library that would >allow them to hang/display works of art from local artists. >The "hanger" onto which individual items are hung is >insignificant. But, to describe how the "system" worked, >it was necessary to include a photo of it. I included it >*exactly* like your example below as this gave it *only* >the space it "deserved" yet allowed it to be included. > >For an example of this, see the center of page 4 at >http://www.fkbcl.org/f/Spring_2009_Newsletter.pdf
Yes, but this is done correctly, it even emphasises the word 'hangers'. My compliments for this newsletter, best I have seen in a very long time if not ever.
>also note the fancy photos! The software that does this >is BFM as far as I am concerned! I'm sure there is a >"simple" explanation for how it works but it always >amazes me how "one click simple" it is to use! Though >I need to learn how better to *take* the photos that >it pieces together -- i.e., the room depicted in the >cover photo is rectangular! :< > >For an example of the advantage of including photos >at high resolution, zoom in on the individual pictures >of the artworks on page 4 -- you can even see the texture >of the "stucco" walls!
xpdf goes to 400%, I can zoom some more by changing to a lower X resolution :-) Yes I see the texture.
>(for an example of NOT using high resolution imiages, >repeat the exercise for the book covers on page 5!)
Yes I see the jpeg artefacts in Mark Twain's
>[note to Tim (OP): decide if it is worthwhile for your >articles to open with a ToC (bookmarks) on the left, >as in this example, or not. E.g., I've found that >opening a document in "facing pages" mode is usually >a *bad* idea -- as the document "always" starts with >a recto page ... *wasting* half of the screen! You can >also see that *only* the fonts used in the publication >are embedded in it -- *AND* that the "special" fonts >(e.g., the "display" font used for article titles) >are *deliberately* included -- since I didn't expect >most systems to have those available] > >Note that the way you layout a technical publication differs >from the way you layout something like this newsletter. >Different audiences, different emotional connections >(in this case, trying to create interest *in* the library) > >> I means what those DTP programs sometimes >> produce, and then they use variable spacing between the WORDS >> to get even line length... terrible. > >Things are much better with modern DTP tools. In years past, >to pad a line to full length, you had to insert *whole* >spaces. For fixed width fonts (e.g., courier), this can be >"like fingernails scraping on a chalkboard". > >Note that most tools will also play games balancing column >lengths (if you so choose). Some will even use *variable* >line SPACING to achieve this! > >> In this picture you | pic | >> see the cat | of | >> jump on the table | cat | >> on the next page _____ >> the cat is shown eating the mouse
Yes, when I ever have the time I may try to find a good DTP program for Linux that actually installs (tried some in the past without much luck). At very old age, if I get that far, when all I can do is press a key, maybe I should write a book. Although these days it is probably 'twitter'. :-)
On a sunny day (Tue, 21 Dec 2010 13:50:30 -0700) it happened D Yuniskis
<not.going.to.be@seen.com> wrote in <ier3dg$96o$1@speranza.aioe.org>:

><grin> This is what I was "competing" with: > >Before: >http://www.fkbcl.org/f/Fall_2009_Newsletter.pdf
# wget http://www.fkbcl.org/f/Fall_2009_Newsletter.pdf --21:44:41-- http://www.fkbcl.org/f/Fall_2009_Newsletter.pdf => all_2009_Newsletter.pdf' Resolving www.fkbcl.org... 69.90.45.41 Connecting to www.fkbcl.org|69.90.45.41|:80... connected. HTTP request sent, awaiting response... 404 Not Found 21:44:42 ERROR 404: Not Found.
>While I am an advocate of FOSS (though don't run Linux), I am >not a zealot. I *gladly* avail myself of the tools that are >available under (e.g.) Windows. Especially if they make my life >easier or my "product" better!
Yea, but I burned my XP disk, as it wasted too much time. So far Linux has always helped me out, did not want to put too much time into that DTP stuff back then, I write my web pages in html with a text editor.
>> At very old age, if I get that far, when all I can do is press a key, >> maybe I should write a book. >> Although these days it is probably 'twitter'. >> :-) > ><frown>
Yes, I frown on that too, but the younger generation seems to use it a lot.
Hi Jan,

On 12/21/2010 1:25 PM, Jan Panteltje wrote:
> On a sunny day (Tue, 21 Dec 2010 13:21:46 -0700) it happened D Yuniskis > <not.going.to.be@seen.com> wrote in<ier1nk$5b1$1@speranza.aioe.org>: > >> OTOH, there are times when it can be very advantageous to >> flow text around a picture -- if the alternative is >> *breaking* the text for an insignificant (small) picture. >> >> E.g., in a newsletter I put together for a local library, >> I was describing a gizmo gifted to the library that would >> allow them to hang/display works of art from local artists. >> The "hanger" onto which individual items are hung is >> insignificant. But, to describe how the "system" worked, >> it was necessary to include a photo of it. I included it >> *exactly* like your example below as this gave it *only* >> the space it "deserved" yet allowed it to be included. >> >> For an example of this, see the center of page 4 at >> http://www.fkbcl.org/f/Spring_2009_Newsletter.pdf > > Yes, but this is done correctly, it even emphasises the word 'hangers'. > > My compliments for this newsletter, best I have seen in a very long time if not ever.
<grin> This is what I was "competing" with: Before: http://www.fkbcl.org/f/Fall_2009_Newsletter.pdf And "since": http://www.fkbcl.org/f/Spring_2010_Newsletter.pdf If you actually *read* them (with an eye towards spelling, punctuation, grammar and content), you'll see big "differences". <wink>
>> also note the fancy photos! The software that does this >> is BFM as far as I am concerned! I'm sure there is a >> "simple" explanation for how it works but it always >> amazes me how "one click simple" it is to use! Though >> I need to learn how better to *take* the photos that >> it pieces together -- i.e., the room depicted in the >> cover photo is rectangular! :< >> >> For an example of the advantage of including photos >> at high resolution, zoom in on the individual pictures >> of the artworks on page 4 -- you can even see the texture >> of the "stucco" walls! > > xpdf goes to 400%, I can zoom some more by changing to a lower X resolution :-) > Yes I see the texture.
It seemed "appropriate" to give the reader/viewer that ability wrt the photos. E.g., you can almost read the label on the "hanger"! I had argued that making the on-line version of the newsletter MORE APPEALING than the "print" version could help migrate people away from the print version (which would cut costs). This is one of the things that gave the "reader" more value in this electronic form than its print counterpart.
>> (for an example of NOT using high resolution imiages, >> repeat the exercise for the book covers on page 5!) > > Yes I see the jpeg artefacts in Mark Twain's
I didn't hunt down the individual titles and take photos of their covers. Instead, I lifted the images from the libraries on-line catalogue. There was enough detail to *suggest* the title of each book (note they are explicitly listed in the article) which I thought was enough for that "application". (I assembled the document remotely --- while I was attending to some family problems "back east" -- so I didn't have access to any of these physical items)
>> [note to Tim (OP): decide if it is worthwhile for your >> articles to open with a ToC (bookmarks) on the left, >> as in this example, or not. E.g., I've found that >> opening a document in "facing pages" mode is usually >> a *bad* idea -- as the document "always" starts with >> a recto page ... *wasting* half of the screen! You can >> also see that *only* the fonts used in the publication >> are embedded in it -- *AND* that the "special" fonts >> (e.g., the "display" font used for article titles) >> are *deliberately* included -- since I didn't expect >> most systems to have those available] >> >> Note that the way you layout a technical publication differs >>from the way you layout something like this newsletter. >> Different audiences, different emotional connections >> (in this case, trying to create interest *in* the library) >> >>> I means what those DTP programs sometimes >>> produce, and then they use variable spacing between the WORDS >>> to get even line length... terrible. >> >> Things are much better with modern DTP tools. In years past, >> to pad a line to full length, you had to insert *whole* >> spaces. For fixed width fonts (e.g., courier), this can be >> "like fingernails scraping on a chalkboard". >> >> Note that most tools will also play games balancing column >> lengths (if you so choose). Some will even use *variable* >> line SPACING to achieve this! >> >>> In this picture you | pic | >>> see the cat | of | >>> jump on the table | cat | >>> on the next page _____ >>> the cat is shown eating the mouse > > Yes, when I ever have the time I may try to find a good DTP program for Linux > that actually installs (tried some in the past without much luck).
While I am an advocate of FOSS (though don't run Linux), I am not a zealot. I *gladly* avail myself of the tools that are available under (e.g.) Windows. Especially if they make my life easier or my "product" better!
> At very old age, if I get that far, when all I can do is press a key, > maybe I should write a book. > Although these days it is probably 'twitter'. > :-)
<frown>
Hi Jan,

On 12/21/2010 12:18 PM, Jan Panteltje wrote:
> On a sunny day (Tue, 21 Dec 2010 19:12:35 GMT) it happened Jan Panteltje > <pNaOnStPeAlMtje@yahoo.com> wrote in<iequ7b$m90$1@news.datemas.de>: > > PS > I prefer it this way: > http://panteltje.com/panteltje/pic/gm_pic/
That forces you to look *past* a photo for the next bit of text. I don't "interrupt" the reader unless the interruption is "worthwhile". I.e., a reader should be able to keep reading and ignore photos, illustrations, tables, etc. if they aren't "significant enough". For example, I like to try to arrange photos/tables/etc. at the top or bottom of a column so they user can conveniently ignore them. OTOH, doing this rigidly, results in a boring (visually) presentation. In the newsletter I mentioned (elsewhere), for example, I took liberties with which "articles" were on each page. And, did some significant editing to those articles to cause images to fall where I wanted them. When I do technical presentations, I try to silently impose a structure on each page so the reader knowws where to look for things. E.g., if I have "screenshots" in the document, then I might opt to "always" put them in the same relative position on a page -- so the user's "muscle memory" directs him to the text or image, as appropriate (without having to "hunt")
On 21/12/10 21:21, D Yuniskis wrote:
> On 12/21/2010 12:12 PM, Jan Panteltje wrote: >> On a sunny day (Tue, 21 Dec 2010 12:11:41 -0700) it happened D Yuniskis >> I means what those DTP programs sometimes >> produce, and then they use variable spacing between the WORDS >> to get even line length... terrible. > > Things are much better with modern DTP tools. In years past, > to pad a line to full length, you had to insert *whole* > spaces. For fixed width fonts (e.g., courier), this can be > "like fingernails scraping on a chalkboard". > > Note that most tools will also play games balancing column > lengths (if you so choose). Some will even use *variable* > line SPACING to achieve this! >
I can see the point of that - by reducing the vertical line spacing, you are reducing the area of the large space and thus its visual effect. I am not sure I like it, however - I thing the line spacing change is distracting and the space is still too big. Sometimes there is nothing that can be done to make the typesetting look good. The answer in a case like this is to slightly re-write the text until you get a good fit - not to massage the spacing to give a slightly less bad fit. The tool in question (FrameMaker) seems to do a better job than word processors, and does a reasonable job of the hyphenation, but it has a lot to learn from TeX. The typesetter (person rather than program) has missed a few points too - though again, it is typeset far better than most publications these days, and it looks very nice.