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

Dombo wrote:

> [..]. On a 1920x1200 screen with Acrobat Reader the text
> isn't as comfortable to read as in most PDFs. When watching it with
> pages side-by-side (as I do with most documents) or at 100% the fonts
> are too thin/light.

Same here on Linux with Acrobat Reader 9.4.1 (1600x1200 display). 
xpdf looks best (as good as Acrobat, but not that thin), evince looks
horrible if not viewed at 300% or more.

bye
Andreas
-- 
Andreas H�nnebeck | email: acmh@gmx.de
----- privat ---- | www  : http://www.huennebeck-online.de
Fax/Anrufbeantworter: 0721/151-284301
GPG-Key: http://www.huennebeck-online.de/public_keys/andreas.asc
PGP-Key: http://www.huennebeck-online.de/public_keys/pgp_andreas.asc

Anton Erasmus wrote:

> Your new updated version looks MUCH better now. Fonts are all vector,
> and it displays correctly in all the viewers I tried.

Same here (Linux), acrobat reader, evince and xpdf all look perfect.

bye
Andreas
-- 
Andreas H�nnebeck | email: acmh@gmx.de
----- privat ---- | www  : http://www.huennebeck-online.de
Fax/Anrufbeantworter: 0721/151-284301
GPG-Key: http://www.huennebeck-online.de/public_keys/andreas.asc
PGP-Key: http://www.huennebeck-online.de/public_keys/pgp_andreas.asc

On 21/12/2010 03:32, Grant Edwards wrote:
> On 2010-12-20, David Brown<david.brown@removethis.hesbynett.no>  wrote:
>> On 20/12/10 17:57, Grant Edwards wrote:
>>> On 2010-12-20, Cesar Rabak<csrabak@bol.com.br>   wrote:
>>>> Em 20/12/2010 05:34, Tim Wescott escreveu:
>>>>> I know there's a few people out there who actually read the papers that I
>>>>> post on my web site.
>>>>>
>>>>> I also know that the papers have gotten a bit ragged, and that I haven't
>>>>> been maintaining them.
>>>>>
>>>>> So here: I've made a start.
>>>>>
>>>>> http://www.wescottdesign.com/articles/Sampling/sampling.pdf
>>>>>
>>>>> My intent (with apologies to all of you with dial-up), is to convert the
>>>>> ratty HTML documents to pdf as time permits, and in a way that leaves the
>>>>> documents easily maintainable and in a form that is easy to look at from
>>>>> the web or to print out, as you desire.
>>>>
>>>> I gave a diagonal look at the paper, as I got curious about the
>>>> complaints on the font.  They look OK to me :-) I'm used to read math's
>>>> articles written in CMR fonts so perhaps I'm not a good judge on this.
>>>
>>> I don't see anything at all wrong with the font.  The one thing that I
>>> would change is the line length.  It looks like a typical line is
>>> upwards of 110 characters.  That's a bit too much to read comfortably.
>>> If you want to use a font that small, and don't want wide margins, I'd
>>> recommend going to a two-column format.
>>
>> I agree that the line width is /slightly/ too wide for comfort, but I'd
>> avoid two-column format unless I were trying to save the last few trees
>> on the planet.
>
> [...]
>
>> If we are going to nit-pick on the typography (which seems a little
>> unfair, given that it is vastly better than in most papers),
>
> Oh, I agree. The typography is certainly better than 99+ percent of
> what's out there, so we are indeed picking nits.
>
>> I still haven't got round to reading the document itself - I hope the
>> contents are worth the effort in the presentation!
>
> I've read parts of it, but the only thing I felt qualified to comment
> on was the typesetting.  :)
>

I'm in the same position.  I not only own copies of the TeXbook, the 
METAFONTbook, and the LaTeX Document Preparation System, but I've read 
them too :-)  On the other hand, when Tim writes something on DSP, I 
consider it gospel until proven otherwise by the other smart folks in 
comp.dsp.

