Plaatjes resize-script

[Verwijderd]

Op het forum zie je vaak dat er geroepen wordt om plaatjes te resizen e.d., maar volgens mij kun je dat makkelijk met een aanpassinkje in het board regelen.
Als je nou bij die img-tags iets van

code:

onLoad="resizePic(this)"

pleurt, en dat dan die functie controleert of de breedte groter is dan 600, en zo ja, dat hij hem dan resizet naar 600, waarbij hij de hoogte-breedte verhouding behoudt.

Je kunt het eventueel ook zo doen dat je ipv een <img>-je overal een <div>je neerzet die een preload-functie aanroept die, als het plaatje groter is dan 600, er gelijk een linkje van maakt wat een nieuw venster opent met daarin het plaatje op originele grootte. Daarvoor hebben we de innerHTML-property van <div>'s

Misschien vinden jullie het overkill, maar ik zou het wel handig vinden, nooit meer posts over layout-verneukende posts

[bazs2000]

Dat is wel leuk maar hoe voorkom je dat je veel serverload krijgt wanneer je een topic wilt zien die vol staat met plaatjes die scriptmatig zijn geresized? Op zich is het wel een leuk idee natuurlijk.

[holoX]

Dat kost veel serverload, vooral met zo'n groot forum
Fok gebruikt ook zoiets, maar dat is javascript dacht ik () en dat werkt dus alleen in IE daar.

[kamerplant]

[img=xxx,xxx] bestaat al. Dat komt toch op het zelfde neer?

Ik vind dat users gewoon niet zo lui moeten zijn en echt moeten resizen zoals ik hier vertelde. Dat doet jouw script niet neem ik aan?
En kost jouw manier ook niet te veel serverload, elke pic moet worden geladen om te controleren hoe groot het is.

[ACM]

Mja, de argumentatie over serverload kan je in deze context wel negeren, dat slaat nergens op natuurlijk

Maar een van de belangrijkste redenen waarvoor men zou moeten resizen is dat men niet 10 plaatjes van 2MB toont, maar 10 van 20KB en dan evt een linkje naar de 2MB versies. Jouw javascript-code doet dat verder niet en dat doel van resizen (imho de belangrijkste) wordt dus niet gehaald.

Verder is het altijd weer een gevecht tussen de programmeur en de browserwereld als je iets in javascript gaat zetten...

[Verwijderd]

Dat scriptje zou inderdaad niet de grootte in B van een plaatje verminderen, het is alleen een Javascriptje (dus niets wat meer serverload zou gebruiken) dat zorgt dat de layout niet verneukt wordt.
Het is dus alleen nuttig voor de layout en lage-resolutie-gebruikers.

[Hahn]

ACM schreef op 27 april 2003 @ 16:04:
Maar een van de belangrijkste redenen waarvoor men zou moeten resizen is dat men niet 10 plaatjes van 2MB toont, maar 10 van 20KB en dan evt een linkje naar de 2MB versies. Jouw javascript-code doet dat verder niet en dat doel van resizen (imho de belangrijkste) wordt dus niet gehaald.

Inderdaad, dat vind ik een stuk belangrijker dan de layout. Zelf heb ik ADSL dus grote plaatjes zijn niet zo héél erg, maar als je 4 MB aan plaatjes moet downloaden ben je toch weer even bezig. Een script die controleert op grote van pics en het dan wel/niet doorlaat zou dan beter zijn. Als je een te groot plaatje post moet je 'm resizen om bijvoorbeeld onder de 300 kb per plaatje te komen

[We Are Borg]

Zou het alleen al niet handig zijn om de layout te sparen ? Dus automatisch resize script. Natuurlijk blijft een plaatje van 2 MB dan nog steeds 2 MB, maar layout blijft dan goed

[intoxicated]

We Are Borg schreef op 27 april 2003 @ 17:26:
Zou het alleen al niet handig zijn om de layout te sparen ? Dus automatisch resize script. Natuurlijk blijft een plaatje van 2 MB dan nog steeds 2 MB, maar layout blijft dan goed

