A-Lehdet siirtyy InDesigniin lehtiensä taitossa

Jep, jos latailee ne jotain ihme IE-only juttua käyttäen, mutta ennenkuin selain voi sanoa tukevansa PNG formaattia taytyy PNG kuvat pystyä sijoittamaan sivuille niinkuin kaikki muutkin kuvat standardin mukaan. Samoin IE ei hanskaa CSS standardin mukaista fixed parametria. ei tarvi sitte lukee mun sivuja IE:llä

Eikä näy ja tukee vain osittain. Esimerkiksi PNG-kuvien alpha-transparency ei ole tuettu, mikä aiheuttaa läpinäkyvyyden sisältävissä kuvissa läpinäkyvyyden sijaan harmaan taustan. Tämä läpinäkyvyys on yksi PNG:n hienoimmista ominaisuuksista. Toisin kuin .GIF- kuvien läpinäkyvyydessä se ei ole rajoitettu yhden värin läpinäkyvyyteen vaan asteittaiseen. Tämä mahdollistaa esimerkiksi tekstien varjostuksien läpinäkyvyyden minkä tahansa värisellä taustakuvalla.

Aha? "ei näy" ja "tukee osittain", nuo ovat ehkä hieman ristiriidassa. Kyllä ne PNG:t ihan iloisesti itsellä toimii, kun ne sivuilla on <img src="mo.png"> -tagilla laitettu. Eli kyllä IE tukee niitä.

Tuo transpency sitten on eri asia, en ole testannut sitä. Mutta harvat sivustot sitä käyttänevät ja ei ole kauhean suuri haitta, ettei niiden läpi näykään.

Ja nämä yhteiset schemat toimisivat sitten windowsissa eikö niin? Tai sitten perinteiseen tapaan taas pimitettäisiin niitä schemoja ja avattaisiin niistä vain tietyt ominaisuudet ja sitten kun joku yrittää portata systeemiä unixille tms. niin homma ei toimi kuin puoliksi ja ms pitää oikeudet schema-muutoksiin. Minusta ajatus on aika kuollut jo syntyessään. Teoriassa tämä kuulostaa ihan mielenkiintoiselta, joskaan ei mitenkään mullistavalta jne., mutta veikkaan, että käytännössä idea ei saa laajempaa kannatusta. WinFS:n piti muistaakseni alunperin pohjautua SQL Serveriin, mutta sekin idea on jo kuopattu suoritustehosyistä. Nyt sitten ilmeisesti etsitään ReiserFS 4:n/Oracle IFS/Gnome Storagen tyyppistä ratkaisua. Koko WinFS tullaan ilmeisesti rakentamaan NTFS:n päälle ja siitä ei mahdollisesti tule edes System Wide (ainakaan alkuun), vaan koskettaa lähinnä Bill Gatesin My Documents folderia tms. Tämä jos joku kuulostaa kludgelta sen varsinaisessa merkityksessä. ReiserFS 4:ssa asiat edes yritetään tehdä "enemmän oikein". Käsittääkseni ReiserFS:ssä kaikki ovat ns. hakemistoja (myös tiedostot) eli esim. tiedosto foo on myös hakemisto foo. Metadata voidaan tallentaa hakemistoon, eli esim. dokumentin foo kirjoittaja voisi löytyä foo/author tiedostosta.

Jeps... Tiedostojärjestelmät soveltuvat nimenomaan tiedostojen tallentamiseen. Siksi meillä on juuri olemassa tietokantoja jne. MS on nyt naittamassa kahta asiaa yhteen, mikä on minusta suhteellisen turha temppu.

Mitä tarkoitat? NTFS:ssä on kovat (ja symboliset) linkit samoin unix-tiedostojärjestelmissä. Ainakin minusta tämä juuri mahdollistaa sen.

Pitäähän niiden olla riittävän avoimet Windowsille kehittäville, mutta tuskinpa Microsoftin intreseissä on portattavuus muille alustoille.

Kyllä se edelleen tulee pohjautumaan SQL Serverin seuraavaan versioon ("Yukon").

