PDF is Driving me Crazy !!

[HarryT]

Originally Posted by kovidgoyal

but my point was that CLIs are more powerful, not easier. And as we gradually emerge from the dawn of computing we really should move towards the more powerful paradigm.

Sorry, I don't understand. Take a typical application, such as a web browser, a word processor, or a spreadsheet. Explain to me how it would be "more powerful" to have to type a command to follow a hyperlink on a web page, rather than simply clicking on it? Or how is it "more powerful" to use a CLI to edit a paragraph in a word processor, rather than just visually scrolling to it, and typing it?

These are the tasks that people in the "real world" use computers for!

There is, to my mind, a rather small group of specialised tasks that a command line interface is convenient for. For the vast majority of "real world" tasks that people use computers for, however, the "point and click" paradigm that a windowing interface and a mouse makes possible is so much productive.

Compare the task of writing a letter in "Word" compared with doing the same thing in "vi". Which is the better tool for the job? I think that only a masochist would choose "vi" .

[alex_d]

EDIT: forget the following, just read my next post

In talking about the learning curve you make some honorable examples. The power of regular expressions, or scripting. It is true, learning them takes time but these skills can be reused widely and are very rewarding.

However, I am talking about the steep learning curve of learning how to use the features of particular tools like ls, wget, vi, etc. There, the learning curve is completely unjustifiable. Worse, if someone were to write wget2, the learning would start all over again and if I were already proficient at wget I'd most probably just never switch. Don't you have lots of examples like that from your own experience?


"I also think that it's much easier to find new features for a command. Since each command is designed to perform a small set of tasks and all those tasks are documented in a single place (the man page or via the --help switch). Whereas for a GUI you typically have to search through help (which is as hard as searching through a man page) or if the help is inadequate you have to hunt through umpteen dialog boxes and tabs which is a god almighty pain."

You've made a non-sequitor. The new features of a GUI program are always in front of your face, you don't search for them or read through help to discover them. Only clis need you to search through help files to find new features!

