[PHP] Hoogte tekst berekenen

[Verwijderd]

Voor een applicatie in PHP moet ik de hoogte van een stuk ingegeven tekst in mm berekenen omdat die waarde van belang is voor het bepalen van de prijs. Wanneer iemand namelijk een advertentie plaats kan ik die aangeven in hoeveel kolommen die moet komen - breedte heb ik dan al dus-, maar de hoogte is afhankelijk van de hoeveelheid tekst die diegene plaatst.

Hoogte d.m.v. Javascript berekenen is geen optie omdat je het dan clientside is en dus per persoon kan verschillen. Denk bijv. aan een hogere of lagere DPI instelling. Heeft iemand een idee hoe dit wel te doen is?
Wegschrijven in JPG en dan gaan rekenen?

[Gomez12]

Weet je niet gewoon simpelweg hoe hoog een regel is?

Als je breedte al hebt dan kun je precies uitrekenen hoeveel regels het kost en dan is het simpelweg : aantal regels * regelhoogte.

[Verwijderd]

Misschien handig om te weten:
- hoe groot is het font? of kan er gekozen worden?
- hoe groot is de advertentie? zijn er verschillende maten?
- wat mag een adverteerder allemaal wijzigen en wat niet?
- waar wordt de advertentie geplaatst? print/web/anders?

Wanneer je namelijk deze dingen weet kun je al van te voren definiëren wat de waarden zijn.

Een adverteerder hoeft echt geen pixel perfect voorbeeld te hebben (tenzij voor web, maar dan maakt een DPI instelling geen verschil). En bij print dan kun je een indicatie geven (mm => px) en na afloop renderen met GD2 of ImageMagick en dit tonen aan de gebruiker. Eventueel zou het je zelfs naar een PDF kunnen zetten die een gebruiker kan downloaden om het te bekijken (op papier).

Gomez12 schreef op dinsdag 19 juli 2011 @ 09:05:
Weet je niet gewoon simpelweg hoe hoog een regel is?

Als je breedte al hebt dan kun je precies uitrekenen hoeveel regels het kost en dan is het simpelweg : aantal regels * regelhoogte.

Maar hoe hoog is een letter en hoe veel witruimte zit er tussen de regels?
En daarnaast; hoeveel leestekens kunnen er op één regel? Want hoe breed is een letter?


Ik denk dat dat de TS of meer informatie moet verschaffen over de mogelijkheden die hij wilt aanbieden, of zich mag gaan verdiepen in typografie (en de problemen bij gebruik ervan).

[ReTechNL]

In je CSS kan je de regel hoogte bepalen. als je deze waarde vermenigvuldigd met het aantal regels dan krijg je de juiste gegevens. eerst moet je het gemiddeld aantal woorden op een regel bepalen. en daarna de woorden tellen.

deel het totaal aantal woorden door de gemiddeld aantal woorden per regel.
Nu heb je in grote richtlijnen het aantal regels. vervolgens doe je dit vermenigvuldigen met het aantal mm dat je heb aangegeven voor regelhoogte in je css. dit kan je eventueel static invullen zodat dit niet beïnvloedbaar is.

Heb al ruim een halfjaar geen PHP gedaan dus ik kan het mis hebben.

Groeten,
Jan

[Woy]

Verwijderd schreef op dinsdag 19 juli 2011 @ 08:50:
Hoogte d.m.v. Javascript berekenen is geen optie omdat je het dan clientside is en dus per persoon kan verschillen. Denk bijv. aan een hogere of lagere DPI instelling. Heeft iemand een idee hoe dit wel te doen is?
Wegschrijven in JPG en dan gaan rekenen?

Hoogte is iets dat bij de representatie hoort, en dus zul je moeten berekenen als je het gaat representeren. De vraag is dus hoe je het uiteindelijk gaat weergeven? Is dat in een plaatje? Dan zul je moeten kijken in de library waarmee je het plaatje gaat maken. Is dat in HTML, dan zul je het toch "clientside" moeten doen ( Waar je natuurlijk wel zelf een client omgeving kunt nadoen, maar dan heb je natuurlijk geen zekerheid hoe het uiteindelijk bij de gebruiker echt word. )

