HL

Hårdvarumässigt räcker det, men du måste konfigurera din PC så att den bryggar nätverket mellan ditt trådbundna och trådlösa kort. Om du bara har en publik IP-adress via din uppkoppling (vilket oftast är fallet) så måste PCn köra NAT. Googla så hittar du nog nåt!

Problemet är väl att det inte finns nån egentlig standard för vilken teckenkodning som används mellan servern och i klienten. Det är lätt att det blir fel, till exempel om man kör Fetch mot en Linux-server. Transmit verkar däremot funka bra mot Linux-servrar med standardinställningen.

Tack, det här har jag också funderat på. Hittade lite godis:

För er (oss) PHP-kids:
http://www.michelf.com/projects/php-markdown/

För er .NET-kids:
http://aspnetresources.com/blog/markdown_announced.aspx

Men vad gör man om man måste använda vanlig ASP ibland?

I Netatalk liksom Samba och diverse FTP-servrar kan man ju dela ut hemmapparna på det sätt som Björnström efterfrågar (utan att man behöver välja varje enskild mapp som en ny share). Jag fattar inte heller varför den möjligheten inte finns i OS X Server.

Adobes Camera Raw har ju en brusreducering som man kan ställa upp eller ner med en "slider". Antar att iphoto har den på 0 så att säga...

Det finns flera sätt att göra samma sak...

Men nåt svar på din fråga har du inte fått: varför tar det sån tid att få upp skriv ut-rutan? Jag har kännt av samma sak då och då men har ingen generell lösning. En grej kan väl vara att se till att alla bilder ligger lokalt på hårddisken och inte på nätverket. En annan är att det kan vara idé att dela upp dokumentet om det är mycket bilder.

Jag tror att du kan få rätt filnamn vid nerladdning om du sätter rätt headers (mime-type mm) i PHP-scriptet som sänder filen. Ingen aning om vilka headers som krävs i det här fallet dock.

Ignorerar den dåliga stämningen...

En viktig skillnad mellan olika serverteknologier som jag inte sett nämnas är väl om det handlar om applikationsservrar eller enkel-exekveringsmodellen eller vad man ska kalla den.

I ena hörnan har vi applikationsservrar som Ruby on Rails, Webware for Python, Zope (Python), Tomcat/Jboss (Java), .NET... Här körs koden i en ständigt rullande process på servern, vilket gör att man kan läsa in allt möjligt (data och logik) i minnet så att det finns tillgängligt på en gång när användaren ansluter.

I den andra hörnan har vi PHP, ASP och gamla hederliga (Perl-)CGI-script. De startas upp varje gång en användare laddar en sida och har alltså en längre startsträcka. Det gör dem mindre lämpliga för större applikationer, men de är i gengäld mindre känsliga för taskig kod/minnesläckor mm, och det är lättare att hosta dem eftersom de inte kräver något av servern så länge ingen ansluter till dem.

Ska man säga nåt om "det senaste" så är det kanske lite applikationsserver-für-alle-stämning eller nåt just nu. Det känns klart mer tillgängligt nu än tidigare.
På samma gång känns det som fler och fler jobbar med vettiga systemdesign-modeller, MVC osv. Mindre databas, logik och formatering i samma fil och mer ORMar, mallar, stylesheets osv. Det behövs ingen applikationsserver för sånt, men ofta känns det som det går hand i hand...

Kan väl passa på att nämna ett gratis alternativ till dem jag nämnde ovan, nämligen Bitstreams Vera-familj. Finns som Sans, Serif och Mono. Schyssta grejjer på skärm i alla fall, säkert ok i utskrift också, men kanske inte världens mest inspirerande.

http://ftp.gnome.org/pub/GNOME/sources/ttf-bitstream-vera/1.10/

Formatet är win-truetype vilket du kan använda även på OS X.

Men vill du ha största möjliga enkelhet för kunden är det ju standard-MS-fonterna som gäller.

Nä, jag tror att Indesign känner av vilken profil bilderna har. Om den inte stämmer med vad man ställt in kan Indesign antingen konvertera automatiskt eller bevara. Om det är samma profil sker ingen konvertering, alltså inget tårta på tårta. (Jag skulle nog sätta den på "Bevara inbäddade" för att slippa oönskade konverteringar.)

Själv använder jag inte färgstyrningen i Indesign. Så länge alla bilder har rätt profil så blir ju åtminstone de rätt. Färgplattor osv kan ju däremot se fel ut på skärmen, men det är oftast inte lika känsligt.

Bästa valet är kanske något ur MS-familjen eftersom det nu handlar om ett MS-program. Två tips:

Trebuchet MS
Georgia

...men Times ska inte underskattas - rätt använd alltså.

Man behöver inte sätta på safe_mode för att begränsa vilka kataloger PHP kommer åt visar det sig. open_basedir styr vilken katalog ett PHP-script kan läsa filer i, men påverkar inga andra funktioner. Enda nackdelen för en vanlig webbhotellkund skulle väl vara att man inte kan använda /tmp.

Från http://se2.php.net/features.safe-mode:

Så användaren klas skulle kunna ha open_basedir = /home/klas/ - eller hur man nu väljer att lägga upp det.

Men, som det står i PHP-dokumentationen, det här är egentligen "fel" sätt att lösa problemet på. Det hjälper inte mot de som kör perl-, python- eller vadsomhelst-script som cgi.

Man har ju bara rätt att exekvera det som filsystemet ger en tillgång till. Men det är ju ett dilemma det här med delad hosting. I och med att alla utdelade filer måste kunna läsas av webbservern (samtidigt som användarna inte har tillgång till webbserverns användare/grupp) så får användarna i princip rätt att läsa varandras filer.

Har inget bra råd att ge.

[EDIT] Kollade på ett webbhotell jag anlitar, och det skulle inte vara några problem för mig att se mina "grannars" utdelade filer, läsa deras php-kod till osv. Så det finns en poäng med safe_mode, helt klart.

[IGEN!] Om man sätter alla användares huvudmapp till mode: 750 och grupp: www-data så bör man ju hindra användarna från att kunna titta in hos varandra (vilket man alltså kan på mitt webbhotell), medan webbservern får tillgång till de utdelade filerna. Det hindrar dock inte att en användare kör ett php-script (vilka körs av webbservern) som läser de andras filer.

Ofta registrerar man sig nog först när man har ett konkret problem/fråga som man vill diskutera, så det är ju inte så bra om det tar för lång tid.

Det är ju Microsoft som ger ut Georgia, så de kanske har blockerat det av politiska skäl... men jag tror inte det.