Se on ollut tiedossa jo pitkään, että se toimii NTFS:n rinnalla/päällä. Samoin se, että WinFS indeksoi ainoastaan My Documentsin tai importoidut folderit esim. muilta osioilta.

Systeemi-foldereiden indeksoinnissa ei olisi mitään järkeä, sillä WinFS on tarkoitettu dokumenttien yms tietojen järjestelyyn ja linkittämiseen. Kuka jotain Windowsin alihakemistoja tiedostoineen haluaisi luokitella? :) Tulisi myös turhaa overheadia tarpeettoman tiedon ylläpitoon.

Tiedostojärjestelmillä tietojen organisointi tulee aina vain hankalammaksi, kun levytila kasvaa teratavujen luokkaan. Fiksun hierarkian rakentaminen ja ylläpito on liikaa vaadittu kokeneeltakin käyttäjältä aloittelijasta puhumattakaan (ne turvautuvat usein pelkkiin hakuihin). Lisäksi sovellusten omat tietokannat/tiedostoformaatit/suljetut metadatat hankaloittavat tiedonvaihtoa ja integrointia.

Käytännössä ainakin Windowsissa ne eivät ole riittävän joustavia ja helppoja. Jos kuva kuuluu esim. perhekuviin ja lomakuviin, niin voi siitä tietty tehdä shortcutin kaikkiin kansioihin, mutta esim. kuvaa siirtäessä linkki menee rikki. Kuvankäsittelyohjelmat saattavat avaa -dialogissa ohittaa shortcutit kokonaan ja sen löytää vain alkuperäisestä kohteesta. Hankalia myös luoda ja hallita suurilla kokoelmilla.

Kun kuvilla on WinFS:n ylläpitämä metadata kategorioista tai linkeistä, löytyy ne myös helposti eri hakukansioista. Lisäksi itemit voivat olla linkitettyjä toisiinsa yhteyksillä (kuten relaatiotietokannoissa). Esim. voidaan hakea kaikki samaan projektiin liittyvät dokumentit, kooditiedostot, sähköpostit ja esitykset eri kriteerein.

Ei tuo WinFS tietenkään merkitse mitään, jollei Windowsin shelliä muokata niiltä osin oleellisesti. Metadatan kerääminen pyritään automatisoimaan mahdollisimman pitkälle.

Yhdessä demossa oli toiminto, joka skannasi kuvasta naamat , joille pystyi syöttämään nimet, joilla voi tietty hakea "kaikki kuvat, joissa on henkilö x". Tämä oli tietty manuaalinen esimerkki metadatan syötöstä, mutta cool :)

http://longhorn.msdn.microsoft.com/ -tuon takaa löytää jotain tietoja koko arkkitehtuurista, tosin blogeista yms löytyy paljon mielenkiintoisempia juttuja.

Mikä tavallaan vesittää koko asian. Toisin sanoen asiassa tulee käymään niin, että joku näyttää pari hassua demoa ja joku ehkä kerran kirjottaa johonkin omaan tiedostoonsa metadataa, mutta jättää asian hyvin nopeasti sikseen.

Ainiin, sehän olikin niin kludge viritelmä, että sen varaan pitää rakentaa oma indeksointi engine ja mitä ilmeisimmin oma API.

Ei kysymys olekaan siitä, kuka haluaisi vaan siitä, miten tuo on toteutettu. Se, että esim. systeemihakemistoon ja sen tiedostoihin voisi lisätä metadataa ei tarkoita, että niihin pitäisi.

Jep ja nimenomaan. WinFS tuo vain turhaa overheadia.

<smartass-comment>
En ymmärrä miten levytilan määrä vaikuttaa tiedon organisointiin. Kai se tiedon määrä on se, mikä siihen vaikuttaa. (ok, ehkä sitä tarkoititkin)
</smartass-comment>

Eikös nämä Windowsin Metadatat vaikeuta asiaa aivan yhtälailla. Jos meillä on vaikka äänitiedosto x, joka sisältää metadataa ja on indeksoitu WinFS:llä, niin mitä tapahtuu, kun tiedosto lähetetään esim. sähköpostilla eteenpäin? Metadata menetetään.