And regarding you claim that searching through GUI help is just as difficult as searching through a man page... ABSOLUTELY NOT. GUI help is usually much more verbose (because it wasn't designed to stupidly spew all its contents onto a single screen) so that you're more likely to find matches using particular search terms. I don't know if I've stated it well, but it makes a huge difference.

And as for links.. you can get some links, but it's just a little icing that's tacked on. Proper help files have introductory text, an outline, and a way to pull up more in-depth articles as you peruse the briefer text. Links in man pages, if they exist, amount to only the most rudimentary "command 'a' is mentioned, so we'll link to its man page to save you the bit of trouble typing 'man a'." There is very, very poor organization and a 'man' page is meant to be just one document. A windows chm file is an entire website. As a direct result, there is too much crap in a man page when you want a quick answer, far too little explanation when you need more detail.



"So yeah I agree that GUIs are [i]initially[\i]easier to learn, but my point was that CLIs are more powerful, not easier. And as we gradually emerge from the dawn of computing we really should move towards the more powerful paradigm."

GUIs are almost always far more powerful than CLI. They're not powerful in the sense of scripting and automation, but they're far more powerful in terms of what particular programs can do, what features they expose.

But even if we do say that clis are more powerful, that power is completely useless if its consequence is stopping change. Yet that's exactly what CLIs do: halt change because no one wants to keep going through painful learning. CLIs have kept generations of people people pinned to the dawn of computing, hardly moving a step! How funny of you to mention it.

[alex_d]

In response to Harry:

You make an argument relating to mouse vs keyboard. I'd like to point out that that's really not the distinction between GUI and CLI, and that I personally try to use the keyboard whenever I can.

The real difference is that a GUI presents to you all the options, in an organized form, with labels and explanations. CLI throws you to the wolves.



You can interface to a computer using keyboards or mice, using text only or bitmaps, menus or buttons, weird interfaces that's no one even thought of, or even speech.

Yet the real issue is entirely orthogonal to that. Presenting the possible options, organizing them elegantly, and offering multiple levels of hints to what the choices do is simply the correct way to present features.

No sane person could argue otherwise. And let me reiterate that this paradigm could be easily used with the same old, simple typing of commands (similar in principle to VC#'s intellisense, not to mention syntax highlighting). Kovigdoyal, please consider this point at length. This obvious design philosophy allows applications to elegantly expose more features, and permits new applications to be adopted. In short, it leads to progress. I don't think you'll be able to disagree.

[HarryT]

Originally Posted by alex_d

Yet the real issue is entirely orthogonal to that. Presenting the possible options, organizing them elegantly, and offering graphical and textual hints to what the choices do is the correct way to present an interface (now that our displays and memory aren't ridiculously limited.)

That's exactly what I said earlier - that in a GUI application you can have all the possible things that it's valid to do at that point nicely presented to you in (for example) a menu or a a dialog box, rather than having to learn a cryptic command for each one.

Eg, in a word processor, the toolbar gives you instant visual feedback on the most common things it's possible to do to text - make it bold, italic, underline, etc. For the less commonly used options, I can go to the "Format" menu and immediately see in front of me a list of all the formatting operations I might want to do at that point.

The primary advantage of a GUI such as Windows (or the Mac, or any other GUI interface) is the fact that every (properly written) application presents a consistent interface to the user. Learn how to open a file once in Windows, and you know how to open a file in every application. Learn how to make text "bold" once, and you know how to do it in every application in which it's a valid operation.

[NatCh]

Originally Posted by HarryT

Sorry, I don't understand. Take a typical application, such as a web browser, a word processor, or a spreadsheet. Explain to me how it would be "more powerful" to have to type a command to follow a hyperlink on a web page, rather than simply clicking on it? Or how is it "more powerful" to use a CLI to edit a paragraph in a word processor, rather than just visually scrolling to it, and typing it?

Okay, I think I can help with the concept here. You're actually looking right at it, but you're not 'looking right.'

So, to take the concept completely away from computers where it might be seen in sharper relief, I ask you to consider Public Address equipment, loudspeakers, I mean.

I run sound-boards at church, and have for a couple of decades now. It's not the complex business that you'd get into at a recording studio, or radio station, but we have a sound-board with lots of knobs and sliders, so it's somewhat complex.

Originally, all we had were a few microphones, some speakers in the wall and a single box amplifier with about 2 knobs on it: power and volume.

These days we have a board with about 12 channels each of which has a slider and a dozen knobs for various functions, plus an separate amplifier, that more or less has the same two controls, power and volume, plus the speakers and microphones ( and tape decks, and recording equipment, and CD, and DVD, etc., etc.), of course.

Both set-ups do the same thing, but the second, more complex one, allows greater control of the operation. If person A's mike sounds a bit tinny, I can tweak the equalizer settings for that channel and fix it. If person B sounds too soft, I can turn just his mike a bit louder, and fix it. I couldn't do either of those things with the old "One Box" system.

But on the other hand, the One Box's learning curve was a short, gentle slope, and the soundboard's is a towering cliff, if you're coming at it cold. But, that very complexity is what gives us greater control over the end result. It's a more powerful interface specifically because it's more complex. That's what makes the greater complexity worth the bother.

Now, to put it back into the original context, the GUI makes it much easier to do the things that it covers, the learning curve on them is quite gentle, but the GUI does only the things it's programmed to do in the way it's programmed to do them -- if you don't like the results, you're still stuck with them. The very fact that the CLI tries to do less for you means that it can offer more flexibility in how whatever you're doing gets done. Yes it takes a lot more time and effort to get to where you can do anything of any significance, but once you do, you have a lot more control over the final result. Sometimes that's a bad thing, of course.

That's all generally speaking, of course, I do realize that there are examples of CLI's that offer no flexibility, and GUI's that offer tuns of it, but I'm just trying to highlight how greater complexity can offer a more powerful interface as a trade-off for that complexity.

I said that you were looking at the solution, but not looking at it right: what I meant was the keyboard mouse thing: the mouse is a lot easier to use for navigation, and in many cases control, but if you had only a nice, elegant, simple mouse, data entry would be a complete nightmare. The keyboard's greater complexity allows you a more powerful data entry mechanism. Conversely, the keyboard's very complexity prompted the invention of the mouse because navigation is kind of a pain on a keyboard, it has a steep learning curve for that sort of thing.

Originally Posted by HarryT

Compare the task of writing a letter in "Word" compared with doing the same thing in "vi". Which is the better tool for the job?

This comment is sooo close to the point I'm making, but just a bit off. The question of GUI vs. CLI isn't so much whether you'd prefer to write a letter in Word or vi, but rather would you prefer to write a letter with only your mouse or only your keyboard?

[HarryT]

Hmmm. I hear what you're saying, Nat, but I'm not sure that I agree with you. Whether an application has a GUI or a CLI has nothing to do with whether or not it lets you "tweak the difficult bits".

Eg, for many years I've used a Windows FTP shareware app called "CuteFTP". At its simplest level, you can just drag and drop files into it. For the "advanced" user, though, it lets you do everything that the command-line FTP client does, plus "advanced" stuff like scripting, macros, etc. Being a GUI doesn't stop it from offering advanced features, but it does mean that the novice doesn't have to learn all the nasty bits of FTP in order to be able to use it.

Similarly with "Word". At its easiest level you can just run it and type a letter. For the advanced user it's fully programmable with a fully-fledged programming language (VBA). Having a GUI doesn't stop it from having advanced features.

Having said all that, I am completely comfortably using command-line FTP clients and the like, for the simple reason that in my job as an IT professional I need to know how to use such tools because they are the only ones I can guarantee will be present on a customer's machine. Given the choice, though, of using command-line FTP or a nice GUI such as CuteFTP, I'll use the GUI every time.

[NatCh]

Yeah, those would be excellent examples of extremely versatile, powerful GUIs. But they're also extremely complex, which was the point I was trying to illustrate: that complexity can allow greater control and flexibility. Of course sometimes more complicated is just more complicated.

And I agree with you wholeheartedly, I'd generally rather use a GUI, assuming it's not a real beast.


Reminds me of a professor I knew about back at Texas A&M. Computer Science prof, no less, who insisted (in 1994) that everything beyond DOS 2.3 (or some such) was just extra fluff and unnecessary -- but boy did that DOS 2.3 run really fast on that Pentium!

[kovidgoyal]

Hmm lots of good points. I agree with you Alex that a GUI is an excellent paradigm for presenting a limited set of options in an easily accessible manner. However, once you need to do more than a limited set of tasks GUI's become a handicap. An illustration of this is Word vs. Tex for typesetting complex documents. I admit Word is much simpler to learn, but its a lot harder to achieve the same level of productivity and quality for non-trivial tasks. The reason is because in a WYSWIG editor you basically have to tell the program exactly where and how you want every visual element, whereas in Tex you simply tell the program what you need and let it figure out the best way to do it. And because Tex is command driven you have ultimately much more flexibility, you can even specify exactly how you want things positioned like in a WYSWIG. @Harry I guess I'm saying here that I would pick vim over Word (or any WYSWIG approach) any day :-)

So perhaps we need to make a distinction here between Command Interfaces and Command line interfaces. For instance, Alex when you talk about using the keyboard in explorer what you're doing is using a command interface rather than a point-and-click interface. This ties in with what Nat was saying before.

I also agree that GUIs have been very good at easing the initial adoption of computer use, but that's precisely my point. It's time we moved beyond the initial phase.

[groosh]

This might be slightly off topic, but does anyone know how to change the size of the pages of a file that is already in pdf format? So, put simply, I have pdf's in regular size but need them in a smaller size so they are easier to read.

[Azayzel]

Originally Posted by groosh

This might be slightly off topic, but does anyone know how to change the size of the pages of a file that is already in pdf format? So, put simply, I have pdf's in regular size but need them in a smaller size so they are easier to read.

Actually, this was right on topic before the discussion moved to the battle of the CLI vs. the GUI.

if you want to change the existing page size to something that will look better on the Reader, use PDFRasterfarian or PDFRead to perform their magic on the file. If you have the original PDF; i.e., one that includes the original text and isn't simply an image, you can use Acrobat Pro to reflow the PDF to a custom page size (I detailed how to do this earlier in the thread, check toward the top). Likewise, if you have the PDF with the text still embedded, you can copy/paste the text into BookDesigner and have it put out a device-ready LRF.

[RWood]

As someone that grew up on IBM 360/370 systems and (at one time) spoke fluent JCL, both CLI (and CI) and GUI are major steps forward from the way things were. If I never see another keypunch machine or a line of code starting with "// " again I will be happy.

Part of the future will be natural language interfaces -- yes, a return to typing or speaking. Rather than point and click or invoking the name of the program, the method would be one of typing or speaking something like "edit my resume" or "move Sherlock Holmes to the Reader."

Over 20 years ago (back before PC speech was mandated) I was addressing a group of new hires in the company and presented a vision of the future of computing that involved the user in a beach chair with the waves breaking in the background and a chorus of exotic dancers came up and while still dancing asked what it was that I wished to know. I told them and they danced off. Sometime later they returned and gave me the information I asked for. I still maintain that that is a superior interface to either CLI or GUI.

[groosh]

The converting sizes of pdf's worked great. I have a further question. How about converting a txt file to something optimized to read on the sony?

[RWood]

Originally Posted by groosh

The converting sizes of pdf's worked great. I have a further question. How about converting a txt file to something optimized to read on the sony?

If there are no graphics in the file, I have found that RTF is quick and simple. It is resizable through the font button (S-M-L) and the Sony performs a type of compression so its doesn't take up that much storage space.

Stingo wrote a macro (click on the Wiki in the top right of the screen and select conversion) that runs in MS Word that removes the line breaks assuming that the original TXT file had double returns (i.e.: blank line) between paragraphs. Most do although some indent the first line with either a series of spaces or a tab character and those are easy enough to change to double returns. You can also set the Title and Author in the File|Properties section so it will show up correctly in the Book and Author listings.

RTF does not provide a Table of Contents or chapter headings. For that you may want to look into a product that creates LRF files. (That's the Sony BBeB format with any Digital Rights Management or DRM.) All of the books in the MobileRead Sony Uploads section are this format. The two tools that seem to be used the most are BookDesigner and linprs500 (which has a component called html2lrf.) Links to both of these can also be found on the Wiki conversion page.

Harry has written a great conversion guide using BookDesigner that can be found in the forums.

Good luck and don't be afraid to ask for more help.

[NatCh]

It'll handle your TXT file just fine as it is, groosh. You can convert it to an RTF or LRF if you really want to, but with a TXT file you won't really get anything extra out of it.

[mogui]

Originally Posted by RWood

. . . I was addressing a group of new hires in the company and presented a vision of the future of computing that involved the user in a beach chair with the waves breaking in the background and a chorus of exotic dancers came up and while still dancing asked what it was that I wished to know. I told them and they danced off. Sometime later they returned and gave me the information I asked for. I still maintain that that is a superior interface to either CLI or GUI.

Yes, the DGUI (Dancing Girl User Interface) is one of my all-time favorites. We haven't invented them all yet have we?

Continuing the subtopic, the *ix command line allows me to do complex tasks by constructing complex commands on one line that route my data through many processes. I can put these complex commands into scripts. I can, in turn, put the scripts into other complex command lines. Life is beautiful!

But I mostly use the GUI