[PHP] bepalen van het aantal pagina's om te printen

Pagina: 1
Acties:
  • 428 views sinds 30-01-2008
  • Reageer

Onderwerpen


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Voor een systeem dat ik aan het maken ben, is het de bedoeling om client side pagina's (A4) te printen. Alleen wil ik vooraf bepalen hoeveel pagina's dat gaan worden. Maar ik heb geen methode gevonden om in PHP te bepalen hoeveel regels een stuk tekst inneemt, laat staan een HTML pagina met afbeeldingen die niet onderbroken mogen worden.

Om er voor te zorgen dat het aantal pagina's ongeacht de client software hetzelfde blijft had ik al bedacht om het te printen document om te zetten naar een PDF. Nou heb ik zitten spelen met fpdf, dompdf, libpdf en html2pdf maar geen van allen lijkt met alle features van een HTML pagina om te kunnen gaan (met name CSS eigenschappen). En het is me ook niet gelukt het aantal pagebreaks te laten tellen.

Acties:
  • 0 Henk 'm!

Verwijderd

Heb je geprobeerd om <br>'s te tellen of \n's?

Ik zou ook niet echt weten hoe je dit moet fixen, waarom wil je zo graag van tevoren weten hoeveel pagina's je krijgt?

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Linebreaks tellen is niet echt van toepassing. Regels kunnen hoger of lager uitvallen, afhankelijk van het lettertype. Bovendien moet er ook rekening worden gehouden met marges, afbeeldingen, tabellen etc. De meeste classes of extensies bieden daar wel ondersteuning voor tot op zekere hoogte, maar kunnen me niet vertellen hoe groot het document uiteindelijk is nadat alles er naartoe geschreven is. Of zie ik het soms over het hoofd?

Het gaat trouwens om grote aantallen pagina's (>50) per document over het algemeen. Het systeem houdt bij hoeveel mensen moeten printen en wordt gebruikt om dat te vergoeden. En om dat niet elke keer met de hand te hoeven tellen is het makkelijk als dat geautomatiseerd gaat.

[edit]
bij dompdf wordt het totaal aantal pagina's gedefinieerd in $PAGE_COUNT, maar dompdf ondersteund bijvoorbeeld geen ordered lists.

[ Voor 8% gewijzigd door Verwijderd op 18-03-2007 22:24 ]


Acties:
  • 0 Henk 'm!

  • Borizz
  • Registratie: Maart 2005
  • Laatst online: 24-08 20:35
Ik zou als ik jou was eens naar html2pdf kijken. Je moet het wel even door krijgen, maar dan werkt het ook perfect. Er zit ondersteuning in voor paginering en paginanummering (via CSS 3 en eigen methodes van html2pdf). Het voordeel is dat je je pagina's gewoon in html op kan maken (t.o.v. bijv fpdf).

Je zou het eventueel ook puur met html en CSS kunnen doen en het rechtstreeks door je browser af laten drukken. Kijk maareens naar de print properties van CSS 2, page-break-after en page-break-before werken volgens mij in alle moderne browsers (en IE 6).

If I can't fix it, it ain't broken.


Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Verwijderd schreef op zondag 18 maart 2007 @ 22:06:
Ik zou ook niet echt weten hoe je dit moet fixen, waarom wil je zo graag van tevoren weten hoeveel pagina's je krijgt?
Omdat 'ie waarschijnlijk "pagina 1 van x" onderaan iedere pagina wil printen ;)

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
html2pdf lijkt tot nu toe het beste pdf's te genereren, alhoewel hij bij sommige tests al weer flink de mist in ging.

##PAGES## wordt automatisch vervangen door het aantal pagina's in het pdf bestandje. Maar ik heb nog niet gevonden hoe ik die waarde terug kan krijgen in mijn php scripje.

Ik vind het vreemd dat het blijkbaar zo lastig is om html naar een pdf om te zetten. Weet iemand misschien nog alternatieve classes (eventueel commercieel)?

Als ik met de printer functies van php iets naar een PDF printer gooi, dan print hij gewoon de source code uit in een pdf. Waarschijnlijk zal het wel lukken op tekst met opmaak in een pdf te zetten als ik php Word laat starten, maar zie daar maar eens het aantal pagina's uit te lezen...

Acties:
  • 0 Henk 'm!

  • pietje63
  • Registratie: Juli 2001
  • Laatst online: 16:14

pietje63

RTFM

