[PHP] tcPDF maakt pagina per array bij grote array.

[Verwijderd]

Ik heb even een testje opgezet met het genereren van een PDF gebruik makend van de volgende PDF tut voor een invoice.

http://www.web-developmen...uments-online-with-tcpdf/

Super goede uitleg en een array waar je wat mee kan, simple dus.

Nu gaat er met die tut wat mis als ik de array vergroot naar een grote van 32 zoals, hierbij even een output voor beide arrays met een print_r():

code:

Array
(
    [0] => Array
        (
            [quant] => 5
            [descr] => .com domain registration
            [price] => 9.95
        )

    [1] => Array
        (
            [quant] => 3
            [descr] => .net domain name renewal
            [price] => 11.95
        )

    [2] => Array
        (
            [quant] => 1
            [descr] => SSL certificate 256-Byte encryption
            [price] => 99.95
        )

    [3] => Array
        (
            [quant] => 1
            [descr] => 25GB VPS Hosting, 200GB Bandwidth
            [price] => 19.95
        )

)

Array
(
    [0] => Array
        (
            [invoice_item_id] => 37
            [is_custom_item] => yes
            [item_order] => 1
            [item_id] => 
            [invoice_id] => 1
            [item_name] => Item 1
            [quantity] => 0
            [price] => 100
        )

    [1] => Array
        (
            [invoice_item_id] => 38
            [is_custom_item] => yes
            [item_order] => 2
            [item_id] => 
            [invoice_id] => 1
            [item_name] => Item 2
            [quantity] => 0
            [price] => 200
        )

*snip*
...en zo nog 400 regels door...
*/snip*
)

Ik krijg dan in totaal 24 pagina's waarbij de eerste pagina wel prima gevuld is, ik comment wel de total regel hiervoor uit, en de rest van de pagina's lijken random een row te bevatten.

Ik pas dus gewoon de foreach aan naar een database query welke de bovenstaande lange output geeft.

Het stoeien duurt vrij lang en ik kom er even niet uit... what goes wrong hier ?

[ Voor 81% gewijzigd door RobIII op 10-10-2011 14:59 ]

[Verwijderd]

Ik merk dat het tevens mis gaat bij het vergroten van de eerste array, deze staat er als volgt in:

code:

$orders[] = array('quant' => 5, 'descr' => '.com domain registration', 'price' => 9.95);
$orders[] = array('quant' => 3, 'descr' => '.net domain name renewal', 'price' => 11.95);
$orders[] = array('quant' => 1, 'descr' => 'SSL certificate 256-Byte encryption', 'price' => 99.95);
$orders[] = array('quant' => 1, 'descr' => '25GB VPS Hosting, 200GB Bandwidth', 'price' => 19.95);

Het lijkt erop dat zodra je buiten de eerste pagina komt het mis gaat.

De footer blijft ook niet als footer staan en wordt een lap text die gewoon naar beneden schuift. Ik was van mening dat die gewoon bleef staan en zodra de pagina tever gevuld zou worden dat de rest doorgezte werd naar een nieuwe pagina. Niet dus.

[MueR]

Wat bedoel je met het "vergroten van de array naar 32". Wat doe je daar dan?

[Verwijderd]

MueR schreef op maandag 10 oktober 2011 @ 12:36:
Wat bedoel je met het "vergroten van de array naar 32". Wat doe je daar dan?

In plaats van 4 regels, 32 in de foreach.

[Janoz]

Hmmm... Blijkbaar is de tutorial dan nog steeds niet duidelijk genoeg. Misschien is het handiger wanneer je de tutorial eens goed doorneemt en dat je ook probeert om bij elke regel en elke aanroep en elke parameter probeert te begrijpen wat dat betekend. De tutorial gaat over een documentje van 1 pagina. Jij wilt meerdere. Misschien eens een idee om de documentatie van tcpdf te kijken. Iets op een Y positie schrijven die buiten de pagina valt hoeft echt niet te betekenen dat tcpdf dan maar zelf bedenkt om er een pagina aan toe te voegen.

[RobIII]

offtopic:
Het is 256bit encryptie en ik heb even 4 pagina's scrollen verwijderd...