[418O2]

janstaal schreef op dinsdag 19 juli 2011 @ 09:15:
In je CSS kan je de regel hoogte bepalen. als je deze waarde vermenigvuldigd met het aantal regels dan krijg je de juiste gegevens. eerst moet je het gemiddeld aantal woorden op een regel bepalen. en daarna de woorden tellen.

deel het totaal aantal woorden door de gemiddeld aantal woorden per regel.
Nu heb je in grote richtlijnen het aantal regels. vervolgens doe je dit vermenigvuldigen met het aantal mm dat je heb aangegeven voor regelhoogte in je css. dit kan je eventueel static invullen zodat dit niet beïnvloedbaar is.

Ik kan je uit zeer recente ervaring vertellen dat dit voor geen kloten werkt (sorry voor mijn taal, maar dit heeft mij zoooveel frustratie opgeleverd).

je kan hier echt niets concreets over zeggen. Je kan hoogstens uitrekenen hoeveel tekens gemiddeld op een regel passen en dan een indicatie afgeven, maar je kan het niet precies zeggen.

Browsers renderen bijvoorbeeld tekst in de hoogte allemaal anders, een imagerenderer doet dat weer anders en de printdesigners NOG weer anders.

Dus gewoon een ochtendje testen hoeveel tekens er gemiddeld op een regel passen en dan kan je een indicatieve schatting afgeven...

[alienfruit]

Zoals de persoon hierboven al vermeld is dit redelijk problematisch. Met name word-wrapping functie verschilt extreem met elkaar. De word-wrapping is tigduizend maal beter in Indesign dan in ImageMagick of Flash. Meestal moet je hetzelf implementeren zo'n word-wrapping voor ImageMagick. Dan hebben we het nog niet gehad over onderbrekingstreepjes aan het eind van een kolom.

[RobIII]

^ Met alles hierboven. Veel beter dan een schatting of indicatie ga je het niet krijgen. En dat betekent dus (allemaal leuk in theorie) in de praktijk een zo goed als zekere kans op problemen in een flink aantal gevallen.

Als ik jou was zou ik eens overwegen te gaan afrekenen op aantal tekens/woorden. Dan kost een:
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
ook evenveel als een
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

[ Voor 37% gewijzigd door RobIII op 19-07-2011 09:35 ]

[Verwijderd]

Zojuist even bij een andere webapplicatie gekeken waarmee ook advertenties te maken zijn en daar zie ik dat ze voor een standaard lettertype (=12px) 4mm per regel nemen. Dit verschilt per gekozen lettertype, maar wanneer ik dit opmeet met mijn liniaaltje () klopt dit wel precies.

Zoals hierboven dus al aangeven kan ik dus voor elk font een hoogte definieren die ik kan gebruiken bij het berekenen van de prijs. Breedte van de advertentie is vast omdat men van te voren al heeft aangegeven wat zij willen: 2,3 of 4 koloms.

Enige lastige - zoals Catch22 - aangeeft wordt dan de word wrapping. Het kan echter niet een indicatieve inschatting worden omdat mensen wel precies willen weten wat ze moeten betalen. Het staat erg slordig als ik aangeef dat een advertentie 15.50 kost terwijl die uiteindelijk 15.95 kost omdat de wordwrapping van de opmaker anders is....

[RobIII]

Verwijderd schreef op dinsdag 19 juli 2011 @ 09:35:
Enige lastige - zoals Catch22 - aangeeft wordt dan de word wrapping. Het kan echter niet een indicatieve inschatting worden omdat mensen wel precies willen weten wat ze moeten betalen. Het staat erg slordig als ik aangeef dat een advertentie 15.50 kost terwijl die uiteindelijk 15.95 kost omdat de wordwrapping van de opmaker anders is....

