borfast

I just love this patents thing... don't you? http://yro.slashdot.org/yro/04/06/02/2222258.shtml?tid=109&tid=155&tid=187&tid=99 By the way, if this one interested you, this other one might also be of interest.

Scott, the wide screen is one of my fears, too. But I think I'll get used to it. Bill, I'm looking at those two websites right now. They seem to have some pretty good stuff... I wonder how easily I could get one of those into Portugal...

Hi Ludovic, and welcome to TCH Without delay, I'll answer what I can from your questions: Certainly! You can upgrade your package at any time. Just submit a help desk ticket and it will get taken care of real fast! I can't give you a definite answer on this one but I don't think TCH offers lower plans than the ones presented. But you'll have to wait for Bill (the owner) or Mike to answer this one "officially". Yes. Each account has it's own login and password, with which you can login via IMAP or POP to fetch e-mail. SMTP doesn't need login, if I'm not mistaken. I'm not sure what is checked, since I'm only a forum moderator but one thing I can guarantee you: your account will be set up in a matter of hours. The second account I subscribed here at TCH was ready for me to start uploading content just 2 hours after I submited the order form! Well, I hope this helps clearing your questions and I hope to see you become part of the family soon

Yep, new toys are pretty cool and I sure would like to have one of those 17" PowerMacs But the price tag..... I'm going to buy a notebook myself this week. Athlon 64 2800 MHz, 512 MB RAM, 60 GB HDD, DVD-+R/-+RW (also burns CDs, of course), 15.4 WideScreen TFT display, ATI Radeon 9700 128 MB VRAM, Wireless card 54 Mbit/s (IEEE 802.11g), wired LAN (10/100 Mbps) built-in, V.90 56K modem built-in, firewire port, irda port and memory card reader that reads SecureDigital Card, MultiMediaCard, Memory Stick, Memory Stick Pro, Compact Flash Type I, Compact Flash Type II, IBM Microdrive. All this for 1499 Euro (1,835.12 USD), which is one heck of a price here in portugal.

Glad you got it working, mike Thumbs Up

Thomas, keep in mind that PDF's are not meant to be edited, they're meant as a standard format for sharing printable documents. Think of a PDF document as a printed document. If you want to change something, you open up the program from where you printed the document (a word processor, spreadsheet, whatever), change the document as you need and print it again, right? PDF is supposed to be the same. If you need to change something in a PDF, you open the program from where you created it, change the document and "print" it to PDF again. Adobe Acrobat does have some PDF editing capabilities, so yes, it is possible to edit them but due to the reason stated above, you will not find many programs that allow you to do that. If you only need to do minor changes, Acrobat is the best solution. But buying the whole thing just because of editing a few words or something like that, is not worth the high price.

schussat is right. Logging out of Gnome/KDE should be enough to switch the desktop environments.

Hi kaula. A bit of clarification: X (or as some people call it, XWindows) is the standard graphical interface for Linux (and other Unix based systems). It's rather safe to say that as long as you have a graphical display in front of you, then you're using X - there are exceptions, of course but as a general rule, this is true. Now about the login screen... it depends. If you're talking about a graphical login screen, then yes, you're using X. If you're talking about the console based login, then no, that's not X, it's... well, the console Now for the technical part of the question: if the login screen is considered an x window. I'm not sure what you (or the person who asked you this) mean by this. If you simply want to know if that's X (the graphical environment), then, as I already said, yes, it is. On the other hand, if you want to know if that's an X window as in a window "object", the code entity that represents X's windows, I don't know the answer, since I never programmed for X.

Yes, I forgot the OCR possibility. Thanks, Rob Don, good catch, I didn't recall that thread

Mattis, I think you should submit a Help Desk ticket about this. That's the proper way to handle this type of situation. Plus, you'll see your problem solved faster

Or perhaps the refresh rate...

Well, I'd say you should store the images in JPEG format, use something like OpenOffice Writer (the equivalent of MS Word) to bind all the pages together and then make use of it's internal PDF exporter to export the document. You don't spend one cent and you can do everything you want About the scanner, I can't help you there. I'm really not up to date in regards to scanners, sorry.