Tarkoitinko minä shortcuteja puhuessani kovista ja symbolisista linkeistä? En. Minä tarkoitin juuri kovia ja symbolisia linkkejä, jotka ovat sekä NTFS että Unix tiedostojärjestelmissä.

En minä ole siihen syyllinen, että Windowsissa on typerä shortcut systeemi sen sijaan, että he rakentaisivat helpon tavan luoda kovia ja symbolisia linkkejä tiedostojen välille. Tämän NTFS osaa, mutta MS ei halua käyttää kyseistä ominaisuutta.

Jep ja kuka ne metatiedot sitten syöttää? Onhan Wordissäkin ollut metadatat jo vuodesta kivi ja jeesus. En ole kenenkään nähnyt kyseisiä ominaisuuksia käyttävän. Tai Wordin versiointiominaisuuksia.

Jeps... kuvista tallennetaan koot ja värimäärät jne. leffoista pituudet yms. Mutta se on aivan utopistista väittää, että jotenkin saataisiin selville esim. se että kuka minkäkin dokumentin oikeasti on kirjoittanut, ketkä näyttelee missäkin elokuvassa. Tämä vaatii sitten manuaalista syöttämistä tai esim. imbs:n käyttöä. Ja edelleen tämä työllä ja tuskalla lisätty metadata menetetään, kun tiedosto lähetetään esim. sähköpostilla eteenpäin? Ei se ainakaan voi sisältyä tiedostoon, koska sehän rikkoisi jo kaikki olemassa olevat formaatit. Tämä taas herättää kysymyksiä koko WinFS:n mielekkyydestä..

Minusta tuntuu, että olet istunut liikaa MSDN jne. Developer Tech tapahtumissa kuuntelemassa heidän markkinointikoneistoa. Älä ota millään pahalla, mutta nytkin täällä alunperin puhuttiin Indesignistä, niin sinä nostit esiin vapour ware Windows Longhornin ja vapour ware WinFS:n. Tuskin ketään taittajaa kiiinnostaa sepostukset Windows specifisen metadata systeemin olemassaolosta.

Eiköhän ne kansiot voi samalla tavalla importoida WinFS storeen siinä missä muutkin.

Useimmat äänitiedostot itsessään pitävät ne kappalekohtaiset metadatat (ID3 etc), mutta luokittelusta yms en sitten tiedä. Vastaanottaja haluaa todennäköisesti ryhmitellä kappaleet/kuvat oman logiikkansa mukaan.

Eiköhän tulevaisuuden formaateissa huomioida myös nuo puolet. Vanhoihin säilyy yhteensopivuus, mutta metadatan merkitys korostuu tulevissa formaateissa.

Näinpä, sen vuoksi niistä on ihan turha puhuakaan, jos niitä nykyisiä tekniikoita ei voida mitenkään järkevästi edes hyödyntää. Ja muutenkin se ratkaisisi vain osan ongelmista.

Microsoft tiedostaa tuon, ettei kukaan niitä syötä ja sen vuoksi sitä automatisointia tuleekin. Metadatan syöttäminen ei tarkoita aina kirjoittamista, vaan esimerkiksi tiedoston pudottamista sopiviin "kansioihin". Kirjoittaja/muokkaaja saadaan vaikka sillä hetkellä kirjautuneesta käyttäjästä etc. Ei mitään idioottivarmaa keinoa tietenkään kaikkeen tietoon ole.

Voi olla, muttei ne itse markkinointipuheet uppoa minuun, jos myös tekniikka tai toteutus ei ole kunnossa. Voi WinFS toki epäonnistua täysin ja unohtua kokonaan, jos se ei ratkaise mm. mainitseamisi ongelmia, mutta sen näkee sitten myöhemmin.

Mielestäni Windows on edelleen (ja vielä pitkään) täynnä kaikenlaisia puutteita ja on vain hyvä, että yritetään löytää uusia keinoja pinttyneiden tottumusten, kuten hierarkisen tiedostonhallinnan, tilalle.

