malkus

Gör så mycket mer egentligen men är ett oerhört coolt program: MetaSynth (ca 4300:-)

FireGPG är ett OpenSource Firefox-tillägg som gör det väldigt smidigt att kryptera och signera sina mail i Gmail men det finns än så länge endast en Intel-version. Den använder sig av GnuPG som är ett fritt OpenSource-alternativ till PGP och jag har nyligen installerat GnuPG för MacOS. Bra instruktioner för detta finns här: Configuring GnuPG (Mac OS X)).

Jag har också installerat stödet för Apple Mail men jag använder även Gmail en hel del och skulle verkligen vilja få det att fungera där med. Är det någon som känner till en annan (PPC-kompatibel) lösning eller kanske t.o.m. sitter på en egenkompilerad version för alla oss mossiga PPC-typer?

Jag ville egentligen köra via Distiller som jag brukar, men de enda inställningar tryckeriet tillhandahåller är för export inifrån layoutprogrammen vilket indikerar att detta enligt de är den optimala och av de föredragna metoden. Förra tryckeriet var föredömliga med både Distiller och InDesign-inställningar och t.o.m. separata inställningar för förenklingen, "flatteneringen", istället för default "low", "medium", "high".

Oavsett om färghantering är påslagen eller inte uppstår felet och på andra sidor så har dessutom även bråkande bilder inbäddade profiler. Utan inbäddad borde dokumentets standard-profil användas (åtminstone när färghanteringen är påslagen) och det är en kompromiss vi tidigare har kunnat acceptera. Men som sagt, sedan visade det ju sig att export-inställningarna ändå inte skickade med profilerna eller gör nån konvertering öht. Då drar man ju slutsatsen att de vill göra det själva men borde de då inte själva vilja ha de profiler som ändå finns...

Men fortfarande: obegripligt varför det blir olika resultat i den "gamla filen" och den nyuppbyggda. Samma bilder, samma inställningar (oaktat om de är rätt eller fel)... Är det en bugg ändå?

Vi har kört samma jobb tidigare (med blandade cmyk- och rgb-bilder) utan problem. Det handlar om en enorm mängd av bilder som vi helt enkelt inte skulle kunna sitta och konvertera manuellt.

Det finns sidor där sådana skillnader förekommer, andra där det inte gör det men där felet ändå uppstår. Men genomskinlighetsblandningen görs i CMYK konsekvent.

Jag gjorde ett litet test där jag strippade en sida med formatmässigt identiska bilder (men där en ger det aktuella felet) på ALLT annat. Packade dessutom om projektet för att rensa filen på ev gammalt skräp. Jag gjorde dessutom en ny fil från scratch med exakt samma bilder monterade. PDF:ade bägge med tryckeriets inställningar. Den rensade råkar ändå ut för samma skit medan den nya klarar sig.

Jag hittar iaf inga skillnader. Nån hugad får gärna nosa i detta! Är det en bugg i inDesign kanske? Tveksamt. Jobbet gör vi i CS "1" men det uppstår även i CS2.

Kika gärna på det. Naturligtvis vill jag ju komma fram till att tryckeriet har goofat. Det tycker jag iofs hur som helst de har gjort då de inte upptäcker och reagerar inför hela sidor utan bilder på svartplåten.

http://www.megaupload.com/?d=2OC66CG8

Men varför konverteras bara vissa rgb-bilder fel och inte andra. Nån som har nån snilleblixt?
Samma inbäddade färgprofiler, samma färgrymd, monterade på samma sätt.. samma, samma, samma....

Ja, den där märkliga företeelsen har man ju fått dras med en hel del. Jag förstår inte varför Adobe inte har löst det där ens i CS3. Att slå av kantutjämningen vid visning i Acrobat gör iofs att de försvinner men då blir också vektorer och text utan kantutjämning.

Att ändra deras exportinställningar till PDF 1.3 istället för 1.5 gör också att allt blir rätt. Då blir ju hela filen "flattenerad" men jag undrar varför det hjälper saken.

Sanning är nog nånstans åt det hållet men vad som är konstigt är att det är bara vissa bilder. 2 bilder med exakt samma egenskaper (inbäddad profil, färgrymd mm) blir behandlade helt olika... Skumt. Men om vi har följt deras instruktioner, slaviskt använt deras inställningar kan det väl knappast ligga oss till last. Och bör inte en faktor på plats reagera om hela svarta kanalen är puts weck på så många bilder..?

I deras profil anges att ingen färghantering ska användas.

Vi har fått vår trycksak levererad från tryckeriet och jag är mycket bekymrad.
Flera bilder såg en aning vissna ut i det digitala lågupplösta korret men liknande "vissenhet" i tidigare jobb har endast lett till små (hyggligt acceptabla) variationer i tryck. Denna gång såg det för hemskt ut och det visar sig vid närmare koll i pdf:en att det på dessa bilder är helt tomt i den svarta kanalen.
Detta sker inte på alla RGB-bilder utan bara vissa och det verkar inte finnas någon uppenbar konsekvens i vilka bilder det här uppstår på annat än att det då är RGB-bilder (förstås...) och färghanteringen för dokumentet är avstängd. Slår man på inkluderande av bilders färgprofiler i tryckeriets export-inställning blir det dock rätt.

Har någon råkat ut för detta? Vad beror det på?

(Vi använder gamla inDesign CS pga av kompatibilitetsbehov med skript)

..och det verkar som om den här tråden slutar med det också. När jag satte upp kontot angav jag lösenord (kontot bör ju vara identiskt med macens amvändarnamn/lösenord) men det visade sig när jag undersökte det i Windows att kontot ändå inte var "password protected". Finns det alltså en skillnad mellan att kontot har ett lösenord och att det är s.a.s. password protected?

Tack ändå för att ni fick gnuggat era gråa en söndagskväll som denna. Förhoppningsvis kan den här tråden vara till nytta för andra blivande RDC-användare i fortsättning...

Jag har en stationär mac och inga lock-tangenter har varit nertryckta, annars är ju den en given klassiker vid inloggningsproblem hade inte tänkt på det faktiskt... Men kan det vara något i själva överföringen av lösenordet? Är det för långt för en RDC-connection kanske? Det är 12 tecken långt, inga siffror, bara vanliga bokstäver (inga diakritiska förstås...)

Vad jag har förstått så läggs användaren till i gruppen "Remote Desktop Users" genom att man defenierar detta via knappen "Select Remote Users...". En slags genväg till att göra det istället för att göra det under User Accounts.

Nej, bara "vanliga" tecken i både användarnamn och lösen. Samma problem oavsett om man skriver in manuellt i inloggningsrutan eller i RDC-inställningarna. Och ja – det går alldeles utmärkt att logga in på PC:n lokalt med detta kontot. Skumt va'?