Websites (incl. got) steeds vaker een dunne balk.

[Verwijderd]

Er is niemand die je tegenhoud om je eigen CSS te schrijven en deze voor GoT te gebruiken in Mozilla

Dat de layout niet meeschaalt is naast dat het een design beslissing kan zijn, ook mogelijk te wijten aan het feiten dat er aan de rechterkant van tweakers.net een skyscraper kan komen te staan. Daarvoor houd je dan ruimte vrij.

Verder vind ik persoonlijk de tweakers.net layout veel prettiger om te lezen, juist omdat er rustruimte inzit. Bij Neowin is het een drukke plaat.

[Verwijderd]

Om jullie er nogmaals aan te herinneren: denk niet alleen in fysieke scherm groottes, maar ook aan de DPI. Tot nu toe blijft dat (binnen een bepaalde marge) redelijk gelijk voor desktop schermen of ze nu groot of klein zijn, maar je ziet dat nu al langzaam veranderen.

Ook al heeft 10% van de bezoekers een scherm met een hogere DPI, dan betekent dat dat toch een significant aantal mensen naar een suboptimaal scherm zit te kijken. Als een klant van ons 10% bezoekers heeft de IE5.0 draaien (afgeleid uit zijn of haar statistieken), dan moeten wij daar in ons ontwerp rekening mee houden. Niet leuk, want IE5.0 compatible zijn is gewoon rot.