[Verwijderd]

Janoz schreef op maandag 10 oktober 2011 @ 14:49:
Hmmm... Blijkbaar is de tutorial dan nog steeds niet duidelijk genoeg. Misschien is het handiger wanneer je de tutorial eens goed doorneemt en dat je ook probeert om bij elke regel en elke aanroep en elke parameter probeert te begrijpen wat dat betekend. De tutorial gaat over een documentje van 1 pagina. Jij wilt meerdere. Misschien eens een idee om de documentatie van tcpdf te kijken. Iets op een Y positie schrijven die buiten de pagina valt hoeft echt niet te betekenen dat tcpdf dan maar zelf bedenkt om er een pagina aan toe te voegen.

tcpdf zou opzich zelf om moeten gaan met het addpage->() verhaal, dit heb ik al met een aantal mensen besproken die het ook gebruiken.

Ook op IRC geeft men aan dat tcpdf het zelf op moet kunnen lossen. Een footer kun je instellen met marges, etc, zoals je bij een header ook kunt.

De header daarintegen werkt wel prima met marges.

Ik ben de docs aan het bestuderen momenteel, maar... het gegeven zou moeten zijn dat het zo werkt per default.

[Janoz]

Maar in je verhaal of je code heb je het nergens over (het aanroepen van) addPage. Je zegt alleen dat je de foreach wat langer laat lopen (waardoor de Y waarschijnlijk groter wordt dan de hoogte van de pagina)

[Verwijderd]

Janoz schreef op maandag 10 oktober 2011 @ 16:07:
Maar in je verhaal of je code heb je het nergens over (het aanroepen van) addPage. Je zegt alleen dat je de foreach wat langer laat lopen (waardoor de Y waarschijnlijk groter wordt dan de hoogte van de pagina)

Ik vond het niet nodig om wat er qua code in de link staat hier ook te posten....

Daar wordt dat zeker aangeroepen!

[Cartman!]

Ik heb meer het idee dat je bij de makers van tcPdf meer kans gaat hebben dan hier, het lijkt meer iets te zijn in de library. Los van dat je tcPdf gebruikt zit er niet veel meer achter en dan zou het 'gewoon' een bug zijn.

Heb je trouwens wel de autoPageBreak aanstaan?

PHP:

$pdf->SetAutoPageBreak(TRUE, PDF_MARGIN_BOTTOM);

[Janoz]

Verwijderd schreef op dinsdag 11 oktober 2011 @ 16:28:
[...]


Ik vond het niet nodig om wat er qua code in de link staat hier ook te posten....

Daar wordt dat zeker aangeroepen!

Niet in de foreach.

[Verwijderd]

Cartman! schreef op dinsdag 11 oktober 2011 @ 16:52:
Ik heb meer het idee dat je bij de makers van tcPdf meer kans gaat hebben dan hier, het lijkt meer iets te zijn in de library. Los van dat je tcPdf gebruikt zit er niet veel meer achter en dan zou het 'gewoon' een bug zijn.

Heb je trouwens wel de autoPageBreak aanstaan?

PHP:

$pdf->SetAutoPageBreak(TRUE, PDF_MARGIN_BOTTOM);

Even uit mijn hoofd gezegd heb ik die niet aan staan inderdaad, daar kan ik even naar kijken... er is al over een bug gesproken met wat support mensen daar... wordt uitgezocht.

Janoz schreef op dinsdag 11 oktober 2011 @ 16:54:
[...]

Niet in de foreach.

helemaal waar, echter zal je dan wel met een count moeten werken in je foreach... anders gaat het niet werken. Of zou jij het anders doen ?

[Verwijderd]

OK even een update.

Ik vond een voorbeeld als volgt:

code:

<?php require_once("tcpdf/tcpdf.php");
$pdf = & new TCPDF("P", "mm", "A5", true, "UTF-8", false);
$pdf->setPrintHeader(false);
$pdf->setPrintFooter(false);
$pdf->SetAutoPageBreak(false);
$con = mysql_connect('localhost', 'root', 'password');
if (!$con) {
    die('Could not connect: ' . mysql_error());
} mysql_select_db('tblnamer', $con);
mysql_query("SET NAMES utf8");
$result = mysql_query('SELECT fieldName1, fieldName2, fieldName3 FROM tblnamer ORDER BY fieldName1', $con);
$pdf->SetMargins(15, 20, 15);
$pdf->AddPage();
$pdf->SetFont('FreeSerif', 'B', 12);
$pdf->SetFillColor(255, 255, 255);
$pdf->Cell(60, $row_height, 'GROUP', 1, 0, 'C', 1);
$pdf->Cell(30, $row_height, 'NAME', 1, 0, 'C', 1);
$pdf->Cell(30, $row_height, 'PEPE', 1, 1, 'C', 1);
$i = 0;
$max = 30;
$row_height = 5;
$backup_group = "";
while ($row = mysql_fetch_array($result)) {
    $group = $row['fieldName1'];
    $name = $row['fieldName2'];
    $pepe = $row['fieldName3'];
    if ($backup_group != $group) {
        $pdf->SetFont('FreeSerif', 'B', 12);
        $pdf->Cell(120, $row_height, $group, 1, 1, 'C', 1);
    } if ($i > $max) {
        $pdf->AddPage();
        $pdf->SetFont('FreeSerif', 'B', 12);
        $pdf->SetFillColor(255, 255, 255);
        $pdf->Cell(60, $row_height, 'GROUP', 1, 0, 'C', 1);
        $pdf->Cell(30, $row_height, 'NAME', 1, 0, 'C', 1);
        $pdf->Cell(30, $row_height, 'PEPE', 1, 1, 'C', 1);
        $i = 0;
    } if (!empty($group)) {
        $pdf->SetFont('FreeSerif', '', 12);
        $pdf->Cell(60, $row_height, $group, 1, 0, 'C', 1);
        $pdf->Cell(30, $row_height, $name, 1, 0, 'C', 1);
        $pdf->Cell(30, $row_height, $pepe, 1, 1, 'C', 1);
    } $backup_group = $group;
    $i++;
} mysql_close($con);
ob_end_clean();
$pdf->Output('mypdf.pdf', 'I'); ?>

Waarbij eerst de pagina, header en zaken worden gezet. Je richt dus je eerste pagina in.

Hiernaa krijg je een while loop, ik maak hier een foreach van die opzich prima werkt als ik limit op bijvoorbeeld 15 regels in de loop.

De regels zijn alleen leeg als ik ze print, dit komt door de count, ik zie een regel langs komen waar ik niet echt van weet waarom die wel geprint wordt.

Maak ik er een else aan vast waarbij dus de rest van de loop wordt doorlopen, krijg ik weer meerdere pagina's met output in de eerste pagina en random alles erna.... en dat is dus niet de bedoeling.

Ik vraag me dus sterk af hoe een dergelijke loop in elkaar moet zitten, het lijkt lastiger dan het wellicht is... of misschien wel anders om

[Janoz]

Ik zie in het geheel niet wat je beschrijving met je stukje code te maken heeft. Je zegt 'dit komt door de count' maar ten eerste heb ik geen idee wat door de count komt en ten tweede zit er in je script helemaal geen count.

Vervolgens heb je het over een else ergens tussen proppen waardoor 'de rest van de loop wordt doorlopen', maar ook daar heb ik geen idee wat je daar nu mee bedoeld.

[Verwijderd]

Janoz schreef op donderdag 13 oktober 2011 @ 13:34:
Ik zie in het geheel niet wat je beschrijving met je stukje code te maken heeft. Je zegt 'dit komt door de count' maar ten eerste heb ik geen idee wat door de count komt en ten tweede zit er in je script helemaal geen count.

Vervolgens heb je het over een else ergens tussen proppen waardoor 'de rest van de loop wordt doorlopen', maar ook daar heb ik geen idee wat je daar nu mee bedoeld.

Wat ik simpel weg gedaan heb is:

code:

$i = 0;
$max = 25;
$currY = 130;