Frylock, yes, you can use that kind of URL for a webpage. It's just like accessing a page via htt*p://domain.com/index.php versus htt*p://domain.com/ If you don't specify which file you want from the directory (in my example, the site root), the web server will simply serve you the file index.php, or index.html, default.asp, etc, depending on how it's configured. I don't know if it's "valid" but it works...

Look here: http://www.totalchoicehosting.com/forums/i...9724

Should one be worried if one answers yes to all of them?

Saw this one on newsforge.com and I thought some people from the forums would like to read it. It talks about some stuff I've been saying for a couple of years, now. "Why you might be an unwitting spammer" http://networking.itmanagersjournal.com/networking/04/05/27/1916219.shtml And here's another one I just saw: How Gluecode led Debisys into the wide open spaces http://business.newsforge.com/business/04/05/17/1729219.shtml?tid=85

This is not a case when you can use this function but there are also a lot of paramenters that you can set via ini_set(): http://php.net/ini_set

Nice reading, Jim. Thanks Thumbs Up

Tracy, I'd say that it's a problem with the browser you're using (IE5/6, I'd guess), because it works just fine with Firefox - I get a horizontal scroll bar to sroll the window and see the areas I can't see with a browser window smaller than 800x600.

Great, now I'm going to have to skip class...

So you decided to use tables, huh... I thought you wanted to use CSS only, so I didn't even think about the table solution, sorry. I still think you should clean up your code. I know you could make that layout work using only CSS

No problem I prefer to do it that way because I'm sure that if for some reason the server where my script is had register_globals set to 1 but suddenly the admins set it to 0, my script will still work. Or if I move it to another server that has register_globals set to 0 I know I won't need to change anything to make it work

Since the question of "which weblog system to use?" has arised here, I thought I'd share this with everyone here: http://slashdot.org/articles/04/05/24/1927242.shtml?tid=126&tid=185&tid=95

Brian, $_SERVER['DOCUMENT_ROOT'] does not return an URL, it returns the document root based on the site you are requesting, just as Mike said above. Try this PHP snippet to see what we mean: ><?php echo $_SERVER['DOCUMENT_ROOT'] ?> That will show you what $_SERVER['DOCUMENT_ROOT'] returns and will help you understand why your code isn't working (notice the paths you're using and compare them with this). Aside from that, Mike and Bruce have already explained everything. By the way, Don, $DOCUMENT_ROOT will only work on servers that have the register_globals configuration directive set to 1. If register_globals is off, $DOCUMENT_ROOT will not work. Since the PHP default is to have register_globals off, it's safer to use the super-global variables, like $_SERVER['DOCUMENT_ROOT'] instead of just $DOCUMENT_ROOT.

Rob, the difference is that if you use this: include("http://domain.com/something.php"); PHP will generate an HTTP request for 'http://domain.com/something.php', as if the file is on another server (PHP doesn't know and doesn't care if it's on the same server or not). What this means is that the webserver where the file is, will receive the request and will process it just as if it was a web browser requesting the file (the web server also doesn't care about who's requesting the file), and so it will pass it through PHP and send back the output of the PHP parser. This means that if you have some variables being declared in the included file and you want to use that variable in the main script, you won't be able to do it, because the script has already been parsed. In other words, if you use this method, what you'll be including is not the PHP source code but the result of it being parsed. On the other hand, if you use filesystem paths to include the file, you'll be including the source code and both the main script and the included script will be parsed together. It's like if the include("/home/username/public_html/scrip.php"); is replaced by the source code inside "script.php". Here's test: create three PHP files, bla.php, bla1.php and bla2.php >/* bla.php */ <?php echo "Using filesystem paths:<br/>"; include("bla1.php"); echo $text1; echo "<br />"; echo "Using HTTP URLs:<br/>"; include("http://192.168.0.1/bla2.php"); echo $text2; ?> >/* bla1.php */ <?php $text1 = "Some text inside PHP code, included via a filesystem path...<br />"; ?> >/* bla2.php */ <?php $text2 = "Some text inside PHP code, included via an HTTP URL...<br />"; ?> Place them in your website root and point your browser to bla.php. You will see that the first variable is accessible by the main script but the second one is not. Hope that makes it clear