Zoals aangegeven zal 't indicatief blijven; je krijgt dit nooit 100% goed. Wanneer je de edge-cases (advertenties die nét passen binnen een bepaalde ruimte) gaat bekijken zul je zien dat 't op een aantal plaatsen net niet past.

Je zou kunnen kijken naar alternatieve manieren van tekst weergeven die wat beter te bepalen zijn (zeg Flash met embedded fonts, canvas, you name it) maar daar wordt je website weer niet echt beter laat staan gebruiksvriendelijker op.

[418O2]

En geef altijd een hogere schatting af zodat je kan garanderen dat het nooit duurder wordt dan aangegeven. Wordwrapping en letterbreedtes zijn vrij onvoorspelbaar.

Met Flash hou je dat probleem alsnog toch RobIII ? Dan heb je wel een vrij precieze schatting hoe het in Flash is, maar dan weet je alsnog niet hoe het op print gaat worden...

[RobIII]

418O2 schreef op dinsdag 19 juli 2011 @ 09:39:
Met Flash hou je dat probleem alsnog toch RobIII ? Dan heb je wel een vrij precieze schatting hoe het in Flash is, maar dan weet je alsnog niet hoe het op print gaat worden...

Als 't om print gaat heb je gelijk inderdaad, maar dat haalde ik niet zo 1,2,3 uit de TS. Daar gaat 't enkel over "een advertentie" en "kolommen".

[Verwijderd]

@Rob -> de door de klant opgemaakte advertentie is voor print.

[Verwijderd]

Misschien een beetje omslachtig maar opzich moet het wel mogelijk zijn met GD. De tekst die iemand intikt geef je bijvoorbeeld met ajax door naar de server. Dan met GD bereken je op basis van het font en tekstterugloop de imagettfbox en weet je de totale hoogte. Dit delen door de regelhoogte en je hebt ook het aantal regels getypt.

Maar ben het wel met de rest eens dat je misschien beter per karakter af kan rekenen oid, maak je het jezelf in iedergeval een stuk makkelijker mee.

[Verwijderd]

Verwijderd schreef op dinsdag 19 juli 2011 @ 09:35:
Enige lastige - zoals Catch22 - aangeeft wordt dan de word wrapping. Het kan echter niet een indicatieve inschatting worden omdat mensen wel precies willen weten wat ze moeten betalen. Het staat erg slordig als ik aangeef dat een advertentie 15.50 kost terwijl die uiteindelijk 15.95 kost omdat de wordwrapping van de opmaker anders is....

Hier is ook een simpele oplossing voor, zoals kranten het doen;

- maak voor jezelf een dummy met alleen maar "W"-tjes (dit is namelijk de breedste letter) over een aantal regels
- pas de witruimte aan zoals je deze wilt hebben (rondom tekst, tussen de regels en tussen de letters)
- kijk hoeveel letters (dus leestekens) er op één regel passen

Nu zeg je gewoon dat er op één regel een maximum van x leestekens mogelijk is, en kun je gemakkelijk zien hoeveel regels er zijn.
De tekst van de advertentie wordt dan volledig uitgelijnd (text-align: justify).

Houd uiteraard wel rekening met vette en scheve letters

[RobIII]

Verwijderd schreef op dinsdag 19 juli 2011 @ 09:41:
@Rob -> de door de klant opgemaakte advertentie is voor print.

Dan zou ik alsnog neigen naar Flash oid. Het is dan wel niet zo "HTML5 hip" als ik graag zou zien maar dat is wel een omgeving waar je (op dit vlak) nog de meeste invloed kunt uitoefenen op 't uiteindelijke resultaat door de juiste fonts te embedden, om te gaan met kerning etc. etc.

En, wat je ook kiest, een dikke disclaimer eronder dat alle bedragen indicaties zijn.

[418O2]

en in de praktijk ga je dus zien dat je advertenties krijgt die niet mooi uitlijnen omdat er _altijd_ ruimte overblijft.

Wij hebben dit voor een klant ook gepoogd te maken en het is gewoon niet heel erg goed te krijgen. Je moet er gewoon rekening mee houden dat het allemaal iets anders uitvalt.