Mja, en dan leg je voor mensen de grens om grote pics te posten nog lager, en wordt het probleem alleen maar groter.

[Azrael]

We Are Borg schreef op 27 April 2003 @ 17:26:
Zou het alleen al niet handig zijn om de layout te sparen ? Dus automatisch resize script. Natuurlijk blijft een plaatje van 2 MB dan nog steeds 2 MB, maar layout blijft dan goed

Nope, zeer slecht idee, want dan zie je ook niet zo snel meer welke foto's te groot zijn.
Breek me de bek niet open over hoe vaak users in GT nog foto's van > 1 MB posten..

[crisp]

tsja, layout verneuking kan je al tegengaan door de containing <table> van de post te voorzien van style="table-layout: fixed". Plaatjes die te groot zijn worden dan gewoon aan de rand afgekapt en zijn dus nog maar deels zichtbaar. Dat is dan misschien voor de plaatjesposter meteen een indicatie dat hij iets niet goed doet

[Positron]

Op de grootte van een plaatje is toch zeker ook wel een restrictie te leggen met behulp van PHP? Want als plaatjes tóch niet groter mogen dan 600*600, dan hoeven ze toch ook niet groter te zijn dan 400kb?

[crisp]

Positron schreef op 27 april 2003 @ 18:47:
Op de grootte van een plaatje is toch zeker ook wel een restrictie te leggen met behulp van PHP? Want als plaatjes tóch niet groter mogen dan 600*600, dan hoeven ze toch ook niet groter te zijn dan 400kb?

Zo werkt dat natuurlijk niet. PHP moet eerst het hele plaatje inlezen voordat hij weet hoe groot het is. Komt er dan dus op neer dat alle plaatjes eerst op de server ingelezen moeten worden voordat hij jouw een topic kan gaan serveren. Dat zal niet veel goeds doen voor het bandbreedte gebruik, en de tijd dat het duurt voordat jij een topic te zien krijgt

[Positron]

crisp schreef op 27 April 2003 @ 18:54:
[...]

Zo werkt dat natuurlijk niet. PHP moet eerst het hele plaatje inlezen voordat hij weet hoe groot het is. Komt er dan dus op neer dat alle plaatjes eerst op de server ingelezen moeten worden voordat hij jouw een topic kan gaan serveren. Dat zal niet veel goeds doen voor het bandbreedte gebruik, en de tijd dat het duurt voordat jij een topic te zien krijgt

Okey, dat is met PHP dus niet mogelijk. Dan houdt het al gauw op

[ACM]

Een andere 'eis' die wij aan de postings stellen is trouwens dat het zo 'schoon' mogelijk moet zijn, dus eigenlijk liever geen javascript, etc.
Zeker met de huidige versie van React is dat niet echt prettig, aangezien voor elke site die op React draait het dan zo geimplementeerd zou moeten worden (ok, beetje overdreven).

Met een volgende versie van React komt daar wel enige verandering in, maar dan nog zie ik het niet echt zitten. Want er zijn af en toe best goede redenen om een te grote afbeelding te posten (zeker als ie binnen de 1024x768 blijft).

[mOrPhie]

Daarnaast: De te versturen data zal je nooit en te nimmer reduceren met javascript. Javascript is nou eenmaal een client-sided script-taaltje. Voor echt goed en netjes server-side resizen van plaatjes, moet je toch met PHP aan de gang. En dát _kan_ wel voor behoorlijke serverload zorgen.

[Janoz]

crisp schreef op 27 april 2003 @ 18:38:
tsja, layout verneuking kan je al tegengaan door de containing <table> van de post te voorzien van style="table-layout: fixed". Plaatjes die te groot zijn worden dan gewoon aan de rand afgekapt en zijn dus nog maar deels zichtbaar. Dat is dan misschien voor de plaatjesposter meteen een indicatie dat hij iets niet goed doet

Probleem is dat dit niet alleen de plaatjes afkapt. In de devschuur wordt nog wel eens een stukje source gepost. Dat een plaatje wat wordt afgekapt maakt natuurlijk niet zoveel uit, maar bij source code is dat en stukje vervelender (en lang niet altijd leesbaarder als er extra enters in worden gezet)..

