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

I used Acrobat Pro 9 on Windows XP. Acroreader 9 on OpenSuse also looks terrible. Looks fine in Evince on the same machine. So it looks like it is Acrobat. Unfortunately that is one PDF Viewer it has to look nice on.

Regards Anton Erasmus

I used 26.99947. I wrote a horrible Basic program that explored the possible selections of available crystals, divided IRQ rates, divided channel rates (16 channels), and possible aliases of the sample rate against line harmonics. All against a guess about avaliable compute power. It was one of those ill-posed problems with no hard quality metric, just a guess as to which solution felt better.

The current harmonics have no real power, at least as long as the voltage waveform is sinusoidal, which it usually sort of is.

Most power people are only concerned with the 10th or maybe 15th harmonic.

Fun, but overkill. The line voltage and currents are constantly jumping around anyhow.

John

In comp.dsp John Larkin wrote: (snip)

I remember a story in an undergrad quantum mechanics class about some radar designers that believe that Heisenberg uncertainty applied to the returning radar reflection.

Unless the source impedance is too high, such as it might be at the end of a long extension cord with small wire.

If you have 1/n harmonic distribution, as from a square wave or from an SCR light dimmer, then you can figure how many harmonics you need from the error tolerance. I might have wanted to go to 1MHz, but 256*60 isn't so far off.

-- glen

In comp.dsp John Larkin wrote: (snip, I wrote harmonics up to...)

It is supposed to be that the most popular crystal is 3579545Hz, as needed for NTSC color TV demodulation. That isn't likely to be a nice multiple of other common frequencies. (Maybe now that analog broadcasting has ceased, the crystals will be harder to find.)

That sounds right. Though I do remember an undergrad physics lab where we looked at the power line with an oscilloscope. It seems that they had a voltage regulating transformer with a large third harmonic. Not so common, though.

I suppose that sound right. The reason to be concerned with the higher ones is the effect on AM radios, but the actual power is pretty low.

(snip)

I was thinking that the PLL might be cheaper than a crystal, but maybe not, and maybe it doesn't matter much. 27Hz is far enough that you don't have to worry about low harmonics even if the crystal is a little off.

-- glen

Nope, looks like it's a Lyx problem (1.6.7 here).

A quickie foo.tex with a minimal header (just \documentclass{article}, \usepackage{amsmath}, and \begin{document}) produces peachy (vector) output when run from the command line through "latex foo.tex" then "dvipdfm foo.dvi" or straight to pdf with "pdflatex foo.tex".

However, the Lyx output, when exported with any of its three pdf options, produces the blocky bitmap-style typefaces.

TeXnic Center's GUI did okay (more peachy output). Didn't try any of the other GUI wrappers.

Unfortunately, that's true. If you have a lot of full-width diagrams or listings, you sort of end up picking your pain. Either the layout is choppy and difficult to manage, lines are too long, or you end up wasting a lot of paper using wider margins and a larger font.

I know what you mean.

Oh, I agree. The typography is certainly better than 99+ percent of what's out there, so we are indeed picking nits.

I've read parts of it, but the only thing I felt qualified to comment on was the typesetting. :)

I think there is some magic ratio of text to graphics (treating tables as graphics) that you must exceed in order for there to be enough text to flow around the graphics.

I think you can probably cheat -- a little -- by using 3/4 wide tables/graphics. I.e., break one column and let the other column flow around it. But, that presumes you won't have a graphic sitting in that "other" column, too. :<

Or, resort to tiny text, etc. in any inserts.

Hi,

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

Regards Anton Erasmus

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

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

bye Andreas

-- Andreas Hünnebeck | email: snipped-for-privacy@gmx.de

----- privat ---- | www :

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.

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.

Groetjes Albert

--

On a sunny day (21 Dec 2010 15:34:45 GMT) it happened Albert van der Horst wrote in :

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.

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

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.

You're allowed. :)

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

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);

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

Well, years of research seems prove you wrong.

Huh?

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)

On a sunny day (Tue, 21 Dec 2010 12:11:41 -0700) it happened D Yuniskis wrote in :

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

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.

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.

On a sunny day (Tue, 21 Dec 2010 19:12:35 GMT) it happened Jan Panteltje wrote in :

PS I prefer it this way: