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.
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 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. :<
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.
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
--
--
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 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.
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.
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).
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..." :>
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
formatting link
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)
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!
On a sunny day (Tue, 21 Dec 2010 13:21:46 -0700) it happened D Yuniskis wrote in :
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.
xpdf goes to 400%, I can zoom some more by changing to a lower X resolution :-) Yes I see the texture.
Yes I see the jpeg artefacts in Mark Twain's
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 wrote in :
# wget
formatting link
--21:44:41--
formatting link
=> all_2009_Newsletter.pdf' Resolving
formatting link
69.90.45.41 Connecting to
formatting link
|69.90.45.41|:80... connected. HTTP request sent, awaiting response... 404 Not Found
21:44:42 ERROR 404: Not Found.
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.
Yes, I frown on that too, but the younger generation seems to use it a lot.
If you actually *read* them (with an eye towards spelling, punctuation, grammar and content), you'll see big "differences".
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.
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)
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!
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")
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.