[Gomez12]

Verwijderd schreef op dinsdag 19 juli 2011 @ 09:35:
Breedte van de advertentie is vast omdat men van te voren al heeft aangegeven wat zij willen: 2,3 of 4 koloms.

Negeer je dan niet het simpele feit dat een w breder kan zijn dan een i (afhankelijk van lettertype) etc.

Enige lastige - zoals Catch22 - aangeeft wordt dan de word wrapping. Het kan echter niet een indicatieve inschatting worden omdat mensen wel precies willen weten wat ze moeten betalen.

Waar je wel een stuk verder mee kunt komen is door vanuit je app een druk-pdf te genereren. Dan blijft je word-wrapping gelijk zoals in je pdf.

Verwijderd schreef op dinsdag 19 juli 2011 @ 09:43:
Misschien een beetje omslachtig maar opzich moet het wel mogelijk zijn met GD. De tekst die iemand intikt geef je bijvoorbeeld met ajax door naar de server. Dan met GD bereken je op basis van het font en tekstterugloop de imagettfbox en weet je de totale hoogte. Dit delen door de regelhoogte en je hebt ook het aantal regels getypt.

Technisch kan er van alles, maar de grote vraag is of je het ook wilt. Volgende vraag van de klant is dat hij tekst wil kunnen slepen etc. etc. En voordat je het weet ben je een wysiwyg editor op het web aan het maken en loop je leeg op de ontwikkelkosten.

[Verwijderd]