foreach ($items as $item) {

if ($i > $max)

{

$pdf->AddPage();

        $pdf->CreateTextBox($item['aantal'], 0, $currY, 20, 10, 10, '', 'C');
        $pdf->CreateTextBox($item['naam'], 20, $currY, 90, 10, 10, '');
        $pdf->CreateTextBox('$'.$item['prijs'], 110, $currY, 30, 10, 10, '', 'R');
        $amount = $item['aantal']*$item['prijs'];
        $pdf->CreateTextBox('$'.$amount, 140, $currY, 30, 10, 10, '', 'R');
        $currY = $currY+5;
        $total = $total+$amount;

$i = 0;
}

$i++;

}

Dit geeft me twee pagina's die leeg zijn en alleen de laatste regel print en daarna weer alles wat onder dit script komt.


Als ik nu na deze if een else doe en gewoon alles weer laat uitpoepen zonder add page, dan krijg ik dus weer vreseljk veel pagina's maar met output. De eerste pagina's lijken netjes, daarna is het weer random zut.

Ik weet dat het dirty is om het op deze manier te doen, een else er achter en de loop er door heen halen... maar ik zal toch ergens criteria op moeten gegeven waarom iets geoutput mag worden of niet en dat gaat icm het aanmaken van de pagina's dus flink mis.

[Janoz]

Duidelijk. Je hebt nog geen enkel idee wat de bedoeling van bijvoorbeeld de variabele $currY is. Daarnaast is het je blijkbaar niet opgevallen dat beide stukjes code compleet verschillende functionaliteit van tcPDF gebruiken. De ene gebruikt absoluut gepositioneerde elementen terwijl het andere voorbeeld relatief gepositioneerde elementen gebruikt.

Nogmaals mijn tip. Stop met prutsen en begin de verschillende stukken code eens echt door te nemen. Voor elk statement vertellen wat het doet. Voor elke variabel op elk punt aangeven wat de waarde is en wat de betekenis van die waarde is. Voor elke parameter aangeven wat de waarde is en wat voor effect dat heeft op wat dat statement eigenlijk doet. Doe dit foor elk mogelijke lettergreep in je code!

[Verwijderd]

Mijn curryY variabele heeft de juiste waarde hoor, zeker voor beide pagina's in het begin waarbij alle regels prima gevuld wordt, hierna gaat het alleen mis.

Je kunt hard roepen dat iemand iets niet doet, maar de juiste richting in helpen is ook niet echt jouw ding blijkt weer...

Wat heb ik aan je posts gehad ? Weinig dan alleen verwijten lezen en geen duidelijk uitleg.

Ik wil best iets verbeteren doormiddel van er nog dieper in te duiken, het blijk alleen dat er een fout/bug in de tcpdf zit waar alleen een dirty workaround voor is die in mijn geval ook niet blijkt te werken. Dit kwam ik vandaag eindelijk eens tegen omdat niemand er echt een probleem van maakt.

[Janoz]

Ik herhaal wat je moet doen omdat je het nog niet gedaan hebt. Als je daadwerkelijk de code had begrepen dan had je nu al lang ontdekt dat de 2e parameter van createTextbox de absolute horizontale positie is van de plek waar die tekst komt en dat de 3e parameter de verticale positie is. Wil je nog steeds beweren dat currY op de tweede pagina de juiste waarde heeft en dat je code goed is en dat het allemaal de schuld is van tcPDF?

[Verwijderd]

Janoz schreef op donderdag 13 oktober 2011 @ 16:02:
Ik herhaal wat je moet doen omdat je het nog niet gedaan hebt. Als je daadwerkelijk de code had begrepen dan had je nu al lang ontdekt dat de 2e parameter van createTextbox de absolute horizontale positie is van de plek waar die tekst komt en dat de 3e parameter de verticale positie is. Wil je nog steeds beweren dat currY op de tweede pagina de juiste waarde heeft en dat je code goed is en dat het allemaal de schuld is van tcPDF?

currY zou opzich geen problemen moeten geven, en dat doet het ook niet zoals ik zeg op de eerste twee pagina's want alle data staat daar alleen over de rest van de 22 pagina's nogmaals.

Als de pagina goed wordt afgebroken is er met currY niets aan de hand hoor.

[Verwijderd]