In article <QLWdne913NWJmpLQnZ2dnUVZ_v-dnZ2d@web-ster.com>,
Tim Wescott  <tim@seemywebsite.com> wrote:
>I know there's a few people out there who actually read the papers that I
>post on my web site.
>
>I also know that the papers have gotten a bit ragged, and that I haven't
>been maintaining them.
>
>So here: I've made a start.
>
>http://www.wescottdesign.com/articles/Sampling/sampling.pdf
>
>My intent (with apologies to all of you with dial-up), is to convert the
>ratty HTML documents to pdf as time permits, and in a way that leaves the
>documents easily maintainable and in a form that is easy to look at from
>the web or to print out, as you desire.

I'd really hate to see documents with a low content/volume ratio
to appear on the net. Like user manuals that are bitmaps of
commercial flyers.
If html is replaced by bitmaps, the visually
impaired can no longer enlarge the fonts and braille terminals
are totally out of the question. And the net becomes unusable for
people at Ivory Coast, slowly but surely.
I hear that there are lines with 110 char's. You know that
professional type setters aim at 60/68 characters/line.
(Look at news papers. Look at a novel that has been printed before
the computer era.) So regardless whether it looks good, it doesn't
read well.

Please find a way to separate textual content and formatting.
Postscript can do the job. (You can add fonts, but you can also
rely on built in fonts.) The preoccupation with how it looks
on this years screens and this years printers is not good.
The content is probably good twenty years from now.
Character based content has brought forth our civilisation. Are we
going back to hieroglyphs?

I generate all my documents for the ciforth project via texinfo
in html, postscript and pdf format and make all three available
(and the source as well).
I try to keep documentation content-oriented.
Acrobat's left content window, and clickable indices are great
as is the "back" key.
I generally use Acrobat version 5 to view acrobat documents,
the last good acrobat. (Maybe we should have a clone of that program
and a downgrader of "modern" acrobat formats to be acceptable
for the acrobat 5 clone.)

These are general concerns. I appreciate that you cannot solve
these kind of problems just in behalf of *your* documentation.

>
>--
>http://www.wescottdesign.com

Groetjes Albert


--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

In article <QLWdne913NWJmpLQnZ2dnUVZ_v-dnZ2d@web-ster.com>,
Tim Wescott  <tim@seemywebsite.com> wrote:
>I know there's a few people out there who actually read the papers that I
>post on my web site.
>
>I also know that the papers have gotten a bit ragged, and that I haven't
>been maintaining them.
>
>So here: I've made a start.
>
>http://www.wescottdesign.com/articles/Sampling/sampling.pdf
>
>My intent (with apologies to all of you with dial-up), is to convert the
>ratty HTML documents to pdf as time permits, and in a way that leaves the
>documents easily maintainable and in a form that is easy to look at from
>the web or to print out, as you desire.

I'd really hate to see documents with a low content/volume ratio
to appear on the net. Like user manuals that are bitmaps of
commercial flyers.
If html is replaced by bitmaps, the visually
impaired can no longer enlarge the fonts and braille terminals
are totally out of the question. And the net becomes unusable for
people at Ivory Coast, slowly but surely.
I hear that there are lines with 110 char's. You know that
professional type setters aim at 60/68 characters/line.
(Look at news papers. Look at a novel that has been printed before
the computer era.) So regardless whether it looks good, it doesn't
read well.

Please find a way to separate textual content and formatting.
Postscript can do the job. (You can add fonts, but you can also
rely on built in fonts.) The preoccupation with how it looks
on this years screens and this years printers is not good.
The content is probably good twenty years from now.
Character based content has brought forth our civilisation. Are we
going back to hieroglyphs?

I generate all my documents for the ciforth project via texinfo
in html, postscript and pdf format and make all three available
(and the source as well).
I try to keep documentation content-oriented.
Acrobat's left content window, and clickable indices are great
as is the "back" key.
I generally use Acrobat version 5 to view acrobat documents,
the last good acrobat. (Maybe we should have a clone of that program
and a downgrader of "modern" acrobat formats to be acceptable
for the acrobat 5 clone.)

These are general concerns. I appreciate that you cannot solve
these kind of problems just in behalf of *your* documentation.

>
>--
>http://www.wescottdesign.com