Bedankt voor alle reacties. Hier kan ik zeker wat mee.
Wat ik mij wel afvraag is hoe ze dit dan bij monuta (http://rouwbericht.monuta.nl/) doen. Hier lees ik niks over het feit dat de gegeven prijzen indicatief zijn...

[ReTechNL]

Reken de klant af op het aantal gebruikte woorden. dit is gemakkelijk en tevens kan je mer regex _ filteren bij het berekeken van je aantal woorden. op het aantal regels afrekenen geeft veel problemen tenzij je niet veel andere dingen te doen heb kan je het altijd zelf nog regel voor regel gaan tellen. bij iedere advertentie.

[RobIII]

Verwijderd schreef op dinsdag 19 juli 2011 @ 09:50:
Wat ik mij wel afvraag is hoe ze dit dan bij monuta (http://rouwbericht.monuta.nl/) doen.

Rechtsklik -> view source.

En zo lekker werkt 't niet bij ze want ik krijg:

Adobe Flash Player nodig
Om deze site te kunnen bekijken heeft u minimaal versie 8 van de Adobe Flash Player nodig.
Uw browser heeft momenteel deze plugin niet geïnstalleerd.

Ondanks dat ik de recentste flash player geïnstalleerd heb

edit:
Hmmm, in latere stappen doen ze een AJAX call (makepreview.php) en wordt er een image gegenereerd. Dan kom je inderdaad bij zaken als GD e.d. uit.

Daarbij: denk je dat ze bij rouwadvertenties gaan zeveren over 3 cent die te weinig geoffereerd zijn? Dat schuiven ze dan heus wel op een grote hoop "ach, shit happens" Als je je marge een paar (tiende?) procent verhoogt kun je alle rekenfoutjes prima opvangen met 't teveel betaalde uit overige advertenties.

Verder:

quote: http://rouwbericht.monuta.nl/info/disclaimer/

Fouten (in de gegevensverwerking) kunnen echter niet altijd voorkomen worden.

[ Voor 77% gewijzigd door RobIII op 19-07-2011 09:59 ]

[Verwijderd]

Verwijderd schreef op dinsdag 19 juli 2011 @ 09:50:
Bedankt voor alle reacties. Hier kan ik zeker wat mee.
Wat ik mij wel afvraag is hoe ze dit dan bij monuta (http://rouwbericht.monuta.nl/) doen. Hier lees ik niks over het feit dat de gegeven prijzen indicatief zijn...

Daar zijn alle waarden vooraf gedefinieerd... per lettertype, per lettergrootte, per alles...
En volgens mij sjoemelen ze ook een beetje met de hoogtes, door de witruimte variabel te maken tussen de verschillende blokken.
Maar dat kan je niet allemaal zien omdat alles door PHP wordt verwerkt.


Je kan het "regeltje meer" probleem ook gewoon oplossen in je marge op de prijzen


Volgens mij is het volledig afhankelijk van een soort bedrijf waar het systeem voor is en het type advertenties, want je kan het zo gemakkelijk of moeilijk maken als je wilt...

[Verwijderd]

Aan de server kant tekst kan je de tekst toch importeren in een PDF template? En op basis daarvan de hoogte bepalen?

[418O2]

in principe kan je hem daar dan heen schrijven en renderen, om het vervolgens weer uit te lezen.

Maar dan moet PDF alsnog 1:1 overeenkomen met de print en ik vraag me af of dat het geval is.

[Verwijderd]

Waarom niet? Zaken als DPI en font kan je vastzetten in PDF evenals de kolombreedte, karakterspatiering, regelhoogte, etc. Daaruit volgt dan toch de hoogte?

[418O2]

in principe wel ja

[Verwijderd]

Oké, dan ga ik vanmiddag daar eens mee "spelen". Tcpdf is daar denk ik wel een goeie lib voor of hebben jullie betere gratis alternatieven ?

[Gomez12]

Verwijderd schreef op dinsdag 19 juli 2011 @ 11:41:
Waarom niet? Zaken als DPI en font kan je vastzetten in PDF evenals de kolombreedte, karakterspatiering, regelhoogte, etc. Daaruit volgt dan toch de hoogte?

Drukken jullie het ook zelf? Zodat je ook echt de juiste fonts/dpi etc kan aangeven of wordt het ook door anderen gedrukt waardoor die misschien fontsubstitutie etc kunnen gaan toepassen?

[Verwijderd]

Nee, het wordt niet door ons zelf afgedrukt. Wij sturen de PDF's naar de uitgevers die zij vervolgens gebruiken.

[Gomez12]

Verwijderd schreef op dinsdag 19 juli 2011 @ 20:00:
Nee, het wordt niet door ons zelf afgedrukt. Wij sturen de PDF's naar de uitgevers die zij vervolgens gebruiken.

Dan moet je er dus wel weer rekening mee gaan houden dat je voordat je met tcpdf aan de slag gaat je eerst met die uitgevers om tafel gaat om te vragen wat die willen.

Je kan het met pdf goedkrijgen, maar die moet dan wel exact volgens de wensen van de uitgevers zijn.

Op dit gebied zijn de uitgevers heer en meester en jij slechts de slaaf, want als er iets foutgaat in het drukproces en de drukker kan het op jou afwentelen omdat jij hebt gehobby'ed dan draag jij de kosten...

[keizert]

*gewist*

[ Voor 96% gewijzigd door keizert op 30-07-2011 12:28 . Reden: reeds als antwoord aanwezig ]

[Verwijderd]

Het valt allemaal niet mee met TCPDF. Vanuit de webinterface kunnen de klanten hun advertentie opmaken door op de teksten in de voorbeeld advertentie te klikken. De gekozen tekst komt dan in FCKeditor waar ze de tekst kunnen bewerken.

Nu dacht ik eenvoudig de HTML van de opgemaakte advertentie aan TCPDF door te geven en klaar te zijn, maar niks lijkt minder waar. Met TCPDF heb je namelijk geen controle op de padding en margin van elementen. Binnen de webapplicatie ziet de advertentie er goed uit, maar zodra ik er een PDF van gemaakt heb staan de teksten ver van elkaar vandaan. Dit komt:
1) doordat je dus geen controle hebt over de margin / padding
2) achter elke div zet TCPDF standaard een nieuwe lege regel. Principe van een p dus. Hier heb je geen enkele controle op dus ik moet wel het SPAN element gaan gebruiken, maar omdat TCPDF geen display="block" accepteert moet ik daar weer een <br /> achter zetten.

Kortom, moeilijk, moeilijk is dit zo. Nu zat ik te kijken naar:
http://code.google.com/p/wkhtmltopdf/wiki/Usage

En die genereert een erg mooi PDF'je van de HTML die je hem voorschotelt. Deze library biedt echter geen methodes om bijv. de hoogte van de advertentie op te vragen zodat ik de prijs kan berekenen.

http://rouwadvertentiemak...pdf/www/examples.php#demo is eveneens een mooie library, maar biedt ook geen juiste methodes.

Kent iemand hier wel een PDF library waar je :
1) HTML aan kan geven
2) Er een mooie PDF van maakt
3) Functies biedt om de hoogte van de advertentie in de PDF op te vragen

