HL

De verkar satsa mycket på att vinna kontorsfolket och pratar ganska lite om PDF-flöden för tryck. Mycket snack om att skapa PDF-filer med ett klick i diverse Microsoft-program, fast bara i Windows...
Hittade i alla fall lite intressant info för grafiker till slut:

- Acrobat 6 kräver OS X 10.2.2 eller högre.
- Distiller ingår.
- Stöd för PDF/X, en begränsad PDF-standard avsedd för att eliminera vanliga problem vid tryck.
- Nya preflightfunktioner.

(Ur denna PDF-fil.)

Skillnade mellan att köra X11-program över SSH och att köra med VNC är att VNC skickar allt i form av skärmbilder. Det går långsammare och det har vissa bieffekter.

Kan också påpeka när det gäller att köra X11 över ssh via Internet att det kräver att port 6000 är öppen på datorn där du sitter (och att port 22 - SSH - är öppen på datorn som programmen körs på). I övrigt funkar det på samma sätt som Cyrion beskrivit.

Men Indesign renderar ju ändå hela filen när man väljer bästa visningsläget. Så varför kan man inte använda de lästa färgvärdena för pipetten när de uppenbarligen används för att skapa en skärmvisning?

Jag menar inte att ställa någon mot väggen här, jag är mest nyfiken... Och jag har full respekt för det exeptionella i ett layoutprogram som läser PS-koden i inkuderade högupplösta bilder. Det känns bara som att pipett-problemet är en onödig begränsning när programmet är så kraftfullt i övrigt.

Jag förstår resonemanget om inkapsling. Tanken med eps är som du säger att bildinformationen (pixel- eller objektgrafik eller både och) inte rörs förrän den når Postscript-tolken (ex en skrivare). Fram till dess används bildens inbyggda förhandsvisning.

Det här är nog egenskaper som många repromänniskor uppskattar, eftersom de vet att inget ont kan hända deras fina bild på dess väg genom layoutprogram mm. Jag förstår med andra ord att man gärna håller fast vid eps. Nu är säkert Indesign kompetent nog att hantera högupplösta bilder på ett bra sätt, men det kan också finnas en poäng i att layoutprogrammet aldrig behöver befatta sig med dem. När det gäller kvaliteten på skärmvisningen så är jag mycket nöjd med Photoshops JPEG-förhandsvisning. (Varför finns inte den möjligheten i Illustrator?)

Men ok, det är en annan diskussion. Jag menar inte att det inte är bra att Indesign har möjligheten att visa bilder högupplöst och att läsa ps-kod så länge man (användaren) har vett att använda den möjligheten i lagom omfattning. Jag tycker bara att när Indesign nu har en inbyggd PS-tolk så måste den väl också kunna avgöra vad som är en ren pixelbild och vad som är objektgrafik. Den borde också kunna läsa korrekta färgvärden från bilderna. Hur gör den annars när den skapar skärmåtergivningen?

Som jag ser det är det här en brist i Indesigns pipettfunktion/PS-tolk. Det är inte en teknisk omöjlighet att få det att funka även om det säkert kan vara lite komplicerat.

Fast det är just det som händer när man väljer bästa visningskvaliteten: Indesign öppnar bilden och visar den i full upplösning. Ändå säger programmet att det måste basera mätvärdet på eps:ens förhandsvisningsbild ("RGB-utkast"). Jag håller med Olav, det är skumt.

(Dessutom säger det att bilden är en vektorbild, vilket ju inte är sant - och nu pratar jag alltså inte om terminologi, som skillnaden mellan vektorgrafik och objektgrafik, utan om pixlar kontra objekt.)

Det låter som något som är värt att testa. Men för ordningens skull vill jag bara säga att Tesa har rätt, descreen-funktionen är till för att ta bort moiré när man scannar en rasterbild, oavsett vad den sen ska användas till.

Tabellen bör väl ha en ID-kolumn som är exempelvs SMALLINT(X), PRIMARY KEY och har AUTO_INCREASE, samt en URL-kolumn som är exempelvis VARCHAR(X). Sen vill du kanske spara nån mer information om varje bild och då blir det ju fler kolumner...

Det enklaste är väl att ladda upp via ett formulär. Det är inte så väldigt svårt. Det finns ett särskilt avsnitt om det i PHP-manualen, under Features har jag för mig. Är det tunga bilder så kan det dock bli svårt...

Ett annat potentiellt problem med formulär-metoden är att du förmodligen måste sätta väldigt generösa rättigheter på den katalog där bilderna ska sparas (för att Apache ska ha rätt att spara bilder där). Kan vara ett orosmoment om sidan ligger på ett webbhotell. Det finns dock sätt att kringgå problemet...

I övrigt är det väl bara att önska lycka till! Hör av dig om du har några specifika frågor!

Nej tack.

Det betyder lägg till alternativet FollowSymLinks men ändra inga andra alternativ som eventuellt redan är satta. Det kanske inte var så relevant i det här fallet egentligen...

Snart dags för nån riktig Apache-guru att uttala sig tycker jag...

Jag har en bredvid mig på skrivbordet och den gör inget annat där än att samla damm. Det är alltså en sk tranciever, en adapter mellan det där skumma gränssnittet och vanligt ethernet (RJ45 eller vad det heter).

Skicka ett privat meddelande om du är intresserad av den.

Just när det gäller bildläsning brukar jag se det som att det finns två typer av upplösningar: dels tätheten hos bildläsarens mätpunkter på originalet och dels den slutliga bildens pixelupplösning. Dessa behöver som bekant inte vara samma eftersom man ofta scannar i andra förstoringar än 100%.

Själv brukar jag kalla det förra för dpi och det andra för ppi. Varför? Jag tycker inte att man kan tala om pixlar (pixels per inch) i det första fallet. "Dots" (dots per inch) känns mer rättvisande. Enligt mitt resonemang gör man alltså rätt när man anger en bildläsares maxupplösning i dpi.

Men jag slår ingen som säger ppi iställer för dpi, inte heller de som säger dpi om pixelupplösningar. Tror bäst approach är att säga så rätt man kan själv och ha överseende med andras fel.

- - - -
Ändring: Det gäller att skriva rätt i den här tråden känns det som...

Testa att lägga in följande i httpd.conf (efter <Directory "/Library/WebServer/Documents">...</Directory>):

<Directory /home/*/Sites>
  Options +FollowSymLinks
</Directory>

Kolla bara att du inte redan har någon aktiv <Directory /home/*/Sites>...</Directory>
Fast du har kanske redan testat?

Då är det kanske Filemaker du ska ha. Förresten finns väl 4D också för OS X? Har ingen erfarenhet av dem själv dock, så jag kan inte rekommendera någon av dem.

MySQL förstås, men det kanske du känner till. Open source, snabb, kraftfull, men saknar ett lika enkelt gränssnitt som Access och Filemaker, åtminstone på OS X. Det finns dock ett bra webbgränssnitt som heter PHPMyAdmin.

Info om hur du installerar finns här.

Har testat Webalizer. Är väl ungefär halvnöjd med det.