Groetjes Albert


--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On a sunny day (21 Dec 2010 15:34:45 GMT) it happened Albert van der Horst
<albert@spenarnc.xs4all.nl> wrote in <ldsb9x.ds1@spenarnc.xs4all.nl>:

>I hear that there are lines with 110 char's. You know that
>professional type setters aim at 60/68 characters/line.

I do disagree.
My current Linux rxvt terminal setting is let's see: 235 columns.
That is the window for the editor 'joe' that I type my source code in,
AND this reply.
Even in Usenet there is no line size limit, although exceeding 78 columns would give the usual complainers something to write about.

Especially in C code, things move to the right with a lot of tabs,
and printf also likes space:
                        fprintf(stderr, "xscpc: detected a line length of more than %d characters, looks like you are not connected to a sc_pic device, check if the correct serial device is specified!\n", RX_BUFFER_SIZE - 1);

Of course you can break lines with '\', but why make things less readable.

So I'd say, especially these days with 16:9 screens, the wider the better.
Of course all bets are off if you use MS windows and small little squares to type code in.


>(Look at news papers.


Something I try to avoid, except online.
Jobs has this idea that newspapers can be replaced by ipads...


>Look at a novel that has been printed before
>the computer era.) So regardless whether it looks good, it doesn't
>read well.

I prefer long lines, reads much better.
Sometimes I wonder if I read all these complaints about people not being able to read something or other...
The times of 12 inch CRTs viewed in half dark rooms are long past.
The time or crap products that force little windows are long past.

This is how *I* see Tim's document:
 ftp://panteltje.com/pub/sampling.gif

Now I am aware if you display that gif in a crap browser on a crap monitor, with crap lighting,
with crap settings, with crap glasses, that that picture may not help much.
But if it looks bad, check any of the things marked 'crap' above, and your eyes too.

On a sunny day (21 Dec 2010 15:34:45 GMT) it happened Albert van der Horst
<albert@spenarnc.xs4all.nl> wrote in <ldsb9x.ds1@spenarnc.xs4all.nl>:

>I hear that there are lines with 110 char's. You know that
>professional type setters aim at 60/68 characters/line.

I do disagree.
My current Linux rxvt terminal setting is let's see: 235 columns.
That is the window for the editor 'joe' that I type my source code in,
AND this reply.
Even in Usenet there is no line size limit, although exceeding 78 columns would give the usual complainers something to write about.

Especially in C code, things move to the right with a lot of tabs,
and printf also likes space:
                        fprintf(stderr, "xscpc: detected a line length of more than %d characters, looks like you are not connected to a sc_pic device, check if the correct serial device is specified!\n", RX_BUFFER_SIZE - 1);

Of course you can break lines with '\', but why make things less readable.

So I'd say, especially these days with 16:9 screens, the wider the better.
Of course all bets are off if you use MS windows and small little squares to type code in.


>(Look at news papers.


Something I try to avoid, except online.
Jobs has this idea that newspapers can be replaced by ipads...


>Look at a novel that has been printed before
>the computer era.) So regardless whether it looks good, it doesn't
>read well.

I prefer long lines, reads much better.
Sometimes I wonder if I read all these complaints about people not being able to read something or other...
The times of 12 inch CRTs viewed in half dark rooms are long past.
The time or crap products that force little windows are long past.

This is how *I* see Tim's document:
 ftp://panteltje.com/pub/sampling.gif

Now I am aware if you display that gif in a crap browser on a crap monitor, with crap lighting,
with crap settings, with crap glasses, that that picture may not help much.
But if it looks bad, check any of the things marked 'crap' above, and your eyes too.

On a sunny day (21 Dec 2010 15:34:45 GMT) it happened Albert van der Horst
<albert@spenarnc.xs4all.nl> wrote in <ldsb9x.ds1@spenarnc.xs4all.nl>:

>I hear that there are lines with 110 char's. You know that
>professional type setters aim at 60/68 characters/line.

I do disagree.
My current Linux rxvt terminal setting is let's see: 235 columns.
That is the window for the editor 'joe' that I type my source code in,
AND this reply.
Even in Usenet there is no line size limit, although exceeding 78 columns would give the usual complainers something to write about.