[Gomez12]

Simpelweg geen html als tussenvorm gebruiken? En zeker geen standaard FCK-editor ervoor stoppen...

Je moet een extreem simpele (niet uitgebreide) taal kiezen waarin mensen het kunnen opmaken, dit kan je dan weer parsen naar html voor een onscreen voorbeeld of je kan het parsen naar normale input voor fpdf.

Html zelf is een veels te uitgebreide taal voor dit soort dingen. Kijk naar het complete internet, is (zo goed als) allemaal gemaakt met html. Dan verwacht jij dat 1 "klein" hobbyprojectje dat allemaal perfect omzet naar een andere stricte taal?

Kijk bijv eens naar een ubb-parser oid om als input taal te gebruiken.

[Verwijderd]

UBB code gebruiken is geen optie omdat UBB niet gebruikersvriendelijk is. Dan kan je net zo goed voor elke positie een aparte FCKeditor maken, maar dat is nou net niet wat de klant wil ;-) Hij wil een voorbeeld advertentie hebben met daarin alle posities gevuld met tekst. Wanneer een bezoeker dan op een bepaalde tekst klikt wordt die tekst in FCKeditor geplaatst zodat het bewerkt kan worden.

Werkt allemaal perfect alleen merk ik nu dus dat TCPDF niet voldoende functionaliteiten biedt om bijv. margins / paddings van elementen te beheren en er bij een div element altijd new line achter volgt.

@Dan verwacht jij dat 1 "klein" hobbyprojectje dat allemaal perfect omzet naar een andere stricte taal?
Nee, en dat is de insteek toch ook niet? Wanneer TCPDF net zo zou omgaan met HTML als de ander genoemde voorbeelden dan ben ik geholpen. Vandaar mijn vraag ;-)

[Gomez12]

Verwijderd schreef op donderdag 04 augustus 2011 @ 22:14:
UBB code gebruiken is geen optie omdat UBB niet gebruikersvriendelijk is.

CKEditor (btw opvolger van FCKEditor) kan met een plugin gewoon omgaan met UBB dus niet-gebruikersvriendelijk?

Hij wil een voorbeeld advertentie hebben met daarin alle posities gevuld met tekst. Wanneer een bezoeker dan op een bepaalde tekst klikt wordt die tekst in FCKeditor geplaatst zodat het bewerkt kan worden.

Ga dan gewoon voor een veel simpeler editor. FCKeditor is hier alleen maar overkill voor en je moet tig opties uitschakelen omdat je pdf-processor er niet mee overweg zal kunnen.

Werkt allemaal perfect alleen merk ik nu dus dat TCPDF niet voldoende functionaliteiten biedt om bijv. margins / paddings van elementen te beheren en er bij een div element altijd new line achter volgt.

TCPDF valt gewoon te veranderen hoor... Default behavior is misschien niet wat je wilt, maar er is veelal geen off-the-shelf gratis product wat precies jouw commerciele ideeen bevat...

Nee, en dat is de insteek toch ook niet? Wanneer TCPDF net zo zou omgaan met HTML als de ander genoemde voorbeelden dan ben ik geholpen. Vandaar mijn vraag ;-)

Dan maak je het, het is hier programming en niet script-zoeken.