Misschien moet je het anders aanpakken -> het geceeerde pdf bestand uitlezen (volgens mij staat daar het aantal pagina's ergens in de header)

De grootste Nederlandstalige database met informatie over computers met zoekfunctie!!


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Hoe ik de pdf header informatie uit moet lezen heb ik nog niet gevonden. Maar als ik pdf bestanden gewoon uitlees in notepad blijkt er inderdaad informatie over het aantal pagina's in te staan. Over het algemeen is het ongeveer het volgende:

code:
1
2
3
4
5
1 0 obj
<</Type /Pages
/Kids [3 0 R ]
/Count 1
/MediaBox [0 0 612.28 790.87]


Achter /Count staat dus het aantal pagina's. De info tussen de [ ] verschilt per pdf, maar het is in prinicipe mogelijk om elk pdf'je met een reguliere expressie te doorzoeken.

Maar ik blijf nog even zoeken naar andere mogelijkheden, want ik begin me een beetje zorgen te maken over de performance van het script.

Acties:
  • 0 Henk 'm!

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 02:21

Janoz

Moderator Devschuur®

!litemod

Als het allemaal apparte regels zijn en het vooraan in de pdf staat lijkt me een regexp complete overkill. Je kunt gewoon een paar regels inlezen per regel en kijken of ze met /Count beginnen.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Acties:
  • 0 Henk 'm!

  • cspare
  • Registratie: Oktober 2006
  • Laatst online: 29-07 22:19

cspare

What the deuce?!

Als je weet hoe veel pixels er op je print papier past, kan je waarschijnlijk met javascript ook een eind komen, zonder gebruik te hoeven maken van pdf.
Zoek eens op offsetHeight. Als je je hele print-content in een div'je zet kan je daarmee waarschijnlijk eea afleiden.

The one who says it cannot be done, should never interrupt the one who is doing it.


Acties:
  • 0 Henk 'm!

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 02:21

Janoz

Moderator Devschuur®

!litemod

Pixels op het scherm komen niet overeen met pixels op de printer. Daarnaast weet je al helemaal niks over de breedte van de pagina Als het op het papier smaller wordt afgedrukt zal de tekst eerder wrappen dus langer zijn. Die terugloop is vervolgens lastig te bepalen omdat plaatjes daar weer heel anders op reageren. Tot slot weet je neit welke marges de gebruiker gebruikt en of de gebruiker ook een header of footer mee afdrukt. Dan ben ik tot slot nog helemaal niet begonnen over of een gebruiker Letter of A4 heeft...

Kortom, druk je html af dan heb je geen enkele zekerheid over hoeveel pagina's het wordt. Het enige dat je kunt doen is aangeven waar een pagebreak mag komen. Wil je exacte controle over hoe iets uit de printer rolt dan kun je gewoon niet heen om een formaat te gebruiken dat exact bepaalt hoe iets uit de printer moet rollen: pdf.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Gelukkig is een developer van html2pdf me te hulp geschoten.

Door het volgende stukje code te gebruiken, kom je achter het aantal pagina's:
PHP:
1
echo $pipeline->output_driver->get_expected_pages();

De regel moet je plaatsen nadat de pdf gecreëerd is.

Hij vertelde er bij dat het voorlopig geen onderdeel gaat worden van de API.

Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Verwijderd schreef op maandag 19 maart 2007 @ 16:24:
Gelukkig is een developer van html2pdf me te hulp geschoten.

Door het volgende stukje code te gebruiken, kom je achter het aantal pagina's:
PHP:
1
echo $pipeline->output_driver->get_expected_pages();

De regel moet je plaatsen nadat de pdf gecreëerd is.

Hij vertelde er bij dat het voorlopig geen onderdeel gaat worden van de API.
Gezien de functienaam get_expected_pages() lijkt me dat overigens niet eens een 'garantie' dat het aantal pagina's ook daadwerkelijk klopt.

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • Atari Paul
  • Registratie: November 2002
  • Laatst online: 13:04
Volgens mij kun je het gemakkelijkst met FOP gaan werken (met XSL-FO kun je in de footer / header gewoon gebruik maken van automatische paginanummering).

Je kunt eventueel via de API van FOP het aantal gerenderde pagina's opvragen. Of de eerder genoemde manier om het uit de PDF zelf te halen.

Stability ?? My Atari still has it :)


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Het is inderdaad een vreemde benaming voor de functie, maar het lijkt er op doordat hij dit na afloop doet het wel altijd het juiste aantal is. Het gaat tot nu toe namelijk allemaal goed, ook wanneer ik afbeeldingen, tabellen of andere lastige objecten op de grens tussen twee pagina's zet.

Als ik het goed begrijp zal ik voor het gebruik van FOP de HTML eerst moeten converten naar Formatting Objects waarna ik die na vervolgens in o.a. PDF kan converteren. Deze extra conversie stap lijkt me niet erg nuttig.

Acties:
  • 0 Henk 'm!

  • Atari Paul
  • Registratie: November 2002
  • Laatst online: 13:04
Dat is waar, je hebt een extra conversie stap, echter je weet zeker dat het goed uit de printer komt ongeacht de browser. En je weet ook exact het aantal pagina's.

Ik moet je echter wel waarschuwen dat het wel wat langer zal duren om een document op deze manier te genereren.

Stability ?? My Atari still has it :)

Pagina: 1