Hier toch ook weer eens in gedoken.

tcPDF lijkt de beste optie hoewel er mensen zijn die er ook wel op willen vloeken en terug gaan naar FPDF.

Wat ik gaande weg wel eens vond was bijvoorbeeld iets als wat hier verteld wordt:

http://www.jonathanlbrown...-paging-those-multicells/

Het blijkt dus eigenlijk een niet goed gedocumenteerde feature te zijn die ook een beetje buggy is en waar je dus een workaround voor moet bedenken.

Of heeft iemand andere ideeën om dit aan te pakken ?

[Verwijderd]

Ik ben er achter dat meerdere PDF libraries dit probleem hebben en dat er tevens hierdoor van HTML naar PDF gecreëerd wordt.

Een goed voorbeeld waar het zelfs gebeurt is simple invoices: http://www.simpleinvoices.org/

Facturen werken in principe altijd met tabellen welke je niet ziet. Wanneer je bij Simple Invoices een factuur maakt welke niet op één pagina past... loopt hij ook over de footer heen.

Een echte oplossing wordt lastig gezien domPDF, mPDF hetzelfde probleem hebben, en dan heb ik het niet niet over de Memory usage of tijd welke het in beslag neemt om de PDF te genereren.

Er is ook http://code.google.com/p/wkhtmltopdf/ en deze schijnt voor HTML/invoices perfect te zijn... helaas is hij niet zo "makkelijk" als domPDF, mPDF.. etc.

[ReenL]

Al een keertje naar Zend_Pdf gekeken? Je zult dan wel met de hand coordinaten moeten berekenen, maar het gebruikt niet de standaard php-library's. Dus bugs die andere software heeft, heeft Zend_Pdf mogelijk niet.

[Manuel]

Verwijderd schreef op vrijdag 18 november 2011 @ 10:06:
Er is ook http://code.google.com/p/wkhtmltopdf/ en deze schijnt voor HTML/invoices perfect te zijn... helaas is hij niet zo "makkelijk" als domPDF, mPDF.. etc.

Dit is juist veel makkelijker dan domPDF, mPDF, tcPDF etc. Bij wkhtmltopdf hoef je helemaal geen rekening te houden met coördinaten, invalide HTML en CSS-hacks. wkhtmltopdf maakt onder de kap gebruik van de Webkit-engine (vandaar ook de naam) en daardoor hoef je geen lelijke CSS-hacks toe te passen om de output te krijgen die je wilt.

Het enige wat er nodig is om het te laten werken zijn twee dingen:

1. pcntl-rechten (system, eval, proc_open).
2. de statische versie van wkhtmltopdf-CPU; de meeste servers maken geen gebruik van een X-server en daarom heb je dus de statische versie nodig.

[Verwijderd]

ReenL schreef op vrijdag 18 november 2011 @ 10:19:
Al een keertje naar Zend_Pdf gekeken? Je zult dan wel met de hand coordinaten moeten berekenen, maar het gebruikt niet de standaard php-library's. Dus bugs die andere software heeft, heeft Zend_Pdf mogelijk niet.

Ik ben niet zo'n Zend_fanyboy... ik weet niet hoe het komt maar ik vind ze zo "star".

Manuel schreef op vrijdag 18 november 2011 @ 11:50:
[...]

Dit is juist veel makkelijker dan domPDF, mPDF, tcPDF etc. Bij wkhtmltopdf hoef je helemaal geen rekening te houden met coördinaten, invalide HTML en CSS-hacks. wkhtmltopdf maakt onder de kap gebruik van de Webkit-engine (vandaar ook de naam) en daardoor hoef je geen lelijke CSS-hacks toe te passen om de output te krijgen die je wilt.

Het enige wat er nodig is om het te laten werken zijn twee dingen:

1. pcntl-rechten (system, eval, proc_open).
2. de statische versie van wkhtmltopdf-CPU; de meeste servers maken geen gebruik van een X-server en daarom heb je dus de statische versie nodig.

Dan ga ik daar nog een keer mee aan de stoei. Op IRC waren mensen er ook al lyrisch over, dus dat beloofde wat vind ik.

