Suffies...(Over Ms,Apple,&standaardisatie.)
Roeland Pluijmers
Maar iedereen (behalve ik) schijnt hun
nodig te hebben vanwege Word & Excel.
Onbegrijpelijk.
Standaardiseert de wereld op een priveprodukt?
Er is toch Ascii?
Er is toch Unicode?
Ooit moest iedereen Wang.
Toen moest iedereen Wordperfect en Lotus.
En de leveranciers hebben het over een door
de marktplaats bepaald aanbod.
Als een onderwijsventje 'C' gaat geven, standaardiseert
hij niet op de standaard (... ), maar op een produkt,
erger nog, op een machine. (En dat met C.. ).
Suffies bij elkaar.
En als je bij Apple op een site kijkt naar een produkt-
overzichtje moet dat zonodig in een of ander prive Adobe
conventie zijn geschreven. (Ik ontstak in grote woede
toen ik dat zag. Ik wilde informatie, niet een of ander
grafisch kunstwerk. (Ik heb onmiddellijk die oensite
verlaten, willen zeker niet verkopen.))
Ik geloof dat het onderwijs op dit gebied een mooie taak
heeft.
Ik maak me geen illusies over wat het onderwijs daarvan
zal maken.
Ik las hier over iemand die een of andere dorpsuniversiteit
per Mac wenste te benaderen.
Dat kon met moeite, omdat de heren van het locale communicatie-
gebeuren aldaar niet in communicatieprotocollen denken,
maar in commerciele programma's... (Je vraagt je af wat
er te communiceren valt met zo'n schooltje met zulke
informatici.)
Bedankt voor het lezen.
R.
--
Roeland Pluijmers 10002...@compuserve.com
I.J.J.Nieuwland
>
[Blaat]
> En als je bij Apple op een site kijkt naar een produkt-
> overzichtje moet dat zonodig in een of ander prive Adobe
> conventie zijn geschreven. (Ik ontstak in grote woede
> toen ik dat zag. Ik wilde informatie, niet een of ander
> grafisch kunstwerk. (Ik heb onmiddellijk die oensite
> verlaten, willen zeker niet verkopen.))
>
Euhhh,... PDF? Ik geloof niet dat ik de afgelopen twee jaar een CD bij
een tijdschrift heb gezien waar Acrobat Reader NIET op stond...
Ilja
compas
Pluijmers <10002...@CompuServe.COM> wrote:
> En als je bij Apple op een site kijkt naar een produkt-
> overzichtje moet dat zonodig in een of ander prive Adobe
> conventie zijn geschreven. (Ik ontstak in grote woede
> toen ik dat zag. Ik wilde informatie, niet een of ander
> grafisch kunstwerk. (Ik heb onmiddellijk die oensite
> verlaten, willen zeker niet verkopen.))
Wordt volgens mij veelvuldig in zowel Mac- als PC-land gebruikt (waar ik
verder niets anders mee wil zeggen dan dat de "conventie" niet zo
bijzonder is). Kijk bij www.apple.com. Daar staan de gegevens ook gewoon
op het web (i.t.t. www.apple.nl).
____________________
Website: http://come.to/pascals.nederlandse.apple.website/
E-mail: com...@casema.net
Steven
>
> In article <3638B7...@let.rug.nl>, "I.J.J.Nieuwland"
> <I.J.J.N...@let.rug.nl> wrote:
>
> > Roeland Pluijmers wrote:
> > >
> > [Blaat]
> >
> > > En als je bij Apple op een site kijkt naar een produkt-
> > > overzichtje moet dat zonodig in een of ander prive Adobe
> > > conventie zijn geschreven. (Ik ontstak in grote woede
> > > toen ik dat zag. Ik wilde informatie, niet een of ander
> > > grafisch kunstwerk. (Ik heb onmiddellijk die oensite
> > > verlaten, willen zeker niet verkopen.))
> > >
> >
> > een tijdschrift heb gezien waar Acrobat Reader NIET op stond...
>
> PDF is een image formaat en is dus veel trager downloaden dan HTML
> [=tekst] bestanden. Om nog maar te zwijgen over de revolutionaire
> mogelijkheid van HTML om de _gebruiker_ te laten bepalen hoe de informatie
> wordt weergegeven.
Dat is lang niet altijd wenselijk.
> Wie heeft er al eens een PDF bestandje beluisterd?
Ik. Jij nog niet?
> --
> Sander Tekelenburg, <URL:http://www.euronet.nl/%7Etekelenb/>
> 'From'-header is invalid. Use Rot 13 on <grxr...@rhebarg.ay>
>
> ...and on the 7th day, God turned off his Macintosh.
Maak je borst maar nat, PDF wordt standaard formaat in Mac OS X.
--
ste...@sifre.demon.nl
(remove * if present)
Steven
>
> In article <36390824...@sifre.demon.nl>, Steven
> <ste...@sifre.demon.nl> wrote:
>
> > Sander Tekelenburg wrote:
>
> [knip]
>
> > > PDF is een image formaat en is dus veel trager downloaden dan HTML
> > > [=tekst] bestanden. Om nog maar te zwijgen over de revolutionaire
> > > mogelijkheid van HTML om de _gebruiker_ te laten bepalen hoe de informatie
> > > wordt weergegeven.
> >
> > Dat is lang niet altijd wenselijk.
>
Als je een bepaald lettertype wilt gebruiken dat belangrijk is voor het
ontwerp bijvoorbeeld. Als je veel aandacht aan een ontwerp hebt besteed en
niet wilt dat dit verloren gaat, als je een ontwerp gemaakt hebt voor print
bijvoorbeeld. Er zijn talloze ontwerp situaties te noemen die simpelweg niet
te realiseren zijn in HTML.
>
> > > Wie heeft er al eens een PDF bestandje beluisterd?
> >
> > Ik. Jij nog niet?
>
> HTML wel, PDF niet nee. Hoe beluister jij PDF?
Ik wist niet dat HTML geluid maakt, het enige wat je kunt doen is een geluid
bestand in je pagina plaatsen. Dat kan bij PDF ook, net als het plaatsen van
hyperlinks, urls, quicktime etc.
> [knip]
>
> > Maak je borst maar nat, PDF wordt standaard formaat in Mac OS X.
>
> Hm... Hoe moet ik me dat precies voorstellen?
> Ik heb eens een Rhapsody demonstratie meegemaakt waarbij werd getoond hoe
> het systeem inderdaad voor alles postscript gebruikt. Mooi.
Wat nu PICT is wordt PDF.
> Maar ik had er
> niet uit begrepen dat ik dan niet meer zelf in m'n browser kan bepalen hoe
> een document wordt weergegeven. [Niet dat de huidige browsers daar nou zo
> geweldig goed in zijn.]
Dat is ook niet gezegd neem ik aan, niet bij die demonstratie en niet door
mij. Reken er toch maar op dat PDF een blijvertje is wat je vaker tegen zal
komen in de toekomst.
Stel je voor een pagina met wat tekst, een paar plaatjes, een paar links naar
nog twee van dergelijke pagina's. Hoe ziet dat er uit als je het download als
HTML? Een folder met drie HTML bestanden, en vijftien GIFje/JPEGjes. Zoiets
downloaden is trouwens ook niet echt eenvoudig. En pas op dat je niets
verplaatst in dit geheel want dan krijg je te maken met gebroken links en dan
ziet die pagina er dus niet meer uit. En hoe ziet het er uit als PDF? Eén
bestand waar alles in zit, plaatjes en links, bij elkaar niet veel groter dan
de HTML folder. Eenvoudig te printen, geen gebroken links en je weet zeker dat
je ziet wat de maker bedoeld heeft.
> --
> Sander Tekelenburg, <URL:http://www.euronet.nl/%7Etekelenb/>
> 'From'-header is invalid. Use Rot 13 on <grxr...@rhebarg.ay>
>
> ...and on the 7th day, God turned off his Macintosh.
--
Roeland Pluijmers
gaf geworden.
Om daarover en aan de hand daarvan nog wat op te merken:
Ongetwijfeld is het Acrobat-Format superieur in bepaalde
opzichten.
Ik mopperde erover dat Apple mij om doorzichtige
commerciele redenen naar zo'n Acrobatlezer wil leiden.
Ik heb op mijn systemen het hoognodige; ik gooi er zoveel
als mogelijk de bijgeleverde demo's en dergelijke af.
Ik heb nooit eerder die Acrobat reader nodig gehad, en ik
ga niet zo'n ding opzoeken om een commercieel tekstbestandje
te lezen.
Dat gegoochel met standaards verveelt me. Het kan ook anders.
Een voorbeeld.
Door de opschudding over het afvoeren van CNN van het
Amsterdamse kabelnet raakte ik geinteresseerd in de
website van MediaOne, een van de eigenaren van KTA-Amsterdam.
Op dat moment had ik alleen mijn kleine nootboekje
bij de hand. Daarop zat toen een Mosaic Browser, aangesloten
op Compuserve.
De Site van MediaOne was met deze browser vrijwel-,
en de site van KTA-Amsterdam was met deze browser
volledig- onbruikbaar, omdat mijn kleine Mosaic geen 'Frames'
(je weet wel, Frames!!....) heeft.
Neem daartegenover een site als die van GTE, een Amerikaans
telefoonbedrijf, eigenaar van Bolt Beranek & Newman, een
firma die zowat aan de wieg van het Internet heeft gestaan.
Deze is toegankelijk ook met zo'n oerbrowser, omdat ze de
toegang van hun site niet afhankelijk hebben gemaakt van
de beschikbaarheid op het clientsysteem van de nieuwste
technologie.
Ik laat de details maar schieten, maar de GTE-BBN wereld is
een andere dan die van MediaOne.
Dat Netscape en Microsoft druk bezig zijn af te tasten
hoever ze kunnen gaan met het inspinnen van de clientele
van hun Internetservers is langzamerhand algemeen bekend.
Maar ook anderen proberen hun klanten afhankelijk te maken.
Anderen, zoals Apple.
* * *
Ik heb een paar jaar geleden voor het eerst van die
Acrobat dingen gehoord: via Compuserve kon men zich abonneren
op tijdschriften die hiervan gebruikmakend electronisch
via Cis werden verspreid. Tegen dergelijke initiatieven maak
ik geen bezwaar. Waarom zou ik?
(Bij Apple zocht ik naar typen en prijzen, meen ik me te
herinneren. Ik heb verschillende sites (ik geloof .nl ,
en .com bezocht.))
* * *
De iMac wordt vooral als Internetterminal geadverteerd.
Als je dat ding ( 1, 2, (er is geen drie) ) in de
browser laat opkomen krijg je een Microsoftscherm.
Zo gaat dat. Niet leuk.
Steven
>
> In article <363A3B10...@sifre.demon.nl>, Steven
> <ste...@sifre.demon.nl> wrote:
>
> > Sander Tekelenburg wrote:
> > >
> > > In article <36390824...@sifre.demon.nl>, Steven
> > > <ste...@sifre.demon.nl> wrote:
>
> > > > Dat is lang niet altijd wenselijk.
> > >
> > > Kun je mij 'verlichten'? In welke situatie is dat bv niet wenselijk?
> >
> > Als je een bepaald lettertype wilt gebruiken dat belangrijk is voor het
> > ontwerp bijvoorbeeld. Als je veel aandacht aan een ontwerp hebt besteed en
> > niet wilt dat dit verloren gaat
>
> zoek is naar informatie.
> In dat laatste geval zul je eerder irritatie oproepen, zoals de aanzet van
> deze draad aangeeft. [Of je dat als maker ooit te weten zult komen is de
> vraag - Hoe vaak neem jij de moeite je te beklagen bij een Webmaster omdat
> haar site je niet bevalt?]
Als ik de keuze heb kies ik voor PDF. HTML is wat mij betreft een ramp.
> Begrijp me niet verkeerd: Ik ben musicus en ik denk dat ik dus aardig kan
> inschatten welke rol de creatieve krachten spelen bij een vormgever. Als
> ik iets abstracts wil overbrengen gebruik ik daar muziek voor. En om dat
> goed te doen studeer ik me suf en is het vervolgens dus fijn om er
> waardering voor te krijgen, evenals je je heel gemakkelijk aangevallen
> voelt wanneer die waardering uitblijft (of erger ;-)). Maar, wanneer ik
> iets concreets wil overbrengen weet ik heel goed dat ik beter
> woorden/tekst kan gebruiken dan muziek. Als ik tenminste begrepen wil
> worden ;-)
PDF is ook niet voor alles bedoeld.
> Ik weet ook dat wanneer ik m'n tekst opneem en als een audio document op
> het Web zet, een dove/slechthorende daar niet veel aan zal hebben. Dus
> gebruik ik HTML. Kan iedereen zelf bepalen op wat voor manier-ie m'n
> informatie laat weergeven[1].
>
> >, als je een ontwerp gemaakt hebt voor print
> > bijvoorbeeld.
>
> Gebruik CSS om een Print Style Sheet te definieren [en moedig
> browsermakers aan het al jaren bestaande CSS eindelijk eens degelijk te
> implementeren].
Nog zo'n ramp.
> > Er zijn talloze ontwerp situaties te noemen die simpelweg niet
> > te realiseren zijn in HTML.
>
> Als je wilt lay-outen moet je inderdaad geen HTML gebruiken.
> Andersom is even waar: als je informatie wilt aanbieden moet je geen PDF
> gebruiken.
Onzin. Als je doelgroep voornamelijk bestaat uit blinde newton gebruikers
mischien. PDF is een uitstekend medium om gestructureerde informatie over te brengen.
> > > > > Wie heeft er al eens een PDF bestandje beluisterd?
> > > >
> > > > Ik. Jij nog niet?
> > >
> > > HTML wel, PDF niet nee. Hoe beluister jij PDF?
> >
> > Ik wist niet dat HTML geluid maakt
>
> HTML is een taal waarmee je enkel en alleen een _structuur_ aanbrengt in
> een tekst document [en eventuele extra's, als plaatjes, etc. er aan
> koppelt]. Hoe die tekst wordt weergegeven wordt bepaald door de browser
> [in relatie tot de gebruiker's instellingen, en haar hardware]. Als die
> browser kan praten wordt hetzelfde HTML document gewoon voorgelezen. Hoeft
> de HTML-maker niets extra's voor te doen.
> Met bv de Webbrowser MacLynx[2] kun je HTML pagina's dmv Apple's standaard
> met het systeem geleverde Speech technologie laten voorlezen. Reken maar
> dat een blinde/slechtziende meer heeft aan zoiets dan aan een PDF
> bestandje.
> [Dat de 'big 2' dit niet kunnen licht alweer aan de
> luiheid/kortzichtigheid van de makers er van. Niet aan HTML, nog aan je
> Mac.]
Met alle respect hoor, maar ik vind niet dat we allemaal in een rolstoel
moeten rijden omdat sommige mensen zich daar noodgedwongen in moeten
voortbewegen. Ik ben helemaal voor oplossingen voor mensen met fysieke
problemen, maar ik vind niet dat we daarvoor iederéén beperkingen moeten opleggen.
> >, het enige wat je kunt doen is een geluid
> > bestand in je pagina plaatsen. Dat kan bij PDF ook, net als het plaatsen van
> > hyperlinks, urls, quicktime etc.
>
> Da's dus niet wat ik bedoelde.
>
><KNIP>
>
> [knip]
>
> > Stel je voor een pagina met wat tekst, een paar plaatjes, een paar links naar
> > nog twee van dergelijke pagina's. Hoe ziet dat er uit als je het download als
> > HTML? Een folder met drie HTML bestanden, en vijftien GIFje/JPEGjes. Zoiets
> > downloaden is trouwens ook niet echt eenvoudig.
>
> De meeste browsers doen dat toch niet onaardig? ;-) [Het downloaden dan.
> Weergave hebben ze wat meer moeite mee.]
Jij vind het mischien prachtig, ik vind het af en toe kromme tenen werk.
>
> Wellicht doel je op het downloaden v.e. complete directory voor off-line
> browsing?
Juist, dat bedoelde ik.
> Daar zijn browsers meestal niet voor gemaakt, maar er zijn wel
> diverse andere tools voor. Het gloedjenieuwe Anarchie Pro 3 bv. En ik hoop
> ook redelijke ervaringen met WebRetriever, dat de links direct ombouwd
> naar je locale situatie.
Wat een zootje onzin krijg je dan op je schijf gekwakt.
> Dan nog: De aanbieder kan net zo makkelijk een link geven naar een
> gecomprimeed bestandje met daarin de HTML en daaraan gelinkte documenten.
> Veel shareware auteurs leveren hun documentatie in die vorm.
Als ze ook een PDFje bieden kies ik dat.
> > En pas op dat je niets
> > verplaatst in dit geheel want dan krijg je te maken met gebroken links en dan
> > ziet die pagina er dus niet meer uit.
>
> [Daarmee geef je een mooie voorzet om deze draad weer wat richting
> on-topic te krijgen ;-)]
>
> Lijkt me een aardige analogie:
> Als je zonder te weten wat je doet van alles in je systeemmap gaat zitten
> verslepen loop je ook het risico dat iets het niet meer doet.
Een document met informatie is iets anders als een folder met systeem
software, alsjeblieft...
> Als Apple
> dan denkt:"We gaan het die domme gebruikers makkelijker maken", en
> vervolgens met de oplossing komt dat de _gehele_ systeemmap uit 1 bestand
> bestaat, waaraan de gebruiker niets kan veranderen/instellen, en het spul
> alleen kan 'gebruiken' zoals Apple dat 'ontworpen' heeft, zouden jij en ik
> en alle Mac gebruikers Apple waarschijnlijk naar de strot vliegen.
Een beetje vergezocht deze vergelijking, als je het mij vraagt.
> Er is niet voor niks een overdaad aan shareware om je Mac meer aan je
> eigen wensen te laten voldoen. Tot en met Kaleidoscope plug-ins om OS8 een
> OS7 look te geven.
> Gebruikers willen _zelf_ bepalen hoe hun machine werkt, reageert, en
> weergeeft. HTML is daar uitermate geschikt voor. Is er zelfs speciaal voor
> bedacht. PDF niet.
Hoe wil jij je krant in de bus hebben? Opgemaakt en leesbaar of gewoon als een
berg knipsels en plaatjes?
> > En hoe ziet het er uit als PDF? Eén
> > bestand waar alles in zit, plaatjes en links, bij elkaar niet veel groter dan
> > de HTML folder. Eenvoudig te printen
>
> De printproblemen met HTML hebben alles te maken met browsers en niets met
> HTML an sich.
Nee, zoals ik al eerder zei, HTML heeft bij lange na niet de accuratesse die
nodig is om behoorlijk drukwerk af te leveren.
> >, geen gebroken links en je weet zeker dat
> > je ziet wat de maker bedoeld heeft.
>
> Klopt.
> Maar dat zal me worst wezen wanneer ik slechts op zoek ben naar informatie.
Opmaak geeft informatie struktuur zodat zijn beter verwerkt kan worden. Het
treurige resultaat van het feit dat dat veel mensen worst is kan iedere dag in
HTML bekeken worden.
> [Ik vraag me overigens af of ik op m'n Newton je PDF bestand zou kunnen lezen.]
Ik denk het niet. Waarom zou je? PDF is high quality. Newton niet.
>
><KNIP>
>
> Apple zegt dus in essentie: Download ons PDF document, scan het in, laat
> je OCR software er mee stoeien, laat je Mac het je voorlezen.
> Terwijl dezelfde informatie met gewone huis-tuin-en-keuken HTML voor
> _iedereen_ even gemakkelijk toegankelijk was geweest.
Ik weet niet of Apple dat zegt. Ik vind dat mischien een reden om bij Apple
aan de bel te trekken en te vragen of er _NAAST_ de pdf bestanden ook een
andere vorm is waarin de informatie wordt aangeboden. Ik vind dit geen reden
op het PDF formaat in het algemeen de schuld te geven.
Steven
>
> Ik mopperde erover dat Apple mij om doorzichtige
> commerciele redenen naar zo'n Acrobatlezer wil leiden.
Ondoorzichtig omdat geen commercieel complot achter zit. Reader is gratis en
werkt op vrijwel alle computers. Wat is het commercieel belang van Apple?
> Ik heb op mijn systemen het hoognodige; ik gooi er zoveel
> als mogelijk de bijgeleverde demo's en dergelijke af.
> Ik heb nooit eerder die Acrobat reader nodig gehad, en ik
> ga niet zo'n ding opzoeken om een commercieel tekstbestandje
> te lezen.
Klinkt een beetje fobisch.
Hoe dan?
> * * *
> Ik heb een paar jaar geleden voor het eerst van die
> Acrobat dingen gehoord: via Compuserve kon men zich abonneren
> op tijdschriften die hiervan gebruikmakend electronisch
> via Cis werden verspreid. Tegen dergelijke initiatieven maak
> ik geen bezwaar. Waarom zou ik?
>
>
> (Bij Apple zocht ik naar typen en prijzen, meen ik me te
> herinneren. Ik heb verschillende sites (ik geloof .nl ,
> en .com bezocht.))
>
> * * *
>
> De iMac wordt vooral als Internetterminal geadverteerd.
> Als je dat ding ( 1, 2, (er is geen drie) ) in de
> browser laat opkomen krijg je een Microsoftscherm.
> Zo gaat dat. Niet leuk.
Sorry? Welk ding in de brouwser "laten opkomen"?
>
> Bedankt voor het lezen.
>
> R.
>
> --
> Roeland Pluijmers 10002...@compuserve.com
--
Steven
>
>
> > > Gebruik CSS om een Print Style Sheet te definieren [en moedig
> > > browsermakers aan het al jaren bestaande CSS eindelijk eens degelijk te
> > > implementeren].
> >
> > Nog zo'n ramp.
>
> Wat, en waarom?
Browsermakers hebben wel wat anders aan hun hoofd. Zoals ontwerpers vierendelen.
> > Met alle respect hoor, maar ik vind niet dat we allemaal in een rolstoel
> > moeten rijden omdat sommige mensen zich daar noodgedwongen in moeten
> > voortbewegen.
>
> Die rolstoel is de browser. De openbare weg is HTML.
Zo ver wilde ik de vergelijking niet doorvoeren. Dan raken we alleen maar
verstrikt in toevallige semantische connecties tussen rolstoelen en snelwegen...
> Ik zeg toch niet dat iedereen alleen het Web op mag met een
> braille-browser?
Nee, je zegt dat alle informatie in HTML geleverd moet worden. En alles wat
daar kwalitatief met kop en schouders boven uitsteekt moet gesnoeid worden.
> Ik zeg dat dmv HTML informatie voor iedereen even
> toegankelijk kan zijn. Ik vind het nogal arrogant om dan toch voor een
> ander formaat te kiezen en daarmee bepaalde groepen uit te sluiten.
Dus het is ook arrogant te praten waar doven bij zijn?
> > Ik ben helemaal voor oplossingen voor mensen met fysieke
> > problemen, maar ik vind niet dat we daarvoor iederéén beperkingen moeten
> opleggen.
>
> PDF legt beperkingen op aan in- en validen door hen niet zelf te laten
> bepalen hoe de informatie wordt weergegeven.
> HTML legt een beperking op aan de auteur door haar niet tot op de
> millimeter nauwkeurig te laten voorschrijven hoe het document zal worden
> ge-lay-out.
Niet alleen aan de auteur ook aan de lezer. Niet alleen millimeters, ook fonts
en meer.
> Het is aan de professionaliteit van de auteur om in een specifieke
> situatie de juiste keuze te maken.
Juist. Apple heeft kennelijk een aantal specsheets die zij voor print gemaakt
heeft in PDF formaat beschikbaar gesteld. Schande!
> [Als ik wordt gevraagd op een bruiloft
> gezellige achtergond muziek te maken weet ik dat ik niet met heftige free
> jazz aan moet komen. Als Han Reiziger me voor zijn programma uitnodigt
> weet ik dat ik lekker creatief kan gaan zijn en dat-ie me niet verwacht
> met een top40 cover-bandje.]
Nu heb je het ineens weer over de inhoud i.p.v container. Niet zo'n
gelukkige vergelijking.
> [knip]
>
> [off-line HTML]
> > > Daar zijn browsers meestal niet voor gemaakt, maar er zijn wel
> > > diverse andere tools voor. Het gloedjenieuwe Anarchie Pro 3 bv. En ik heb
> > > ook redelijke ervaringen met WebRetriever, dat de links direct ombouwd
> > > naar je locale situatie.
> >
> > Wat een zootje onzin krijg je dan op je schijf gekwakt.
>
> Gewoon een folder, met daarin alle gelinkte documenten. Wat is het probleem?
Als jij dat zo fijn vind: fijn. Ik vind het een gammel zootje. Alleen voor een document!
> > > Als je zonder te weten wat je doet van alles in je systeemmap gaat zitten
> > > verslepen loop je ook het risico dat iets het niet meer doet.
> >
> > Een document met informatie is iets anders als een folder met systeem
> > software, alsjeblieft...
>
> [knip]
>
> > Een beetje vergezocht deze vergelijking, als je het mij vraagt.
>
> Jij schreef:"En pas op dat je niets verplaatst in dit geheel want dan
> krijg je te maken met gebroken links en dan ziet die pagina er dus niet
> meer uit."
>
> In beide situaties gaat het over een zooitje files die tezamen 1 geheel
> vormen en waarin je niet zonder te weten wat je doet dingen moet gaan
> verplaatsen. Prima analogie dus.
Je Systeem map is geen document. Een document is een container waarin
informatie vastgelegd is. Een Systeemmap is geen vastgelegde informatie maar
geheel dat informatie verwerkt. Heel iets anders.
> > Hoe wil jij je krant in de bus hebben? Opgemaakt en leesbaar of gewoon als een
> > berg knipsels en plaatjes?
>
> Geef mij maar die berg knipsels en plaatjes. Graag zelfs! :-) Die kan ik
> dan in een browser volgens mijn voorkeuren laten weergeven. Kan ik
> plaatjes en advertenties die ik niet wil zien onderdrukken. Kan ik m'n
> voorkeurs lettertype en grootte gebruiken. Kan ik bookmarks aanmaken naar
> zaken die ik later nog weer eens wil opzoeken. Kan ik zelf bepalen of die
> krant tijdens het lezen m'n hele tafel in beslag neemt, of slechts een
> gedeelte, zodat m'n koffie er nog veilig naast kan staan. Kan ik er voor
> kiezen me die krant door m'n browser te laten voorlezen terwijl ik me
> douche.
Jij houdt je kennelijk liever bezig met puzzelen dan met het lezen van de krant.
Trouwens hoe zet je de krant die in de bus valt in je brouwser inelkaar? Ga je
hem eerst inscannen etc...?
> [knip]
>
> > [...] HTML heeft bij lange na niet de accuratesse die
> > nodig is om behoorlijk drukwerk af te leveren.
>
> Je had het over printen. Dan denk ik aan de gemiddelde
> huis-tuin-en-keuken-StyleWriter of zo. Bij de term 'drukwerk' denk ik aan
> professionele kwaliteit [tijdschriften, posters, etc.]. Ik wist niet dat
> PDF in die laatste situatie ook wordt gebruikt.
Wel degelijk. PDF wordt héél belangrijk in de drukkers wereld. En zelfs op m'n
huis tuin en keuken printertje kan ik je gegarandeerd aanwijzen wat van
oorsprong PDF is en wat HTML.
> > > [...opmaak...] zal me worst wezen wanneer ik slechts op zoek ben naar
> informatie.
> >
> > Opmaak geeft informatie struktuur zodat zijn beter verwerkt kan worden.
>
> HTML gaat dan ook _juist_ over struktuur :-)
Een grove struktuur met vele beperkingen.
> > Het
> > treurige resultaat van het feit dat dat veel mensen worst is kan iedere dag in
> > HTML bekeken worden.
>
> Dat auteurs niet met hun gereedschap [HTML] om kunnen gaan kun je moeilijk
> dat gereedschap verwijten.
Nee, het ligt niet alleen aan de makers -er zijn er inderdaad veel, zoals jij
die het allemaal worst is en die maar wat doen- het ligt voor een groot deel
ook aan de beperkingen van HTML die een verarming van de beeldtaal inhoud
door alles in een tamelijk ruw stramien te persen.
> > > [Ik vraag me overigens af of ik op m'n Newton je PDF bestand zou
> kunnen lezen.]
> >
> > Ik denk het niet. Waarom zou je?
>
> Ik ben op reis. M'n desktop pastte net niet in m'n koffer, dus heb ik
> niets anders dan m'n Newton en GSM beschikbaar. Ik zoek een hotel voor die
> avond. Informatie over jouw hotel is alleen in PDF beschikbaar. Je
> concurrent gebruikt HTML. Mijn keuze is snel gemaakt.
Zijn we terug bij de keuze voor het meest geschikte bestandsformaat voor de
betreffende informatie. Ik ben nog geen reisburo tegen gekomen die dergelijke
informatie aanbied in PDF formaat. Wat let je om te bellen trouwens? Of mag
tegenwoordig niets meer op de eenvoudige manier?
> > > Apple zegt dus in essentie: Download ons PDF document, scan het in, laat
> > > je OCR software er mee stoeien, laat je Mac het je voorlezen.
> > > Terwijl dezelfde informatie met gewone huis-tuin-en-keuken HTML voor
> > > _iedereen_ even gemakkelijk toegankelijk was geweest.
> >
> > Ik weet niet of Apple dat zegt. Ik vind dat mischien een reden om bij Apple
> > aan de bel te trekken en te vragen of er _NAAST_ de pdf bestanden ook een
> > andere vorm is waarin de informatie wordt aangeboden.
>
> Sure. Als Apple alles graag dubbel doet kan ze dezelfde informatie ook in
> audio-formaat aanbieden.
> Als Apple de boel gewoon in valid HTML aanbiedt hoeft ze geen dubbel werk
> te leveren.
Apple moet helemaal geen drukwerk meer uitgeven? Geen folders met specs?
> Heeft Apple meer resources beschikbaar om MacOS X verder te
> ontwikkelen ;-)
Als het je zo hoog zit moet je Apple daar maar eens op aanspreken. Laat me
weten wat ze zeggen. Dan vraag ik bij Adobe na of ze iets gaan doen aan de
"voorleesbaarheid" van PDF.
> > Ik vind dit geen reden
> > op het PDF formaat in het algemeen de schuld te geven.
>
> Ik ook niet. Ik reageer op het _gebruik_ van het gereedschap.
Steven
>
> In article <363D3C12...@sifre.demon.nl>, Steven> [knip]
>
> > > Ik zeg toch niet dat iedereen alleen het Web op mag met een
> > > braille-browser?
> >
> > Nee, je zegt dat alle informatie in HTML geleverd moet worden.
>
> Ik zeg dat de revolutionaire kracht van HTML niet wordt gezien.
Dat zie ik wel. Ik echter _ook_ de beperkingen die jij niet lijkt te zien. Het
zeker niet "all things to all people" en dus geen vervanger voor andere formaten.
> Dat heeft IMHO alles te maken met
> 1) de moeite die veel mensen blijken te hebben met de abstractie van
> WYSIMPNWOS [WhatYouSeeIsMostProbablyNotWhatOthersSee].
> 2) de maatschappij die [nog] geen kans ziet naast het vastleggen van HTML
> en CSS als standaards ook de implemetatie er van bij de gebruiker te
> krijgen [lees: er zijn geen goede browsers.]
> 3) het feit dat het bedrijfsleven in dat gat springt met haar eigen
> 'standaards'.
>
Nee, HTML heeft inherente beperkingen die blijven bestaan, ook als al deze
hobbels genomen zijn blijft er een legitieme plaats voor ander formaten, zoals PDF.
> > > Ik zeg dat dmv HTML informatie voor iedereen even
> > > toegankelijk kan zijn. Ik vind het nogal arrogant om dan toch voor een
> > > ander formaat te kiezen en daarmee bepaalde groepen uit te sluiten.
> >
> > Dus het is ook arrogant te praten waar doven bij zijn?
>
> Kom op Steven. Ik ben een hoger niveau van je gewend.
Het is gewoon een vraag die voortvloeid uit jouw opmerking. Een medium
gebruiken dat sommigen niet kunnen gebruiken is arrogant volgens jou. Ik zou
niet weten waarom deze vraag onder de maat zou zijn.
> > [...] Apple heeft kennelijk een aantal specsheets die zij voor print gemaakt
> > heeft in PDF formaat beschikbaar gesteld. Schande!
>
> Als _dat_ de situatie is [bij die mogelijkheid had ik nog niet stil
> gestaan] kan ik me nog iets bij voorstellen bij hun keuze voor PDF. Een
> reeds bestaand document ff naar PDF 'printen' is net iets sneller dan het
> omzetten naar HTML. [Maar veel hoeft het niet te schelen.]
Het is trouwens ook mogelijk vanuit bijvoorbeeld PageMaker te exporteren naar
HTML. Het is dus heel wel mogelijk om informatie tegen geringe kosten in beide
formaten te leveren zoals ik ook al eerder suggereerde.
> > > [Als ik wordt gevraagd op een bruiloft
> > > gezellige achtergond muziek te maken weet ik dat ik niet met heftige free
> > > jazz aan moet komen. Als Han Reiziger me voor zijn programma uitnodigt
> > > weet ik dat ik lekker creatief kan gaan zijn en dat-ie me niet verwacht
> > > met een top40 cover-bandje.]
> >
> > Nu heb je het ineens weer over de inhoud i.p.v container. Niet zo'n
> > gelukkige vergelijking.
>
> Je hebt gelijk.
>
> [knip]
>
> [analogie 'Systeemmap' <-> 'folder met via HTML gelinkte files']
> > Je Systeem map is geen document. Een document is een container waarin
> > informatie vastgelegd is. Een Systeemmap is geen vastgelegde informatie maar
> > geheel dat informatie verwerkt. Heel iets anders.
>
> De _functie_ is anders ja. Niet de fysieke structuur op je harddisk.
Kijk, dat zal _mij_ nou worst wezen, het zijn uiteidelijk allemaal eenen en
nullen. Dat wil toch niet zeggen dat het niet nuttig is een onderscheid te
maken tussen een applicatie en een document?
> En
> niet het principe dat beiden bestaan uit een aantal verschillende delen
> die onlosmakelijk met elkaar zijn verbonden, met als doel de gebruiker
> invloed te kunnen laten uitoefenen op het gedrag van het geheel.
Het punt van een document is juist dat het een vastgelegt geheel is.
> > > > Hoe wil jij je krant in de bus hebben? Opgemaakt en leesbaar of
> gewoon als een
> > > > berg knipsels en plaatjes?
>
> [knip]
>
> > Trouwens hoe zet je de krant die in de bus valt in je brouwser inelkaar? Ga je
> > hem eerst inscannen etc...?
>
> Flauw hoor. Een Website bestaat ook uit aan elkaar gelinkte documenten.
> Als de maker dat linken nalaat wordt het inderdaad puzzelen of wegrennen.
> Er zijn al veel kranten on-line. Ik ben er nog niet 1 tegen gekomen die
> het niet nodig vond z'n teksten, plaatjes, etc. aan elkaar te koppelen.
HTML is een mooi medium voor online reading. Het is naar mijn mening niet erg
geschikt als portable formaat, of om bestaande vormgeving tot zijn recht te
laten komen.
> > > Dat auteurs niet met hun gereedschap [HTML] om kunnen gaan kun je moeilijk
> > > dat gereedschap verwijten.
> >
> > Nee, het ligt niet alleen aan de makers -er zijn er inderdaad veel, zoals jij
> > die het allemaal worst is en die maar wat doen-
>
> Lees nog eens terug. Zul je zien dat ik schreef dat het me als _lezer_
> worst zal zijn hoe de maker vind dat het moet worden opgemaakt. Daarvan
> maak jij nu opeens dat ik als HTML _maker_ 'maar wat doe'. Iets dat mijn
> 'kruistocht voor HTML' alhier nou niet direct suggereert.
Sorry, dat was niet beledigend bedoeld, maar ik kan er eigenlijk niet omheen.
Ik kan me niet voorstellen dat het je aan de ene kant worst is hoe het er
uitziet en het aan het de andere kant een punt van kritische beschouwing en
zorg is
voor je.
> > het ligt voor een groot deel
> > ook aan de beperkingen van HTML die een verarming van de beeldtaal inhoud
> > door alles in een tamelijk ruw stramien te persen.
>
> Waarom is de _verrijking_ die HTML biedt nou zo moeilijk te zien? :-)
Die zie ik ook wel. In sommige omstandigheden weegt die echter niet op tegen
de nadelen.
> > > Ik ben op reis. M'n desktop pastte net niet in m'n koffer, dus heb ik
> > > niets anders dan m'n Newton en GSM beschikbaar. Ik zoek een hotel voor die
> > > avond. Informatie over jouw hotel is alleen in PDF beschikbaar. Je
> > > concurrent gebruikt HTML. Mijn keuze is snel gemaakt.
> >
> > Zijn we terug bij de keuze voor het meest geschikte bestandsformaat voor de
> > betreffende informatie. Ik ben nog geen reisburo tegen gekomen die dergelijke
> > informatie aanbied in PDF formaat.
>
> Misschien niet. Maar er zijn er genoeg die hun site van plaatjes en
> JAVAscript afhankelijk maken omdat ze informatie en lay-out niet los van
> elkaar kunnen zien. Dan gaat het in principe om hetzelfde probleem.
Dat is het probleem met werken met een formaat met een onduidelijke standaard
die door verschillende commerciele instanties naar eigen inzich wordt
aangepast. Zie ook mijn eerdere opmerking over het vierendelen van ontwerpers
door brouwser makers. Als je informatie op het net zet moet je er inderdaad bij
stilstaan voor wie deze bedoeld is. Als je als Newton gebruiker iets niet kunt
lezen kun je daar ook in veel gevallen uit concluderen dat je Newton tekort
schiet voor de betreffende informatie in plaats van dat de ontwerper niet deugd.
> > Wat let je om te bellen trouwens? Of mag
> > tegenwoordig niets meer op de eenvoudige manier?
>
> Bellen betekent een lokaal telefoonboek [of vergelijkbare bron] vinden; 1
> voor 1 diverse hotels opbellen; je vragen klaar hebben; voor elk
> telefoontje wachten tot er opgenomen wordt; hopen dat je een
> gemeenschappelijke taal spreekt; antwoorden noteren om ze later te kunnen
> vergelijken; opnieuw bellen om je keuze te boeken.
> 1 keer inloggen, een paar pagina's opzoeken en opslaan, vergelijken en tot
> slot 1 telefoontje om te boeken is gewoon sneller/makkelijker.
Als dat reisburo een presence heeft op het web zal het vast ook wel een
telefoonnummer hebben op die page die door je Newton gelezen kan worden. Dat
reisburo kan je vervolgens -als het een goed reisburo is- prima voorlichten
over de mogelijkheden betreffende hotels. Er zijn zelfs mensen die reizen
zonder
Newton!:-)
> Zullen we het hier bij laten? Het begint zo langzamerhand een herhaling
> van dezelfde argumenten te worden. [Het is zo langzamerhand ook hoogstens
> on-topic in de zin dat veel Mac gebruikers grafisch onwerper zijn.]
Als we het er over eens zijn dat beide formaten hun voordelen en beperkingen
hebben en dus beide bestaansrecht hebben en dat niet één van beide de voorkeur
heeft voor _alle_ informatie is het belangrijkste wel gezegd inderdaad.
zie je later,
Steven
Steven
>
> In article <363F3AA8...@sifre.demon.nl>, Steven
> <ste...@sifre.demon.nl> wrote:
>
> > Sander Tekelenburg wrote:
> > >
> > > In article <363D3C12...@sifre.demon.nl>, Steven
> > > <ste...@sifre.demon.nl> wrote:
> > >
> > > > Sander Tekelenburg wrote:
>
> [knip]
>
> >
> > Dat zie ik wel. Ik echter _ook_ de beperkingen die jij niet lijkt te zien.
>
> diezelfde beperking, waar het opmaak betreft, echter als een groot
> voordeel.
Ik denk dat de lezer wil lezen en zich niet wil bezig houden met de layout.
Stanley Morison -Typograaf, ontwerper van Times lettertype- zegt: "Typografie
zou men kunnen definiëren als de kunst drukmateriaal zodanig te schikken, dat
dit in overeenstemming is met een specifiek doel: de letters te schikken, het
wit te verdelen, en het zetsel te ordenen om de lezer in de hoogst mogelijke
mate behulpzaam te zijn bij het begrijpen van de tekst. Typografie is een
zakelijk middel tot een vooral nuttig en slechts bij toeval esthetisch doel,
want het genieten van fraaie figuren is zelden het voornaamste oogmerk van de
lezer. Hij heeft ook gezegd: (uit m'n hoofd) "Een goed ontworpen letter is
onzichtbaar".
Bij HTML is de kans te groot dat je afgeleid wordt door de opmaak en de
typografie. Jij lijkt de denken dat lay out en typografie liefhebberijen van
ontwerpers zijn die de lezer voor lief moet nemen...
> [knip]
>
> > > > > Ik zeg dat dmv HTML informatie voor iedereen even
> > > > > toegankelijk kan zijn. Ik vind het nogal arrogant om dan toch voor een
> > > > > ander formaat te kiezen en daarmee bepaalde groepen uit te sluiten.
> > > >
> > > > Dus het is ook arrogant te praten waar doven bij zijn?
> > >
> > > Kom op Steven. Ik ben een hoger niveau van je gewend.
> >
> > Het is gewoon een vraag die voortvloeid uit jouw opmerking. Een medium
> > gebruiken dat sommigen niet kunnen gebruiken is arrogant volgens jou. Ik zou
> > niet weten waarom deze vraag onder de maat zou zijn.
>
> We hebben het over digitale communicatie, waarin HTML voor iedereen even
> toegankelijk is.
> Dat doorttrekken naar 'real life' waar iets als HTML [bij mijn weten]
> uiteraard geen optie is vind ik flauw.
Ik wil niet drammerig lijken, maar dit is niet flauw bedoeld. Jouw stelling
is: "Het is arrogant om een medium te kiezen waarmee je anderen uitsluit."
Naar mijn mening doet het feit of het een digitaal medium dan wel een analoog
medium betreft niets af aan het oordeel dat je daarmee geeft. Daarmee zou dat
oordeel ook geldig zijn in de door mij geschetste situatie, d.i. praten waar
doven bij zijn is arrogant.
> > > [analogie 'Systeemmap' <-> 'folder met via HTML gelinkte files']
> > >
> > > De _functie_ is anders ja. Niet de fysieke structuur op je harddisk.
> >
> > Kijk, dat zal _mij_ nou worst wezen
>
> Dat zal je geen worst wezen, want 1 van je argumenten tegen HTML was dat
> je in de zooi documenten niets mag verplaatsen omdat het dan niet meer
> werkt en je daarom bij voorkeur met 1 allesomvattend bestand te maken
> hebt.
Het zal me wčl worst wezen! Jij zegt: "Het is hetzelfde omdat het allemaal om
mijn schijf staat". Ik zeg: "Dat het allemaal enen en nullen zijn zal mij
worst wezen wat voor mij van belang is de functie".
>
> >, het zijn uiteidelijk allemaal eenen en
> > nullen. Dat wil toch niet zeggen dat het niet nuttig is een onderscheid te
> > maken tussen een applicatie en een document?
>
> Uiteraard.
> M'n punt was dat als alles in 1 document zit vastgebakken de gebruiker het
> veel minder kan beďnvloeden. Weg interactiviteit.
Nee. De interactiviteit zit hem in de links, en de multimedia die er in is
verwerkt. Het feit dat ik het lettertype kan veranderen beschouw ik niet als
interactiviteit. Interactiviteit heeft naar mijn bescheiden mening te maken
met het verhaal dat de schrijver mij wil vertellen en en de participatie die
mij daarbij toegestaan wordt.
> > > En
> > > niet het principe dat beiden bestaan uit een aantal verschillende delen
> > > die onlosmakelijk met elkaar zijn verbonden, met als doel de gebruiker
> > > invloed te kunnen laten uitoefenen op het gedrag van het geheel.
> >
> > Het punt van een document is juist dat het een vastgelegt geheel is.
>
> Precies :-)
>
> > HTML [...] is naar mijn mening niet erg
> > geschikt [...] om bestaande vormgeving tot zijn recht te
> > laten komen.
>
> Helemaal mee eens. [Daar is HTML dan ook nooit voor bedoeld.]
Dacht ik wel, het is bedoel om informatie te ordenen en toegankelijk te maken.
Hetzelfde doel als bestaande vormgeving.
> > Ik kan me niet voorstellen dat het je aan de ene kant worst is hoe het er
> > uitziet en het aan het de andere kant een punt van kritische beschouwing en
> > zorg is voor je.
>
> Het is me absoluut _geen_ worst hoe het er uit ziet. Maar als begruiker
> wil ik dat zo veel mogelijk _zelf_ bepalen.
Wat zul jij ongelukkig zijn met een degelijk boek. :-)
> > > [...] zijn er genoeg die hun site van plaatjes en
> > > JAVAscript afhankelijk maken omdat ze informatie en lay-out niet los van
> > > elkaar kunnen zien. Dan gaat het in principe om hetzelfde probleem.
> >
> > Dat is het probleem met werken met een formaat met een onduidelijke standaard
>
> HTML een onduidelijke standaard?
Tot een bepaald punt zij ze het er over eens, maar voorbij dat punt worden er
allerlei creatieve dingen aan toegevoegd waar geen overeenstemming over is...
> > die door verschillende commerciele instanties naar eigen inzich wordt
> > aangepast.
>
> Bij HTML is het idee _juist_ dat de browser [aangepast aan hardware
> omstandigheden en software instellingen] de lay-out bepaalt. Een
> browsermaker mag dus naar eigen inzicht HTML lay-outen. _Daarom_ ziet een
> HTML pagina er in iedere situatie ook anders uit.
> Het vervelende is alleen dat tot op heden browsermakers de gebruiker daar
> erg weinig invloed op laten uitoefenen.
Die beperking zit in HTML, niet in de browsers.
> > [...] Als je als Newton gebruiker iets niet kunt
> > lezen kun je daar ook in veel gevallen uit concluderen dat je Newton tekort
> > schiet voor de betreffende informatie in plaats van dat de ontwerper
> niet deugd.
>
> Als die ontoegankelijke informatie bv bestaat uit:"2-persoons kamer
> inclusief ontbijt: Fl 75,-" ligt de fout toch echt bij de ontwerper.
Helemaal mee eens.
> > Als dat reisburo een presence heeft op het web zal het vast ook wel een
> > telefoonnummer hebben op die page die door je Newton gelezen kan worden.
>
> Het is zondagavond, 21:00 uur. Het reisbureau is gesloten. Hun Website niet.
Dat wordt een avontuur!
> > [...] Er zijn zelfs mensen die reizen zonder Newton!:-)
>
> Daar moeten we dan gauw maar eens een steun-fonds voor oprichten ;-)
Ik meld me direkt aan.:-)
> > > Zullen we het hier bij laten? Het begint zo langzamerhand een herhaling
> > > van dezelfde argumenten te worden. [Het is zo langzamerhand ook hoogstens
> > > on-topic in de zin dat veel Mac gebruikers grafisch onwerper zijn.]
> >
> > Als we het er over eens zijn dat beide formaten hun voordelen en beperkingen
> > hebben en dus beide bestaansrecht hebben en dat niet één van beide de voorkeur
> > heeft voor _alle_ informatie is het belangrijkste wel gezegd inderdaad.
>
> Ik kon het toch niet laten :-)
Me neither :-/
Roeland Pluijmers
Deze was informatief, informatief, informatief,
en snel.
Wel geeft hun softwareoverzicht de suggestie dat
de Apple vooral bedoeld is voor grafici & kinderen.
Steven
van goed webdesign?
Steven
>
> In article <363FDF6D...@sifre.demon.nl>, Steven
> <ste...@sifre.demon.nl> wrote:
>
> > Sander Tekelenburg wrote:
> > >
> > > In article <363F3AA8...@sifre.demon.nl>, Steven
> > > <ste...@sifre.demon.nl> wrote:
> > >
> > > > Sander Tekelenburg wrote:
>
> > Stanley Morison -Typograaf, ontwerper van Times lettertype- zegt: "Typografie
> > zou men kunnen definiëren als de kunst drukmateriaal zodanig te schikken, dat
> > dit in overeenstemming is met een specifiek doel: de letters te schikken, het
> > wit te verdelen, en het zetsel te ordenen om de lezer in de hoogst mogelijke
> > mate behulpzaam te zijn bij het begrijpen van de tekst. Typografie is een
> > zakelijk middel tot een vooral nuttig en slechts bij toeval esthetisch doel,
> > want het genieten van fraaie figuren is zelden het voornaamste oogmerk van de
> > lezer. Hij heeft ook gezegd: (uit m'n hoofd) "Een goed ontworpen letter is
> > onzichtbaar".
> >
> > Bij HTML is de kans te groot dat je afgeleid wordt door de opmaak en de
> > typografie.
>
>
> > Jij lijkt de denken dat lay out en typografie liefhebberijen van
> > ontwerpers zijn die de lezer voor lief moet nemen...
>
> Mogelijk laat ik me toch iets te veel leiden door de overdaad aan
> waardeloze vormgevers op het Web?
Dat is heel goed mogelijk..;-)
> Echter, inherent aan het Web is dat
> alles en iedereen kan publiceren. Dus is er per definitie veel troep [qua
> lay-out, content kan uiteraard nog best zeer de moeite waard zijn]. Dan is
> HTML [bij voorkeur in combinatie met user-defined Style Sheets], waarbij
> de gebruiker die lay-out zelf kan bepalen, dus het ideale vehikel.
In theorie en voor on line browsing wel. Als ik een artikel wil bewaren of
printen heb ik liever PDF.
> Wat overeind blijft is dat wanneer je via zoiets als PDF 'op het Web
> print', je als auteur gewoon niet kunt weten hoe het er op het scherm van
> de gebruiker uit zal zien. De auteur weet niet hoe groot dat scherm is,
> hoeveel kleuren er op beschikbaar zijn, hoe snel de beeldopbouw is, welke
> resolutie mogelijk is. [Zelfde geldt uiteraard voor die gebruiker's
> printmogelijkheden, als-ie al een printer heeft.]
Al deze bezwaren gelden ook voor HTML en andere formaten.
> Vķķr m'n PPC-dagen moest ik het doen met een IIci, 8MbRAM, 14",
> 256-kleuren.
Those were the days...
> De ongelooflijk trage beeldopbouw van zo'n PDF file op zo'n
> machine maakte dat ik aan PDF een ontzettende schurfthekel had.
Begrijpelijk.
> Op je
> dooie gemakje een roman in PDF-formaat van a tot z doorlezen ging nog
> enigszins, maar ff wat opzoeken in een in PDF geleverde handleiding was 1
> van de grootste bronnen van ergernis.
> [Toegegeven, dit laatste heeft veel te maken met de auteur die te
> lamlendig is een beschaafde inhoudsopgave met links toe te voegen en die
> dus in plaats daarvan gewoon het voor hardcopy bestemde document ff naar
> PDF print. Maar als het HTML was geweest was de beeldopbouw 30 keer
> sneller geweest en was 'met de hand zoeken' dus geen onoverkomelijk
> probleem. Bovendien is in zo'n tekstbestand 'Comand-F' te gebruiken.]
Die verschillen in snelheid van beeldopbouw zouden nu dus ook moeten bestaan.
Een PDF van één pagina laad net zo snel als een HTML pagina. Het punt met PDF
documenten is dat ze uit vele pagina's bestaan.
>
> [de analogie nog steeds ;-)]
> > > M'n punt was dat als alles in 1 document zit vastgebakken de gebruiker het
> > > veel minder kan beīnvloeden. Weg interactiviteit.
> >
> > Nee. De interactiviteit zit hem in de links
>
> mmmja..., OK..., maar wel of geen links is een keuze van de auteur. Geen
> links, dan geen interactiviteit. Op dit punt gaat het dus niet over
> interactiviteit voortvloeiend uit het _formaat_.
> Als een PDF auteur er voor kiest plaatjes in een document op te nemen komt
> de gebruiker van dat document er niet onderuit dat plaatje 'te laden',
> omdat het nu eenmaal onlosmakelijk in het document zit vastgebakken. Dit
> vloeit _wel_ voort uit het formaat.
Dat is waar.
> >, en de multimedia die er in is verwerkt.
>
> Wat is er voor de gebruiker interactief aan multimedia?
Inderdaad, _werkelijke_ interactiviteit, inbreng, participatie in de
inhoudelijke informatie, is inderdaad nog zeldzaam. Invloed op de vorm waarin
de informatie geconsumeerd wordt komt veel voor maar ik vraag me af of dit
werkelijke interactiviteit is. Ik kan op m't TV ook invoed uitoefenen op het
beeld en het geluid, toch is TV geen interactief medium. Je hebt gelijk,
mutimedia voegt niet direct interactiviteit toe. I was painting with too broad
a brush...
>
> > Het feit dat ik het lettertype kan veranderen beschouw ik niet als
> > interactiviteit.
>
> Ik wel.
Dan is mijn radio ook interactief omdat ik het geluid kan regelen.
> > Interactiviteit heeft naar mijn bescheiden mening te maken
> > met het verhaal dat de schrijver mij wil vertellen en en de participatie die
> > mij daarbij toegestaan wordt.
>
> "Toestemming hebben om interactief te zijn" komt volgens mij aardig in de
> buurt van een contradictio in terminus.
Toestemming is mischien een vreemd woord in deze. Toch is dit geen tegenspraak.
> > > Het is me absoluut _geen_ worst hoe het er uit ziet. Maar als begruiker
> > > wil ik dat zo veel mogelijk _zelf_ bepalen.
> >
> > Wat zul jij ongelukkig zijn met een degelijk boek. :-)
>
> Een mooie Hemingway in een [voor mij] rottig lettertype pleziert me minder
> dan hetzelfde in een [voor mij] comfortabel lettertype.
Ik had het over een degelijk boek :-)
> > > HTML een onduidelijke standaard?
> >
> > Tot een bepaald punt zij ze het er over eens, maar voorbij dat punt worden er
> > allerlei creatieve dingen aan toegevoegd waar geen overeenstemming over is...
>
> [Ik neem aan dat je doelt op verzinsels als <FRAMES>? Daar is Netscape
> _zelf_ het al niet eens over eens ;-)]
> Waar geen overeenstemming over is is dan ook geen standaard. De HTML
> standaard [de DTD, niet het gebruik in de praktijk] is behoorlijk
> duidelijk.
Als het echt duidelijk zou zijn zou het onmogelijk moeten zijn dat twee
brouwsers de informatie verschillend interpreteren.
> > > Bij HTML is het idee _juist_ dat de browser [aangepast aan hardware
> > > omstandigheden en software instellingen] de lay-out bepaalt. Een
> > > browsermaker mag dus naar eigen inzicht HTML lay-outen. _Daarom_ ziet een
> > > HTML pagina er in iedere situatie ook anders uit.
> > > Het vervelende is alleen dat tot op heden browsermakers de gebruiker daar
> > > erg weinig invloed op laten uitoefenen.
> >
> > Die beperking zit in HTML, niet in de browsers.
>
> Welnee.
> Al in de dagen van HTML 2.0 kon een browsermaker de gebruiker de
> mogelijkheid bieden in te stellen dat bv het begin v.e. nieuwe alinea x
> eenheden moet inspringen, dat de 1e letter van een alinea in lettertype x,
> kleur y, en grootte z moet worden weergegeven en dat als je met de muis op
> die letter klikt er een konijntje uit een hoed te voorschijn springt dat
> direct met grote ijver in de vorm van die letter over je desktop begint te
> keutelen.
> In MacWeb [en ik meen ook in Mosaic] vond je al wat van dat soort opties,
> zij het dat je om dat in te stellen wel weer wat van HTML moest weten.
> Maar da's slechts een kwestie v.e. betere interface voor die instellingen
> maken.
>
De ambiguīteit die inherent is aan HTML is het logische en noodzakelijk
gevolg van het feit dat een aantal keuzes aan de gebruiker wordt overgelaten.
Can't have your cake and eat it too!
> [Web vs traditioneel telefoneren]
> > > Het is zondagavond, 21:00 uur. Het reisbureau is gesloten. Hun Website niet.
> >
> > Dat wordt een avontuur!
>
> Sommigen pakken een tandenborstel en Newton en gaan op pad. Anderen boeken
> hun wintersport vakantie in de lente [en zijn er al 6 jaar eerder voor
> gaan sparen] ;-)
Wat!? Kun je met die Newton je tanden niet poetsen?
> > > > [...] Er zijn zelfs mensen die reizen zonder Newton!:-)
> > >
> > > Daar moeten we dan gauw maar eens een steun-fonds voor oprichten ;-)
> >
> > Ik meld me direkt aan.:-)
>
> Voor het oprichten? ;-)
Een steunfonds voor mezelf oprichten, waarom heb ik daar zelf niet aan gedacht!
Steven
>
> In article <3641D252...@sifre.demon.nl>, Steven
> <ste...@sifre.demon.nl> wrote:
>
> > Sander Tekelenburg wrote:
> > >
> > > In article <363FDF6D...@sifre.demon.nl>, Steven
> > > <ste...@sifre.demon.nl> wrote:
> > >
> > > > Sander Tekelenburg wrote:
>
>
> > > Wat overeind blijft is dat wanneer je via zoiets als PDF 'op het Web
> > > print', je als auteur gewoon niet kunt weten hoe het er op het scherm van
> > > de gebruiker uit zal zien. De auteur weet niet hoe groot dat scherm is,
> > > hoeveel kleuren er op beschikbaar zijn, hoe snel de beeldopbouw is, welke
> > > resolutie mogelijk is. [Zelfde geldt uiteraard voor die gebruiker's
> > > printmogelijkheden, als-ie al een printer heeft.]
> >
> > Al deze bezwaren gelden ook voor HTML en andere formaten.
>
> Ik bedoel dan ook dat dat lay-out probleem niet opgelost is door ipv HTML
> PDF te gebruiken. De enige echte oplossing is papier.
Jawel, Ik weet precies hoe de opmaak van de pagina is, welke letter gebruikt
wordt, in welk formaat. De kwalieit van monitor en printer doet daar niet aan
af. Het is niet zo dat twee printers van goede kwaliteit een PDF zullen
printen met een verschillende opmaak of letter. Hooguit zal de resolutie
tekortschieten of de kleur afwijken, dat is echter en ander probleem. Bij HTML
ligt de plaatsing van elementen op de pagina niet absoluut vast. Of moet ik
zeggen "absoluut niet vast"?
> > Die verschillen in snelheid van beeldopbouw zouden nu dus ook moeten bestaan.
> > Een PDF van één pagina laad net zo snel als een HTML pagina. Het punt met PDF
> > documenten is dat ze uit vele pagina's bestaan.
>
> Dan kun je dat al weer als argument _voor_ HTML gebruiken: De
> user-experience zal op dit punt positiver zijn, want je ervaart het laden
> als sneller.
Voor online reading mischien.
> Overigens doelde ik niet op de snelheid van het laden van een document,
> maar op de snelheid van de beeldopbouw. Die is bij iedere pagina opnieuw
> van toepassing.
>
Ik denk dat dat een kwestie is van de optimalisatie van het PDF bestand. Met
PDF bestanden die niet net zo snel opbouwen als een gemiddelde web pagina is
iets mis.
> > > > Het feit dat ik het lettertype kan veranderen beschouw ik niet als
> > > > interactiviteit.
> > >
> > > Ik wel.
> >
> > Dan is mijn radio ook interactief omdat ik het geluid kan regelen.
>
> [g]
> OK. Dan moeten we maar niet meer spreken van wel of geen interactiviteit,
> maar van de _mate_ van interactiviteit.
Werkelijke interactiviteit is bestaat uit het kunnen ingrijpen in het
'verhaal'.
> > > "Toestemming hebben om interactief te zijn" komt volgens mij aardig in de
> > > buurt van een contradictio in terminus.
> >
> > Toestemming is mischien een vreemd woord in deze. Toch is dit geen
> tegenspraak.
>
> Als je met 'toestemming' zoiets bedoeld als 'de mogelijkheid bieden'
> _klinkt_ het in ieder geval al minder restrictief ;-)
Juist zoiets bedoelde ik.
> > > > > HTML een onduidelijke standaard?
> > > >
> > > > Tot een bepaald punt zij ze het er over eens, maar voorbij dat punt
> worden er
> > > > allerlei creatieve dingen aan toegevoegd waar geen overeenstemming
> over is...
> > >
> > > [Ik neem aan dat je doelt op verzinsels als <FRAMES>? Daar is Netscape
> > > _zelf_ het al niet eens over eens ;-)]
> > > Waar geen overeenstemming over is is dan ook geen standaard. De HTML
> > > standaard [de DTD, niet het gebruik in de praktijk] is behoorlijk
> > > duidelijk.
> >
> > Als het echt duidelijk zou zijn zou het onmogelijk moeten zijn dat twee
> > brouwsers de informatie verschillend interpreteren.
>
> [Ik heb de indruk dat het niet moeilijk is om een slechte browser te maken ;-)]
Ook dat!
> Als je met 'interpreteren' doelt op verschillende manieren om dezelfde
> 'content' weer te geven: Die mogelijkheid is nou juist expres in HTML
> ingebouwd.
Probeer maar eens dezelfde pagina er precies hetzelfde uit te laten zien in
Explorer en Navigator. In veel gevallen lukt je dat niet. Dit illustreert dat
hoewel HTML zich flexibel laat interpreteren het de controle over die
interpretatie niet in handen geeft van de gebruiker.
> _Juist_ omdat je als maker de set-up/instellingen/voorkeuren
> van de gebruiker niet kunt weten. Alleen hierdoor is het mogelijk
> 'content' 100% uitwisselbaar te maken.
Juist, de flexibiliteit van HTML is uit nood geboren.
> Lay-out daarentegen, zal, zolang er
> nog einzelgänger zijn die liever iets anders dan Zinloos 95 op een Compaq
> draaien, nooit 100% uitwisselbaar zijn. Of je moet terug naar papier.
In een PDF bestand ligt de layout vast. Precies zoals de maker het bedoeld
heeft. Daar staan inderdaad een paar kleine nadelen tegenover. Voor HTML geldt
een soortgelijke afweging van eigenschappen. Of moet ik zeggen "eigenaardigheden"?
> > > Sommigen pakken een tandenborstel en Newton en gaan op pad. Anderen boeken
> > > hun wintersport vakantie in de lente [en zijn er al 6 jaar eerder voor
> > > gaan sparen] ;-)
> >
> > Wat!? Kun je met die Newton je tanden niet poetsen?
>
> Kan wel, maar je krijgt dat spuug zo lastig weer van je Newton.
Klinkt alsof je het geprobeerd hebt..:-)
Jeroen Scheerder
> > Ik denk dat dat een kwestie is van de optimalisatie van het PDF bestand.
> > Met PDF bestanden die niet net zo snel opbouwen als een gemiddelde web
> > pagina is iets mis.
>
> Ik heb me nooit verdiept in het maken van PDF. Jij zult dat ongetwijfeld
> beter weten.
Het hangt af van twee zaken: of je `geoptimaliseerde' PDF hebt is de
eerste. Deze optimalisatie wordt (in de laatste paar generaties
PDF-generatoren) standaard uitgevoerd bij het wegschrijven van de files.
De tweede factor is of de web server het zgn. `byte-ranged' uitserveren
van PDF wel ondersteunt. Zo niet, dan moet het _hele_ pdf doc aanwezig
zijn voor je de eerste pagina kunt bekijken; zo ja, dan krijg je steeds
alleen maar netwerkverkeer voor precies dat deel dat je aan het bekijken
bent. Dat is -- met uitzondering van heel kleine documenten --
doorgaans sneller; html kan namelijk _niet_ in het algemeen incrementeel
en modulair geladen worden.
-- J$
--
dash dash space
this is my .sig it's not so .big
Steven
>
> In article <36434791...@sifre.demon.nl>, Steven
> <ste...@sifre.demon.nl> wrote:
>
> > Sander Tekelenburg wrote:
>
> > > Overigens doelde ik niet op de snelheid van het laden van een document,
> > > maar op de snelheid van de beeldopbouw. Die is bij iedere pagina opnieuw
> > > van toepassing.
> > >
> > Ik denk dat dat een kwestie is van de optimalisatie van het PDF bestand. Met
> > PDF bestanden die niet net zo snel opbouwen als een gemiddelde web pagina is
> > iets mis.
>
> beter weten.
Dat is een waarheid als een koe.
> > Probeer maar eens dezelfde pagina er precies hetzelfde uit te laten zien in
> > Explorer en Navigator. In veel gevallen lukt je dat niet.
>
> Maar waarom zou je dat ook in godsnaam willen?
Om te demonstreren dat HTML je volledige controle geeft over de layout van het
document? Of om te onderzoeken in hoeverre je die controle hebt?
> Als een Exploder-gebruiker
> jouw spul wil zien zoals Netschaap [welke van de 100+ versies?] het
> weergeeft dan moet-ie maar Netschaap gebruiken.
>
> [Een Hagenees denkt:"Kom, ik gaat een avondje stappe in Amsterdam". Hij
> stapt in z'n Kadett, maar net voor-ie de snelweg oprijdt komt-ie voor een
> slagboom met een bordje:"Sorry. No go. This road is optimized for the
> Toyota Carina. You can get your Carina _H_E_R_E_"
> Denkt-ie:"Pleur op! In Rotterdam hebben ze ook bier."]
Is Rotterdam wel "kadett compatibel"? Heb je daar geen oude cadilac nodig?
Soms moet je inderdaad een of andere Player gaan ophalen om een muziekje te
horen, terwijl je eigen gitaar binnen handbereik is...
> > Dit illustreert dat
> > hoewel HTML zich flexibel laat interpreteren het de controle over die
> > interpretatie niet in handen geeft van de gebruiker.
>
> Natuurlijk wel. De gebruiker kiest voor de hardware, het OS, en de
> instellingen en kan dus ook zelf kiezen welke browser-ie gebruikt. Het
> enige gebrek aan controle is het gevolg van tekortschietende
> browsermakers. Dat heeft niets te maken met HTML.
Jawel. HTML zou de browser moeten controleren en niet andersom. Inherent aan
HTML is dat het ruimte voor interpretatie open laat. Daarom kunnen browsers
verschillende interpretaties maken.
> > > _Juist_ omdat je als maker de set-up/instellingen/voorkeuren
> > > van de gebruiker niet kunt weten. Alleen hierdoor is het mogelijk
> > > 'content' 100% uitwisselbaar te maken.
> >
> > Juist, de flexibiliteit van HTML is uit nood geboren.
>
> Ja eeh, zo lust ik er nog wel een paar. In die zin is het wiel ook uit
> nood geboren :-)
Is het ook. Het ontstaan van HTML is de geschiedenis van het weglaten
(overlaten aan browser en gebruiker) van functies uit SGML die niet
ondersteund konden worden door de beperkingen van netwerk protocollen
en copyrights.
> > > Lay-out daarentegen, zal, zolang er
> > > nog einzelgänger zijn die liever iets anders dan Zinloos 95 op een Compaq
> > > draaien, nooit 100% uitwisselbaar zijn. Of je moet terug naar papier.
> >
> > In een PDF bestand ligt de layout vast. Precies zoals de maker het bedoeld
> > heeft. Daar staan inderdaad een paar kleine nadelen tegenover.
>
> - Zoals dat de maker niet kan weten hoe de gebruiker dat document het
> liefst ge-lay-out had gezien.
Dat weet de HTML maker ook niet. En het is lang niet altijd mogelijk de
aangeleverde HTML weer te geven zoals _ik_ het ge-layout zou hebben.
> - Zoals dat een PDF-bestand niet door een search engine kan worden
> geindexeerd. Hoogstens op naam [filename.pdf]. Zeker niet op content.
Dat is waar. Acrobat heeft zelf wel een goede search functie overigens.
Jeroen Scheerder
> Om te demonstreren dat HTML je volledige controle geeft over de layout van
> het document? Of om te onderzoeken in hoeverre je die controle hebt?
Dat is een vraagstelling die een diep, diep onbegrip van de materie in
zich herbergt. HTML's reden van bestaan is juist het _abstraheren_ van
de layout; en als je zo'n abstractie (beschrijving van de structuur,
_niet_ van de opmaak) dan gaat zien als een fysieke beschrijving van het
document, tsja... berg je dan maar.
-- J$
--
Here's nice tip for you HTML-editing dweebs: the next two lines should
handle these nasty people using Mozilla or MS Exploder nicely --
insert at the top of each document:
<NOFRAME>
<FONT FACE="dingbats">
That'll teach them.
Steven
>
> Steven <ste...@sifre.demon.nl>:
>
> > Om te demonstreren dat HTML je volledige controle geeft over de layout van
> > het document? Of om te onderzoeken in hoeverre je die controle hebt?
>
> Dat is een vraagstelling die een diep, diep onbegrip van de materie in
> zich herbergt. HTML's reden van bestaan is juist het _abstraheren_ van
> de layout; en als je zo'n abstractie (beschrijving van de structuur,
> _niet_ van de opmaak) dan gaat zien als een fysieke beschrijving van het
> document, tsja... berg je dan maar.
Dat is precies wat ik zeg, mischien op een ongelukkige manier. Mijn stelling
is dat die controle er in veel geringere mate is dan in Sander's overtuiging.
Punt is dat je als lezer de layout niet of slechts in beperkte mate kunt bepalen.
> -- J$
> --
> Here's nice tip for you HTML-editing dweebs: the next two lines should
> handle these nasty people using Mozilla or MS Exploder nicely --
> insert at the top of each document:
>
> <NOFRAME>
> <FONT FACE="dingbats">
>
> That'll teach them.
--
Jeroen Scheerder
> Wat HTML betreft kan de lezer/luisteraar/whatever de lay-out tot in het
> extreme beïnvloeden. Juist omdat HTML zich niet met die lay-out bezig
> houdt.
Precies. HTML is volledig vrij van layout: de hele afbeelding van
structuur (de html) naar presentatie (de layout) zit aan de kant van de
lezer.
De auteur van de HTML daarentegen heeft absoluut geen enkele invloed op
de layout. Tenzij zhij er vanuit gaat dat degene die het lezen gaat
toevallig precies dezelfde versie van hetzelfde programma, op precies
dezelfde wijze ingesteld, en draaiend op precies dezelfde machine,
heeft. Wat juist in flagrante tegenspraak is met hele raison d'être van
HTML, dergelijke beperkingen.
Steven
>
> Sander Tekelenburg <NOS...@nowhere.edu>:
>
> > Wat HTML betreft kan de lezer/luisteraar/whatever de lay-out tot in het
> > houdt.
>
> Precies. HTML is volledig vrij van layout: de hele afbeelding van
> structuur (de html) naar presentatie (de layout) zit aan de kant van de
> lezer.
>
> De auteur van de HTML daarentegen heeft absoluut geen enkele invloed op
> de layout. Tenzij zhij er vanuit gaat dat degene die het lezen gaat
> toevallig precies dezelfde versie van hetzelfde programma, op precies
> dezelfde wijze ingesteld, en draaiend op precies dezelfde machine,
> HTML, dergelijke beperkingen.
>
Ik vaag me af of we het over hetzelfde hebben. Wat versta jij onder "layout"?
Steven
>
> In article <36441A11...@sifre.demon.nl>, Steven> [knip]
>
> > > > Probeer maar eens dezelfde pagina er precies hetzelfde uit te laten
> zien in
> > > > Explorer en Navigator. In veel gevallen lukt je dat niet.
> > >
> > > Maar waarom zou je dat ook in godsnaam willen?
> >
> > document?
>
> mogelijkheid bied. Browsermakers zijn op het moment nog te simplistisch
> bezig. In plaats van de gebruiker die keuzes te geven zitten ze daar zelf
> mee te kleien. Browsermakers houden zich daarmee dus meer bezig met het
> ontwikkelen van goedkope modieuze trends dan met het ontwikkelen van
> degelijk gereedschap.
> Da's erg jammer. Zeker gezien het feit dat er al lang een standaard is
> [CSS] die die browsermakers als uitgangspunt kunnen nemen om user-defined
> Style Sheets te implementeren.
>
> > Of om te onderzoeken in hoeverre je die controle hebt?
>
> Dat browsers daar in de praktijk nog nauwelijks iets van bakken heeft
> niets met HTML te maken.
>
> [knip]
>
> > Soms moet je inderdaad een of andere Player gaan ophalen om een muziekje te
> > horen, terwijl je eigen gitaar binnen handbereik is...
>
> Ten 1e omdat er voor audio in dit verband geen standaard is vastgelegd.
> Ten 2e omdat audio vele malen meer ruimte in beslag neemt. Je zit daardoor
> met de beperkingen van bandbreedte en gemiddelde download snelheid. Als
> auteur moet je dus een aantal afwegingen maken en vervolgens voor een
> bepaalde kwaliteit kiezen. Die keuze heeft al gauw invloed op het formaat.
>
> Overigens heb je het bij audio [even ervan uitgaand dat dat muziek is] al
> gauw over iets dat in de buurt van 'Kunst' komt. Dat betekent dat de
> content onlosmakelijk met de 'lay-out' verbonden is. In zo'n situatie is
> iets als HTML uiteraard geen optie. [Geld natuurlijk even goed voor
> visuele kunst.]
> Enige uitzondering is wanneer het bij de muziek niet om Kunst gaat, maar
> om de content. Dan is er bv MIDI, waarmee je als auteur de 'bare
> essentials' kunt vastleggen, en de 'lay-out' [de karakteristiek en
> kwaliteit van de klank] aan de gebruiker over laat. Voor iemand die wel
> eens serieus met MIDI heeft gewerkt is het dan ook niet zo'n enorme
> gedachtensprong om bij het werken met HTML de 'lay-out urge' te
> overwinnen.
Ik reageerde alleen op jouw enigszins cynische commentaar: "This road is
optimized for the Toyota Carina. You can get your Carina _H_E_R_E_"
Denkt-ie:"Pleur op! In Rotterdam hebben ze ook bier."]
>
> > [...] HTML zou de browser moeten controleren
>
> Dat doet het ook, qua structuur v.e. document. Niet qua lay-out.
En de structuur beperkt de mogelijkheden de layout te wijzigen.
> > en niet andersom.
>
> Het _is_ ook niet andersom. De browser controleert de HTML niet. Alleen de
> auteur controleert de HTML.
>
> > Inherent aan
> > HTML is dat het ruimte voor interpretatie open laat. Daarom kunnen browsers
> > verschillende interpretaties maken.
>
> 'Interpretatie' suggereert dat HTML al iets zegt over de lay-out, en de
> browser daar z'n eigen variant op mag verzinnen. HTML zegt [een enkel
> discutabel element daargelaten] niets over lay-out en laat de browser
> daarin volledig vrij. Er is dus geen sprake van interpretatie.
Ik denk dat we het eens moeten worden over het begrip "layout". Ik denk niet
dat we daar hetzelfde onder verstaan.
>
> [knip]
>
> > [...] Het ontstaan van HTML is de geschiedenis van het weglaten
> > (overlaten aan browser en gebruiker) van functies uit SGML die niet
> > ondersteund konden worden door de beperkingen van netwerk protocollen
> > en copyrights.
>
> hm?
Is dit een vraag? Die netwerk protocollen spelen geloof ik maar een
zijdelinkse rol overigens.
>
> > > > In een PDF bestand ligt de layout vast. Precies zoals de maker het bedoeld
> > > > heeft. Daar staan inderdaad een paar kleine nadelen tegenover.
> > >
> > > - Zoals dat de maker niet kan weten hoe de gebruiker dat document het
> > > liefst ge-lay-out had gezien.
> >
> > Dat weet de HTML maker ook niet.
>
> Precies. En juist daarom gebruikt-ie HTML.
Ja, en? De één heeft een specidfiek beeld in gedachten waarmee hij zijn
boodschap wil communiceren, de ander zal het worst wezen.
> > En het is lang niet altijd mogelijk de
> > aangeleverde HTML weer te geven zoals _ik_ het ge-layout zou hebben.
>
> Omdat je browser zich nog in het stadium van 'lullig speeltje' bevind.
> De 1e auto's waren ook niets meer dan een koets met een motor er opgeknutseld.
Ik krijg een HTML pagina binnen die bestaat uit: Een kop; een inleiding; een
plaatje; broodtekst en een inset. Die wil ik als volgt opmaken:
De inleiding voorop over de volle breedte gezet in 12/18 punts Optima, dan de
kop daaronder in gecenterd in 24 punts Veljovic Extra Bold Italic, daaronder
de brood tekst gezet in twee kolommen, in 10/13 punts Times Roman, met een
regel wit tussen de alinea's en een de eerste regel een pasje ingesprongen en
ten slotte, ingesloten tussen de kolommen (met tekstomploop) de inset en de
afbeelding. Dat dit niet likt ligt aan de browser?
Jeroen Schaap
Steven <steven@sifre*.demon.nl> wrote:
>> > Om te demonstreren dat HTML je volledige controle geeft over de layout van
>> Dat is een vraagstelling die een diep, diep onbegrip van de materie in
>> zich herbergt. HTML's reden van bestaan is juist het _abstraheren_ van
>> de layout; en als je zo'n abstractie (beschrijving van de structuur,
>> _niet_ van de opmaak) dan gaat zien als een fysieke beschrijving van het
>> document, tsja... berg je dan maar.
>Dat is precies wat ik zeg, mischien op een ongelukkige manier. Mijn stelling
>is dat die controle er in veel geringere mate is dan in Sander's overtuiging.
>Punt is dat je als lezer de layout niet of slechts in beperkte mate
>kunt bepalen.
Inderdaad!!! Maar dat is het hele punt niet!!!
Bij HTML gaat het er om INFORMATIE over te brengen, niet om LAYOUT of
een 'smoel' of zoiets. Dat is het hele probleem in deze discussie.
Probeer dat in te zien. HTML is er puur voor de inhoud. Op welke
manier je die inhoud over moet brengen. Hoe je verwijzingen aanbrengt.
Standaardisatie van Meta-info, dat het zoekmachines wat gemakkelijker maakt.
Voor LAYOUT is html echt ongeschikt. Is er gewoon niet voor bedoeld.
Je hebt ook geen layout nodig als je alleen de bedoeling hebt informatie
over te brengen. Simpel.
Jammer genoeg is het voor bedrijven heel belangrijk om een layout over te
dragen, de informatie komt vaak op de tweede plaats. Goed, dat is een
keuze. Het gevolg is wel dat er allerlei onnodige extensies op html zijn
gekomen. De beste poging tot nu toe is CSS. Heb ik ook mee lopen stoeien
op mijn homepage. Jammer genoeg is de implementatie door zowel MSIE en
netschaap slecht. XEmacs doet het al beter. Voordeel van CSS is dat
text-browsers en oudere browsers de CSS gewoon negeren.
Maar echt een perfekte controle over de layout geeft CSS niet. Makkelijk
zat. Daarvoor is PDF inderdaad beter geschikt. Maar tegelijkertijd maak
je de informatie met PDF minder toegankelijk. Vaak moet ik voor
PDF van programma wisselen... dat doe ik alleen maar als ik de info
graag wil hebben. Of als ik een wetenschappelijk artikel wil lezen.
Dat doe ik het meest efficient in de standaard layout, dus wil ik voor
die dingen een PDF bestand hebben.
Conclusie,
PDF vs HTML is een discussie over Layout vs Informatie.
(als je het zwart-wit wil zien......)
Jeroen
--
Jeroen Schaap.............I was dreaming of guitarnotes that would irritate
Homepage: <http://rulffh.medfac.leidenuniv.nl>..| ^|^ |...an executive kind
Keywords: Guitars, Linux, Mac and SCN...........\_`-'_/..............of guy
Tel: (0)71-5276811................................| |...........Frank Zappa
Jeroen Scheerder
> Ik vaag me af of we het over hetzelfde hebben. Wat versta jij onder "layout"?
De fysieke presentatie, in contrast tot de `abstracte' structuur. HTML
is abstracte structuur (`markup language'), die aan de kant van de
interpretator afgebeeld wordt -- op principieel oncontroleerbare en
onbeinvloedbare wijze -- op een fysieke structuur, i.e. je schermlayout.
Of je braille-lezer layout, of je speech synthesizer. Whatever.
Steven
Uit deze enigszins troebele definitie haal ik twee tegenstellingen die volgens
jou de scheidslijn vormen tussen "layout" en "HTML": De tegenstelling
"fysiek/abstract" (juister zou zijn: concreet/abstract) en
"presentatie/struktuur" (is dit eigenlijk een tegenstelling?). Je suggereert
dat de term "markup language" aantoont dat het om een abstracte struktuur
gaat. Dit ontgaat me. Als deze term al ergens naar verwijst is het naar
layout. Je zou het kunnen vertalen als "opmaak taal" of "zet instructie".
Layout zou volgens je definitie concreet (fysiek) zijn, dus onlosmakelijk
verbonden met een fysieke werkelijkheid. Is dit wel zo? Volgens mij niet. De
layout van een document kan heel goed los van dat document zelf en de inhoud
vastgelegd worden. HTML zou abstract zijn. Kan HTML los van de inhoud van het
document bestaan? Nee. Structuur bestaat op verschillende niveaus in een
document, ook op het niveau van de layout. Struktuur op zich is dus geen
gelukkige term om hier een onderscheid te maken. HTML bevat elementen die
direct verwijzen naar de presentatie van de inhoud.
Ik geloof niet dat we hiermee verder komen.
Uit de HTML 4 specificatie: "SGML is a system for defining markup languages.
Authors mark up their documents by representing structural, presentational,
and semantic information alongside content. HTML is one example of a markup language."
Let op de woorden "presentational" en "alongside". "Presentational" geeft aan
dat er niet alleen structuur gedefinieerd wordt maar ook zaken betreffende de
presentatie. "Alongside" geeft aan dat de markup informatie niet abstract is
van de inhoud.
Jeroen Schaap
Wat versta jij onder "layout"?
>> De fysieke presentatie, in contrast tot de `abstracte' structuur. HTML
>> is abstracte structuur (`markup language'), die aan de kant van de
>> interpretator afgebeeld wordt -- op principieel oncontroleerbare en
>> onbeinvloedbare wijze -- op een fysieke structuur, i.e. je schermlayout.
>Uit deze enigszins troebele definitie haal ik twee tegenstellingen die volgens
>jou de scheidslijn vormen tussen "layout" en "HTML": De tegenstelling
>"fysiek/abstract" (juister zou zijn: concreet/abstract) en
>"presentatie/struktuur" (is dit eigenlijk een tegenstelling?). Je suggereert
>dat de term "markup language" aantoont dat het om een abstracte struktuur
>gaat. Dit ontgaat me. Als deze term al ergens naar verwijst is het naar
>layout. Je zou het kunnen vertalen als "opmaak taal" of "zet instructie".
Aha, daar zit het hem in.
Zoals je wel weet is HTML een subset van SGML, en daarmee dus een broertje
van Latex. Dit zijn 'markup' languages. En dat zijn geen 'zet-instructies'.
Nee, het is een methode waarbij je beschrijft WAT je intikt, niet HOE het
er uit ziet!!!
Dus 'markup-language'-> (meta-)beschrijving van de INHOUD.
itt 'printertaal'-> beschrijving van de printercommando's, al dan niet
systeemafhankelijk. PDF is in mijn ogen een printer
taal, met een paar extra dingetjes. (ook wel
'wangedrocht'). Postscript en DVI hebben mijn
voorkeur.
Een beetje goede printertaal is goed genoeg
voor zetinstructies. Dat zijn dus ps en dvi.
>Layout zou volgens je definitie concreet (fysiek) zijn, dus onlosmakelijk
>verbonden met een fysieke werkelijkheid. Is dit wel zo? Volgens mij niet. De
>layout van een document kan heel goed los van dat document zelf en de inhoud
>vastgelegd worden. HTML zou abstract zijn. Kan HTML los van de inhoud van het
>document bestaan? Nee. Structuur bestaat op verschillende niveaus in een
>document, ook op het niveau van de layout. Struktuur op zich is dus geen
>gelukkige term om hier een onderscheid te maken. HTML bevat elementen die
>direct verwijzen naar de presentatie van de inhoud.
Jammer genoeg. Is eigenlijk niet nodig.
>Ik geloof niet dat we hiermee verder komen.
Jawel. Altijd nuttig om te zien hoe anderen met een bepaald systeem omgaan.
>Uit de HTML 4 specificatie: "SGML is a system for defining markup languages.
>Authors mark up their documents by representing structural, presentational,
>and semantic information alongside content.
HTML is one example of a markup language."
Ze zullen wel moeten, nu er CSS bijgekomen is.
Nou ja, dat is te sterk. Ook in latex zitten standaard een heleboel
layout-commando's.
Het belangrijke is dat de layout los staat van de 'markup'. Het is beter als
je de layout kan veranderen zonder aan de inhoud te hoeven knoeien.
Je kan SGML/HTML/Latex zodanig verkrachten dat daar niks meer van over is.
Ik vind dat je HTML zo zou moeten kunnen lezen, zonder een browser. Gewoon
vanaf de broncode. Op mijn pagina's is dat ook grotendeels het geval.
>Let op de woorden "presentational" en "alongside". "Presentational" geeft aan
>dat er niet alleen structuur gedefinieerd wordt maar ook zaken betreffende de
>presentatie. "Alongside" geeft aan dat de markup informatie niet abstract is
>van de inhoud.
Jeroen, die altijd van discussie houdt.....
Steven
>
> >> > Ik vaag me af of we het over hetzelfde hebben.
> Wat versta jij onder "layout"?
>
> >> De fysieke presentatie, in contrast tot de `abstracte' structuur. HTML
> >> is abstracte structuur (`markup language'), die aan de kant van de
> >> interpretator afgebeeld wordt -- op principieel oncontroleerbare en
> >> onbeinvloedbare wijze -- op een fysieke structuur, i.e. je schermlayout.
>
> >Uit deze enigszins troebele definitie haal ik twee tegenstellingen die volgens
> >jou de scheidslijn vormen tussen "layout" en "HTML": De tegenstelling
> >"fysiek/abstract" (juister zou zijn: concreet/abstract) en
> >"presentatie/struktuur" (is dit eigenlijk een tegenstelling?). Je suggereert
> >dat de term "markup language" aantoont dat het om een abstracte struktuur
> >gaat. Dit ontgaat me. Als deze term al ergens naar verwijst is het naar
> >layout. Je zou het kunnen vertalen als "opmaak taal" of "zet instructie".
>
> Aha, daar zit het hem in.
> Zoals je wel weet is HTML een subset van SGML,
Nee, dat wist ik niet, vertelt U eens, professor...
> en daarmee dus een broertje
> van Latex. Dit zijn 'markup' languages. En dat zijn geen 'zet-instructies'.
>
> Nee, het is een methode waarbij je beschrijft WAT je intikt, niet HOE het
> er uit ziet!!!
Daar gaan we weer. Heel wat tags beschrijven wčl het uiterlijk.
> Dus 'markup-language'-> (meta-)beschrijving van de INHOUD.
Een meta-beschrijving van de inhoud? Waar heb je dāt vandaan?
> itt 'printertaal'-> beschrijving van de printercommando's, al dan niet
> systeemafhankelijk. PDF is in mijn ogen een printer
> taal, met een paar extra dingetjes. (ook wel
> 'wangedrocht').
Dat heeft volgens mij meer met jouw definities te maken dan met PDF.
> Postscript en DVI hebben mijn voorkeur.
> Een beetje goede printertaal is goed genoeg
> voor zetinstructies. Dat zijn dus ps en dvi.
>
> >Layout zou volgens je definitie concreet (fysiek) zijn, dus onlosmakelijk
> >verbonden met een fysieke werkelijkheid. Is dit wel zo? Volgens mij niet. De
> >layout van een document kan heel goed los van dat document zelf en de inhoud
> >vastgelegd worden. HTML zou abstract zijn. Kan HTML los van de inhoud van het
> >document bestaan? Nee. Structuur bestaat op verschillende niveaus in een
> >document, ook op het niveau van de layout. Struktuur op zich is dus geen
> >gelukkige term om hier een onderscheid te maken. HTML bevat elementen die
> >direct verwijzen naar de presentatie van de inhoud.
>
> Jammer genoeg. Is eigenlijk niet nodig.
>
> >Ik geloof niet dat we hiermee verder komen.
>
> Jawel. Altijd nuttig om te zien hoe anderen met een bepaald systeem omgaan.
Ik geloof dat ik al genoeg weet.
> >Uit de HTML 4 specificatie: "SGML is a system for defining markup languages.
> >Authors mark up their documents by representing structural, presentational,
> >and semantic information alongside content. HTML is one example of a markup
> >language."
>
> Ze zullen wel moeten, nu er CSS bijgekomen is.
In de teksten die ik er over heb gelezen wordt CSS niet behandeld als een
vanzelfsprekend onderdeel van HTML.
> Nou ja, dat is te sterk. Ook in latex zitten standaard een heleboel
> layout-commando's.
>
> Het belangrijke is dat de layout los staat van de 'markup'. Het is beter als
> je de layout kan veranderen zonder aan de inhoud te hoeven knoeien.
> Je kan SGML/HTML/Latex zodanig verkrachten dat daar niks meer van over is.
Het woord "markup" schijnt een bijzondere betekenis te hebben voor jou. Je
associeert het met "abstacte structuur" en "meta beschrijving" en nu wordt het
weer veelbetekenend tussen aanhalingstekens geplaatst.
> Ik vind dat je HTML zo zou moeten kunnen lezen, zonder een browser. Gewoon
> vanaf de broncode. Op mijn pagina's is dat ook grotendeels het geval.
>
> >Let op de woorden "presentational" en "alongside". "Presentational" geeft aan
> >dat er niet alleen structuur gedefinieerd wordt maar ook zaken betreffende de
> >presentatie. "Alongside" geeft aan dat de markup informatie niet abstract is
> >van de inhoud.
>
> Jeroen, die altijd van discussie houdt...
Ik heb inderdaad geen idee waar je heen wilt.
> --
> Jeroen Schaap.............I was dreaming of guitarnotes that would irritate
> Homepage: <http://rulffh.medfac.leidenuniv.nl>..| ^|^ |...an executive kind
> Keywords: Guitars, Linux, Mac and SCN...........\_`-'_/..............of guy
> Tel: (0)71-5276811................................| |...........Frank Zappa
--
Roeland Pluijmers
Wat is er eigenlijk van OpenDoc geworden?
Heeft iemand daarmee ervaringen? Is toch ook cross-platform?
(En ik dacht afkomstig van Apple.)
Steven
--
ste...@sifre.demon.nl
(remove * if present)
ace
> Wanneer een boodschap werkelijk niet zonder de door de auteur gedachte
> opmaak valt over te brengen kan PDF een [nood-]oplossing zijn. Maar het
> lukt me maar niet een voorbeeldsituatie te verzinnen. Jij?
Jawel: formules en dergelijke. Ik kan maar heel moeilijk (lees: niet)
een formule in HTML opschrijven waarin dingen als symbolen, wortels,
breuken en dergelijke optreden. Wanneer een formeel instituut zhaar
publicaties beschikbaar wil stellen, dan is HTML geen optie, en PDF
zonder meer een uitkomst.
ace
--
=^^=
( )~ _________________________________________ (c) ace <a...@xs4all.nl>
Steven
>
> In article <364657D0...@sifre.demon.nl>, Steven
> <ste...@sifre.demon.nl> wrote:
>
> > Sander Tekelenburg wrote:
> > >
> > > In article <36441A11...@sifre.demon.nl>, Steven
> > > <ste...@sifre.demon.nl> wrote:
>
>
> > > > [...] HTML zou de browser moeten controleren
> > >
> > > Dat doet het ook, qua structuur v.e. document. Niet qua lay-out.
> >
> > En de structuur beperkt de mogelijkheden de layout te wijzigen.
>
De struktuur dicteert de volgorde. Sommige layou ingrepen vragen om een
wijziging van de volgorde.
> [knip]
>
> > Ik denk dat we het eens moeten worden over het begrip "layout". Ik denk niet
> > dat we daar hetzelfde onder verstaan.
>
> Denk ik ook.
> Wat ik er onder versta is eigenlijk hetzelfde als Jeroen Scheerder schreef
> [Message-ID: <1di93z9.1v9mmuyxwqge8N@[192.168.0.2]>].
>
> In de traditionele visuele media is het zo dat in de _praktijk_ de
> structuur deel uitmaakt van de lay-out:
Huh?
> Je bewerkt een kop v.e. artikel net zo lang [lettertype, plaatsing, kleur, etc.]
Lettertype behoort bij de zet instruktie. Niet bij de layout. Het feit dàt het
een kop is behoort bij de struktuur, waar die kop geplaatst wordt hoort bij de
layout, soms wil je de struktuur daarvoor wijzigen, bijvoorbeeld de volgorde.
>totdat
> 1) het er 'goed uit ziet' in de zin van dingen als "spacing, uniformiteit
> binnen het gehele document, etc.".
> 2) je denkt dat het voor de gebruiker duidelijk zal zijn dat het een kop is.
>
> Beide behoren in de traditionele visuele media tot het vakgebied van de
> vormgever. Maar dat wil niet zeggen dat het onderscheid in 2 aspecten,
> zoals ik dat hierboven maak, niet bestaat.
> HTML is de [1e?] implementatie van dit onderscheid.
Ik zeg niet dat zo'n onderscheid niet bestaat. Ik zeg dat dit onderscheid in
de praktijk niet volledig te maken is.
> > > [knip]
> > >
> > > > [...] Het ontstaan van HTML is de geschiedenis van het weglaten
> > > > (overlaten aan browser en gebruiker) van functies uit SGML die niet
> > > > ondersteund konden worden door de beperkingen van netwerk protocollen
> > > > en copyrights.
> > >
> > > hm?
> >
> > Is dit een vraag?
>
> Internet shorthand voor:"verklaar je nader."/"wat bedoel je precies?" ;-)
HTML is een SGML subset.
> [knip]
>
> > [...] De één heeft een specidfiek beeld in gedachten waarmee hij zijn
> > boodschap wil communiceren, de ander zal het worst wezen.
>
> [M'n gebruik van de kreet 'worst wezen' heeft wel indruk op je gemaakt zeg ;-)]
Mensen die iets te zeggen denken te hebben over vormgeving en tegelijkertijd
dergelijke opmerkingen maken over vorm vallen nou eenmaal op. Een valse noot.
Je kent dat wel. Kippevel.:-)
>
> Je kunt pas een goede keuze maken wanneer je weet waar je tussen kiest.
hm?
> Het zwaarst wegende argument is compatibiliteit en toegankelijkheid. Dus HTML.
> Wanneer een boodschap werkelijk niet zonder de door de auteur gedachte
> opmaak valt over te brengen kan PDF een [nood-]oplossing zijn. Maar het
> lukt me maar niet een voorbeeldsituatie te verzinnen. Jij?
Dat komt omdat jij andere eisen stelt aan de kwaliteit denk ik. Ik heb een
kleine honderd documenten in PDF formaat die informatie voor mij op een
aangename manier toegankelijk maakt die ik in HTML vorm met tegenzin zou
raadplegen. Bijvoorbeeld: Van de CSS2 spec is een PDF document. Dat is voor
mij de moeite waard om te bestuderen, van CSS1 spec is voor zover ik kan
nagaan alleen een HTML pagina. Deze zal ik alleen in noodsituaties raadplegen.
In de tussentijd houd ik mijn ogen open voor een andere bron voor deze
informatie.
> Een eventuele uitzondering kan bv zijn de beperking qua mogelijke
> karakters binnen HTML. Een wetenschappelijk document zal niet altijd
> zonder meer met pure HTML publiceerbaar zijn. Je kunt dan evt. voor
> speciale karakters GIFFjes maken, of de boel in bv PDF publiceren.
> [Het lijkt overigens me dat Unicode dit probleem ondervangt, maar daar ben
> ik niet genoeg in thuis. Wellicht iemand anders wel?]
>
> > > > En het is lang niet altijd mogelijk de
> > > > aangeleverde HTML weer te geven zoals _ik_ het ge-layout zou hebben.
> > >
> > > Omdat je browser zich nog in het stadium van 'lullig speeltje' bevind.
> > > De 1e auto's waren ook niets meer dan een koets met een motor er
> opgeknutseld.
> >
> > Ik krijg een HTML pagina binnen die bestaat uit: Een kop; een inleiding; een
> > plaatje; broodtekst en een inset. Die wil ik als volgt opmaken:
> > De inleiding voorop over de volle breedte gezet in 12/18 punts Optima, dan de
> > kop daaronder in gecenterd in 24 punts Veljovic Extra Bold Italic, daaronder
> > de brood tekst gezet in twee kolommen, in 10/13 punts Times Roman, met een
> > regel wit tussen de alinea's en een de eerste regel een pasje ingesprongen en
> > ten slotte, ingesloten tussen de kolommen (met tekstomploop) de inset en de
> > afbeelding. Dat dit niet lukt ligt aan de browser?
>
> Ja.
Dus de gebruiker kan ook de structuur van het document naar eigen inzicht
wijzigen. Dat is nieuw voor mij.
Steven
>
> In article <36479659...@sifre.demon.nl>, Steven
> <ste...@sifre.demon.nl> wrote:
>
> [knip]
>
> > [...] HTML bevat elementen die
> > direct verwijzen naar de presentatie van de inhoud.
>
> zoals <I> en <HR>. HTML 3.2 bevat inderdaad enkele discutabele elementen.
> HTML 4.0 alweer minder.
> Die discutabele elementen zijn alweer het gevolg van de kortzichtigheid
> van browsermakers [die ook zitting hebben in het W3C]. HTML 3.2 was dan
> ook meer een indexering van de op dat moment in zwang zijnde elementen dan
> dat het een weldoordachte standaard is. Toegegeven, HTML 3.2 verkreeg de
> status van standaard, maar het feit dat in HTML 4.0 op dit gebied weer gas
> is teruggenomen en nu bovendien zeer concreet wordt verwezen naar CSS voor
> lay-out zegt IMHO genoeg.
Toekomstmuziek, die overigens volgens mij heel wat monotoner zal klinken dan
nu voorgesteld wordt.
>
> [knip]
>
> > Uit de HTML 4 specificatie: "SGML is a system for defining markup languages.
> > Authors mark up their documents by representing structural, presentational,
> > and semantic information alongside content. HTML is one example of a
> markup language."
> >
> > Let op de woorden "presentational" en "alongside". "Presentational" geeft aan
> > dat er niet alleen structuur gedefinieerd wordt maar ook zaken betreffende de
> > presentatie.
>
> 'Presentational' is niet synoniem aan 'lay-out'.
Dat zeg ik niet. Ik bestrijd alleen dat HTML _alleen_ de structuur vastlegt.
Zelfs al zou de gebruikte HTML helemaal 'puur' zijn en louter structuur
vastleggen, dan nòg is door de rigide structuur de mogelijkheid de layout te
wijzigen beperkt.
> Bij 'presentation of content' kun je ook denken aan de keuze van de auteur
> - of een volgend gedeelte een nieuwe alinea is, of een nieuw hoofdstuk
> - of iets wel of niet een <LIST> is
> - of informatie wel of niet tabulair dient weergegeven te worden.
Dit is de structuur van een document. Presentatie bepaalt hoe de tabel er uit
ziet, waar die geplaatst wordt, hoe de tekst lijnt, hoe de kop er uit ziet etc.
> Met wat voor lettertype, spacing, kleur, etc. je vervolgens die nieuwe
> alinea/dat nieuwe hoofdstuk/die lijst/die tabel als zodanig herkenbaar
> maakt en vorm geeft is een andere zaak.
Dat dacht ik niet. Heeft die "andere zaak" ook een naam in jouw leerboek?
> IMHO is _dit_ het soort 'presentatie' waar je citaat op doelt.
Steven
> > >
> > > >Ik geloof niet dat we hiermee verder komen.
> > >
> > > Jawel. Altijd nuttig om te zien hoe anderen met een bepaald systeem omgaan.
> >
> > Ik geloof dat ik al genoeg weet.
> >
> > > > Uit de HTML 4 specificatie: "SGML is a system for defining markup
> > > > languages. Authors mark up their documents by representing structural,
> > > > presentational, and semantic information alongside content. HTML is one
> > > > example of a markup language."
> > >
> > > Ze zullen wel moeten, nu er CSS bijgekomen is.
> >
> > In de teksten die ik er over heb gelezen wordt CSS niet behandeld als een
> > vanzelfsprekend onderdeel van HTML.
>
> - De term 'CSS' komt 97 keer voor. De term 'style sheet' 189 keer.
> - Hoofdstuk 15 is geheel en al gewijd aan CSS en begint met:
Wat bewijst dat nou? In de handleiding van Photoshop komt het woord
Illustrator 80 keer voor. Betekent dat dat Illustrator een onderdeel is van Photoshop?
> <begin citaat>
> Style sheets represent a major breakthrough in how Web page designers
> work, by expanding their
> ability to improve the appearance of their pages. In the scientific
> environments in which the Web
> was conceived, people are more concerned with the content of their
> documents than the
> presentation. As people from wider walks of life discovered the Web, the
> limitations of HTML
> became a source of continuing frustration. These authors were used to
> paper media where they
> had full control. They learned how to sidestep HTML's stylistic
> limitations. While the intentions have
> been good - to improve the presentation of Web pages - the techniques for
> doing so have had
> unfortunate side effects. These techniques work for some of the people,
> some of the time, but
> never for all of the people, all of the time, They include:
>
> Using proprietary HTML extensions
> Converting text into images
> Using images for white space control
> Use of tables for page layout
> Writing a program instead of using HTML
>
> These techniques considerably increase the complexity of Web pages, have
> limited flexibility as well
> as suffering from interoperability problems, and creating hardships for
> people with disabilities.
>
> Style sheets bring back the ease of control over presentation, and
> supersede the limited range of
> presentation mechanisms added to HTML over the last few years. Style
> sheets make it easy to
> specify the amount of white space between text lines, the amount lines are
> indented, the colors
> used for the text and the backgrounds, the font size and style, and a host
> of other details.
> <einde citaat>
>
> - Vele elementen uit vorige HTML definities worden in HTML 4.0 sterk
> afgeraden met de opmarking dat CSS de voorkeur heeft.
> Bijvoorbeeld:
>
> uit de HTML 4.0 definitie:
>
> <begin citaat>
> 16.1.1
>
> [...] bgcolor = color
> Deprecated[*].This attribute sets the background color for the
> document body or table cells.
>
> This attribute sets the background color of the canvas for the document
> body (the BODY element)
> or for tables (the TABLE, TR, TH, and TD elements). Additional attributes
> for specifying text color can
> be used with the BODY element.
>
> This attribute has been deprecated in favor of style sheets for specifying
> background color
> information.
> <einde citaat>
>
> [*] 'to deprecate' is zoiets als 'ernstig afkeuren'.
Bewijst dit dat CSS een onderdeel is van HTML? Volgens mij niet.
> > > Nou ja, dat is te sterk. Ook in latex zitten standaard een heleboel
> > > layout-commando's.
> > >
> > > Het belangrijke is dat de layout los staat van de 'markup'. Het is beter als
> > > je de layout kan veranderen zonder aan de inhoud te hoeven knoeien.
> > > Je kan SGML/HTML/Latex zodanig verkrachten dat daar niks meer van over is.
> >
> > Het woord "markup" schijnt een bijzondere betekenis te hebben voor jou. Je
> > associeert het met "abstacte structuur" en "meta beschrijving" en nu wordt het
> > weer veelbetekenend tussen aanhalingstekens geplaatst.
> >
> > > Ik vind dat je HTML zo zou moeten kunnen lezen, zonder een browser. Gewoon
> > > vanaf de broncode. Op mijn pagina's is dat ook grotendeels het geval.
> > >
> > > >Let op de woorden "presentational" en "alongside". "Presentational"
> > > >geeft aan dat er niet alleen structuur gedefinieerd wordt maar ook zaken
> > > >betreffende de presentatie. "Alongside" geeft aan dat de markup informatie
> > > >niet abstract is van de inhoud.
> > >
> > > Jeroen, die altijd van discussie houdt...
> >
> > Ik heb inderdaad geen idee waar je heen wilt.
> >
--
ace
[ formules ]
> Deze ene uitzondering noemde ik dan ook al in de direct hierop volgende
> zin [misschien had ik 'm niet duidelijk genoeg ge-lay-out? ;-)].
> Dit heeft echter niets met 'fysieke structuur' vs 'opmaak' te maken, maar
> met de beperkte character sets die momenteel in gebruik zijn.
Dat, ja, maar toch ССk met dingen als bereik, en positie. Een
wortelteken dat over een breuk heenstaat, bijvoorbeeld, dat vraagt toch
echt van het programma dat op je scherm danwel je papier tekent dat het
wat weet van fysieke afstanden en posities. Dingen als:
___________________3
- | a_3^2 * b_n^2 - c
\| d_1
...ofzo. In LaTeX is dat een makkie, en om daar PDF van te maken is
slechts een kwestie van de goeie outputbestemming kiezen, maar in HTML
krijg ik dat niet voor elkaar.
Maarten van Steenbergen
>Sander Tekelenburg <NOS...@nowhere.edu>:
>
>> Wanneer een boodschap werkelijk niet zonder de door de auteur gedachte
>> opmaak valt over te brengen kan PDF een [nood-]oplossing zijn. Maar het
>> lukt me maar niet een voorbeeldsituatie te verzinnen. Jij?
>
>een formule in HTML opschrijven waarin dingen als symbolen, wortels,
>breuken en dergelijke optreden. Wanneer een formeel instituut zhaar
>publicaties beschikbaar wil stellen, dan is HTML geen optie, en PDF
>zonder meer een uitkomst.
Dat soort dingen moet je ook niet direct in HTML gaan opschrijven. Er staan
veel technische/wiskundige/natuurkundige zaken op het WWW die gewoon met
latex2html zijn gemaakt. Op die manier kost het helemaal geen extra moeite, en
het ziet er toch redelijk uit. (Al komt dat pas echt goed met MathML van
www.w3c.org).
Maarten
--
Maarten van Steenbergen <stee...@phys.uu.nl>
-----=====* http://www.phys.uu.nl/~steenbrg/ *=====-----
(o.a. Linux cd's voor een tientje te vinden op deze pagina)
Jeroen Schaap
Jeroen Schaap <jer...@rulffh.medfac.leidenuniv.nl> wrote:
>??? Met het verkeerde been uit bed gestapt sander?
Ik bedoelde dus Steven, maar dat was al duidelijk....
Jeroen
Jeroen Schaap
Steven <steven@sifre*.demon.nl> wrote:
>> Zoals je wel weet is HTML een subset van SGML,
>Nee, dat wist ik niet, vertelt U eens, professor...
Hoho... mijn excuses hier. Zo wou ik niet overkomen....
Ik bedoelde alleen te zeggen dat HTML een vorm van SGML is..
>> en daarmee dus een broertje
>> van Latex. Dit zijn 'markup' languages. En dat zijn geen 'zet-instructies'.
>> Nee, het is een methode waarbij je beschrijft WAT je intikt, niet HOE het
>> er uit ziet!!!
>Daar gaan we weer. Heel wat tags beschrijven wčl het uiterlijk.
Dat doen ze ook inderdaad. Maar dat is (hoort) eigenlijk alleen voor
fine-tuning bedoeld. De beschrijving van de inhoud is belangrijkste functie
van die talen. Op grond van de beschrijving en een kit van voorkeuren wordt
een pagina opgemaakt.
>> Dus 'markup-language'-> (meta-)beschrijving van de INHOUD.
>Een meta-beschrijving van de inhoud? Waar heb je dāt vandaan?
Is inderdaad dubbelop hier. Het was meer voor de duidelijkheid bedoeld. ;)
Laat dat meta maar weg.
>> itt 'printertaal'-> beschrijving van de printercommando's, al dan niet
>> systeemafhankelijk. PDF is in mijn ogen een printer
>> taal, met een paar extra dingetjes. (ook wel
>> 'wangedrocht').
>Dat heeft volgens mij meer met jouw definities te maken dan met PDF.
Kom op, niet zo snel...
Ik heb al eerder gezegd dat ik PDF voor sommige dingen het beste vind.
Bevoorbeeld die inhoudsbalk aan de linkerkant is soms superhandig.
>> Jawel. Altijd nuttig om te zien hoe anderen met een bepaald systeem omgaan.
>Ik geloof dat ik al genoeg weet.
??? Met het verkeerde been uit bed gestapt sander?
Ik bedoelde het positief: ik sta altijd open voor andere meningen. Ik vind
het dus echt NUTTIG.
>> Ze zullen wel moeten, nu er CSS bijgekomen is.
>
>In de teksten die ik er over heb gelezen wordt CSS niet behandeld als een
>vanzelfsprekend onderdeel van HTML.
Inderdaad, het is er uit noodzaak bijgekomen. Het is meer een
standaardisatie van die stomme netscape-tags...
>> Nou ja, dat is te sterk. Ook in latex zitten standaard een heleboel
>> layout-commando's.
>>
>> Het belangrijke is dat de layout los staat van de 'markup'. Het is beter als
>> je de layout kan veranderen zonder aan de inhoud te hoeven knoeien.
>> Je kan SGML/HTML/Latex zodanig verkrachten dat daar niks meer van over is.
>
>Het woord "markup" schijnt een bijzondere betekenis te hebben voor jou. Je
>associeert het met "abstacte structuur" en "meta beschrijving" en nu wordt het
>weer veelbetekenend tussen aanhalingstekens geplaatst.
Het loopt inderdaad in elkaar over. Maar in zo'n discussie is het gemakkelijk
om het als twee uitersten te beschouwen.
>> Ik vind dat je HTML zo zou moeten kunnen lezen, zonder een browser. Gewoon
>> vanaf de broncode. Op mijn pagina's is dat ook grotendeels het geval.
>> Jeroen, die altijd van discussie houdt...
>Ik heb inderdaad geen idee waar je heen wilt.
Gewoon een siesta houden, in je ogen wrijven en het nog een keer lezen.
En met een pot bier in de hand, als je daar vrolijk van wordt...
Jeroen
Steven
>
> In article <3648315E...@sifre.demon.nl>,
> Steven <steven@sifre*.demon.nl> wrote:
> >Nee, dat wist ik niet, vertelt U eens, professor...
>
>
> Ik bedoelde alleen te zeggen dat HTML een vorm van SGML is..
Dat had ik al eerder gemeld.
> >> en daarmee dus een broertje
> >> van Latex. Dit zijn 'markup' languages. En dat zijn geen 'zet-instructies'.
> >> Nee, het is een methode waarbij je beschrijft WAT je intikt, niet HOE het
> >> er uit ziet!!!
> >Daar gaan we weer. Heel wat tags beschrijven wèl het uiterlijk.
>
> Dat doen ze ook inderdaad. Maar dat is (hoort) eigenlijk alleen voor
> fine-tuning bedoeld. De beschrijving van de inhoud is belangrijkste functie
> van die talen. Op grond van de beschrijving en een kit van voorkeuren wordt
> een pagina opgemaakt.
>
> >> Dus 'markup-language'-> (meta-)beschrijving van de INHOUD.
> >Een meta-beschrijving van de inhoud? Waar heb je dàt vandaan?
>
> Is inderdaad dubbelop hier. Het was meer voor de duidelijkheid bedoeld. ;)
> Laat dat meta maar weg.
Dan houden we over "beschrijving van de inhoud", eh.. wat waren we ook al weer
aan het zeggen?
> >> itt 'printertaal'-> beschrijving van de printercommando's, al dan niet
> >> systeemafhankelijk. PDF is in mijn ogen een printer
> >> taal, met een paar extra dingetjes. (ook wel
> >> 'wangedrocht').
PDF is gebaseerd op PostScript level 2.
> >Dat heeft volgens mij meer met jouw definities te maken dan met PDF.
>
> Kom op, niet zo snel...
> Ik heb al eerder gezegd dat ik PDF voor sommige dingen het beste vind.
> Bevoorbeeld die inhoudsbalk aan de linkerkant is soms superhandig.
Ik dacht dat je het een "wangedrocht" vond?
> >> Jawel. Altijd nuttig om te zien hoe anderen met een bepaald systeem omgaan.
> >Ik geloof dat ik al genoeg weet.
> ??? Met het verkeerde been uit bed gestapt sander?
Mijn naam is Steven. Niet goed uitgeslapen? Een "pot" bier te veel gedronken gisteravond?
> Ik bedoelde het positief: ik sta altijd open voor andere meningen. Ik vind
> het dus echt NUTTIG.
Dat hangt er maar net van af of er zinnige dingen gezegd worden.
> >> Ze zullen wel moeten, nu er CSS bijgekomen is.
> >
> >In de teksten die ik er over heb gelezen wordt CSS niet behandeld als een
> >vanzelfsprekend onderdeel van HTML.
>
> Inderdaad, het is er uit noodzaak bijgekomen. Het is meer een
> standaardisatie van die stomme netscape-tags...
Het is een aparte specificatie. Geen onderdeel van HTML 4.
> >> Nou ja, dat is te sterk. Ook in latex zitten standaard een heleboel
> >> layout-commando's.
> >>
> >> Het belangrijke is dat de layout los staat van de 'markup'. Het is beter als
> >> je de layout kan veranderen zonder aan de inhoud te hoeven knoeien.
> >> Je kan SGML/HTML/Latex zodanig verkrachten dat daar niks meer van over is.
> >
> >Het woord "markup" schijnt een bijzondere betekenis te hebben voor jou. Je
> >associeert het met "abstacte structuur" en "meta beschrijving" en nu wordt het
> >weer veelbetekenend tussen aanhalingstekens geplaatst.
>
> Het loopt inderdaad in elkaar over. Maar in zo'n discussie is het gemakkelijk
> om het als twee uitersten te beschouwen.
Zoals ik al eerder betoogde kan bij beide omschrijvingen een groot vraagteken
geplaatst worden. Nou gaan ze ook nog in elkaar overlopen! Help!!
> >> Ik vind dat je HTML zo zou moeten kunnen lezen, zonder een browser. Gewoon
> >> vanaf de broncode. Op mijn pagina's is dat ook grotendeels het geval.
>
> >> Jeroen, die altijd van discussie houdt...
>
> >Ik heb inderdaad geen idee waar je heen wilt.
>
> Gewoon een siesta houden, in je ogen wrijven en het nog een keer lezen.
> En met een pot bier in de hand, als je daar vrolijk van wordt...
Ik ben goed wakker en met bier doe je mij geen plezier.
> Jeroen
Jeroen Scheerder
> [..] maar in HTML krijg ik dat niet voor elkaar.
<PRE>
___________________3
_7| a_3^2 * b_n^2 - c
\| d_1
</PRE>
...maar je hebt wel gelijk, natuurlijk. Er is heel wat te vinden dat je
in typesetting tools anno dertig jaar geleden prima kunt genereren --
precies het soort dingen dat je wilt kunnen ebliceren, doorgaans -- maar
waarvan HTML zowel de directe expressiviteit als de uitbreidbaarheid
ontbeert om een adequate beschrijving te kunnen geven.
Laat staan dat je enige adequate _replicatie_ kunt bewerkstelligen.
Soms wil je dat, en dan is HTML sowieso al geen optie. Formules of niet
-- al maken die de misvatting wel aperter.
Jeroen Schaap
>Ik dacht dat je het een "wangedrocht" vond?
Ja. Maar wel een bruikbaar/ soms zelfs praktisch wangedrocht.
Dat neemt niet weg dat het vis noch vlees is. Het is een 'presentatie'-
protocol, maar geen printertaal noch een SGML.
De viewers zijn vaak buggy, en veel van de documenten kloppen vaak niet.
Bijvoorbeeld: voor het printen met de laserwriter onder MacOS werkt AR2.0
het beste, maar die geeft op het scherm weer minder mooi dan AR3.0. Helaas
geeft de laatste consequent postscript fouten als ik probeer te printen.
>Zoals ik al eerder betoogde kan bij beide omschrijvingen een groot vraagteken
>geplaatst worden. Nou gaan ze ook nog in elkaar overlopen! Help!!
Kom, er is wel degelijk onderscheid te maken tussen formaten die alleen
opmaak-commando's hebben, zoals wordperfect (niet word, want daar kan je wel
degelijk 'markeer'-opdrachten mee geven) en formaten die voornamelijk met
markeer-commando's werken, zoals latex (en HTML ;).
Jeroen
Maarten van Steenbergen
> ___________________3
> - | a_3^2 * b_n^2 - c
> \| d_1
>
>...ofzo. In LaTeX is dat een makkie, en om daar PDF van te maken is
>krijg ik dat niet voor elkaar.
Met latex2html is een html bestand maken net zo makkelijk als een PDF, DVI of
PS maken. Van formules worden vaak gifjes gemaakt. Het ziet er prima uit, en
ook dingen als hyperlinks worden automatisch geregeld.
groeten
Steven
>
> In article <3648E600...@sifre.demon.nl>, Steven> [knip]
>
> > > > In de teksten die ik er over heb gelezen wordt CSS niet behandeld als een
> > > > vanzelfsprekend onderdeel van HTML.
> > >
> > > - De term 'CSS' komt 97 keer voor. De term 'style sheet' 189 keer.
> > > - Hoofdstuk 15 is geheel en al gewijd aan CSS en begint met:
> >
> > Wat bewijst dat nou? In de handleiding van Photoshop komt het woord
> > Illustrator 80 keer voor. Betekent dat dat Illustrator een onderdeel is
> van Photoshop?
>
>
> > Bewijst dit dat CSS een onderdeel is van HTML? Volgens mij niet.
>
> [in de HTML 4.0 definitie] naar CSS waar het de weergave van in HTML
> bepaalde structuur betreft.
> Met al die verwijzingen is CSS dus een vanzelfsprekend gereedschap naast HTML.
OK. Jij gebruikt de term HTML dus losjes en bedoeld er
HTML/DHTML/CSS/XML/JAVASCRIPT/etc. mee.
> CSS is dus inderdaad geen <tag> in HTML.
>
> Ik dacht dat we een inhoudelijke discussie voerden over in hoeverre HTML
> de browser/gebruiker vrij laat een document weer te geven.
Vallen definities van termen die we gebruiken en verduidelijking van _hoe_ we
die definities gebruiken niet onder "inhoudelijke discussie"?
> Als je wilt winnen' door te gaan miereneuken is dat je goed recht.
Is er wat te winnen? Dat wist ik niet.
> Dan heb je mij verder ook niet meer nodig.
Nodig? Je verspreidt informatie die naar mijn oordeel niet helemaal juist is.
Steven
>
> In article <3648E46C...@sifre.demon.nl>, Steven
> <ste...@sifre.demon.nl> wrote:
>
> > Sander Tekelenburg wrote:
> > >
> > > In article <364657D0...@sifre.demon.nl>, Steven
> > > <ste...@sifre.demon.nl> wrote:
>
>
> > De struktuur dicteert de volgorde. Sommige layou ingrepen vragen om een
> > wijziging van de volgorde.
>
> middenin de tekst zou mogen weergeven. Alleen dat <Hn> als zodanig
> herkenbaar moet zijn.
Het zegt óók niet dat de client dat wèl kan. HTML is niet object georienteerd
maar procedureel. Daardoor ligt de volgorde vast.
> Dat de middelen om zo'n weergave in de praktijk te brengen momenteel niet
> beschikbaar zijn is een 2e.
Geef eens een voorbeeld dan van HTML/CSS code die de gebruiker de mogelijkheid
geeft de volgorde van elementen van een document te wijzigen?
> Je zult voor zoiets een _veel_ beter configureerbare browser [wellicht dmv
> iets als CSS] nodig hebben.
Laat eerst maar eens zien hoe die code er uit ziet in plaats van je
achter de browser implementatie te verschuilen.
> Je zult ook voor een aantal HTML elementen
> nieuwe attributes moeten vastleggen, opdat je de header en de daarbij
> behorende tekst aan elkaar kunt koppelen.
> Maar het _wezen_ van HTML/CSS staat zoiets niet in de weg IMHO.
Het _wezen_ van HTML? Je bedoelt dast het met HTML 4.0 niet mogelijk is.
> [knip] (het is net of ik bij de kapper zit)
>
> > > In de traditionele visuele media is het zo dat in de _praktijk_ de
> > > structuur deel uitmaakt van de lay-out:
> >
> > Huh?
>
> Die praktische scheiding 'HTML+auteur bepalen structuur' vs
> 'browser+gebruiker bepalen weergave', bestaat niet in de traditionele
> visuele media, waar de auteur het _geheel_ in handen heeft. Dan nòg zijn
> ook voor die auteur
> 1)structuur, en
> 2)weergave daarvan
> twee verschillende dingen.
Precies. En omdat hij beide kan wijzigen heeft hij qua layout alle
mogelijkheden.
De HTML auteur heeft beperktere mogelijkheden omdat hij rekening moet houden
met een breed scala aan configuraties aan de client zijde. De lezer ten slotte
heeft
ook beperktere mogelijkheden omdat hij de in HTML vastliggende structuur niet
kan wijzigen.
> > > Je bewerkt een kop v.e. artikel net zo lang [lettertype, plaatsing,
> > > kleur, etc.]
> >
> > Lettertype behoort bij de zet instruktie. Niet bij de layout. Het feit dàt het
> > een kop is behoort bij de struktuur, waar die kop geplaatst wordt hoort bij de
> > layout, soms wil je de struktuur daarvoor wijzigen, bijvoorbeeld de volgorde.
>
> Je bedoelt de situatie dat de auteur bv de kop 'midden in het artikel', of
> er onder wil hebben? [je laat me wel raden zeg...]
Goed geraden. 10 punten!
> Ik zie niet in waarom HTML de gebruiker in die mogelijkheid zou beperken.
Toch is het zo.
> > > > [...] De één heeft een specifiek beeld in gedachten waarmee hij zijn
> > > > boodschap wil communiceren, de ander zal het worst wezen.
> > >
> > > [M'n gebruik van de kreet 'worst wezen' heeft wel indruk op je gemaakt
> zeg ;-)]
> >
> > Mensen die iets te zeggen denken te hebben over vormgeving en tegelijkertijd
> > dergelijke opmerkingen maken over vorm vallen nou eenmaal op. Een valse noot.
> > Je kent dat wel. Kippevel.:-)
>
> Ik gebruikte die term als _gebruiker_. Als auteur bedien je de gebruiker.
> Het zou je als auteur dus geen worst mogen zijn dat het de gebruiker worst
> is hoe je iets had willen vormgeven.
Dus als muzikant hecht je groot belang aan de zeggenskracht van je muziek,
maar als luisteraar zal het je worst wezen? Verbazingwekkend! Ik ken maar
weinig muzikanten die zo denken.
> > > Je kunt pas een goede keuze maken wanneer je weet waar je tussen kiest.
> >
> > hm?
>
> De naderverklaring stond er volgens mij toch direct onder.
Nu zie ik wat je bedoelt.
> > > Het zwaarst wegende argument is compatibiliteit en toegankelijkheid.
> > > Dus HTML.
> > > Wanneer een boodschap werkelijk niet zonder de door de auteur gedachte
> > > opmaak valt over te brengen kan PDF een [nood-]oplossing zijn. Maar het
> > > lukt me maar niet een voorbeeldsituatie te verzinnen. Jij?
> >
> > Dat komt omdat jij andere eisen stelt aan de kwaliteit denk ik. Ik heb een
> > kleine honderd documenten in PDF formaat die informatie voor mij op een
> > aangename manier toegankelijk maakt die ik in HTML vorm met tegenzin zou
> > raadplegen.
>
> Prima.
> Maar ik dacht dat we het over publiceren hadden. Dan heb je met meer
> mensen dan alleen jezelf te maken.
Hoe is dit te rijmen met je opmerking: "Hoe het er uit ziet zal me worst wezen
[als lezer]". Gaan we met twee maten meten?
> [knip]
>
> > > > Ik krijg een HTML pagina binnen die bestaat uit: Een kop; een
> > > > inleiding; een plaatje; broodtekst en een inset. Die wil ik als
> > > > volgt opmaken: De inleiding voorop over de volle breedte gezet in
> > > > 12/18 punts Optima, dan de kop daaronder in gecenterd in 24 punts
> > > > Veljovic Extra Bold Italic, daaronder de brood tekst gezet in twee
> > > > kolommen, in 10/13 punts Times Roman, met een regel wit tussen
> > > > de alinea's en een de eerste regel een pasje ingesprongen en
> > > > ten slotte, ingesloten tussen de kolommen (met tekstomploop) de
> > > > inset en de afbeelding. Dat dit niet lukt ligt aan de browser?
> > > Ja.
> >
> > Dus de gebruiker kan ook de structuur van het document naar eigen inzicht
> > wijzigen. Dat is nieuw voor mij.
>
> Dit is geen wijzigen van structuur. Het is definieren hoe die structuur
> dient te worden weergegeven.
Over mierenneuken gesproken...
Dus de gebruiker kan de wijze waarop de impliciete en expliciete structuur,
vastgelegd in HTML, wordt weergegeven naar eigen believen wijzigen? Elementen
kunnen dus in een andere volgorde worden weergegeven dan die die impliciet
gegeven is in de code?
Steven
>
> [over PDF...]
>
> >Ik dacht dat je het een "wangedrocht" vond?
>
> Ja. Maar wel een bruikbaar/ soms zelfs praktisch wangedrocht.
> Dat neemt niet weg dat het vis noch vlees is. Het is een 'presentatie'-
> protocol, maar geen printertaal noch een SGML.
Je blijft jezelf tegenspreken. Eerst zei je dat PDF een printertaal is, nu is
het weer _geen_ printertaal.
Citaat: "PDF is in mijn ogen een printer taal, met een paar extra dingetjes.
(ook wel 'wangedrocht')."
> De viewers zijn vaak buggy, en veel van de documenten kloppen vaak niet.
Ik maak behoorlijk vaak gebruik van PDF, ik heb geen idee waar je het hier
over hebt.
> Bijvoorbeeld: voor het printen met de laserwriter onder MacOS werkt AR2.0
> het beste, maar die geeft op het scherm weer minder mooi dan AR3.0. Helaas
> geeft de laatste consequent postscript fouten als ik probeer te printen.
Ik heb deze problemen niet. Hoe kan dat nou? AR 2? Is die uit de middeleeuwen?
> >Zoals ik al eerder betoogde kan bij beide omschrijvingen een groot vraagteken
> >geplaatst worden. Nou gaan ze ook nog in elkaar overlopen! Help!!
>
> Kom, er is wel degelijk onderscheid te maken tussen formaten die alleen
> opmaak-commando's hebben, zoals wordperfect (niet word, want daar kan je wel
> degelijk 'markeer'-opdrachten mee geven) en formaten die voornamelijk met
> markeer-commando's werken, zoals latex (en HTML ;).
Ik had het niet over verschillende formaten, maar over verschillende
"definities" van HTML die jij naar voren bracht. Als ik je vraag naar
deze onduidelijkheid zeg je "Het loopt inderdaad in elkaar over". Kan het nog
wat onduidelijker?
> Jeroen
Steven
>
> In article <3648E5A1...@sifre.demon.nl>, Steven> > > In article <36479659...@sifre.demon.nl>, Steven
> > > <ste...@sifre.demon.nl> wrote:
>
> [knip]
>
> > > > languages. Authors mark up their documents by representing structural,
> > > > presentational, and semantic information alongside content. HTML is one
> > > > example of a markup language."
> > > >
> > > > geeft aan dat er niet alleen structuur gedefinieerd wordt maar ook
> > > > zaken betreffende de presentatie.
> > > >
Klopt. Niet synoniem omdat de "presentational information" in HTML/CSS te
beperkt is om het hele terrein van de layout te bestrijken.
> [knip]
>
> > > Bij 'presentation of content' kun je ook denken aan de keuze van de auteur
> > > - of een volgend gedeelte een nieuwe alinea is, of een nieuw hoofdstuk
> > > - of iets wel of niet een <LIST> is
> > > - of informatie wel of niet tabulair dient weergegeven te worden.
> >
> > Dit is de structuur van een document.
>
> Inderdaad.
> "Presenteer ik mijn ideeën in de vorm van een roman, een toneelstuk, of
> een politieke toespraak?" is een afweging die gaat over structuur.
>
> > Presentatie bepaalt hoe de tabel er uit
> > ziet, waar die geplaatst wordt, hoe de tekst lijnt, hoe de kop er uit
> > ziet etc.
>
> Nee. Ik beweer nou juist dat die term 'presentation' uit dat citaat IMHO
> niet zo geïnterpreteerd dient te worden.
Dus "structural" = "presentational" en W3C gebruikt de termen dubbelop om de
opsomming wat aan te dikken?
> > > Met wat voor lettertype, spacing, kleur, etc. je vervolgens die nieuwe
> > > alinea/dat nieuwe hoofdstuk/die lijst/die tabel als zodanig herkenbaar
> > > maakt en vorm geeft is een andere zaak.
> >
> > Dat dacht ik niet. Heeft die "andere zaak" ook een naam in jouw leerboek?
>
> Zoiets als 'weergave van structuur'.
Onzin.
Jeroen Schaap
wel duidelijker dan eerdere postings....
In article <364B5A10...@sifre.demon.nl>,
Steven <steven@sifre*.demon.nl> wrote:
>> [over PDF...]
>> >Ik dacht dat je het een "wangedrocht" vond?
>> Ja. Maar wel een bruikbaar/ soms zelfs praktisch wangedrocht.
>> Dat neemt niet weg dat het vis noch vlees is. Het is een 'presentatie'-
>> protocol, maar geen printertaal noch een SGML.
>Je blijft jezelf tegenspreken. Eerst zei je dat PDF een printertaal is, nu is
>het weer _geen_ printertaal.
>Citaat: "PDF is in mijn ogen een printer taal, met een paar extra dingetjes.
>(ook wel 'wangedrocht')."
Juist. Ik vond het een wangedrocht juist omdat het zoveel extra dingen
heeft. Jij zei dat het op grond van PSl2 gemaakt was. Wel, dat is een
(sterke) printertaal, maar PDF is zo uitgebreid dat het veel meer is
geworden, met een index, filmpjes, geluidsopnamen en vast nog wel meer. Mijn
ervaring met PDF is dat je het eerst moet converteren naar een printertaal
voordat je het naar de printer kan sturen, dus de eerste keer had ik niet
mogen zeggen dat het een printertaal was, denk ik.
Bij nader inzien is de term 'wangedrocht' wel overdreven. Ik vind wel dat
het een onoverzichtelijk groot geheel is. Dat kan tot afhankelijkheid
en onbetrouwbaarheid leiden.
Ik zie zelf meer in de verdeel en heers-strategie. Daarbij gebruik je veel
verschillende programma's, kleine programma's, voor afzonderlijke taken.
Mocht een onderdeel slecht zijn (buggy, onhandig, lelijk) dan kan je het
gewoon vervangen door een ander. Het scheelt gigantisch veel in overhead en
dus in processor-snelheid. Zo'n aanpak is gewoon veel flexibeler. Een goed
voorbeeld vind ik het Quicktime protocol. Als je een filmpje in een bepaald
document wil bekijken, wordt dat filmpje ter plekke weergegeven door
Quicktime. Dat vind ik beter dan een grote document-reader maken die zelf
een methode bedenkt om een filmpje weer te geven.(2)
>> De viewers zijn vaak buggy, en veel van de documenten kloppen vaak niet.
>Ik maak behoorlijk vaak gebruik van PDF, ik heb geen idee waar je het hier
>over hebt.
Nou ja, veel van de documenten maken gewoon geen gebruik van de
PDF-standaarden, zodat een aantal voordelen verloren gaan. Het grote
voorbeeld is de pagina-index, die heb ik tot nu toe alleen bij PDFs van
Apple gezien. Maar die zijn wel zeer handig... Een ander voorbeeld is dat
bij sommige documenten (en dat zie ik te vaak) de letters niet netjes op
dezelfde hoogte uitgelijnd zijn. Dat stoort.
>> Bijvoorbeeld: voor het printen met de laserwriter onder MacOS werkt AR2.0
>> het beste, maar die geeft op het scherm weer minder mooi dan AR3.0. Helaas
>> geeft de laatste consequent postscript fouten als ik probeer te printen.
>Hoe kan dat nou? AR 2? Is die uit de middeleeuwen?
Ja, maar die werkt wel!!! En hoe het kan AR3 ps-errors geeft, weet ik echt
niet. Het is wel erg vervelend.
>> >Zoals ik al eerder betoogde kan bij beide omschrijvingen een groot
>>vraagteken >> >geplaatst worden. Nou gaan ze ook nog in elkaar overlopen!
>>Help!!
>> Kom, er is wel degelijk onderscheid te maken tussen formaten die alleen
>> opmaak-commando's hebben, zoals wordperfect (niet word, want daar kan je wel
>> degelijk 'markeer'-opdrachten mee geven) en formaten die voornamelijk met
>> markeer-commando's werken, zoals latex (en HTML ;).
>
>Ik had het niet over verschillende formaten, maar over verschillende
>"definities" van HTML die jij naar voren bracht. Als ik je vraag naar
>deze onduidelijkheid zeg je "Het loopt inderdaad in elkaar over". Kan het nog
>wat onduidelijker?
Bij mijn weten heb ik geen verschillende "definities" van HTML naar voren
gebracht. Ik heb het de hele tijd over "opmaak" vs "markeer"(1). En dat zijn
twee uiterste methoden. In de praktijk hebben alle "markeer" methoden
"opmaak"-elementen. (Omgekeerd hoeven "opmaak" methoden geen
"markeer"-elementen te vertonen. Zie wordperfect, of een postscript bestand.)
HTML hoort bij de "markeer" methoden.
Zo is het nou eenmaal gemaakt, en het is een krachtige methode.
Eigenlijk kan ik me het heel goed voorstellen dat een graficus niet tevreden
met het resultaat is, en dus al het mogelijke doet om zijn ontwerp zo goed
mogelijk tot uiting te laten komen. Maar ja, met bepaalde trucjes doe je wel
afbreuk aan de kracht van HTML, de flexibiliteit en de toegankelijkheid.(3)
Zo ook met PDF. Enorm geschikt voor het overbrengen van een officieel
document, vanwege de rigide opmaak. Daarvoor gebruik ik het ook. Maar in
mijn ogen niet geschikt voor het overbrengen van informatie in het algemeen.
Wanneer je PDF gebruikt voor een internet-pagina, dan mis je:
(a) Flexibiliteit: alleen het publiek dat die ene reader wil/kan gebruiken
zal die informatie tot zich (kunnen) nemen.
(b) Toegankelijkheid: Je informatie kan niet geindexeerd worden.
Mensen kunnen niet verwijzen naar een subgedeelte
van je informatie.
Een toegepast voorbeeld:
Voor de macfaq pagina's gebruik ik vooral platte tekst. Gewoon omdat het
beter toegankelijk is dan HTML. Ik schrijf het in latex, zodat ik heel
flexibel ben. Ik kan (redelijk) opgemaakte platte tekst aanbieden, naast
het html-formaat en goed opgemaakte postscript. HTML heeft de extra
flexibiliteit van de hyperlinks, en biedt dus zeker voordelen. Mijn
'klanten' kunnen dus het formaat kiezen dat ze het liefst willen zien.
PDF zou simpelweg veel te lange download-tijden vragen, veel mensen zouden
daarom de informatie niet lezen, afgezien van het feit dat niet iedereen
Acrobat Reader heeft (bijvoorbeeld de mensen die een classic
gebruiken....).
Misschien is PDF wel een goed additioneel formaat, de Acrobat-Reader is nou
eenmaal wijder verspreid dan GhostView. Aan de andere kant, niemand heeft
ooit het ps-formaat opgevraagd, HTML is blijkbaar handiger en voldoende qua
opmaak (en kleiner).
Ik hoop dat ik mijn standpunt nu tenminste duidelijk heb gemaakt. Je hoeft
het er niet mee eens te zijn, maar ik hoop dat je het op zijn minst kan
volgen. Als je de flexibiliteit en toegankelijkheid van HTML niet nodig
vindt, dan gebruik je gewoon PDF, of postscript, of word, of nog wat anders.
Jeroen
(1) 'Mark-up' is volgens mij correcter vertaald met 'markeer' dan met
'opmaak'. 'Opmaken' komt meer overeen met 'publishing' als in DTP.
(2) Ik heb geen flauw idee hoe acrobatreader dat doet, het zou best kunnen
zijn dat die ook Quicktime gebruikt.
(3) Waarbij gezegd moet worden dat je met CSS wel meer controle hebt over de
opmaak dan met gewone HTML, zonder dat je de flexibiliteit of
toegankelijkheid enigszins tekort doet.
Jeroen Schaap
Steven <ste...@sifre.demon.nl> wrote:
>Precies. En omdat hij beide kan wijzigen heeft hij qua layout alle
>mogelijkheden.
>De HTML auteur heeft beperktere mogelijkheden omdat hij rekening moet
>houden met een breed scala aan configuraties aan de client zijde. De lezer
>ten slotte heeft ook beperktere mogelijkheden omdat hij de in HTML
>vastliggende structuur niet kan wijzigen.
Als de auteur niet probeert de opmaak te dicteren en zich alleen bezighoudt
met het markeren van zijn tekst, dan hoeft hij nergens rekening mee te houden.
Aan de andere kant, als de auteur de structuur in zijn informatie goed
kiest, hoeft de lezer niets meer te wijzigen. Hij kan de informatie wel op
zijn favoriete manier tot zich nemen (qua lettertype, grootte,
schermgrootte, met of zonder plaatjes, etc).
Jeroen
Steven
>
> In article <364B5363...@sifre.demon.nl>,
> Steven <ste...@sifre.demon.nl> wrote:
>
> >mogelijkheden.
>
> >De HTML auteur heeft beperktere mogelijkheden omdat hij rekening moet
> >houden met een breed scala aan configuraties aan de client zijde. De lezer
> >ten slotte heeft ook beperktere mogelijkheden omdat hij de in HTML
> >vastliggende structuur niet kan wijzigen.
>
> met het markeren van zijn tekst, dan hoeft hij nergens rekening mee te houden.
Jawel, met de volgorde bijvoorbeeld.
> Aan de andere kant, als de auteur de structuur in zijn informatie goed
> kiest, hoeft de lezer niets meer te wijzigen.
Sander wil niet dat de auteur keuzes voor hem maakt, hij wil alles kunnen
wijzigen en zegt dat HTML daar volledige vrijheid in bied. Dat laatste
bestrijd ik.
> Hij kan de informatie wel op
> zijn favoriete manier tot zich nemen (qua lettertype, grootte,
> schermgrootte, met of zonder plaatjes, etc).
Al deze parameters beïnvloeden mede de layout, en er is geen mogelijkheid voor
de gebruiker om daar invloed op uit te oefenen. Alles bij elkaar zijn de
mogelijkheden van HTML op dit gebied beperkt.
> Jeroen
Steven
Huh?
> Zo'n aanpak is gewoon veel flexibeler. Een goed
> voorbeeld vind ik het Quicktime protocol. Als je een filmpje in een bepaald
> document wil bekijken, wordt dat filmpje ter plekke weergegeven door
> Quicktime. Dat vind ik beter dan een grote document-reader maken die zelf
> een methode bedenkt om een filmpje weer te geven.(2)
Ik dacht dat Acrobat Quicktime gebruikte voor dergelijke content.
> >> De viewers zijn vaak buggy, en veel van de documenten kloppen vaak niet.
>
> >Ik maak behoorlijk vaak gebruik van PDF, ik heb geen idee waar je het hier
> >over hebt.
>
> Nou ja, veel van de documenten maken gewoon geen gebruik van de
> PDF-standaarden, zodat een aantal voordelen verloren gaan. Het grote
> voorbeeld is de pagina-index, die heb ik tot nu toe alleen bij PDFs van
> Apple gezien. Maar die zijn wel zeer handig... Een ander voorbeeld is dat
> bij sommige documenten (en dat zie ik te vaak) de letters niet netjes op
> dezelfde hoogte uitgelijnd zijn. Dat stoort.
Hier heb je het over slordig gemaakte documenten. Ik vermoed dat bij deze
documenten de fonts die correct "ge-embed" zijn. Er zijn ook zat websites die
onoordeelkundig inelkaar gezet zijn.
> >> Bijvoorbeeld: voor het printen met de laserwriter onder MacOS werkt AR2.0
> >> het beste, maar die geeft op het scherm weer minder mooi dan AR3.0. Helaas
> >> geeft de laatste consequent postscript fouten als ik probeer te printen.
>
> >Hoe kan dat nou? AR 2? Is die uit de middeleeuwen?
>
> Ja, maar die werkt wel!!! En hoe het kan AR3 ps-errors geeft, weet ik echt
> niet. Het is wel erg vervelend.
Dat zou kunnen liggen aan de manier waarop het document gegenereerd is. Het
zou kunnen dat deze gemaakt zijn met PDF Writer. (Windows nerds kunnen deze
los downloaden, en menen mischien dat dit het begin en einde is van PDF) Deze
is handig voor het snel maken van een PDFje, maar kan het ingwikkeldere werk
niet aan aan. Ook zou het kunnen liggen aan de compatibiliteit die gekozen is
is bij het maken van het document. (Acrobat 2.0 compatibel of Acrobat 3.0
compatibel). Het maken van een bookmark structuur wordt gedaan in Acrobat
Exchange. Niet iedere auteur neemt de moeite van deze mogelijkheden gebruik te
maken. Mensen die alleen PDF Writer hebben zullen geen goede PDFs kunnen
genereren. Als ze dan ook nog te lui zijn om de instellingen te optimaliseren
dan kan je inderdaad rommel verwachten. Je kan met Quark ook rommel maken. Of
in HTML...
> >> >Zoals ik al eerder betoogde kan bij beide omschrijvingen een groot
> >>vraagteken >> >geplaatst worden. Nou gaan ze ook nog in elkaar overlopen!
> >>Help!!
>
> >> Kom, er is wel degelijk onderscheid te maken tussen formaten die alleen
> >> opmaak-commando's hebben, zoals wordperfect (niet word, want daar kan je wel
> >> degelijk 'markeer'-opdrachten mee geven) en formaten die voornamelijk met
> >> markeer-commando's werken, zoals latex (en HTML ;).
> >
> >Ik had het niet over verschillende formaten, maar over verschillende
> >"definities" van HTML die jij naar voren bracht. Als ik je vraag naar
> >deze onduidelijkheid zeg je "Het loopt inderdaad in elkaar over". Kan het nog
> >wat onduidelijker?
>
> Bij mijn weten heb ik geen verschillende "definities" van HTML naar voren
> gebracht.
Mischien was dat een een andere Jeroen Sch...?
> Ik heb het de hele tijd over "opmaak" vs "markeer"(1). En dat zijn
> twee uiterste methoden. In de praktijk hebben alle "markeer" methoden
> "opmaak"-elementen. (Omgekeerd hoeven "opmaak" methoden geen
> "markeer"-elementen te vertonen. Zie wordperfect, of een postscript bestand.)
>
> HTML hoort bij de "markeer" methoden.
>
> Zo is het nou eenmaal gemaakt, en het is een krachtige methode.
Krachtig naar de maatstaven van het web, niet naar de maatstaven van Xpress of PageMaker.
> Eigenlijk kan ik me het heel goed voorstellen dat een graficus niet tevreden
> met het resultaat is, en dus al het mogelijke doet om zijn ontwerp zo goed
> mogelijk tot uiting te laten komen. Maar ja, met bepaalde trucjes doe je wel
> afbreuk aan de kracht van HTML, de flexibiliteit en de toegankelijkheid.(3)
>
> Zo ook met PDF. Enorm geschikt voor het overbrengen van een officieel
> document, vanwege de rigide opmaak. Daarvoor gebruik ik het ook. Maar in
> mijn ogen niet geschikt voor het overbrengen van informatie in het algemeen.
> Wanneer je PDF gebruikt voor een internet-pagina, dan mis je:
> (a) Flexibiliteit: alleen het publiek dat die ene reader wil/kan gebruiken
> zal die informatie tot zich (kunnen) nemen.
Als je geen Reader _wil_ gebruiken moet je dat zelf weten. Als ik geen
brouwser wil gebruiken kan ik ook weinig met HTML/CSS. Er zijn maar weinig
computers die geen Reader _kunnen_ gebruiken.
> (b) Toegankelijkheid: Je informatie kan niet geindexeerd worden.
> Mensen kunnen niet verwijzen naar een subgedeelte
> van je informatie.
Niet van buiten af. Wel vanuit een PDF. PDF is gemakkelijk te splitsen in
kleinere documenten die wčl dirct naar verwezen kan worden. Ik pleit er niet
voor om web pagina's te vervangen door PDF.
> Een toegepast voorbeeld:
>
> Voor de macfaq pagina's gebruik ik vooral platte tekst. Gewoon omdat het
> beter toegankelijk is dan HTML. Ik schrijf het in latex, zodat ik heel
> flexibel ben. Ik kan (redelijk) opgemaakte platte tekst aanbieden, naast
> het html-formaat en goed opgemaakte postscript. HTML heeft de extra
> flexibiliteit van de hyperlinks, en biedt dus zeker voordelen. Mijn
> 'klanten' kunnen dus het formaat kiezen dat ze het liefst willen zien.
>
> PDF zou simpelweg veel te lange download-tijden vragen, veel mensen zouden
> daarom de informatie niet lezen, afgezien van het feit dat niet iedereen
> Acrobat Reader heeft (bijvoorbeeld de mensen die een classic
> gebruiken....).
Nogmaals, ik heb nooit gezegd dat dergelijke documenten in PDF moeten.
> Misschien is PDF wel een goed additioneel formaat, de Acrobat-Reader is nou
> eenmaal wijder verspreid dan GhostView. Aan de andere kant, niemand heeft
> ooit het ps-formaat opgevraagd, HTML is blijkbaar handiger en voldoende qua
> opmaak (en kleiner).
PDF heeft de pretentie/ambitie de spil te worden van de prepress wereld. Dat
lijkt me wat meer dan alleen een additioneel formaat. Als het die ambitie
verwezenlijkt zal er waarschijnlijk geen ander formaat zijn dat de ins en outs
van gecompliceerde documenten beter beheerst.
> Ik hoop dat ik mijn standpunt nu tenminste duidelijk heb gemaakt. Je hoeft
> het er niet mee eens te zijn, maar ik hoop dat je het op zijn minst kan
> volgen. Als je de flexibiliteit en toegankelijkheid van HTML niet nodig
> vindt, dan gebruik je gewoon PDF, of postscript, of word, of nog wat anders.
Ik geloof dat we het in grote lijnen wel eens zouden kunnen worden.
> Jeroen
>
> (1) 'Mark-up' is volgens mij correcter vertaald met 'markeer' dan met
> 'opmaak'. 'Opmaken' komt meer overeen met 'publishing' als in DTP.
>
> (2) Ik heb geen flauw idee hoe acrobatreader dat doet, het zou best kunnen
> zijn dat die ook Quicktime gebruikt.
>
> (3) Waarbij gezegd moet worden dat je met CSS wel meer controle hebt over de
> opmaak dan met gewone HTML, zonder dat je de flexibiliteit of
> toegankelijkheid enigszins tekort doet.
--
Jeroen Schaap
>> Ik zie zelf meer in de verdeel en heers-strategie. Daarbij gebruik je veel
>> verschillende programma's, kleine programma's, voor afzonderlijke taken.
>> Mocht een onderdeel slecht zijn (buggy, onhandig, lelijk) dan kan je het
>> gewoon vervangen door een ander. Het scheelt gigantisch veel in overhead en
>> dus in processor-snelheid.
>
>Huh?
Bovenstaande is gewoon een beknopte beschrijving van de unix-strategie. Je
gebruikt veel kleine programmaatjes die via de kernel en/of unix sockets
boodschappen uitwisselen. Als die met elkaar samenwerken heb je een groot
geheel.
Het voordeel vanaf de systeemontwikkelaar gezien is de hogere efficientie:
je kan de meest efficiente methode voor elke stap gebruiken. Bijvoorbeeld,
je moet van een bepaalde ascii-file de derde kolom hebben en die sorteren.
Daarvoor heb je twee applicaties nodig. Eentje die de derde kolom uit de
file vist, en eentje die de kolom vervolgens sorteert. Op het moment dat er
een snellere sorteer-methode is, vervang je gewoon het sorteer-programma,
zonder dat je aan de rest van de keten iets hoeft te vervangen. Deze
methode is in een unix systeem ver doorgevoerd.
Dat geldt ook voor de communicatie tussen de onderdelen. Je kan gewoon de
snelste methode kiezen. Wil je een groot programma maken, dan zul je zelf
opnieuw een methode voor de communicatie moeten uitvinden. Vaak heeft dat
tot gevolg dat in een groot programma veel minder is geoptimaliseerd.
Dat heeft voordelen, en ook nadelen. Een voordeel is dat je een willekeurig
component kan vervangen door een ander. Als je bijvoorbeeld zeer
rekenintensieve taken hebt op een machine terwijl het presenteren van de
data ook best wat processor-tijd nodig hebt, dan kan je het rekenen op de
ene machine laten doen, en het resultaat van het programma weergeven op een
andere machine. Bij elkaar heb je dan een veel snellere machine. Een ander
voorbeeld, bij het maken van de film de 'Titanic' was de 3D-rendering
uitgevoerd op een stuk of 150 linux machines tegelijkertijd (op gratis
software...). Dat was een stuk goedkoper dan een hele snelle computer te
kopen (of ergens anders rekentijd te kopen).
Jeroen
Jeroen Schaap
>> Als de auteur niet probeert de opmaak te dicteren en zich alleen bezighoudt
>> met het markeren van zijn tekst, dan hoeft hij nergens rekening mee te houden.
>
>Jawel, met de volgorde bijvoorbeeld.
OK. Maar dat is ook echt wel het werk van een schrijver.
>
>> Aan de andere kant, als de auteur de structuur in zijn informatie goed
>> kiest, hoeft de lezer niets meer te wijzigen.
>
>Sander wil niet dat de auteur keuzes voor hem maakt, hij wil alles kunnen
>wijzigen en zegt dat HTML daar volledige vrijheid in bied. Dat laatste
>bestrijd ik.
Volledige vrijheid niet. Maar hij kan het wel wijzigen (omdat html nou
eenmaal ASCII broncode heeft, dus kan je wijzigen wat je wil). En met CSS
kan de lezer bepaalde elementen plaatsen waar hij wil. Volgorde van
paragrafen etc veranderen gaat volgens mij niet.
>> Hij kan de informatie wel op
^^^
>> zijn favoriete manier tot zich nemen (qua lettertype, grootte,
>> schermgrootte, met of zonder plaatjes, etc).
>
>Al deze parameters beïnvloeden mede de layout, en er is geen mogelijkheid voor
>de gebruiker om daar invloed op uit te oefenen. Alles bij elkaar zijn de
>mogelijkheden van HTML op dit gebied beperkt.
Ik bedoelde met 'Hij' de lezer.....
Jeroen Schaap
>documenten de fonts die correct "ge-embed" zijn. Er zijn ook zat websites die
>onoordeelkundig inelkaar gezet zijn.
Vrij veel zelfs ;)
>> Ja, maar die werkt wel!!! En hoe het kan AR3 ps-errors geeft, weet ik echt
>> niet. Het is wel erg vervelend.
>
>Dat zou kunnen liggen aan de manier waarop het document gegenereerd is. Het
Ik heb dat met vnl de Apple-info-PDFs. Weet jij toevallig hoe die gemaakt
zijn?
>> Bij mijn weten heb ik geen verschillende "definities" van HTML naar voren
>> gebracht.
>
>Mischien was dat een een andere Jeroen Sch...?
Waar heb ik dat dan gezegd?
>> HTML hoort bij de "markeer" methoden.
>>
>> Zo is het nou eenmaal gemaakt, en het is een krachtige methode.
>Krachtig naar de maatstaven van het web, niet naar de maatstaven van Xpress
>of PageMaker.
Niet qua opmaak, nee. Maar dat is dan ook niet essentieel voor het
communiceren van informatie. (Maar wel voor het communiceren van reclame,
bedrijfs-image ....)
>Als je geen Reader _wil_ gebruiken moet je dat zelf weten. Als ik geen
>brouwser wil gebruiken kan ik ook weinig met HTML/CSS. Er zijn maar weinig
>computers die geen Reader _kunnen_ gebruiken.
Jawel, als HTML netjes geschreven is dan is de broncode ook leesbaar.
>Niet van buiten af. Wel vanuit een PDF. PDF is gemakkelijk te splitsen in
>kleinere documenten die wčl dirct naar verwezen kan worden. Ik pleit er niet
>voor om web pagina's te vervangen door PDF.
Juist....ik leefde dus wel in die veronderstelling.
Wat je vindt van PDF staat hieronder. Maar wat vind je van HTML? Een
voorbijgaand fenomeen?
[]
>PDF heeft de pretentie/ambitie de spil te worden van de prepress wereld. Dat
>lijkt me wat meer dan alleen een additioneel formaat. Als het die ambitie
>verwezenlijkt zal er waarschijnlijk geen ander formaat zijn dat de ins en outs
>van gecompliceerde documenten beter beheerst.
Lijkt me voor de prepress wereld wel logisch. Maar als we het over prepress
hebben, wat is er dan mis met postscript?
>Ik geloof dat we het in grote lijnen wel eens zouden kunnen worden.
mooi.
Jeroen
Steven
>
> >> Ik zie zelf meer in de verdeel en heers-strategie. Daarbij gebruik je veel
> >> verschillende programma's, kleine programma's, voor afzonderlijke taken.
> >> Mocht een onderdeel slecht zijn (buggy, onhandig, lelijk) dan kan je het
> >> gewoon vervangen door een ander. Het scheelt gigantisch veel in overhead en
> >> dus in processor-snelheid.
> >
> >Huh?
>
> gebruikt veel kleine programmaatjes die via de kernel en/of unix sockets
> boodschappen uitwisselen. Als die met elkaar samenwerken heb je een groot
> geheel.
>
overstappen op UNIX? Ik denk dat de overhead van een gemiddelde browser groter
is dan die van Acrobat Reader. Als de PDF filosofie zo onverenigbaar is met de
UNIX filosofie wat moet ik dan denken van Mac OS X dat steunt op beide technologieën?
>
> Jeroen
Steven
>
> >Hier heb je het over slordig gemaakte documenten. Ik vermoed dat bij deze
> >documenten de fonts die correct "ge-embed" zijn. Er zijn ook zat websites die
> >onoordeelkundig inelkaar gezet zijn.
>
>
> >> Ja, maar die werkt wel!!! En hoe het kan AR3 ps-errors geeft, weet ik echt
> >> niet. Het is wel erg vervelend.
> >
> >Dat zou kunnen liggen aan de manier waarop het document gegenereerd is. Het
>
> zijn?
Geef eens een url naar zo'n boosdoener, dan zal ik eens kijken.
> >> Bij mijn weten heb ik geen verschillende "definities" van HTML naar voren
> >> gebracht.
> >
> >Mischien was dat een een andere Jeroen Sch...?
>
> Waar heb ik dat dan gezegd?
In mijn nieuwsreader worden langere namen van de afzenders soms niet helemaal
weergegeven. Dat is een probleem als zowel Jeroen Schaap als Jeroen Scheerder
in dezelfde draad posten.
> >> HTML hoort bij de "markeer" methoden.
> >>
> >> Zo is het nou eenmaal gemaakt, en het is een krachtige methode.
>
> >Krachtig naar de maatstaven van het web, niet naar de maatstaven van Xpress
> >of PageMaker.
>
> Niet qua opmaak, nee. Maar dat is dan ook niet essentieel voor het
> communiceren van informatie. (Maar wel voor het communiceren van reclame,
> bedrijfs-image ....)
Terug naar de typemachiene.
> >Als je geen Reader _wil_ gebruiken moet je dat zelf weten. Als ik geen
> >brouwser wil gebruiken kan ik ook weinig met HTML/CSS. Er zijn maar weinig
> >computers die geen Reader _kunnen_ gebruiken.
>
> Jawel, als HTML netjes geschreven is dan is de broncode ook leesbaar.
Ik zou zweren dat ik met een DOS adept te maken heb:-)
> >Niet van buiten af. Wel vanuit een PDF. PDF is gemakkelijk te splitsen in
> >kleinere documenten die wčl dirct naar verwezen kan worden. Ik pleit er niet
> >voor om web pagina's te vervangen door PDF.
>
> Juist....ik leefde dus wel in die veronderstelling.
Ik bestrijd alleen de misvatting dat PDF "verboden zou moeten worden" en dat
HTML zaligmakende kwaliteit kan afleveren. Ik heb al eerder toegegeven dat in
sommige omstandigheden PDF de voorkeur heeft en in andere HTML.
> Wat je vindt van PDF staat hieronder. Maar wat vind je van HTML? Een
> voorbijgaand fenomeen?
Nee, geen voorbijgaand fenomeen, zeer geschikt voor korte documenten die
on-line gelezen worden, maar ontoereikend voor bijvoorbeeld een 500 pagina's
tellende handleiding die een behoorlijke hoeveelheid layout vereist om goed
leesbaar te zijn en die je wilt downloaden en uitprinten.
> >PDF heeft de pretentie/ambitie de spil te worden van de prepress wereld. Dat
> >lijkt me wat meer dan alleen een additioneel formaat. Als het die ambitie
> >verwezenlijkt zal er waarschijnlijk geen ander formaat zijn dat de ins en outs
> >van gecompliceerde documenten beter beheerst.
>
> Lijkt me voor de prepress wereld wel logisch. Maar als we het over prepress
> hebben, wat is er dan mis met postscript?
PostScript kan niet on-line gelezen worden zoals PDF, PostScript heeft niet de
mogelijkheid om fonts in te bedden, zodat het niet echt portable is en niet
echt cross platform, PostScript is document-georienteerd, PDF is pagina
georienteerd (je kunt in een bestaand document een pagina invoegen met andere
fonts en layout) etc. Het november nummer van publish heeft PDF als
hoofdthema.
> >Ik geloof dat we het in grote lijnen wel eens zouden kunnen worden.
>
> mooi.
>
> Jeroen
Steven
>
> >> Als de auteur niet probeert de opmaak te dicteren en zich alleen bezighoudt
> >> met het markeren van zijn tekst, dan hoeft hij nergens rekening mee te houden.
> >
> >Jawel, met de volgorde bijvoorbeeld.
>
> OK. Maar dat is ook echt wel het werk van een schrijver.
Niet alleen. Om tot een goede layout te komen moet je soms de volgorde kunnen
wijzigen. Niet van de text die door ee schrijver is aangeleverd, maar van
bijvoorbeeld een kop en een inleiding, of van een tekstblok en een afbeelding,
of van een tweede textlijn...
> >> Aan de andere kant, als de auteur de structuur in zijn informatie goed
> >> kiest, hoeft de lezer niets meer te wijzigen.
> >
> >Sander wil niet dat de auteur keuzes voor hem maakt, hij wil alles kunnen
> >wijzigen en zegt dat HTML daar volledige vrijheid in bied. Dat laatste
> >bestrijd ik.
>
> Volledige vrijheid niet. Maar hij kan het wel wijzigen (omdat html nou
> eenmaal ASCII broncode heeft, dus kan je wijzigen wat je wil). En met CSS
> kan de lezer bepaalde elementen plaatsen waar hij wil. Volgorde van
> paragrafen etc veranderen gaat volgens mij niet.
>
> >> Hij kan de informatie wel op
> >> zijn favoriete manier tot zich nemen (qua lettertype, grootte,
> >> schermgrootte, met of zonder plaatjes, etc).
> >
> >Al deze parameters beïnvloeden mede de layout, en er is geen mogelijkheid voor
> >de gebruiker om daar invloed op uit te oefenen. Alles bij elkaar zijn de
> >mogelijkheden van HTML op dit gebied beperkt.
>
> Ik bedoelde met 'Hij' de lezer.....
Ja, en HTML beperkt zijn mogelijkheden. Met 'zijn' verwijs ik naar de lezer.
> Jeroen
Dennis SCP
> Interessant, maar wat heeft dit te maken met de discussie?
> Moeten we allemaal overstappen op UNIX? Ik denk dat de overhead
> van een gemiddelde browser groter is dan die van Acrobat Reader.
> Als de PDF filosofie zo onverenigbaar is met de UNIX filosofie wat
> moet ik dan denken van Mac OS X dat steunt op beide technologieën?
Wat betreft PDF hangen wij Mac gebruikers geheel af van Adobe software.
Ik heb het Rhapsody project gevolgt en daar klinken positieve verhalen
over PDF software van een andere fabrikant. Wij ervaren PDF door Acrobat
Reader als log, maar waarschijnlijk ligt er een goed gestructureerd
systeem onder dat via de Adobe programma's niet zo goed uit de verf
komt. Dit kan met de komst van Mac OS 10 wel eens aangenaam veranderen
want Apple heeft natuurlijk niet voor niets voor PDF gekozen. (Ze hebben
Display Postscript laten vallen om onder de licensie kosten van Adobe
uit te komen)
Dennis SCP
--
[MS Office 98 Assistant: Uw signature is leeg. Weet u zeker dat u niets
nuttigs aan de mensheid heeft mede te delen?]
Jeroen Scheerder
> PostScript kan niet on-line gelezen
Jawel hoor; onder Unix is het doorgaans geen probleem. Maar het is
inderdaad niet op alle platforms doenlijk.
En je bent inderdaad beperkt tot de gegarandeerd aanwezige PS-fonts.
Jeroen Scheerder
> Interessant, maar wat heeft dit te maken met de discussie? Moeten we allemaal
> overstappen op UNIX?
Nee. Modularisering door functionalteit in `componenten' te stoppen,
die met elkaar communiceren, is helemaal niet gebonden aan Unix. Er is
een Unix command-line mechanisme dat het goed mogelijk maakt (de pipe),
maar da's maar één manier.
Neem Internet Config. In wezen hetzelfde idee, maar dan op een
fundamenteler niveau uitgevoerd. Neem Mac OS' printing architecture --
of de hele architectuur van Mac OS, voor wat dat betreft. Er is één
ding dat text editing doet (ja, daar valt in de praktijk wat op af te
dingen). Zodoende is copy&paste, search&replace, spellchecking, URL
support (of wat dan ook) op een eenvoudige manier toe te voegen --
alleen in één component, en vervolgens krijgen alle applicaties het
cadeau.
> Ik denk dat de overhead van een gemiddelde browser groter
> is dan die van Acrobat Reader.
Ja, de `gemiddelde browsers' van het moment zijn een paar jaar terug
onder hun eigen gewicht ingestort, ten gevolge van een combinatie van de
ziekte die `featuritis' heet en korte-termijn-georienteerde
besluitvorming.
> Als de PDF filosofie zo onverenigbaar is met de UNIX filosofie wat moet ik
> dan denken van Mac OS X dat steunt op beide technologieėn?
Wees blij. Yellow Box (m.n.) is bij uitstek geschikt om `onder de
motorkap' functionaliteit van (vele) componenten te in een applicatie te
herbergen. Een tamelijk volledige tekstverwerker schrijf je in een
handvol regels; en dan heb je spell checking, de volledige quicktime
media layer, enzovoorts, zonder ook maar een bit aan bloat aan je
applicatie toe te voegen.
Het centrale idee is dat je functionaliteit één op één concentreert in
componenten. In de Unix shell is er een _toevallige_ samenkomst van
`component' en `programma', maar dat is alleen maar de manier waarop dat
idee in traditionele Unix shell programming gestalte heeft gekregen.
Er is niets Unix-specifieks aan modulaire opbouw middels functionele
componenten. Mac OS annu nu, intern, is al een stuk verder dan plain
Unix ooit zijn zal, en OS X's Yellow Box stoot het idee verder door naar
een ongekend hoog niveau.
Mijn voornaamste vraag op dit vlak is in hoeverre ook Carbon hier nog
vrucht van zal kunnen plukken. Als dat substantieel is, betekent dat
ook heel wat voor de `triviale conversie' van de huidige Mac OS
software: die wint dan ook onmiddellijk nog een boel extra aan kracht.
Sander Flobbe
> > Lijkt me voor de prepress wereld wel logisch. Maar als we het over prepress
> > hebben, wat is er dan mis met postscript?
>
> PostScript kan niet on-line gelezen worden zoals PDF, PostScript heeft niet de
> mogelijkheid om fonts in te bedden, zodat het niet echt portable is en niet
> echt cross platform, PostScript is document-georienteerd, PDF is pagina
> georienteerd (je kunt in een bestaand document een pagina invoegen met andere
> fonts en layout) etc. Het november nummer van publish heeft PDF als
> hoofdthema.
Postscript kan prima online gelezen worden! Op een unix machine gebeurt
dat met de door Jeroen beschreven manier van sub-programa's. gv,
ghostview, PS Viewer, ... rusten voor zover ik weet het algemene
programma gs (ghostscript).
Op een unix machine kom je eerder een postscript viewer tegen dan een
PDF viewer! Online browsen doe je door in je browser de juiste
programma's in te stellen bij *.ps.gz en *.ps :-)
Je argument dat postscript niet pagina-georienteerd zou zijn (zo zeg
je het niet precies) klopt niet. Daarvoor is er een Adobe Document(?)
Layout(?) Convention ofzoiets :-) Ik kan dus gewoon in een lijstje
met paginanummers klikken.
Zoals PDF zich nu als standaard begint op te werpen, zo is postscript
dat al jaren in het wereldje van wiskunde/natuurkunde-publicaties.
Dat heeft natuurlijk te maken met LaTeX, dat ook nog steeds ongeloof-
lijk populair is in dat wereldje. (Terecht!!)
Laat ik een volstrekt willekeurig voorbeeld geven:
http://www.math.uu.nl/people/vorst/publ.html
S.
Kees
<flo...@phys.uu.nl> wrote:
#Steven wrote:
#Je argument dat postscript niet pagina-georienteerd zou zijn (zo zeg
#je het niet precies) klopt niet. Daarvoor is er een Adobe Document(?)
#Layout(?) Convention ofzoiets :-) Ik kan dus gewoon in een lijstje
#met paginanummers klikken.
Het nadeel van het gebruik van PostScript zie je pas als je het naar een
printer wilt sturen. Wij hebben op het werk printers met verschillende
papierlades voor verschillende formaten. Als je nu een in de USA gemaakte
PS file naar zo'n 'slimme' printer stuurt, ziet de printer dat het
papierformaat bv. US Letter moet zijn en gaat dan op zoek naar een
papierbak met dat formaat. Die vindt ie echter niet, en geeft dus een
'paper jam' fout. Dan kan je met de hand de printer resetten, de PS file
alsnog met Acrobat Distiller omzetten naar een PDF document, dan in
Acrobat Reader de page size instellen en dán pas printen...
#Zoals PDF zich nu als standaard begint op te werpen, zo is postscript
#dat al jaren in het wereldje van wiskunde/natuurkunde-publicaties.
#Dat heeft natuurlijk te maken met LaTeX, dat ook nog steeds ongeloof-
#lijk populair is in dat wereldje. (Terecht!!)
TeX/LaTeX is inderdaag een prettig systeem om natuurkundige verhandelingen
in op te maken door de goede support voor formules. Als je de PS file die
er uiteindelijk uitkomt nu nog eventjes door Distiller haalt om daar een
PDF van te maken, kun je ook over de hele wereld verspreiden zonder alle
printers op hol te laten slaan. Het bijkomend voordeel is dat de PDF file
een stuk kleiner is dan de PS file, čn platform onafhankelijk.
Ik voer al jarenlang (en de laatste tijd met succes) een strijd op het
werk tegen het gebruik van PS files voor distributie. Nu we voor alle
platformen Acrobat Distiller/Exchange hebben beginnen mijn collega's in te
zien dat PDF toch wel een fijn formaatje is.
--kees
--
-- Illiterate? Write for free help --
Steven
>
> In article <364B5A04...@sifre.demon.nl>, Steven> > > In article <3648E600...@sifre.demon.nl>, Steven
> > > <ste...@sifre.demon.nl> wrote:
>
> [knip]
>
> > >
> > > > Bewijst dit dat CSS een onderdeel is van HTML? Volgens mij niet.
> > >
> > > Die citaten die ik aanhaalde zijn voorbeelden van de _vele_ verwijzingen
> > > [in de HTML 4.0 definitie] naar CSS waar het de weergave van in HTML
> > > bepaalde structuur betreft.
> > > Met al die verwijzingen is CSS dus een vanzelfsprekend gereedschap
> naast HTML.
> >
> > OK. Jij gebruikt de term HTML dus losjes en bedoeld er
> > HTML/DHTML/CSS/XML/JAVASCRIPT/etc. mee.
>
> ik HTML en JAVA-script met elkaar vereenzelvig.
Je laat me wel raden zeg... Het woord JAVA komt ook best vaak voor in de HTML spec...
> Als ik 'HTML' schrijf doel ik meer op het principe er van. Als ik 'de HTML
> definitie' schrijf doel ik op de concrete invulling van dat principe.
>
> > > CSS is dus inderdaad geen <tag> in HTML.
> > >
> > > Ik dacht dat we een inhoudelijke discussie voerden over in hoeverre HTML
> > > de browser/gebruiker vrij laat een document weer te geven.
> >
> > Vallen definities van termen die we gebruiken en verduidelijking van _hoe_ we
> > die definities gebruiken niet onder "inhoudelijke discussie"?
>
> Jij kwam met de zin 'CSS is geen onderdeel van HTML'.
Omdat jij bepaalde claims doet over de mogelijkheden van HTML. Omdat je die
niet uit jezelf ondersteund moet ik je helaas doorzagen over het bewijs.
Definities zijn daarbij belangrijk.
> Daar reageerde ik op
> met die citaten uit de HTML 4.0 definitie, die aangeven dat HTML zeer
> strikt voor _structuur_ alleen bedoeld is, en voor beïnvloeding op de
> weergave ervan CSS dient te worden gebruikt. IMHO mag ik daaruit afleiden
> dat HTML en CSS _zeer_ nauw verbonden zijn.
Toch zegt dat heel weinig. Het woord beeldscherm komt mischien ook wel vaak
voor in die tekst.
> In de strikte zin van het woord is CSS dan inderdaad niet "onderdeel" van
> HTML. Maar ik vind dat dus miereneuken op grond van elkaars taalgebruik.
> Dat wekt irritatie en verveeldheid op en suggereert dat je 'op zoek bent'
> naar argumenten.
Nee, het suggereerd dat ik wil dat je je claims hard maakt. Daarvoor is het
allereerst nodig je claims te zwart op wit te krijgen in door de grafische wereld
gebruikte termen.
> Maar misschien bedoelde je het niet zo. Het zijn maar eenen en nullen
> hier. 't is soms lastig elkaar in te schatten.
Ik kom mischien rechtlijnig of drammerig over. Dat moet je niet persoonlijk
opvatten.
Steven
>
> Steven <ste...@sifre.demon.nl> wrote:
>
> > Interessant, maar wat heeft dit te maken met de discussie?
> > van een gemiddelde browser groter is dan die van Acrobat Reader.
>
> Wat betreft PDF hangen wij Mac gebruikers geheel af van Adobe software.
> Ik heb het Rhapsody project gevolgt en daar klinken positieve verhalen
> over PDF software van een andere fabrikant.
O? Welke?
> Wij ervaren PDF door Acrobat
> Reader als log, maar waarschijnlijk ligt er een goed gestructureerd
> systeem onder dat via de Adobe programma's niet zo goed uit de verf
> komt.
Hoezo? Adobe heeft beide ontwikkeld toch?
> Dit kan met de komst van Mac OS 10 wel eens aangenaam veranderen
> want Apple heeft natuurlijk niet voor niets voor PDF gekozen. (Ze hebben
> Display Postscript laten vallen om onder de licensie kosten van Adobe
> uit te komen)
Niet vanwege de kosten. Apple wil haar Systeem niet afhankelijk maken van een
technologie die door een ander gecontroleerd wordt. Adobe wil Display
PostScript niet meer ondersteunen en ook niet verkopen. Apple wilde het kopen.
Daarom is gekozen voor PDF wat wel een open formaat is.
Steven
>
> Steven <ste...@sifre.demon.nl>:
>
> > Interessant, maar wat heeft dit te maken met de discussie? Moeten we allemaal
> > overstappen op UNIX?
>
> die met elkaar communiceren, is helemaal niet gebonden aan Unix. Er is
> een Unix command-line mechanisme dat het goed mogelijk maakt (de pipe),
> maar da's maar één manier.
>
Interessant, maar wat heeft dit te maken met de discussie?
--
Steven
>
[knip]
> > > [knip]
> > >
> > > > > > Uit de HTML 4 specificatie: "SGML is a system for defining markup
> > > > > > languages. Authors mark up their documents by representing structural,
> > > > > > presentational, and semantic information alongside content. HTML
> > > > > > is one example of a markup language."
> > > > > >
> > > > > > Let op de woorden "presentational" en "alongside". "Presentational"
> > > > > > geeft aan dat er niet alleen structuur gedefinieerd wordt maar ook
> > > > > > zaken betreffende de presentatie.
> > > > > >
> > > > > 'Presentational' is niet synoniem aan 'lay-out'.
> >
> > Klopt. Niet synoniem omdat de "presentational information" in HTML/CSS te
> > beperkt is om het hele terrein van de layout te bestrijken.
>
> zijn. Dat gaat over taal. Niet over HTML.
Waar komt 'weergave' nu ineens weer vandaan?
> > > [knip]
> > >
> > > > > Bij 'presentation of content' kun je ook denken aan de keuze van
> > > > > de auteur
> > > > > - of een volgend gedeelte een nieuwe alinea is, of een nieuw hoofdstuk
> > > > > - of iets wel of niet een <LIST> is
> > > > > - of informatie wel of niet tabulair dient weergegeven te worden.
> > > >
> > > > Dit is de structuur van een document.
> > >
> > > Inderdaad.
> > > "Presenteer ik mijn ideeėn in de vorm van een roman, een toneelstuk, of
> > > een politieke toespraak?" is een afweging die gaat over structuur.
> > >
> > > > Presentatie bepaalt hoe de tabel er uit
> > > > ziet, waar die geplaatst wordt, hoe de tekst lijnt, hoe de kop er uit
> > > > ziet etc.
> > >
> > > Nee. Ik beweer nou juist dat die term 'presentation' uit dat citaat IMHO
> > > niet zo geļnterpreteerd dient te worden.
> >
> > Dus "structural" = "presentational" en W3C gebruikt de termen dubbelop om de
> > opsomming wat aan te dikken?
>
> Als jij het zo wilt opvatten. Ik heb dat in de verste verte niet beweert.
Lees het nog maar eens terug dan. Ik kan er niets anders van maken.
> Ik zeg alleen dat het woord 'presentatie' niet per definitie op weergave
> hoeft te slaan[1].
Sterker nog: Ik heb het woord "weergave" helemaal niet gebruikt. Ik had het
over layout. Ik ben graficus, geen muzikant.
> Nogmaals wat hier een paar regels hoger staat:
> <start quote>
> "Presenteer ik mijn ideeėn in de vorm van een roman, een toneelstuk, of
> een politieke toespraak?" is een afweging die gaat over structuur.
> <end quote>. [Let op het eerste woord.]
Dus "presentatie" kan zo'n beetje overal op slaan behalve op "layout"? Beetje
krom lijkt me.
> > > > > Met wat voor lettertype, spacing, kleur, etc. je vervolgens die nieuwe
> > > > > alinea/dat nieuwe hoofdstuk/die lijst/die tabel als zodanig herkenbaar
> > > > > maakt en vorm geeft is een andere zaak.
> > > >
> > > > Dat dacht ik niet. Heeft die "andere zaak" ook een naam in jouw leerboek?
> > >
> > > Zoiets als 'weergave van structuur'.
>
> [Alleen 'weergave' was eigenlijk al genoeg geweest.]
>
> > Onzin.
>
> Sterk argument ;-)
Ik denk dat ik hier geen sterk argument nodig heb.
Steven
>
> In article <364B5363...@sifre.demon.nl>, Steven
> <ste...@sifre.demon.nl> wrote:
>
> > Sander Tekelenburg wrote:
> > >
> > > In article <3648E46C...@sifre.demon.nl>, Steven
> > > <ste...@sifre.demon.nl> wrote:
> > >
> > > > Sander Tekelenburg wrote:
>
>
> > > Voor zover ik weet zegt HTML niet dat een HTML-client <Hn> niet pas
> > > middenin de tekst zou mogen weergeven. Alleen dat <Hn> als zodanig
> > > herkenbaar moet zijn.
> >
> > Het zegt óók niet dat de client dat wèl kan.
>
We hadden het over layout. Ik weet niet waar je de term 'weergave' vandaan hebt.
Waar kan ik de definitie vinden van deze term in de spec van HTML? Of in een
tekstboek over grafische vormgeving en layout?
> > HTML is niet object georienteerd
> > maar procedureel. Daardoor ligt de volgorde vast.
>
> De volgorde waarin de 'code' door de browser wordt ingelezen ja. Dat hoeft
> niet te betekenen dat diezelfde volgorde dogmatisch moet worden
> vastgehouden bij de weergave van de content.
Jawel.
> Als je een lap tekst in een <TABLE> zet en over 2 kolommen verdeelt
> verschijnt het 1e woord van de 2e kolom ook bovenaan.
Fout voorbeeld. Je kunt als lezer nog steeds niet de volgorde van de kop en de
tabel wijzigen. Ook tabellen geven de lezer geen volledige vrijheid bij het
bepalen van de layout.
> Ook al staat het in
> het HTML document halverwege. Dit is een keuze van de browser/gebruiker;
De lezer heeft alleen de keuze tussen wèl of géén tabel gebruiken.
> een sprekende browser zou precies hetzelfde HTML document uiteraard niet
> zo weergeven.
>
> > > Dat de middelen om zo'n weergave in de praktijk te brengen momenteel niet
> > > beschikbaar zijn is een 2e.
> >
> > Geef eens een voorbeeld dan van HTML/CSS code die de gebruiker de mogelijkheid
> > geeft de volgorde van elementen van een document te wijzigen?
>
> Zoals ik schreef: de middelen zijn momenteel niet beschikbaar. Ik kan dus
> moeilijk voorbeeldcode geven.
Je beweert dat het aan de browser ligt, niet aan HTML. Dan moet het dus niet
te veel gevraagd zijn om een voorbeeld te geven van de code die de gewenste
layout beschrijft en daarbij aan te geven welke onderdelen van de code door de
browser fout of niet gebruikt worden.
> Het _principe_ van zo'n voorbeeld beschreef ik hier al[*].
>
> > > Je zult voor zoiets een _veel_ beter configureerbare browser [wellicht dmv
> > > iets als CSS] nodig hebben.
> >
> > Laat eerst maar eens zien hoe die code er uit ziet in plaats van je
> > achter de browser implementatie te verschuilen.
>
> [{zucht}
Inderdaad!
> Je vraagt me nogal eens te verwijzen naar de volgende alinea in
> m'n vorige bericht.]
Je blijft steeds dezelfe bewering herhalen zonder de validiteit daarvan aan te
tonen. Door te verwijzen naar eerdere argumenten die ik al verworpen heb
overtuig je me niet.
> Ik 'verschuil' me niet achter een browser implementatie. Ik zei dat de
> middelen [nog] niet beschikbaar zijn. Vervolgens noem ik die middelen:
> browser _en_ HTML definitie.
Nee, je moet niet je eigen woorden verdraaien. We hadden het eerder over de
controle die de lezer heeft. Je zei:
-->Die _heb_ je. Dat kun je zo bij de W3C nalezen.
-->Dat browsers daar in de praktijk nog nauwelijks iets van bakken heeft
-->niets met HTML te maken.
> Ik zal pogen het te verduidelijken:
> Aangezien HTML zich niet met de weergave [of opmaak/lay-out, hoe je het
> noemen wilt] bezig houdt, mag IMHO een browser een <Hn> weergeven midden
> in de tekst die in het HTML document pas _na_ <Hn> staat.
Ik zeg het nog maar een keer, hoewel ik zo langzamerhand de hoop verloren heb
dat het tot je door zal dringen: HTML legt zaken vast die het wijzigen van de
layout door de gebruiker beperken.
> Ik zie echter in de praktijk 2 problemen:
> 1) een browser moet dat kunnen.
> 2) als de structuur van dat document is:
>
> <H1>
> <H2>
> tekst
> <H2>
> tekst
>
> dan zal op de 1 of andere manier duidelijk moeten zijn welke <Hn> bij
> welke tekst hoort.
> Daarvoor is een aanvulling in de HTML definitie nodig.
Ik dacht dat je beweerde dat het al lang kon en dat je het zo kon nalezen op
W3C? En dat het alleen aan de browser ligt dat we die mogelijkheden niet hebben?
> Een systeem [bv in
> de vorm van attributes] waarmee je elementen aan elkaar kunt koppelen.
> Iets vreselijks nieuws zou dat niet zijn. Een Hyperlink is ook code die
> het 1 aan het ander koppelt. <TABLE> koppelt ook data en elementen.
>
> Op beide punten gaat het mijns inziens slechts om implementatie, en niet
> over geweld aandoen van het idee achter HTML, CSS, browsers, het WWW, etc.
>
> [*]
> > > Je zult ook voor een aantal HTML elementen
> > > nieuwe attributes moeten vastleggen, opdat je de header en de daarbij
> > > behorende tekst aan elkaar kunt koppelen.
> > > Maar het _wezen_ van HTML/CSS staat zoiets niet in de weg IMHO.
> >
> > Het _wezen_ van HTML? Je bedoelt dat het met HTML 4.0 niet mogelijk is.
>
> Ik bedoel dat het _wezen_ van HTML dat niet in de weg staat, maar dat het
> met de huidige _definities_ van HTML nog niet mogelijk is.
Dat probeer ik je dus nu al een week lang aan je verstand te brengen.
> > > [knip] (het is net of ik bij de kapper zit)
>
> Anders groeit het zo voor de ogen...
>
> > > > > In de traditionele visuele media is het zo dat in de _praktijk_ de
> > > > > structuur deel uitmaakt van de lay-out:
> > > >
> > > > Huh?
> > >
> > > Die praktische scheiding 'HTML+auteur bepalen structuur' vs
> > > 'browser+gebruiker bepalen weergave', bestaat niet in de traditionele
> > > visuele media, waar de auteur het _geheel_ in handen heeft. Dan nòg zijn
> > > ook voor die auteur
> > > 1)structuur, en
> > > 2)weergave daarvan
> > > twee verschillende dingen.
> >
> > Precies. En omdat hij beide kan wijzigen heeft hij qua layout alle
> > mogelijkheden.
>
> Inderdaad.
>
> > De HTML auteur heeft beperktere mogelijkheden omdat hij rekening moet houden
> > met een breed scala aan configuraties aan de client zijde.
>
> Klopt. Dat 'rekening houden met' is ook de reden om HTML te gebruiken.
Dat is ook precies de reden waarom bepaalde beperkingen blijven bestaan.
> > De lezer ten slotte
> > heeft
> > ook beperktere mogelijkheden omdat hij de in HTML vastliggende
> structuur niet
> > kan wijzigen.
Over "weergave" gesproken, wat doet jouw nieuwslezer met mijn quotes? (zie
boven) Of moet me dat ook worst wezen?
> Maar, potentieel, wel de weergave er van.
In de toekomst mischien in beperkte mate.
> > [knip]
>
> > > Ik zie niet in waarom HTML de gebruiker in die mogelijkheid zou beperken.
> >
> > Toch is het zo.
>
> De huidige praktijk ja. Maar HTML als concept niet. Ik zie niet in waarom
> die beperking in de weergave van de volgorde niet in de [hopelijk nabije]
> toekomst kan worden opgeheven.
> Wellicht is dit voor te dragen voor de nieuwe HTML/CSS schetsen.
Het is een vergelijking met een oneidig aantal onbekenden. Die los
je niet op door nog een paar variabelen toe te voegen.
> [knip]
>
> ['worst']
> > > > Mensen die iets te zeggen denken te hebben over vormgeving en
> tegelijkertijd
> > > > dergelijke opmerkingen maken over vorm vallen nou eenmaal op. Een
> valse noot.
> > > > Je kent dat wel. Kippevel.:-)
Bovenstaande "weergave" laat duidelijk zien wat er onder "worst" moet worden
verstaan. :-)
> > > Ik gebruikte die term als _gebruiker_. Als auteur bedien je de gebruiker.
Die het vervolgens worst is...
> > > Het zou je als auteur dus geen worst mogen zijn dat het de gebruiker worst
> > > is hoe je iets had willen vormgeven.
> >
> > Dus als muzikant hecht je groot belang aan de zeggenskracht van je muziek,
> > maar als luisteraar zal het je worst wezen? Verbazingwekkend! Ik ken maar
> > weinig muzikanten die zo denken.
>
> Dit zijn jouw woorden. Ik heb dit niet gezegd.
Dat zeg je wèl.
> Lees nog 'ns m'n verhaaltje na over de vergelijking tussen tekst en audio
> in Message ID <NOSPAM-0911...@p151.mas.euronet.nl>.
>
> Als ik van iemand een MIDI-file krijg zal het me inderdaad worst wezen
> of-ie de melodie voor een trompet of een tenorsax heeft bedoeld. Als-ie
> dat in het MIDI-file heeft vastgelegd zal ik het weten, maar dan nog kan
> ik dat veranderen naar m'n eigen voorkeur.
Je moet oppassen met het doortrekken van muzikale verhoudingen naar grafische.
Het weergeven van een MIDI bestand met een bepaald instrument kan vergeleken
worden met het drukken van een tekst in een bepaalde letter. Dat is iets
anders dan de layout. Bovendien is het meestal niet de eindgebruiker die MIDI
files gebruikt. MIDI wordt vooral gebruikt door muzikanten. Aan informatie in
de vorm van tekst worden heel andere eisen gesteld dan aan muziek.
> [knip]
>
> > > Maar ik dacht dat we het over publiceren hadden. Dan heb je met meer
> > > mensen dan alleen jezelf te maken.
> >
> > Hoe is dit te rijmen met je opmerking: "Hoe het er uit ziet zal me worst wezen
> > [als lezer]". Gaan we met twee maten meten?
>
> Ik ben er 99% zeker van dat ik het zo nooit heb gezegd. Kun jij me
> aanwijzen waar ik dat heb geschreven?
Dit is wat je schreef:
"[...opmaak...] zal me worst wezen wanneer ik slechts
op zoek ben naar informatie."
> Wat ik heb geschreven was "Het zal me als gebruiker worst wezen hoe de
> auteur de content had willen weergeven". Hoe het wordt weergegeven zal me
> zeker geen worst wezen, maar ik, als gebruiker, wil dat zo veel mogelijk
> zelf _kunnen_[1] bepalen.
>
> [knip]
>
> > > Dit is geen wijzigen van structuur. Het is definieren hoe die structuur
> > > dient te worden weergegeven.
> >
> > Over mierenneuken gesproken...
>
> [ah. de nieuwe spelling ;-)]
Ja, ja, voor zover ik het nog kan overzien neuk jij meerdere mieren...:-)
> Huh?
> Het verschil tussen structuur en de weergave er van is dacht ik het hele
> punt van deze draad!
Ik heb het niet over weergave gehad.
> > Dus de gebruiker kan de wijze waarop de impliciete en expliciete structuur,
> > vastgelegd in HTML, wordt weergegeven naar eigen believen wijzigen? Elementen
> > kunnen dus in een andere volgorde worden weergegeven dan die die impliciet
> > gegeven is in de code?
>
> [Het is me niet geheel duidelijk wat je hier met "impliciet" en
> "expliciet" bedoeld.]
Ik dacht dat ik dat in de tweede zin duidelijker maakte. Met impliciet bedoel
ik bij voorbeeld de volgorde, daarvoor is geen expliciete tag, maar die isdoor de
procedurele aard van HTML wel vastgelegd.
> Ik ben er van overtuigd dat dat kan ja. Alleen nog niet in de huidige
> praktijk. Het wachten is op de implementatie hiervan.
Dan kunnen we deze draad nu beeindigen. Tot nu toe beweerde je namelijk dat
het wèl kon en zó was na te lezen op W3C.
Steven
>
> Steven wrote:
>
> > > Lijkt me voor de prepress wereld wel logisch. Maar als we het over prepress
> > > hebben, wat is er dan mis met postscript?
> >
> > PostScript kan niet on-line gelezen worden zoals PDF, PostScript heeft niet de
> > mogelijkheid om fonts in te bedden, zodat het niet echt portable is en niet
> > echt cross platform, PostScript is document-georienteerd, PDF is pagina
> > georienteerd (je kunt in een bestaand document een pagina invoegen met andere
> > fonts en layout) etc. Het november nummer van publish heeft PDF als
> > hoofdthema.
>
> Postscript kan prima online gelezen worden! Op een unix machine gebeurt
> dat met de door Jeroen beschreven manier van sub-programa's. gv,
> ghostview, PS Viewer, ... rusten voor zover ik weet het algemene
> programma gs (ghostscript).
Ik zei, "niet zoals PDF", op dezelfde manier op alle platforms, zonder dat de
fonts geïnstalleerd hoeven te zijn. Wat dacht je trouwens van gewicht van
PostScript in vergelijking met PDF?
> Op een unix machine kom je eerder een postscript viewer tegen dan een
> PDF viewer!
Die bestaat wel.
> Online browsen doe je door in je browser de juiste
> programma's in te stellen bij *.ps.gz en *.ps :-)
>
> Je argument dat postscript niet pagina-georienteerd zou zijn (zo zeg
> je het niet precies) klopt niet.
Jawel. Je kunt niet een pagina uit een PostScript bestand halen om ergens
anders te gebruiken zonder dat die zijn layout en tekstspecificaties verliest.
Die staan namelijk aan het begin van het PS bestand. Bij PDF staat deze
informatie op de pagina zelf.
> Daarvoor is er een Adobe Document(?) Layout(?) Convention ofzoiets :-)
> Ik kan dus gewoon in een lijstje met paginanummers klikken.
En dan? Kun je die pagina los bewaren? Of in een ander document invoegen?
Met behoud van de opmaak eb tekstspecificaties?
> Zoals PDF zich nu als standaard begint op te werpen, zo is postscript
> dat al jaren in het wereldje van wiskunde/natuurkunde-publicaties.
> Dat heeft natuurlijk te maken met LaTeX, dat ook nog steeds ongeloof-
> lijk populair is in dat wereldje. (Terecht!!)
Als de mensheid voor een groot deel uit wiskundigen zou bestaan zou dat indruk
op me maken. Je argumenten doen me denken aan het soort dat eind jaren
tachtig/begin jaren negentig te berde gebracht werd ter verheerlijking van DOS.
> S.
Frank Eetgerink
Helemaal mee eens.
In mijn ervaring is pdf, ondanks wat schoonheidsfoutjes, het best dekkende
format.
De bestandsgrootte valt ook best mee, als je kwaliteit met kwaliteit
vergelijkt. Alleen zou Adobe er meer een open standaard van moeten maken:
bijv. een gratis verspreiding van de PDF-Writer, de print-to-pdf-file
driver. Pas dan zal pdf bredere aanhang krijgen. Goedkopere licenties kan
ook, zodat het breed wordt opgenomen in andere progs.
Voor het fine-tunen van een file heb je toch nog de 'echte' programma's
nodig.
Frank
----------
>From: kees....@nikhef.nl (Kees)
>Newsgroups: nl.comp.sys.mac
>Subject: PDF vs PS was: PDF vs HTML
>Date: zat, 14 nov 1998 17:37
>
>een stuk kleiner is dan de PS file, èn platform onafhankelijk.
Steven
>
> Kees,
> Helemaal mee eens.
> In mijn ervaring is pdf, ondanks wat schoonheidsfoutjes, het best dekkende
> format.
> De bestandsgrootte valt ook best mee, als je kwaliteit met kwaliteit
> vergelijkt. Alleen zou Adobe er meer een open standaard van moeten maken:
> bijv. een gratis verspreiding van de PDF-Writer, de print-to-pdf-file
> driver.
Dit is een veel voorkomende denkfout: Als iets gratis is is het een open
standaard. Fout. Voorbeeld: Internet Explorer is gratis en wint daardoor veel
aanhang. Betekent dat dat Microsoft een groot voorstander is van een open
standaard? Is het om zeep helpen van open systemen niet juist het hele eieren
eten van die gratis Explorer?
> Pas dan zal pdf bredere aanhang krijgen. Goedkopere licenties kan
> ook, zodat het breed wordt opgenomen in andere progs.
> Voor het fine-tunen van een file heb je toch nog de 'echte' programma's
> nodig.
>
> Frank
> ----------
Maarten van Steenbergen
>Het nadeel van het gebruik van PostScript zie je pas als je het naar een
>printer wilt sturen. Wij hebben op het werk printers met verschillende
>papierlades voor verschillende formaten. Als je nu een in de USA gemaakte
>PS file naar zo'n 'slimme' printer stuurt, ziet de printer dat het
>papierformaat bv. US Letter moet zijn en gaat dan op zoek naar een
>papierbak met dat formaat. Die vindt ie echter niet, en geeft dus een
>'paper jam' fout. Dan kan je met de hand de printer resetten, de PS file
>alsnog met Acrobat Distiller omzetten naar een PDF document, dan in
>Acrobat Reader de page size instellen en dán pas printen...
Maar er is hier toch geen PS/PDF oorlog aan de gang? Het zijn allebei formaten
met de gedachte: "geen gezeik bij het printen". Dat PDF wat minder gezeik
geeft is een detail. Het zou een stuk beter zijn als MS standaard een PDF/PS
programma zou meeleveren, want ik hoor heel vaaak van mensen die Word
gebruiken en enorme ellende hebben als ze het ergens anders moeten uitprinten.
Overigens: Is er niet een utility die van de US-PS een a4-PS maakt? pstops
ofzo?
>TeX/LaTeX is inderdaag een prettig systeem om natuurkundige verhandelingen
>in op te maken door de goede support voor formules.
Hehe,... eindelijk iets waar iedereen in deze thread het over eens lijkt te
zijn. Het is jammer dat TeX/LaTeX niet wat meer aandacht krijgt in bladen
etc., want ook voor scholieren en grotere bedrijven lijkt het me erg handig.
(vooral LaTeX dan :-)
Maarten
--
Maarten van Steenbergen <stee...@phys.uu.nl>
-----=====* http://www.phys.uu.nl/~steenbrg/ *=====-----
Kees
stee...@phys.uu.nl (Maarten van Steenbergen) quoth:
#Maar er is hier toch geen PS/PDF oorlog aan de gang? Het zijn allebei formaten
#met de gedachte: "geen gezeik bij het printen". Dat PDF wat minder gezeik
#geeft is een detail.
Niet als je de systeembeheerder bent die telkens de printers door het hele
gebouw moet resetten door foutieve PS format informatie... Dan vind je PDF
tóch wel prettiger.
Sander Flobbe
> Jawel. Je kunt niet een pagina uit een PostScript bestand halen om ergens
> anders te gebruiken zonder dat die zijn layout en tekstspecificaties verliest.
> Die staan namelijk aan het begin van het PS bestand. Bij PDF staat deze
> informatie op de pagina zelf.
>
> > Daarvoor is er een Adobe Document(?) Layout(?) Convention ofzoiets :-)
> > Ik kan dus gewoon in een lijstje met paginanummers klikken.
>
> En dan? Kun je die pagina los bewaren? Of in een ander document invoegen?
> Met behoud van de opmaak eb tekstspecificaties?
Yep :-)
Psselect selects pages from a PostScript document, creat-
ing a new PostScript file. The input PostScript file
should follow the Adobe Document Structuring Conventions.
S.
Sander Flobbe
> Maar er is hier toch geen PS/PDF oorlog aan de gang? Het zijn allebei formaten
> met de gedachte: "geen gezeik bij het printen". Dat PDF wat minder gezeik
> geeft is een detail.
Wat mij betreft geen oorlog, maar wel even een eerlijke discussie. Ik
weet
van PDF alleen maar dat
- de viewer onder MacOS erg groot en traag is
- mijn printer (Apple Personal LaserWriter) het alleen op 100 dpi ofzo
kan uitprinten, niet op 300
- er geen viewer is voor mkLinux / linuxppc
- het maken van PDF documenten alleen met payware mogelijk is
Ik wil graag meer van PDF weten want ik heb momenteel een nogal
negatieve
kijk op die standaard (zie boven).
Ik kan mij erg opwinden over Netscape op Windhoos machines / MacOS
machines. Ik zie vaak hele stapels papier in de printer liggen, van
mensen die even op 'print' duwen in Netscape. Zelf geef ik in Netscape
het print-commando "psnup -2 | lp -dprinter", zodat je de uitvoer
netjes in twee kolommen op papier krijgt. Volgens mij KAN dat niet
eens in Windows / MacOS.
Als ik de sourcecode van een programma wil nalezen, tiep ik
'sourceprint'. Dat is een alias voor:
a2ps -1 -p -nL *.cc *.h | ssh ruunat "psbook | psnup -2 | psprint -i4"
De stapel A4-tjes uit de printer kan ik dubbelvouwen, en
dan heb ik een A5-boekje. psbook zorgt ervoor dat de pagina's
in de goede volgorde komen hiervoor.
Kan dit zo makkelijk met `PDF-software'?
S.
Sander Flobbe
> ... Alleen zou Adobe er meer een open standaard van moeten maken:
> bijv. een gratis verspreiding van de PDF-Writer, de print-to-pdf-file
> driver. Pas dan zal pdf bredere aanhang krijgen. Goedkopere licenties kan
> ook, zodat het breed wordt opgenomen in andere progs.
Als het een open standaard zou worden, dan zou er vanzelf meer support
ontstaan ja. Maar enkel het leveren van wat drivers geeft geen brede
ondersteuning.
Mensen met exotische hardware mogen naar de maan lopen?
Als je eens om je heen kijkt naar wat een gemiddeld software-bedrijf
ondersteunt qua platforms, dan zul je zien dat Adobe al een van de
gunstige uitzonderingen vormt. Maar voor veel zaken ben je verplicht
op je computer inferieure systemen te installeren; wil je met de
wereld kunnen communiceren. Dat is zowel frustrerend als
noodzakelijk. Het zou alleen prettig zijn wanneer PDF niet op die
manier een duit in het zakje doet. En dat kan alleen als het echt
een open standaard wordt.
S.
Jeroen Scheerder
[knip]
> Interessant, maar wat heeft dit te maken met de discussie?
Er leek hier een misverstand over te zijn -- een quasi-onenigheid. In
een uitloper van de discussie, toegegeven. Een schijn van onenigheid
die me belangrijk genoeg toescheen om 'm in /dev/kiem te smoren.
-- J$
--
PDF files are only as large as the source.
Jeroen Scheerder
> - er geen viewer is voor mkLinux / linuxppc
> - het maken van PDF documenten alleen met payware mogelijk is
Volgens mij kloppen deze `weetjes' beiden niet. Iemand anders moet maar
wat zinvols melden over de standaard Linux distributies, maar:
- het PDF format is gedocumenteerd, en er is dan ook behoorlijk
wat third party support voor. Zeker in de Unix wereld; op mijn
NeXT heb ik b.v. OmniPDF.
- Op al mijn Unix systemen kan ik (dank, Ronald!) PDFTeX draaien,
waarin het `dvi' format vervangen is door PDF. Verder bestaan
er `distiller' replacements: Unix heeft helemaal geen generieke
print architectuur (eigenlijk heeft alleen Mac OS dat), maar
hierdoor is de stap van PostScript naar PDF wel een min of
meer universeel toegankelijke. Printen _is_ PostScript genereren,
doorgaans, op een Unix systeem; het is op zijn minst een optie,
als het al niet de enige mogelijkheid is.
N-up printing is iets wat geen deel is van het representatieformat: het
is een functie die de print architectuur hoort te bieden. A la Mac OS
-- maar onder Unix is het goed te doen om een aparte queue (of
specifieke lp of lpr opties, en support daarvoor) op te zetten die de
benodigde conversies alsmede de gewenste n-upping doen.
Ik heb ook wel eens gezocht naar de PDF specs. Ze moeten er zijn, maar
ik stuitte er niet 1-2-3 op. Om echt op PDF te kunnen vertrouwen, is
het een spijkerharde sine qua non dat de specificaties openbaar en vrij
toegankelijk zijn, uiteraard. Anders houdt het hele verhaal op, en is
het enkel het zoveelste proprietary format. Ook al is in principe nog
zo'n goed idee, als je ermee aan de luimen van een enkele fabrikant
overgeleverd wordt, is het wat mij betreft onbruikbaar. URL, iemand?
-- J$
--
Engineers at Intel called Adobe all in a huff about Apple's new ad
campaign that shows a snail carrying an Intel Pentium II chip.
Their grievance, in particular, was the on-screen disclaimer-sized
statistic that shows that in Photoshop tests Apple's G3 was nearly
twice as fast as Intel's Pentium II chip. The engineers were crying
foul (asserting that the tests were, perhaps rigged) and asked Adobe
(who offers Photoshop for both Mac and Windows) to perform the speed
tests themselves so they (Intel) might get an unbiased result.
Well, big mistake for Intel.
Adobe agreed and according to Adobe's own in-house Photoshop test,
"Apple had actually UNDERSTATED the performance gap between the G3 and
the Pentium II."
Steven
>
> In article <364DD987...@sifre.demon.nl>, Steven
> <ste...@sifre.demon.nl> wrote:
>
> [knip]
>
> > Dus "presentatie" kan zo'n beetje overal op slaan behalve op "layout"?
> > Beetje krom lijkt me.
>
> Alweer iets wat ik niet heb gezegd.
Jij verklaart "presentational" als volgt:" "Presenteer ik mijn ideeën in de
vorm van een roman, een toneelstuk, of een politieke toespraak?" is een
afweging die gaat over structuur.
<NOSPAM-1211...@p210.mas.euronet.nl> "
Ten eerste wordt "presentational" hier gelijkgesteld met "structural", ten
tweede kan aan de lijst: "roman, toneelstuk, politieke toespraak" nog een
lange rij modaliteiten toegevoegd worden: Presenteer ik het in het Frans,
presenteer ik het als storyboard, presenteer ik het met of zonder inleiding,
presenteer ik het als sinterklaas geschenk of als kerst kado, noem maar op,
als het maar geen layout is omdat dit je met dit argument mijn stelling dat
HTML bepaalde layout informatie bevat wilt ontzenuwen. Ten derde: moet ik
uit verklaring van de term "presentational" en en het feit dat W3C zegt dat
HTML "presentational information" bevat opmaken dat er een <toneelstuk> tag
is en een <roman> tag? Dit is _niet_ wat er in de grafische wereld onder
"presentational" wordt verstaan.
> In een gesproken discussie kun je dit soort spelletjes spelen.
Ik speel geen spelletjes.
> In een
> digitale discussie is het zinloos, omdat alles wat gezegd is gewoon
> letterlijk is na te lezen.
Als we er tenminste op tijd bij zijn want je staat niet toe dat je berichten
gearchiveerd worden zodat we ons via DejaNews kunnen voorzien van juiste
citaten. Dus je eis om message IDs op te geven is op z'n minst een beetje
merkwaardig als je ons niet toestaat je berichten via DejaNews na te lezen.
> Indien ik inconsequent ben geweest in m'n uitspraken kun je de moeite
> nemen te verwijzen naar citaten, inclusief bron [Message ID].
Het punt is dat ik moet raden naar wat je bedoeld als je HTML zegt. Het ene
moment lijk je het over de HTML 4.0 spec te hebben die "gewoon na te lezen is
op W3C", een ander moment -als je je argumenten met gewoon HTML niet kunt
waarmaken- doe je alsof CSS een onderdeel is van HTML. Dat toon je vervolgens
aan door een ' word count'. Vind je het gek dat ik me afvraag wat voor jou
nog meer 'vanzelfsprekende onderdelen' zijn van wat je bedoeld als je HTML
zegt? Als ik de logica toepas die jij gebruikt om aan te tonen dat CSS bij
HTML hoort horen veel andere technologieën er ook gewoon bij.
> Maar dat doe je niet.
> Ik sta open voor terechtwijzingen. Ik ben hier niet om 'te overtuigen'.
Het leek er alleen verdomd veel op toen je het had over de "revolutionaire
mogelijkheid van HTML om de _gebruiker_ te laten bepalen hoe de informatie
wordt weergegeven.". <NOSPAM-3010...@p247.mas.euronet.nl>
En je noemde het zelf "je kruistocht voor HTML":
"Iets dat mijn 'kruistocht voor HTML' alhier nou niet direct suggereert."
<NOSPAM-0311...@p142.mas.euronet.nl>
> Ik vind het interessanter wat te leren, wat dus ook betekent
> dat ik me er zeer van bewust ben dat ik me kan vergissen.
En, ben je je er al van bewust dat je je vergist?
Eerst schreef je:
> Ik zeg dat dat dat niet aan HTML ligt, maar aan de
> kwaliteit van de browser. Wat HTML betreft kan de lezer/luisteraar/whatever de
> lay-out tot in het extreme beïnvloeden. Juist omdat HTML zich niet met die
> lay-out bezig houdt." <NOSPAM-0911...@p151.mas.euronet.nl>
En:
> [controle] _heb_ je. Dat kun je zo bij de W3C nalezen. Dat browsers daar
> in de praktijk nog nauwelijks iets van bakken heeft niets met HTML te maken." <NOSPAM-0911...@p151.mas.euronet.nl>
Nu schrijf je:
> Ik bedoel dat het _wezen_ van HTML dat niet in de weg staat,
> maar dat het met de huidige _definities_ van HTML nog niet mogelijk is." <NOSPAM-1411...@1dyn5.utr.casema.net>
> Maar als je
> iemand's vergissing wilt aantonen zul je wat beter je best moeten doen.
Nee, we gaan de bewijslast niet omdraaien. Zo van: Jij roept wat en als ik
niet de tijd heb om de onjuistheid aan te tonen is het dus waar. Zo gaat dat
niet. Als jij beweert dat HTML de gebruiker volledige vrijheid geeft bij het
bepalen van de layout zul je zelf je best moeten doen om dat aan te tonen.
> Je vraagt om exacte definities en verwijzingen naar tekstboeken, alsof je
> erg veel waarde hecht aan precisie, maar tegelijkertijd 'citeer' je me
> ronduit slordig en neem je niet de moeite naar de bron te verwijzen.
_Jij_ bent de bron. Dat lijkt me duidelijk. Dat jij je berichten niet laat
archiveren en vervolgens citaten gaat aanvechten een bronnen eist zegt iets
over jou. Niet over mij. Mischien speel _jij_ wel spelletjes?
> Misschien ben je veel slimmer dan je je voordoet en ben je gewoon een
> spelletje aan het spelen. Misschien heb je een leesprobleem. Misschien
> valt het je zwaar open te staan voor een andere invalshoek/een ander
> concept dan je gewoon bent. Ik heb geen idee. In ieder geval zou
> zolangzamerhand het enige waarmee ik nog inhoudelijk op je follow-ups zou
> kunnen reageren de zoveelste herhaling zijn van wat ik allang in
> verschillende bewoordingen heb gepoogd uit te leggen.
Dat hoef je niet te doen, ik heb al aangegeven dat ik van mening ben dat je er
naast zit. Bovendien is dit niet een kwestie van "een andere mening" of een
"andere invalshoek". Het is gewoon een kwestie van aantoonbare feiten en
algemeen geldende afspraken over terminologie. Je terminologie is niet de
gangbare en de feiten die je claimt zijn niet juist.
> Aangezien dat
> allemaal na te lezen is zie ik geen reden deze groep daar nog verder mee
> te vervelen.
Ik raad iedereen aan die deze draad op z'n gemak wil nalezen hem in z'n geheel
naar een aparte map te copieren voordat hij van de server verdwijnt aangezien
Sander niet toestaat dat zijn berichten gearchiveerd worden door DejaNews.
Steven
Mm.. Daar was ik niet bekend mee. Feit blijft dat dit de verdienste is van het
programma en niet van het PostScript formaat dat document georienteerd is. Het
is dus niet zo dat de poagina er gewoon ongewijzigd tussen uit gehaald kan
worden zoals bij PDF, in plaats daarvan wordt een pagina aangewezen in de PS
structuur en wordt op basis van de specificaties aan het begin van het
document een nieuwe pagina gecreëerd.
Jeroen Schaap
>> gebruikt veel kleine programmaatjes die via de kernel en/of unix sockets
>> boodschappen uitwisselen. Als die met elkaar samenwerken heb je een groot
>> geheel.
>Interessant, maar wat heeft dit te maken met de discussie? Moeten we
>allemaal >overstappen op UNIX? Ik denk dat de overhead van een gemiddelde
>browser groter >is dan die van Acrobat Reader. Als de PDF filosofie zo
>onverenigbaar is met de >UNIX filosofie wat moet ik dan denken van Mac OS X
>dat steunt op beide technologieën?
Oh nee, het is niet onverenigbaar. Het is alleen anders.
En wat ik moet denken van PDF als grafisch abstractieniveau weet ik echt
niet. Het lijkt met niet dat het huidige PDF daar geschikt voor is.
Maar aan de andere kant, toen ik hoorde dat Rhapsody met postscript zou gaan
werken, was ik erg enthousiast: eindelijk precies hetzelfde op beeldscherm
en printer! Mijn redenen om niet enthousiast te zijn over PDF zullen
misschien meer emotionele/behoudende redenen zijn: postscript heeft zich
eeuwen geleden al met vlag en wimpel bewezen, terwijl PDF naar mijn zin nog
te veel fouten bevat en bovendien ondoorzihtig qua inhoud en strategie.
Postscript heeft een duidelijk doel(1) en is simpel, overzichtelijk.
In een echte BSD omgeving kan je elke laag vervangen door een ander, zonder
al te veel problemen. Dus we zullen het op de lange duur wel zien hoe PDF
het houdt in die concurrentieslag.
Jeroen
(1) Tenminste in mijn ogen: af te drukken beeld beschrijven met
wiskunde zodat de taal onafhankelijk is van het output-apparaat.
--
Jeroen Schaap.............I was dreaming of guitarnotes that would irritate
Homepage: <http://rulffh.medfac.leidenuniv.nl>..| ^|^ |...an executive kind
Keywords: Guitars, Linux, Mac and SCN...........\_`-'_/..............of guy
Tel: (0)71-5276811................................| |...........Frank Zappa
Jeroen Schaap
Jeroen Scheerder <j...@xs4all.nl> wrote:
>Het centrale idee is dat je functionaliteit één op één concentreert in
>componenten. In de Unix shell is er een _toevallige_ samenkomst van
>`component' en `programma', maar dat is alleen maar de manier waarop dat
>idee in traditionele Unix shell programming gestalte heeft gekregen.
>
>Er is niets Unix-specifieks aan modulaire opbouw middels functionele
>componenten.
Ehhhmmm. Dat concept is in eerste instantie met Unix echt tot leven gekomen.
Dat levert natuurlijk wel de bekende achterstand van pioniers op: latere
technologien kunnen beter zijn dan de allereerste. Unix heeft nog steeds de
command-line, en komt daar nooit meer van af. Maar dat is niet het enige
waar die modulariteit in uiting komt. Dat komt onder meer in uiting in de
internet-protocollen, de modulariteit van Xwindows (Xservers losgekoppeld
van Xclients, en beide staan ze los van de window-manager) etc etc.
Neemt niet weg dat MacOS qua gebruikersvriendelijkheid/GUI en modulariteit
mooier is dan Unix.
Jeroen
Jeroen Schaap
Oh. Ik heb ze thuis staan. Ik heb ze voornamelijk gevonden in de 'Inside
Macintosh' serie, die *gratis* van het net af te plukken is.... ergens onder
ftp://dev.apple.com (oppassen: extreem langzame verbindingen...).
>> >Als je geen Reader _wil_ gebruiken moet je dat zelf weten. Als ik geen
>> >brouwser wil gebruiken kan ik ook weinig met HTML/CSS. Er zijn maar weinig
>> >computers die geen Reader _kunnen_ gebruiken.
>> Jawel, als HTML netjes geschreven is dan is de broncode ook leesbaar.
>Ik zou zweren dat ik met een DOS adept te maken heb:-)
LOL
>PostScript kan niet on-line gelezen worden zoals PDF, PostScript heeft niet de
>mogelijkheid om fonts in te bedden, zodat het niet echt portable is en niet
>echt cross platform, PostScript is document-georienteerd, PDF is pagina
>georienteerd (je kunt in een bestaand document een pagina invoegen met andere
>fonts en layout) etc. Het november nummer van publish heeft PDF als
>hoofdthema.
Ik dacht je bij postscript juist wel de mogelijkheid had om in een header
alle fonts mee te sturen.... zal wel niet zo zijn dan.
Maar je noemt inderdaad wel een paar significante voordelen op ja.
Jeroen Schaap
>#Layout(?) Convention ofzoiets :-) Ik kan dus gewoon in een lijstje
>#met paginanummers klikken.
>Het nadeel van het gebruik van PostScript zie je pas als je het naar een
>printer wilt sturen. Wij hebben op het werk printers met verschillende
>papierlades voor verschillende formaten. Als je nu een in de USA gemaakte
>PS file naar zo'n 'slimme' printer stuurt, ziet de printer dat het
>papierformaat bv. US Letter moet zijn en gaat dan op zoek naar een
>papierbak met dat formaat. Die vindt ie echter niet, en geeft dus een
>'paper jam' fout. Dan kan je met de hand de printer resetten, de PS file
>alsnog met Acrobat Distiller omzetten naar een PDF document, dan in
>Acrobat Reader de page size instellen en dán pas printen...
Kan ook best met postscript hoor. Ik heb daar wel een CLI-progje voor
(ps2ps).
>#Zoals PDF zich nu als standaard begint op te werpen, zo is postscript
>#dat al jaren in het wereldje van wiskunde/natuurkunde-publicaties.
>#Dat heeft natuurlijk te maken met LaTeX, dat ook nog steeds ongeloof-
>#lijk populair is in dat wereldje. (Terecht!!)
>TeX/LaTeX is inderdaag een prettig systeem om natuurkundige verhandelingen
>in op te maken door de goede support voor formules. Als je de PS file die
>er uiteindelijk uitkomt nu nog eventjes door Distiller haalt om daar een
>PDF van te maken, kun je ook over de hele wereld verspreiden zonder alle
>printers op hol te laten slaan. Het bijkomend voordeel is dat de PDF file
>een stuk kleiner is dan de PS file, čn platform onafhankelijk.
Hee! Da's interessant! Kijk, mijn eerste ervaringen met het genereren van
PDF waren zeer slecht. Deed ik met ghostscript. Het resultaat was dat alle
tex-fonts naar bitmap worden geconverteerd, en als zodanig in de PDF werden
gedumpt. Uiteindelijk was 'ie 10 maal zo groot dan PS.
Noot: Latex is ook fijn voor allerhande documenten. Elke officiele brief
gaat bij mij met LaTeX. In augustus was ik een brief begonnen in Word, maar
daar ben ik, toen de brief langer werd, maar snel van afgestapt. Dat soort
dwalingen bega ik nooit meer.... Als je Latex schrijft, hoef je je totaal
*niet* druk te maken om de opmaak. Gaat volkomen automatisch. Als je in word
tikt, zie de opmaak (als je het heel goed doet) opkomen terwijl je tikt. Is
zeer vervelend.
>Ik voer al jarenlang (en de laatste tijd met succes) een strijd op het
>werk tegen het gebruik van PS files voor distributie. Nu we voor alle
>platformen Acrobat Distiller/Exchange hebben beginnen mijn collega's in te
>zien dat PDF toch wel een fijn formaatje is.
Is dat payware, die distiller?
Ronald Rietman
>Sander Flobbe <flo...@phys.uu.nl>:
>
>> - er geen viewer is voor mkLinux / linuxppc
Is xpdf niet te compileren? En recente versies van ghostscript kunnen ook met
pdf overweg.
>> - het maken van PDF documenten alleen met payware mogelijk is
>
pdfTeX kan het ook, zoals Jeroen al opmerkte.
>
>Ik heb ook wel eens gezocht naar de PDF specs. Ze moeten er zijn, maar
>ik stuitte er niet 1-2-3 op.
<http://www.adobe.com/supportservice/devrelations/PDFS/TN/PDFSPEC.PDF>
Ronald
Steven
>
> Hee! Da's interessant! Kijk, mijn eerste ervaringen met het genereren van
> PDF waren zeer slecht. Deed ik met ghostscript. Het resultaat was dat alle
> tex-fonts naar bitmap worden geconverteerd, en als zodanig in de PDF werden
> gedumpt. Uiteindelijk was 'ie 10 maal zo groot dan PS.
>
> Noot: Latex is ook fijn voor allerhande documenten. Elke officiele brief
> gaat bij mij met LaTeX. In augustus was ik een brief begonnen in Word, maar
> daar ben ik, toen de brief langer werd, maar snel van afgestapt. Dat soort
> dwalingen bega ik nooit meer.... Als je Latex schrijft, hoef je je totaal
> *niet* druk te maken om de opmaak. Gaat volkomen automatisch. Als je in word
> tikt, zie de opmaak (als je het heel goed doet) opkomen terwijl je tikt. Is
> zeer vervelend.
>
> >Ik voer al jarenlang (en de laatste tijd met succes) een strijd op het
> >werk tegen het gebruik van PS files voor distributie. Nu we voor alle
> >platformen Acrobat Distiller/Exchange hebben beginnen mijn collega's in te
> >zien dat PDF toch wel een fijn formaatje is.
>
> Is dat payware, die distiller?
Ja. Kost 410,= bij MailaMac. Daarvoor krijg je:
-Acrobat Distiller, voor het converteren van PostScript bestanden naar PDF,
ook die met hoge resolutie illustraties of EPS-bestanden
-Acrobat Exchange, voor het maken van een bookmark structuur, hyperlinks, het
plaatsen van multimedia elementen, notities etc.
-Acrobat Catalog, voor het maken van een index van meerdere PDF documenten
zodat ze doorzoekbaar worden.
-Acrobat Capture, voor het maken van PDF van een gedrukt document via een scan.
-Acrobat Search, voor het doorzoeken van geindexeerde documenten met
trefwoord, boolean logic, en proximity.
-Acrobat PDFWriter, voor het snel maken van eenvoudige PDF documenten direct
vanuit een applicatie.
-Acrobat Reader, voor het lezen van PDF documenten en om mee te sturen met je documenten.
Ik vind je oordeel over PDF wel héél beslist, vooral als blijkt dat je
Distiller of Exchange nog nooit gebruikt of van dichtbij gezien hebt. Ik zou
me nooit zo'n oordeel over Latex permitteren dat ik nooit gebruik.
> Jeroen
Steven
>
> >Geef eens een url naar zo'n boosdoener, dan zal ik eens kijken.
>
> Oh. Ik heb ze thuis staan. Ik heb ze voornamelijk gevonden in de 'Inside
> Macintosh' serie, die *gratis* van het net af te plukken is.... ergens onder
> ftp://dev.apple.com (oppassen: extreem langzame verbindingen...).
Het duurt me inderdaad een beetje te lang... Ik vermoed dat het probleem hem
zit in het originele formaat dat Apple gebruikte voor die Inside Macintosh
serie. Ik heb die hele serie op CD niet in PDF, maar in Apple's eigen
"DocViewer" formaat. Ik weet niet wat dit precies voor formaat is, maar het
zag er wel tamelijk krakkemikkig uit. Als Apple dit over gezet heeft naar PDF
begrijp ik je problemen...
> >> >Als je geen Reader _wil_ gebruiken moet je dat zelf weten. Als ik geen
> >> >brouwser wil gebruiken kan ik ook weinig met HTML/CSS. Er zijn maar weinig
> >> >computers die geen Reader _kunnen_ gebruiken.
> >> Jawel, als HTML netjes geschreven is dan is de broncode ook leesbaar.
>
> >Ik zou zweren dat ik met een DOS adept te maken heb:-)
>
> LOL
>
> >PostScript kan niet on-line gelezen worden zoals PDF, PostScript heeft niet de
> >mogelijkheid om fonts in te bedden, zodat het niet echt portable is en niet
> >echt cross platform, PostScript is document-georienteerd, PDF is pagina
> >georienteerd (je kunt in een bestaand document een pagina invoegen met andere
> >fonts en layout) etc. Het november nummer van publish heeft PDF als
> >hoofdthema.
>
> Ik dacht je bij postscript juist wel de mogelijkheid had om in een header
> alle fonts mee te sturen.... zal wel niet zo zijn dan.
Voor zover ik weet zijn font er ook weer uit te halen. Dat geeft een copyright
probleem.
> Maar je noemt inderdaad wel een paar significante voordelen op ja.
>
Jeroen Schaap
>Ja. Kost 410,= bij MailaMac. Daarvoor krijg je:
>-Acrobat Distiller, voor het converteren van PostScript bestanden naar PDF,
>ook die met hoge resolutie illustraties of EPS-bestanden
>-Acrobat Exchange, voor het maken van een bookmark structuur, hyperlinks, het
>plaatsen van multimedia elementen, notities etc.
>-Acrobat Catalog, voor het maken van een index van meerdere PDF documenten
>zodat ze doorzoekbaar worden.
>-Acrobat Capture, voor het maken van PDF van een gedrukt document via een scan.
>-Acrobat Search, voor het doorzoeken van geindexeerde documenten met
>trefwoord, boolean logic, en proximity.
>-Acrobat PDFWriter, voor het snel maken van eenvoudige PDF documenten direct
>vanuit een applicatie.
>-Acrobat Reader, voor het lezen van PDF documenten en om mee te sturen met je documenten.
Hmm. Ik zal eens rondsnuffelen of dat pakket hier ergens rondhangt. Ik meen
me te herinneren dat dat wel zo was.
>Ik vind je oordeel over PDF wel hייl beslist, vooral als blijkt dat je
>Distiller of Exchange nog nooit gebruikt of van dichtbij gezien hebt. Ik zou
>me nooit zo'n oordeel over Latex permitteren dat ik nooit gebruik.
Ik heb inderdaad nauwelijks ervaring als producent van PDFs. En als
gebruiker heeft het voor mij wat betreft bepaalde applicaties zijn nut
duidelijk bewezen. Voor andere toepassingen hoe ik mijn ogen open, met enige
kritische kanttekeningen. Overigens, je hebt me al op een aantal nuttige
eigenschappen gewezen.
Groeten,
Kees
jer...@rulffh.medfac.leidenuniv.nl (Jeroen Schaap) quoth:
#>> Is dat payware, die distiller?
#
#>Ja. Kost 410,= bij MailaMac. Daarvoor krijg je:
[...]
#
#Hmm. Ik zal eens rondsnuffelen of dat pakket hier ergens rondhangt. Ik meen
#me te herinneren dat dat wel zo was.
Jeroen,
Ik zie aan je email adres dat je op de Universiteit van Leiden zit. Dat
betekent dat je ook via SURF
<http://www.surfdiensten.nl/licenties/soft.htm> kunt bestellen en dan
krijg je een aardige educatieve korting: het kost dan nog maar f 60,= per
licentie, met een jaarlijkse opslag (eenmalig) van f 250,-.
Neem eens kontakt op met de SURFdiensten kontaktpersoon binnen de UvL. Het
rekencentrum zal wel weten wie dat is.
Nog meer leuke prijzen:
Acrobat stuks f 60,=
After Effects stuks f 525,=
ATM (Adobe Type Manager) Deluxe stuks f 60,=
ATR (Adobe Type Reunion) Deluxe stuks f 80,=
Dimensions stuks f 40,=
Framemaker stuks f 195,=
Framemaker + SGML stuks f 435,=
Framemaker/Unix stuks f 565,=
Framemaker/Unix + SGML stuks f 870,=
Illustrator stuks f 115,=
Pagemaker stuks f 170,=
Pagemill stuks f 80,=
Photoshop stuks f 205,=
Premiere stuks f 170,=
Streamline stuks f 40,=
Ik heb voor m'n Macje op 't werk bijna de hele set besteld. Eindelijk
alles officieel!
Jeroen Schaap
Kees <kees....@nikhef.nl> wrote:
>#
>#Hmm. Ik zal eens rondsnuffelen of dat pakket hier ergens rondhangt. Ik meen
>#me te herinneren dat dat wel zo was.
>Ik zie aan je email adres dat je op de Universiteit van Leiden zit. Dat
>betekent dat je ook via SURF
><http://www.surfdiensten.nl/licenties/soft.htm> kunt bestellen en dan
>krijg je een aardige educatieve korting: het kost dan nog maar f 60,= per
>licentie, met een jaarlijkse opslag (eenmalig) van f 250,-.
Dat ziet er zeer interessant uit. Ook Applesoft:
macOS voor 35! Hmmm
Bedankt voor de link!!
Dennis SCP
> Ik schreef
> > Wat betreft PDF hangen wij Mac gebruikers geheel af van Adobe software.
> > Ik heb het Rhapsody project gevolgt en daar klinken positieve verhalen
> > over PDF software van een andere fabrikant.
>
> O? Welke?
Omni Development heeft volgens mij een PDF lees en schrijf programma, al
sinds de Next tijd.
> > Wij ervaren PDF door Acrobat
> > Reader als log, maar waarschijnlijk ligt er een goed gestructureerd
> > systeem onder dat via de Adobe programma's niet zo goed uit de verf
> > komt.
>
> Hoezo? Adobe heeft beide ontwikkeld toch?
Toch heb ik het idee dat met wat meer intresse in code optimalistie er
veel sneller programma op de Mac zou draaien. Ik heb alleen met Reader
gewerkt en heb het idee dat het niet met veel Mac liefde is gemaakt,
maar dat is natuurlijk een persoonlijke mening.
> > Dit kan met de komst van Mac OS 10 wel eens aangenaam veranderen
> > want Apple heeft natuurlijk niet voor niets voor PDF gekozen. (Ze hebben
> > Display Postscript laten vallen om onder de licensie kosten van Adobe
> > uit te komen)
>
> Niet vanwege de kosten. Apple wil haar Systeem niet afhankelijk maken van een
> technologie die door een ander gecontroleerd wordt. Adobe wil Display
> PostScript niet meer ondersteunen en ook niet verkopen. Apple wilde het kopen.
> Daarom is gekozen voor PDF wat wel een open formaat is.
O ja, zo zat het (Het negatieve effect van het lezen van Advocacy
groepen is dat de dingen die veel geroepen zijn de nieuwsfeiten wel eens
wat overstemmen in het geheugen)
Dennis SCP (weet eigenlijk niet veel van Adobe technologie, ieder is
vrij om dit bericht aan te vullen want in discussie gaan kan ik verder
toch niet.;-)
--
[MS Office 98 Assistant: Uw signature is leeg. Weet u zeker dat u niets
nuttigs aan de mensheid heeft mede te delen?]
Steven
>
> Steven <ste...@sifre.demon.nl> wrote:
> > Ik schreef
> > > Wat betreft PDF hangen wij Mac gebruikers geheel af van Adobe software.
> > > Ik heb het Rhapsody project gevolgt en daar klinken positieve verhalen
> > > over PDF software van een andere fabrikant.
> >
> > O? Welke?
>
> Omni Development heeft volgens mij een PDF lees en schrijf programma, al
> sinds de Next tijd.
Mmm, daar had ik nog niet van gehoord. Wanneer was dat precies, de NeXT tijd?
eind tachtiger, begin negentiger jaren?
> > > Wij ervaren PDF door Acrobat
> > > Reader als log, maar waarschijnlijk ligt er een goed gestructureerd
> > > systeem onder dat via de Adobe programma's niet zo goed uit de verf
> > > komt.
> >
> > Hoezo? Adobe heeft beide ontwikkeld toch?
>
> Toch heb ik het idee dat met wat meer intresse in code optimalistie er
> veel sneller programma op de Mac zou draaien. Ik heb alleen met Reader
> gewerkt en heb het idee dat het niet met veel Mac liefde is gemaakt,
> maar dat is natuurlijk een persoonlijke mening.
Ik heb geen klachten over de snelheid van Acrobat of over de interface. Reader
is niet echt om mee te "werken", maar om mee te lezen.
> > > Dit kan met de komst van Mac OS 10 wel eens aangenaam veranderen
> > > want Apple heeft natuurlijk niet voor niets voor PDF gekozen. (Ze hebben
> > > Display Postscript laten vallen om onder de licensie kosten van Adobe
> > > uit te komen)
Ik sta altijd open voor aangename verrassingen.
> > Niet vanwege de kosten. Apple wil haar Systeem niet afhankelijk maken van een
> > technologie die door een ander gecontroleerd wordt. Adobe wil Display
> > PostScript niet meer ondersteunen en ook niet verkopen. Apple wilde het kopen.
> > Daarom is gekozen voor PDF wat wel een open formaat is.
>
> O ja, zo zat het (Het negatieve effect van het lezen van Advocacy
> groepen is dat de dingen die veel geroepen zijn de nieuwsfeiten wel eens
> wat overstemmen in het geheugen)
>
> Dennis SCP (weet eigenlijk niet veel van Adobe technologie, ieder is
> vrij om dit bericht aan te vullen want in discussie gaan kan ik verder
> toch niet.;-)
Ik heb wel de indruk dat Adobe niet meer primair voor de Mac ontwikkeld. Als
ze geld kunnen besparen door zaken "gelijk te trekken" doen ze dat, met voor
Mac gebruikers onaangename gevolgen. Ik denk bijvoorbeeld aan de vertaling van
menu commado's. Voorbeeld: het eerste menu heet in het engels zowel op de Mac
als in Windows "File", naar Mac 'conventies' werd dit in het nederlands
vertaald als "Archief", in Windows als "Bestand". Sinds Illustrator 7 heet dit
menu zowel op de Mac als in Windows "Bestand", waardoor Illustrator niet meer
zo naadloos integreerd in de nederlandse Mac interface. En dit geld niet
alleen voor dit ene menu... Ik ben dus overgestapt op een compleet engels
systeem. Ik ben wel benieuwd of Illustrator 8 wat dit betreft beter is als 7...
> --
> [MS Office 98 Assistant: Uw signature is leeg. Weet u zeker dat u niets
> nuttigs aan de mensheid heeft mede te delen?]
--
Jeroen Scheerder
> Ik sta altijd open voor aangename verrassingen.
Voila, ClibPDF: <http://www.fastio.com/>.
-- J$ (vee ame toh pleesse)
--
dash dash space
this is my .sig it's not so .big
Steven
Mmm, goed te weten dat ook andere partijen de mogelijkheden van PDF benutten.
I'm not into compiling my own programs though. (Unless someone shows me it's
easy and painless:-).