Kieltämättä venyi jo offtopiciksi, mutta pointti oli se, että mielestäni suunta on oikea, entistä avoimempaan linjaan - ainakin Windowsin softissa (muut järjestelmät on tietty toinen juttu), kun siirrytään enemmän jaettuihin formaatteihin. Tästä joku vain puhui muuta ("yhteensopimattomat formaatit"), mikä toi aiheen mieleeni. :)

Mitä vaporwareen tulee, niin kyse ei ole oikeastaan siitä, vaan MS haluaa juuri rakentavaa kritiikkiä näin varhaisessa vaiheessa kaikesta tulevasta. Vielä ne ehtivät reagoimaan hieman suurempaankin palautteeseen, toisin kuin jossain beta 2 vaiheessa.

Ei siis ole yhtään liian varhaista puhua siitä jo nyt, sillä myös softankehitys vie aikansa, joten on tärkeää, että kehittäjät (ja loppukäyttäjätkin) ottavat tulevaisuuden huomioon jo nyt.

Onko? Voisitko kertoa mistä ne saa päälle? Olen meinaan todella paljon kaivannut hakemiston symbolista linkkiä, sitä kuitenkaan löytämättä.

Ja selitys sille, miksi ne löytyvät: POSIX. Microsoft vain estää käyttäjää tekemästä tällaisia vaikka ne monesti olisivat hyödyllisiäkin. Esim. Case-sensitive file names. NT:eissä on kuitenkin POSIX -subsystem, joten myös mainitsemani temput ovat näin mahdollisia, joskaan työkaluja tällaiseen MS ei juurikaan tarjoa.

Tätä me koitettiin järjestelmätukikurssilla opelta kysyä, että: "Mitä ne skemat oikein on?" Ei se osannut kertoa, selittipähän mitä on skemet. Onko tuolle skemalle mitään kansantajuista selitystä, jollei jopa suomenkielistä vastinetta?

Sillä termillä on useita merkityksiä. Lähinnä se tarkoittaa muottia/mallia ainakin tietokonemaailmassa.

Esim. tietokannan luontiskripti, joka määrittelee taulurakenteet, yhteydet, rajoitteet yms sisältää kyseisen tietokannan skeman. Tyhjä muotti, minne voidaan tallentaa tietoja tarkan kaavan mukaan.

Vastaavasti XML Schema määrittelee XML-tiedoston rakenteen: mitä elementtejä ja attribuutteja dokumentin ilmentymä voi/täytyy sisältää ja missä järjestyksessä niiden on oltava ja miten paljon yms.

Ilman skemaa XML-parseri voi korkeintaan tarkistaa, että syntaksi on oikein ("well-formed"), skemaa noudattava rakenne on "valid".

Hesarillahan ei ole mitään tekemistä ID:n kanssa, HS ja IS taitetaan rupisella tanskalaisella CCI NewsDesk ohjelmalla. Vain Nyt & Kuukausiliite taitetaan ID:llä.

No, ei lisääntyneet typotkaan suoranaisesti liity ID:iin.

Ja InDesignin OpenType tuki...

Näin kävi juu. Corelin Mac-versiokin kuoli taannoin.

"Kevyt taitto-ohjelma" kuulostaa äkkiseltään hyvältä idealta, mutta kun alkaa miettiä mitä ominaisuuksia pudotetaan pois ilman että lopputuloksena on huonoja dokumentteja... No, toivotaan että jotain ilmaantuu...

Adobella on Freehandin kilpailijana (ja monen mielestä voittajana) Illustrator. Taittosoftia Macromedialla ei ole, Freehandista ei oikein siihen hommaan ole.

No, Freehand kelpaa mainiosti kun taitetaan nelisivuinen esite (Illuhan on rajoittunut yhteen sivuun), mutta vähänkin isommissa projekteissa se tukehtuu armotta.

Voipi olla, mutta kerholehtiset ei varmaan kauhean suuria opuksia yleensä oo. Että luulis FHn hanskaavan.