Weinig echte examples waar je van zegt... ja dat doet het!

Opzich ben ik huiverig voor van die commandline versies, het is niet OS native vaak... dus ik twijfel nog nadat ik nog verder ben gaan uitzoeken what's best is.

[Cartman!]

Verwijderd schreef op vrijdag 18 november 2011 @ 13:27:
[...]
Ik ben niet zo'n Zend_fanyboy... ik weet niet hoe het komt maar ik vind ze zo "star".

Ik ben fan van Zend Framework maar Zend_Pdf slaat de plank behoorlijk mis vind ik omdat je alles zelf moet berekenen. Kun je niet simpelweg in een bestaande oplossing je rijen opsplitsen en dmv. een loop daarmee meerdere pagina's maken?

[Verwijderd]

Cartman! schreef op vrijdag 18 november 2011 @ 13:36:
[...]

Ik ben fan van Zend Framework maar Zend_Pdf slaat de plank behoorlijk mis vind ik omdat je alles zelf moet berekenen. Kun je niet simpelweg in een bestaande oplossing je rijen opsplitsen en dmv. een loop daarmee meerdere pagina's maken?

Dat is op zich ook een idee, wellicht een prima idee! Thanks.

Eigenlijk doe je dan precies hetzelfde als je in tcPDF wil doen, het einde van je pagina berekeken en dan afkappen.

Het probleem in tcPDF is wel dat die headers moeilijk gaan doen dergelijke loops. Een standaard header is het makkelijkste, maar opvolgende pagina's zijn altijd plainer.

Ik denk dat dat best optie zou zijn... eens kijken naar de code!

(ideeën zijn welkom natuurlijk)

[Cartman!]

In je loop weet je toch of het wel of niet je eerste pagina is, die behandel je gewoon anders. Ik zie t probleem niet zo eerlijk gezegd. Desnoods maak je de chunk met rijen kleiner dan op volgpagina's, moet ook geen probleem zijn.

[Verwijderd]

Cartman! schreef op vrijdag 18 november 2011 @ 14:03:
In je loop weet je toch of het wel of niet je eerste pagina is, die behandel je gewoon anders. Ik zie t probleem niet zo eerlijk gezegd. Desnoods maak je de chunk met rijen kleiner dan op volgpagina's, moet ook geen probleem zijn.

Je bent natuurlijk afhankelijk van je font en dergelijke in je regels.

Dit moet je erg uitkauwen anders krijg je later echt problemen.

Kolommen dienen lang genoeg te zijn en tcPDF kan wel een hoogte van een tabel aanpassen als de text er niet meer in past, dus dan wil je eigenlijk je $currY weten zoals in het voorbeeld.

Wat je zegt klopt, je zal alleen rijen af moeten kappen denk ik in text wil je het zeker weten!

[Manuel]

Verwijderd schreef op vrijdag 18 november 2011 @ 13:27:
Dan ga ik daar nog een keer mee aan de stoei. Op IRC waren mensen er ook al lyrisch over, dus dat beloofde wat vind ik.

Weinig echte examples waar je van zegt... ja dat doet het!

Opzich ben ik huiverig voor van die commandline versies, het is niet OS native vaak... dus ik twijfel nog nadat ik nog verder ben gaan uitzoeken what's best is.

Ik werk hier inmiddels nu voor 3 maanden mee i.c.m. Symfony2 en KnpSnappyBundle en het werkt echt goed en makkelijk. Het heeft mij in ieder geval veel tijd bespaart.

Zolang je deze executable niet als root draait maar in een jail kan je niets gebeuren. Desnoods kun je zelf nog de broncode doornemen van wkhtmltopdf en controleren of er ook wat wordt gedaan wat jij niet wilt, desnoods compile je het zelf nog even om er zeker van te zijn.

Mijn advies: probeer het gewoon en kijk of het je bevalt.

[Verwijderd]

Manuel schreef op vrijdag 18 november 2011 @ 14:16:
[...]

Ik werk hier inmiddels nu voor 3 maanden mee i.c.m. Symfony2 en KnpSnappyBundle en het werkt echt goed en makkelijk. Het heeft mij in ieder geval veel tijd bespaart.