Bij hoeveel procent gebruikers met een hogere resolutie en/of DPI gaat tweakers de layout aanpassen? 20%? 30%? 40%? Als er op een gegeven moment niet meer 1 overweldigend dominantie resolutie / DPI is (zoals nu 1024*768@17" CRT), meer een heel scala, dan kom je met je design gewoon niet meer weg door voor 1 resolutie alles te bouwen.

Als tussenweg ipv de volledig vloeibare layout kun je nog wel 3 standaard layouts maken, en daar de gebruiker tussen laten schakelen.

[Verwijderd]

Dan kom ik weer terug op het verhaal met afbeeldingen, dat is momenteel nog een shitload aan werk om DPI afhankelijk te maken. Denk jij daar dan ook even aan, ik neem aan dat de offerte dan ook een tikkeltje hoger kan, of wordt daarvan ook al verwacht dat dat standaard als service geleverd wordt? Of laten we vooral veel tijd steken in meerdere layouts, die je allemaal kunt onderhouden, aanpassen en initieel uit de grond stappen. Dank u liever niet...volgende advies graag.

Die dynamische layouts zijn leuk voor de duizend in een dozijn css sites die puur via kleurvlakken werken, maar pas dat eens toe op een rich media interface. Echt niet dat je daar vrolijk van wordt. Niet als ontwikkelaar, designer, en ook niet als de persoon die er voor betaald of moet gaan betalen.

[ Voor 48% gewijzigd door Verwijderd op 07-03-2005 13:21 ]

[crisp]

De vraag is in hoeverre je daar als webdesigner allemaal nog rekening mee kunt blijven houden. Je zou ook kunnen stellen dat de meeste browsers op dit moment nog niet voldoende features bieden om dingen af te stemmen op grotere resoluties en/of hogere DPI's

[Verwijderd]

m.a.w. laten wij als webdesigners maar heel hard gaan bidden dat er *nooit* een hogere DPI zal komen, en ALS die dan ooit komt dat ie dan de huidige IN EEN KLAP wegvaagt. Als het langzaam gaat, dan zal er een moment komen dat beide DPIs een groot markaandeel hebben (zeg 40% wat nu standaard is, 40% de nieuwe, en 20% een scala aan anderen).

Wat gaan wij dan doen? We zijn dus klaarblijkelijk niet in staat om meerdere DPIs te ondersteunen, dus kiezen er @random eentje?

Gelukkig is die tijd nog niet aangebroken. Maar mocht dat ooit gaan gebeuren (signalen in markt wijzen er wel op), dan zullen veel webdesigners van nu er waarschijnlijk het bijltje bij neer moeten gaan gooien...

crisp schreef op maandag 07 maart 2005 @ 13:19:
De vraag is in hoeverre je daar als webdesigner allemaal nog rekening mee kunt blijven houden. Je zou ook kunnen stellen dat de meeste browsers op dit moment nog niet voldoende features bieden om dingen af te stemmen op grotere resoluties en/of hogere DPI's

Dat is natuurlijk waar. Veel van onze problemen komen ook voort uit simpelweg de tekortkomeningen van HTML. Plaatjes wordt vooral als probleem genoemd. Opera kan deze wel mee scalen, de meeste (alle?) andere browsers niet. Images, zeker die met veel kleur overgangen ( 'foto realistische' afbeeldingen), scalen betrekkelijk goed. Beter zou het worden als SVG standaard gebruikt zou worden voor de wat abstractere afbeeldingen, vooral dingen met harde, schuine lijnen, scalen slecht via een 2D scaler.

[ Voor 39% gewijzigd door Verwijderd op 07-03-2005 16:07 ]

[Verwijderd]

Het kan nog altijd erger dan got hoor. Got is nog niets eens de grootste ramp. Ik doelde eigenlijk meer op websites in het algemeen. Dat je het een paar jaar geleden eigenlijk nooit zag, en dat het nu steeds meer een trend aan het worden is: enkele dunne gecentreerde balken met tekst op je scherm met er omheen helemaal niks. Het viel me gewoon op dat ik dat steeds meer en meer zie.

Zie bijvoorbeeld de website:

http://www.hometheaterblo...er/2004/11/true_hdtv.html

Op mijn 17"@1280*1024 is de gehele content van de site slechts 46% van de breedte van mijn scherm. Dit lijkt wel een ontwerp voor een 640*480 resolutie.

[Verwijderd]

Dat is het verschijnsel wat zijn intrede deed toen CSS layouting populairder werd.

[Clay]

Die smalle en vaak minimalistische "weblogdesigns" zijn gewoon de zoveelste trend die vanzelf weer plaats gaat maken voor wat anders. Het probleem ervan zie ik trouwens niet zo. De tekst is prima leesbaar, tenzij je een te kleine monitor met een te hoge resolutie hebt maar dat is geen nieuw probleem.

Als minderheid zou ik me dan ook niet op de borst gaan kloppen hoe vooruitstrevend ik ben en dat de rest van de wereld gek is omdat ik met mn hoge resolutie - en dus kunstmatig hogere dpi - geen site meer fatsoenlijk lezen kan. 1280*1024 is bovendien niet geschikt voor normale monitoren; het vervormt je beeld.

leeko
Dat is natuurlijk waar. Veel van onze problemen komen ook voort uit simpelweg de tekortkomeningen van HTML.

HTML heeft niets met presentatie te maken, en dus niets met dpi problemen of de geniaalheid van svg.

[Verwijderd]

HTML heeft niets met presentatie te maken

HTML + CSS dan

Of eigenlijk meer algemeen "een webpagina". De combo HTML/CSS leent zich wel voor layouten, maar niet goed voor scalen. Tegelijk een auto-layout doen EN scalen werkt zowieso niet. Als je de beschikbare ruimte voor een pagina vergroot, wat moet de browser dan doen? Overnieuw een layout maken of scalen?

Voor HTML zou dit natuurlijk layouten moeten zijn, waarbij je scalen via een aparte knop doet. Nu hebben de meeste browsers een font-size button of menu item. Deze heeft jarenlang goed gewerkt als full page scaler (hoewel het dat eigenlijk niet is), maar met de huidige 'verticale balk' designs werkt dat dus niet meer.

Opera heeft het schijnbaar begrepen, maar ook andere browsers zouden deze trend moeten signaleren en erop in spelen. Nog beter zou het zijn als er wel een expliciete scale support zou komen. Een flash plug-in kan hier heel eenvoudig op reageren, en een HTML renderer zou als reactie nieuwe images kunnen opvragen in een hogere resolutie (zeg maar zoals mip-mapped textures in 3D omgevingen).

Zeg niet dat zoiets nooit zal kunnen. De allereerste generatie webdesigners was er nog niet eens zeker van dat de <img> tag in HTML zou komen

[RM-rf]

Verwijderd schreef op maandag 07 maart 2005 @ 16:04:

Beter zou het worden als SVG standaard gebruikt zou worden voor de wat abstractere afbeeldingen, vooral dingen met harde, schuine lijnen, scalen slecht via een 2D scaler.

Ik denk echt niet dat SVG bedoeld is voor de presentatie van informatieve tekst-gebaseerde data...
zeg nu zelf, denk je dat zulke transformaties, text-on-paths, filters/lichteffecten, masks e.d. een tekst 'leesbaarder' maken?

Vormgeving binnen HTML is voornamelijk een vorm van 'typografie', oftewel het leesbaar presenteren van tekstuele informatie ...
Hierbinnen is het grootste probleem dat je als HTML-typograaf een enorm grote bepalende factor overlaat aan de lezer, die vaak zelf de ruimte heeft om een beperkt aantal lettertypes geinstalleerd te hebben, die zelf de ruimte heeft om zijn scherminstellingen te kiezen: schermgrootte, resolutie en contrastinstellingen ...

De gevolgen hiervan bewijzen voornamelijk het nut van een typografische vormgever, want nooit hebben zoveel mensen puur fysieke problemen met de leesbaarheid, krijgen hoofpijn/ vermoeide ogen...
Maar juist dat komt voornamelijk omdat de gebruiker zelf uiteindelijk helemaal niet zo goed in staat is dit voor zichzelf te bepalen, niet gebruiksvriendelijkheid is de leidraad in zijn keuzes, maar eerder kortzichtige en foute aannames, als zou hij zijn scherm onder alle voorwaarden gewoon altijd op de grootst mogelijke resolutie moeten afstellen ...
Of de contrastinstellingen die wat hem betreft voordeel hebben bij het 's nachts spelen van spelletjes Doom of Quake ... maar die kennelijk overdag het onmogelijk maken nog teksten te lezen ...

dan zou je daaromheen alsnog vervolgens technische omwegen tegenover gaan stellen, als automatisch schaalbare websites, die dan alsnog een aloud 480x600 beeld presenteren op schermen met een 1200x1600 instellingen ... waarbij het beeld netjes geschaald wordt ... Maar waar ben je dan nog mee bezig?

[Verwijderd]

RM-rf schreef op dinsdag 08 maart 2005 @ 11:31:
[...]


Ik denk echt niet dat SVG bedoeld is voor de presentatie van informatieve tekst-gebaseerde data...
zeg nu zelf, denk je dat zulke transformaties, text-on-paths, filters/lichteffecten, masks e.d. een tekst 'leesbaarder' maken?

Als ik de tekst zo lees dan wordt volgens mij bedoeld dat slechts bitmaps (images, plaatjes) gedeeltelijk vervangen worden door SVG. Bitmaps zijn namelijk de enigste onderdelen van je page die niet (mooi) mee kunnen scalen. Fonts zijn bijna altijd vector gebasseerd en vlakken en dergelijke scalen ook altijd mooi mee.

ls automatisch schaalbare websites, die dan alsnog een aloud 480x600 beeld presenteren op schermen met een 1200x1600 instellingen ...

Als je puur in informatie denkt dan heb je helemaal geen 480*600 beeld en zul je ook nooit zitten met het probleem van 1200x1600 instellingen. Idealiter maak je een layout binnen een bepaalde gebied. Gegeven een bepaald aantal pixels per karakter zou je hier een bepaald aantal pixels voor nodig hebben, maar dit aantal pixels per karakter weet jij helemaal niet. Dat is namelijk een user setting. Is het aantal pixels per karakter hoger, dan heb je dus meer pixels in de breedte nodig voor je totale pagina. Voor users met een hogere PPI voor hun scherm komt de layout dan nog steeds precies overeen met die van users die een lagere PPI hebben.

DTP werkt ook zo. De echte resolutie van het drukwerk komt absoluut niet overeen met wat de designer op haar scherm ziet. Toch komt de layout wel exact overeen. Dit komt omdat DTP'er helemaal niet in pixels denken, maar in logische units.

Zeker voor het web is het gaan denken in pixels een slechte ontwikkeling. Ten eerste zou informatie voor langere tijd inzichtbaar moeten zijn. De PPI die nu gelden, hoeven helemaal niet meer over 10 jaar te gelden. Gaat iedereen het design van oude (mischien alleen nog maar in caches voorkomende) pages aanpassen? Natuurlijk is got dynamisch en staat het layout design los van de data die in de DB staat, maar toch...

Juist web clients kunnen heel gevarieerd zijn en zullen alleen maar gevarieerder worden. Door in pixels te gaan denken druk je jezelf toch in hoekje. Wij zijn er met z'n allen toch wel over uit dat je niet je web pages IE-only moet gaan maken, ondanks dat de statistieken toch wel aangeven dat eigenlijk bijna iedereen alleen maar IE gebruikt. Je weet gewoon dat dit moreel gezien geen goede zaak is. Designers zullen ook moeten gaan inzien dat voor pixels designen op het web eigenlijk niet natuurlijk is.

[ Voor 60% gewijzigd door Verwijderd op 08-03-2005 13:26 ]

[Verwijderd]

Verwijderd schreef op dinsdag 08 maart 2005 @ 11:29:

Henk, begrijp je zelf wel wat je schrijft? Seriously...

Schalen op het web is technisch prima mogelijk, mits de browsers een stapje verder zijn in hun ondersteuning. De identifiers "em" en "%" zijn er niet voor niets.

Waar de problemen komen is het moment waarop je koeieletters op je scherm krijgt met font size 48 maar het logo van het bedrijf nog steeds 32x32 groot is.

Op dat moment zul je dus ook moeten kijken naar het vergroten van afbeeldingen, desnoods met relative waarden, en dan heb je dus een probleem want dan heb je de keuzes tussen verschillende afmetingen media of tussen het schalen van die afbeelding met al het kwaliteitsverlies inbegrepen. Dat laatste accepteerd geen enkele klant, die eerst wel, maar dat betekend voor de ontwikkelende/designende partij een takkewerk.

[Not Pingu]

Verwijderd schreef op dinsdag 08 maart 2005 @ 13:05:
DTP werkt ook zo. De echte resolutie van het drukwerk komt absoluut niet overeen met wat de designer op haar scherm ziet. Toch komt de layout wel exact overeen. Dit komt omdat DTP'er helemaal niet in pixels denken, maar in logische units.

Het verschil tussen DTP en webdesign is wel zo allejezus groot!
Ten eerste bepaal je bij DTP zelf het medium waarop je creatie te zien zal zijn; grootte van het papier etc staan vast en daar ontwerp je voor.

In hoeverre zijn centimeters wel logische eenheden en pixels niet? Een DTP'er denkt ook niet in procenten ofzo, die maakt gewoon een design dat zoveel centimeter breed is.
Het verschil is dat 1 cm voor een DTP'er altijd 1 cm is. Voor een webdesigner zijn 100pixels op het ene beeldscherm/resolutie breder dan op het andere.

[Verwijderd]

Verwijderd schreef op dinsdag 08 maart 2005 @ 13:25:
[...]


Henk, begrijp je zelf wel wat je schrijft? Seriously...

Schalen op het web is technisch prima mogelijk, mits de browsers een stapje verder zijn in hun ondersteuning. De identifiers "em" en "%" zijn er niet voor niets.

Waar de problemen komen is het moment waarop je koeieletters op je scherm krijgt met font size 48 maar het logo van het bedrijf nog steeds 32x32 groot is.

En begrijp jij dan wel wat ik schrijf? Ik snap ook wel dat lezen op got door de geringe breedte moeilijk voor je is, maar... (ok, dat was een grapje )

Serieus, ik stel toch dat het bitmap gebeuren een probleem is, en dat daar binnen de HTML standaard een oplossing voor gezocht moet worden. Persoonlijk zie ik wel iets in het specificeren van een bitmap in een relatieve eenheid, waarbij de browser dan aan de server een image request in een size die zo dicht mogelijk matched. De server kan dan voor elke image meerdere sizes hebben. Zoals ik al schreef (en waar je mischien overheen las?), 3D designers gebruiken een soortgelijke techniek al voor textures.

Voorts zou gedeeltelijk vervangen van bitmaps door vector images ook een mogelijke oplossing zijn. Mischien dat SVG daarvoor gebruikt kan worden. Natuurlijk zijn niet alle images geschikt voor vectorisatie. Echte foto's zijn dat niet, maar bedrijfs logo's veelal weer wel.

maar dat betekend voor de ontwikkelende/designende partij een takkewerk.

Zie het als een uitdaging in je profesionele carrierre.

[Mud.Starrr]

Mischien een 2e beeldscherm speciaal voor GOT

[Verwijderd]

Gunp01nt schreef op dinsdag 08 maart 2005 @ 13:34:
[...]
In hoeverre zijn centimeters wel logische eenheden en pixels niet?

Omdat centimeters als logische eenheid kunnen mappen naar pixels. Of je onderliggende media nu 96DPI heeft, 600DPI, of 3600DPI, maakt helemaal niks uit. Sterker nog, het ontwerp an-sich is helemaal niet pixel afhankelijk. Grafieken kunnen net zo goed door een plotter gedaan worden waarbij je uberhaupt geen enkele pixel hebt.

Omdat je dus een indirectie level hebt, spreek je van een logische eenheid itt een fysieke.

[Not Pingu]

Verwijderd schreef op dinsdag 08 maart 2005 @ 13:35:
De server kan dan voor elke image meerdere sizes hebben. Zoals ik al schreef (en waar je mischien overheen las?), 3D designers gebruiken een soortgelijke techniek al voor textures.

Game designers bedoel je dan.
Maar het probleem zit niet in HTML, het probleem zit hem in het feit dat bitmaps in pixels gemeten worden. Tekst is schaalbaar, HTML elementen zijn schaalbaar, bitmaps en andere pixelafbeeldingen niet.

[Verwijderd]

Gunp01nt schreef op dinsdag 08 maart 2005 @ 13:46:
[...]
Game designers bedoel je dan.

Beetje offtopic: Dacht ik eerst ook altijd, maar tegenwoordig woorden ook voor meer profesionele 3D toepassingen textures gebruikt, hoewel wat minder intensief dan in games.

Maar het probleem zit niet in HTML, het probleem zit hem in het feit dat bitmaps in pixels gemeten worden. Tekst is schaalbaar, HTML elementen zijn schaalbaar, bitmaps en andere pixelafbeeldingen niet.

Precies. Dat is de hele issue. Daarom zou daar ook wat op gevonden moeten worden...

[Clay]

Een face in een game bevat ook gewoon een geprojecteerde bitmap texture, eventueel een aantal lagen detail-textures eroverheen voor mooie closeups en afgeserveerd door de grafische kaart inc hippe lighting-, shaders-, bump en [watnietal]maps. Ter info, Een game als UT2k4 mapt ook gewoon een texture van 1024 x 1024 px op een face van 256x256 units. Op je scherm levert dit misschien meer/mooier detail op, het blijven evengrote pixels met dezelfde lage dpi.

Dat is niet echt te vergelijken met de kale resize waar browsers images mee mishandelen als ze een andere dan hun originele grootte krijgen.

[Verwijderd]

Clay schreef op dinsdag 08 maart 2005 @ 14:13:
Een face in een game bevat ook gewoon een geprojecteerde bitmap texture

Deze kunnen wel in verschillende resoluties klaargezet worden. Meestal heb je een serie textures die telkens de helft van de resolutie zijn van de vorige. Voor de uiteindelijke projectie maak je een keuze welke bron texture het dichts kwa resolutie bij je doel object zit.

[Mithrandir]

henk_DE_man: waar je het over hebt is toekomstmuziek. Iedereen wil het, maar niets kan het.

Tot de tijd dat we geen last meer hebben van pixel-graphics, of in elk geval niet goede resize-ondersteuning van browsers, kun je fluiten naar je automatisch-schalende websites.

Of je moet, zoals eerder gezegd, een browser als opera gebruiken met scale functies.

Volgens mij heeft iedereen z'n punt wel duidelijk gemaakt.

[Matias]

Verwijderd schreef op dinsdag 08 maart 2005 @ 13:35:
[...]


En begrijp jij dan wel wat ik schrijf? Ik snap ook wel dat lezen op got door de geringe breedte moeilijk voor je is, maar... (ok, dat was een grapje )

Serieus, ik stel toch dat het bitmap gebeuren een probleem is, en dat daar binnen de HTML standaard een oplossing voor gezocht moet worden. Persoonlijk zie ik wel iets in het specificeren van een bitmap in een relatieve eenheid, waarbij de browser dan aan de server een image request in een size die zo dicht mogelijk matched. De server kan dan voor elke image meerdere sizes hebben. Zoals ik al schreef (en waar je mischien overheen las?), 3D designers gebruiken een soortgelijke techniek al voor textures.

Een bitmap in een relatieve eenheid specificeren; met dure woorden zeg je dus eigenlijk dat de oplossing is dat het plaatje relatief geschaald word naar de opgegeven schermresolutie. Erg fijn lijkt me dat, dan zijn er dus 2 opties voor zo'n server,
1. Een plaatje in ongeveer dezelfde afmetingen word geselecteerd en geladen.
2. Het plaatje zal worden gescaled.

Ik weet niet of je weleens wat doet aan non-print ontwerpen maar het word allemaal heel leuk om een plaatje in 8 verschillende resoluties te gaan opslaan omdat je dan ondersteuning hebt voor verschillende pc's

Voorts zou gedeeltelijk vervangen van bitmaps door vector images ook een mogelijke oplossing zijn. Mischien dat SVG daarvoor gebruikt kan worden. Natuurlijk zijn niet alle images geschikt voor vectorisatie. Echte foto's zijn dat niet, maar bedrijfs logo's veelal weer wel.

Ook leuk bedacht, is natuurlijk een utopische oplossing aangezien je dan het complete non-print ontwerpconcept moet gaan herschrijven.

Serieus henk, de enige oplossing die jou je de comfortabele browse-ervaring zal geven zijn schermformaten die niet meer gebruik maken van pixels, maar van vectoren.

Zodra er een vectorberekening + engine is uitgevonden die afbeeldingen kan omzetten naar een berekenbaar vectorenbestand is oneindig schalen natuurlijk mogelijk. JPG werkt bijvoorbeeld met miniscule gradients, dit principe zou je ook kunnen toepassen bij vectoren, en dan tijdens het schalen van afbeeldingen nieuwe gradients tussen de bestaande gradients kunnen berekenen. Natuurlijk neemt de filesize afhankelijk van de uitvergroting exponentioneel toe, aangezien een 4pixel afbeelding bij een vergroting van factor 2 een 16voudige gradient + alphacontrol zal moeten hebben. Daarnaast zal een plaatje van 100x100 pixels nooit schaalbaar zijn tot 1000 x 1000 pixels. Het principe word al toegepast in Photoshop; Als je een afbeelding uitvergroot worden er gradients berekend tussen de ontbrekende en niet aansluitende pixels om een zo natuurlijk mogelijk resultaat te geven

Verder moeten die schermen dus gebruik maken van lichtstralen in plaats van punten, zodat je een perfecte 0 resolutie krijgt. Vergeet natuurlijk niet de hardware, om deze vectoren browse-baar te kunnen berekenen zal je wel een processor met de rekenkracht van een IBM Blue Gene Supercomputer nodig hebben om de nodige teraflops in luttele nanoseconden te berekenen.

Met andere woorden, een compleet schaalbare wereld is mogelijk, het zal alleen eventjes duren. Verder heb ik al eerder vermeld in dit topic dat ik een website schalen naar het formaat van een 23" beeldscherm absoluut belachelijk vind. Wie wilt er nou een website lezen op een breedte van 1680? Ze bouwen krantenkolommen toch ook niet in de volle breedte van een a3 simpelweg omdat het platform a3 is?

Hopelijk snap je een beetje wat ik zonet allemaal schreef en zie je in dat wat je zegt niet iedereen als logisch in de oren klinkt.

[T-MOB]

matiasjansen schreef op woensdag 16 maart 2005 @ 22:34:
[...]

Je overdrijft hier nogal... understatement

Henk wil gewoon "normaal" kunnen browsen op een relatief groot scherm. Opera laat op dit moment inzoomen tot 1000% toe. En toegegeven dat ziet er niet uit. Twee- of driehonderd procent is daarentegen nog prima te bekijken en wat mij betreft een prima oplossing voor Henk's über-grote scherm. Dit kan zonder een Blue Gene in no time
En jah dit is waarschijnlijk gewoon scaling (in elk geval voor wat betreft de afbeeldingen, text zal wel écht groter gerendered worden). Maar who cares... 1024x768 ziet er ook acceptabel uit op een 21" scherm, iig voor een website. Waar het om gaat is dat een website die op 800x600 pixels is gebouwd onleesbaar is op 1920x1440 pixels. Een goede manier om relatieve waarden te gebruiken is wat mij betreft dus gewoon welkom - en vectoren zijn daarbij de utopie...

*T-MOB denkt dat kleine schermen (like gsm-style) het echte probleem gaan vormen...

[snooze]

ik heb de ideale (zei het omslachtige) manier om om de scaling heen te werken je gebruikt een pdf printer driver om alles naar een pdf te printen en dan ga je met acrobat alles lekker lezen je kunt inzoomen zover als je wilt en het blijft scherp (fok lezen op de bank met een 30"tft)

[Paradoxia]

Verwijderd schreef op maandag 28 februari 2005 @ 22:35:
[...]


Je hoeft helemaal niet in pixels te denken, maar kan dat beter in logische eenheden doen. Denk in objecten en percentages van je scherm. Ondanks dat word documenten net zoals HTML ook 'wrappen' kan ik die gewoon wel perfect scalen zodat het precies past op mijn scherm. Met PDF lukt dat helemaal perfect, en met 3D games ook.

Dat je met een klein font een gehele kolom op 1 regel krijgt als je deze op een 1920 resolutie zet lijkt me logisch, maar daarvoor is het 'grote font' knopje uitgevonden he? Zo kun je precies zelf bepalen hoeveel tekst je op een regel wil. Niet iedereen heeft dezelfde voorkeuren.


[...]


Doe ik ook niet. Met mijn vorige scherm (Nec p750) heb ik zelfs zo'n 7 jaar gedaan. Niet iedereen die vandaag een scherm kocht, kocht er precies vorig jaar ook eentje. Tussen de groep kopers van vandaag zitten net zo goed mensen voor wie het het eerste scherm is, die 3 jaar geleden er eentje kochten, 4 jaar geleden, 5 jaar, enz...

Meneertje,

Als de tijd komt dat iedereen een mega-scherm heeft worden de websites wel aangepast. Ik zit op het moment op een 1280*1024 en het hoeft van mij nog niet echt groter, zelfs in applicaties zoals Maya en Photoshop. Ik heb hier ook een 19" staan die hoger gaat, en eerlijk gezegd vind ik dat maar behoorlijk kut werken.

[Verwijderd]

Dat is best wel een hele bruikbare oplossing zeg!

Ik heb het net geprobeerd bij fok en het werkt eigenlijk super. Even de headers in firefox uitzetten, de margins wat verkleinen en je hebt een zeer goed leesbaar geheel. Op mijn 17"@1024*786 kan ik got op 220% zetten, zonder dat het aantal karakters per regels gaat veranderen of dat allineas verschuiven en dergelijke.

Alleen merk ik dat Acrobat distiller de licht grijze achtergrond niet overneemt. Maakt niet zoveel uit natuurlijk.Op deze manier kun je niet meer browsen, maar is wel redelijk ideaal om een (lange) web page gewoon even rustig helemaal te lezen (ipv het 'scannen' wat je normaal op een webpagina doet).

Het zou mischien wel zijn om voor zoiets een firefox plugin te maken die net even de stap om na CTRL-P op ok te clicken overslaat en het PDF bestand in de temp dir zet.

[flowerp]

Voor Safari onder Mac OS X werkt het ook super. Stom dat ik hier niet zelf aan had gedacht!

Het werkt zelfs nog makkelijker dan met Firefox en Xp. Apple-p en dan op voorvertoning (nl) of preview (eng) clicken en na enkele seconde staat de PDF voor je neus. Systeem verzocht zelf automatisch de temp file en het opstarten van acrobat reader.

Wel zou het mooi zijn als je via zo'n plug-in per site kon instellen waar de verticale balk zich bevind en wat het zoom percentage moet zijn. Om got een beetje normaal te lezen (dwz, dat het dunne verticale balk effect volledig weggewerkt is), moet ik arcrobat op 400% instellen (1024 op 15" scherm, def 100% is kleiner dan origineel vandaar die hoge zoom), maar voor theserverside is dit weer een andere percentage, etc.

Ik denk dat zo'n plug-in wel populair kan worden. Ik zie het al voor me:

Anti-vertical bar plug-in.

Are you tired of the fact that nowadays every web-designer wishes to squeeze a web-site's content into a narrow vertical bar utilizing no more than 60% of your screen? Now's your chance to fight back and reclaim your screen's real estate. Anti-vertical bar plug-in does away with the wasted empty space and show's the actual site content as it should be showed: in the full width of your browser windows.
Give all those 'narrow' minded (pun intended!) web-designers a punch back and install Anti-vertical bar today.

Anti-vertical bar - you decide how to view you data!


(iedereen die inderdaad zo'n plug-in wil maken mag deze tekst vrij gebruiken )