Especially in C code, things move to the right with a lot of tabs,
and printf also likes space:
                        fprintf(stderr, "xscpc: detected a line length of more than %d characters, looks like you are not connected to a sc_pic device, check if the correct serial device is specified!\n", RX_BUFFER_SIZE - 1);

Of course you can break lines with '\', but why make things less readable.

So I'd say, especially these days with 16:9 screens, the wider the better.
Of course all bets are off if you use MS windows and small little squares to type code in.


>(Look at news papers.


Something I try to avoid, except online.
Jobs has this idea that newspapers can be replaced by ipads...


>Look at a novel that has been printed before
>the computer era.) So regardless whether it looks good, it doesn't
>read well.

I prefer long lines, reads much better.
Sometimes I wonder if I read all these complaints about people not being able to read something or other...
The times of 12 inch CRTs viewed in half dark rooms are long past.
The time or crap products that force little windows are long past.

This is how *I* see Tim's document:
 ftp://panteltje.com/pub/sampling.gif

Now I am aware if you display that gif in a crap browser on a crap monitor, with crap lighting,
with crap settings, with crap glasses, that that picture may not help much.
But if it looks bad, check any of the things marked 'crap' above, and your eyes too.

On 2010-12-21, Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:
> On a sunny day (21 Dec 2010 15:34:45 GMT) it happened Albert van der Horst
><albert@spenarnc.xs4all.nl> wrote in <ldsb9x.ds1@spenarnc.xs4all.nl>:
>
>>I hear that there are lines with 110 char's. You know that
>>professional type setters aim at 60/68 characters/line.
>
> I do disagree.

You're allowed. :)

> My current Linux rxvt terminal setting is let's see: 235 columns.
> That is the window for the editor 'joe' that I type my source code
> in, AND this reply. Even in Usenet there is no line size limit,
> although exceeding 78 columns would give the usual complainers
> something to write about.

We're not talking about editing souce code.  We're talking about
reading prose.

> Especially in C code, things move to the right with a lot of tabs,
> and printf also likes space:
>                         fprintf(stderr, "xscpc: detected a line length of more than %d characters, looks like you are not connected to a sc_pic device, check if the correct serial device is specified!\n", RX_BUFFER_SIZE - 1);
>
> Of course you can break lines with '\', but why make things less readable.

Again, we're talking about English prose, not about C source code.

> So I'd say, especially these days with 16:9 screens, the wider the
> better.

Well, years of research seems prove you wrong.

> Of course all bets are off if you use MS windows and small little
> squares to type code in.

Huh?

>>(Look at news papers.
>
> Something I try to avoid, except online. Jobs has this idea that
> newspapers can be replaced by ipads...



>
>>Look at a novel that has been printed before
>>the computer era.) So regardless whether it looks good, it doesn't
>>read well.
>
> 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.

-- 
Grant

Hi Grant,

On 12/21/2010 11:48 AM, Grant Edwards wrote:

[attributions elided]

>>> Look at a novel that has been printed before
>>> the computer era.) So regardless whether it looks good, it doesn't
>>> read well.
>>
>> 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?).

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".  E.g., when reading Braille
(two-fisted), you read the left half of the line with our
left hand, meet up with your right hand "mid-line", finish
the line with your right hand -- while your left retraces
the line back to the start as it then seeks the start of the
next line (row).  [if you read one-handed -- typ right -- the
other hand marks the start of the line so the "active" hand can
find it more quickly]

When I read a hard-bound text, my reading rate drops precipitously.
Almost by a third.  I attribute this to the fact that my eyes
must "walk" across the page, then retrace their path as they hunt
for the next line.

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.

Writing code is a different thing, entirely.  You have *lots*
of visual cues to help you move through the "text" -- all that
indentation and decorative punctuation.  You subconsciously
know whether to seek an indented line, an outdented line, a
closing brace, etc.  (though I still constrain my code to ~80
columns so that it fits nicely on damn near *any* display
device -- print or otherwise)