Zolang je deze executable niet als root draait maar in een jail kan je niets gebeuren. Desnoods kun je zelf nog de broncode doornemen van wkhtmltopdf en controleren of er ook wat wordt gedaan wat jij niet wilt, desnoods compile je het zelf nog even om er zeker van te zijn.

Mijn advies: probeer het gewoon en kijk of het je bevalt.

Ga ik doen.

Hoe is jouw ervaring met performance ?

Dan bedoel ik dus zoiets:

http://phpexcel.codeplex.com/discussions/242617

[Manuel]

Verwijderd schreef op vrijdag 18 november 2011 @ 14:37:
[...]


Ga ik doen.

Hoe is jouw ervaring met performance ?

Dan bedoel ik dus zoiets:

http://phpexcel.codeplex.com/discussions/242617

Performance zit wel snor bij wkhtmltopdf. Het duurt bij mij ongeveer om een factuur te genereren ongeveer 1s en daar zit de rendertijd van het HTML-bestand bij in. Probeer anders gewoon eens dit topic op te slaan als een html-bestand en kijk eens hoe lang het duurt.

offtopic:
Trouwens, als je wkhtmltopdf werkend wilt hebben hoef je alleen maar de functie 'save' aan te passen in '1.7.6.zip\Classes\PHPExcel\Writer\PDF.php'.

De enige twee functies die je nodig gaat hebben zijn:
http://nl3.php.net/manual/en/function.escapeshellarg.php
http://nl3.php.net/manual/en/function.system.php (of http://nl3.php.net/manual/en/function.proc-open.php)

[Verwijderd]

Manuel schreef op vrijdag 18 november 2011 @ 15:57:
[...]

Performance zit wel snor bij wkhtmltopdf. Het duurt bij mij ongeveer om een factuur te genereren ongeveer 1s en daar zit de rendertijd van het HTML-bestand bij in. Probeer anders gewoon eens dit topic op te slaan als een html-bestand en kijk eens hoe lang het duurt.

offtopic:
Trouwens, als je wkhtmltopdf werkend wilt hebben hoef je alleen maar de functie 'save' aan te passen in '1.7.6.zip\Classes\PHPExcel\Writer\PDF.php'.

De enige twee functies die je nodig gaat hebben zijn:
http://nl3.php.net/manual/en/function.escapeshellarg.php
http://nl3.php.net/manual/en/function.system.php (of http://nl3.php.net/manual/en/function.proc-open.php)

Ik ben nog even wat aan het vergelijken met mijn eigen frameworks en CI... en daar kwam dit ook even aan het licht.

Ik bedacht me ineens... ik kan deze pagina wel printen... maar je wil met een invoice bijvoorbeeld wel dat je per pagina print wat je wil printen. Jij zou dit dus naar HTML pagina's doen en die naar PDF zetten ? Een autobreak blijft het probleem.

[Manuel]

Verwijderd schreef op zaterdag 19 november 2011 @ 21:42:
[...]

Ik bedacht me ineens... ik kan deze pagina wel printen... maar je wil met een invoice bijvoorbeeld wel dat je per pagina print wat je wil printen. Jij zou dit dus naar HTML pagina's doen en die naar PDF zetten ? Een autobreak blijft het probleem.

Ik genereer ook dagelijks facturen met mijn eigen Bundle op basis van Symfony2 en heb geen last van autobreak problemen.

Heb je wkhtmltopdf nou al eens geprobeerd?

[kwaakvaak_v2]

Heb je wkhtmltopdf nou al eens geprobeerd?

volgens mij niet, ik krijg sterk het idee dat het vooral blijft bij het theoretisch proberen op te lossen.

[Ventieldopje]

Volgens mij had hij in de tijd dat hij aan het denken was al een aantal keer zelf een oplossing kunnen schrijven

[Verwijderd]

kwaakvaak_v2 schreef op zondag 20 november 2011 @ 13:02:
[...]


volgens mij niet, ik krijg sterk het idee dat het vooral blijft bij het theoretisch proberen op te lossen.

Nog niet getest, even de pro's en de con's van alles aan het bekijken en noteren.