[Verwijderd]

Janoz schreef op 28 April 2003 @ 10:22:
[...]

Probleem is dat dit niet alleen de plaatjes afkapt. In de devschuur wordt nog wel eens een stukje source gepost. Dat een plaatje wat wordt afgekapt maakt natuurlijk niet zoveel uit, maar bij source code is dat en stukje vervelender (en lang niet altijd leesbaarder als er extra enters in worden gezet)..

Als pref functie misschien

[Snow_King]

ik zie het nut niet echt, want je moet dus nog steeds die 2MB van dat plaatje binnenhalen zoals gezegt wordt.

* Snow_King heeft gewoon fotoalbum @ tweakers.net en die geeft me gewoon een UBB code met een geresized plaatje er in!

[Sassie]

Gewoon grote of bij heel veel plaatjes de link neerzetten ipv het hele plaatje.
Als mensen het plaatje willen zien kunnen ze ook gewoon op de link klikken.

[RM-rf]

crisp schreef op 27 april 2003 @ 18:54:
[...]

Zo werkt dat natuurlijk niet. PHP moet eerst het hele plaatje inlezen voordat hij weet hoe groot het is. Komt er dan dus op neer dat alle plaatjes eerst op de server ingelezen moeten worden voordat hij jouw een topic kan gaan serveren. Dat zal niet veel goeds doen voor het bandbreedte gebruik, en de tijd dat het duurt voordat jij een topic te zien krijgt

niet het gehel plaatje, de grootte is bij bestanden als PNG/GIF en JPEG onderdeel van de eerste header-informatie, je hoeft maar hooguit enkel bytes per plaatje in te lezen; evenals de filesize (ooit afgevraagd waarom clients zaken als 'downloading 23% from 1,067 GB, at 1.4 Kb/s, estimated time remaining .. blah' kunne weergeven?)
maar dan nog, flink wat programmeermoeite en extra serverbelasting vanwege het feit dat mensen onnadenkend te grote plaatjes plaatsen

[crisp]

RM-rf schreef op 28 April 2003 @ 16:51:
[...]
niet het gehel plaatje, de grootte is bij bestanden als PNG/GIF en JPEG onderdeel van de eerste header-informatie, je hoeft maar hooguit enkel bytes per plaatje in te lezen; evenals de filesize (ooit afgevraagd waarom clients zaken als 'downloading 23% from 1,067 GB, at 1.4 Kb/s, estimated time remaining .. blah' kunne weergeven?)
maar dan nog, flink wat programmeermoeite en extra serverbelasting vanwege het feit dat mensen onnadenkend te grote plaatjes plaatsen

Maar sturen alle webservers standaard de filesize informatie in de headers?
Sowieso als ik een plaatje doorstuur via een php scriptje, dan moet ik wel zelf die header erin zetten, anders weet de client niet hoe groot het bestand is, en krijg je ook geen procentuele voortgang te zien. Gaat dus niet altijd op denk ik

[drm]

crisp:
Maar sturen alle webservers standaard de filesize informatie in de headers?
Sowieso als ik een plaatje doorstuur via een php scriptje, dan moet ik wel zelf die header erin zetten, anders weet de client niet hoe groot het bestand is, en krijg je ook geen procentuele voortgang te zien. Gaat dus niet altijd op denk ik

Wat RM-rf volgens mij bedoelt met "headers" is niet de HTTP-headers maar de eerste paar bytes van een bestand. En dat klopt volgens mij wel, want je kunt bijvoorbeeld in de headers van een GIF bestand ook de palette uitlezen. Daarvoor hoef je niet het hele gif-bestand uit te lezen (for example).

Overigens denk ik niet dat progress-bars van browsers werken volgens de informatie in het bestand, maar eerder volgens de "Content-length" HTTP - header De headerinformatie in een bestand zelf is tenslotte niet gestandaardiseerd ('t zou in theorie op elke offset kunnen staan die je maar wenst ), maar HTTP is wel een standaard

_{irritant, he, die woorden die meerdere dingen kunnen betekenen}