Ik dacht daar ineens aan, aangezien dat mijn first issue was.

[Manuel]

Verwijderd schreef op zondag 20 november 2011 @ 13:31:
[...]


Nog niet getest, even de pro's en de con's van alles aan het bekijken en noteren.

Ik dacht daar ineens aan, aangezien dat mijn first issue was.

Nogmaals, probeer het gewoon eens en post je bevindingen.

[Verwijderd]

Manuel schreef op zondag 20 november 2011 @ 13:34:
[...]

Nogmaals, probeer het gewoon eens en post je bevindingen.

De bevindingen zijn opzich prima, alleen ben ik van mening dat je een invoice echt niet van HTML naar PDF wil poepen.

Een native PDF schrijven heb je echt meer in de hand. Natuurlijk kan je een prachtige HTML pagina parsen en deze via de webkit omzetten naar PDF, maar de tussenlaag zint me niet.

Hoofdbrekens... dat wel inderdaad. Ik ga gewoon niet voor de meest snelle dirty manier, want dat vind ik met tussenlagen.

[kwaakvaak_v2]

Ik mag dan hopen dat het een hobby project voor je is, want als iemand je daadwerkelijk moet gaan betalen voor alle uren die al hebt zitten hoofdbreken, testen, filosoferen en weet ik al nog niet meer is voor die persoon onder andere goedkoper geworden om een Adobe Distiller Server te kopen.

[Verwijderd]

kwaakvaak_v2 schreef op maandag 28 november 2011 @ 17:03:
Ik mag dan hopen dat het een hobby project voor je is, want als iemand je daadwerkelijk moet gaan betalen voor alle uren die al hebt zitten hoofdbreken, testen, filosoferen en weet ik al nog niet meer is voor die persoon onder andere goedkoper geworden om een Adobe Distiller Server te kopen.

Ja eigen projectje, maar dat wil ik wel goed hebben!

Zelfs het aankopen van producten voor dergelijke functies vind ik niets als het er is in de OSS wereld.

Soms wil je dingen in eigen hand hebben, dat is meestal mijn advies.

[Manuel]

Verwijderd schreef op maandag 28 november 2011 @ 12:24:
De bevindingen zijn opzich prima, alleen ben ik van mening dat je een invoice echt niet van HTML naar PDF wil poepen.

Een native PDF schrijven heb je echt meer in de hand. Natuurlijk kan je een prachtige HTML pagina parsen en deze via de webkit omzetten naar PDF, maar de tussenlaag zint me niet.

Care to explain?

Wat heb je precies meer in de hand? Features, mogelijkheden of meta-informatie? Ik begrijp niet waarom je nog een topic op GoT aanmaakt met een probleem. Je wilt geen tussenlaag hebben maar je wilt wel graag de functionaliteit hebben van die tussenlaag. Dan blijft er maar 1 optie over en dat is: het wiel opnieuw uitvinden.

[Verwijderd]

Manuel schreef op maandag 28 november 2011 @ 17:48:
[...]

Care to explain?

Wat heb je precies meer in de hand? Features, mogelijkheden of meta-informatie? Ik begrijp niet waarom je nog een topic op GoT aanmaakt met een probleem. Je wilt geen tussenlaag hebben maar je wilt wel graag de functionaliteit hebben van die tussenlaag. Dan blijft er maar 1 optie over en dat is: het wiel opnieuw uitvinden.

Een product wat je koopt en closed source is kun je nooit doorontwikkelen als het weg valt....

Beter iets bouwen dat je kunt extenden of aan kunt passen dan de andere variant.

[kwaakvaak_v2]

Klinkt als een zwaar geval van NIHS, of in dit geval NIBMS. (not invented by me syndrome)

maar goed... doe vooral wat je leuk vind, maar ik denk dat je in dit topic niet zo heel veel medewerking meer gaat vinden

[Verwijderd]

kwaakvaak_v2 schreef op maandag 28 november 2011 @ 18:26:
maar goed... doe vooral wat je leuk vind, maar ik denk dat je in dit topic niet zo heel veel medewerking meer gaat vinden

Is ook niet meer nodig