[IE] Print HTML pagina over meerdere pagina's

[Verwijderd]

Hallo web-devvers,

Mijn vraag is kort maar krachtig:
Is het met IE mogelijk om een pagina met bijvoorbeeld 2 regels tekst bewust te verdelen over 2 pagina's?

Dus bijvoorbeeld:
<!-- Dit op 1ste pagina bij printen -->
Regel1<br />
<!-- Dit op 2de pagina bij printen -->
Regel2<br />

Het aantal regels/de hoogte is variabel, gewoon opvullen met whitespaces is geen optie! (of ik moet bijvoorbeeld per div of per table een pagina kunnen vullen).

De pagina zelf krijgt de gebruiker nooit te zien. Ik gebruik een IE instance middels ActiveX in mijn eigen applicatie maar heb ruzie met de Windows Print Queue en daardoor heb ik soms problemen met de volgorde waarin pagina's uit de printer komen.

[RobIII]

Verwijderd schreef op zaterdag 11 april 2009 @ 23:23:
De pagina zelf krijgt de gebruiker nooit te zien. Ik gebruik een IE instance middels ActiveX in mijn eigen applicatie maar heb ruzie met de Windows Print Queue en daardoor heb ik soms problemen met de volgorde waarin pagina's uit de printer komen.

Lijkt me eerder dat je dan het probleem aanpakt i.p.v. aan symptoombestrijding gaat doen

Anyhow: een nieuwe pagina kun je 'afdwingen' met css: http://www.w3schools.com/CSS/css_ref_print.asp

[Verwijderd]

Ligt bij Microsoft, en ik heb de tijd niet om daar op te wachten ;-).
Moet nu elke dag een horde gehumeurde magazijnmedewerkers aanzien wiens pakbonnen soms niet op volgorde uit de printers komen.
Dit is precies wat ik nodig had, ik kreeg het niet gegoogled. Bedankt!

[ Voor 2% gewijzigd door Verwijderd op 12-04-2009 15:23 . Reden: Type ]

[RobIII]

Verwijderd schreef op zondag 12 april 2009 @ 15:20:
Ligt bij Microsoft, en ik heb de tijd niet om daar op te wachten ;-).

Dan ben ik toch erg benieuwd naar wat het issue precies is?

[Verwijderd]

Zie o.a.
http://social.msdn.micros...61-4b19-907e-c5c2360d0725
http://social.msdn.micros...69-401c-a05f-370416296016

Ik heb toen winspool.drv geinteropped (= gister nacht). En krijg nu een callback bij spoolerevents maar krijg de eventsflags nog niet correct gedecode (moet bijvoorbeeld wel weten of het event getriggerd wordt door het toevoegen van een job, of het completen ervan etc.). Helaas is die oplossing te kostbaar (kost veel te veel tijd krijg ik niet gefactureerd voor een volgorde probleem). Ook een aantal threading problemen die ik tegengekomen ben zie:
\[.NET] Gerenderde HTML printen vanuit non-UI MTA thread

Deze CSS oplossing is geniaal in zijn eenvoudigheid ten opzichte van de 1000den regels code die ik er tot nu toe tegenaan gegooid heb

[ Voor 20% gewijzigd door Verwijderd op 12-04-2009 15:32 ]

[_Thanatos_]

Ik weet niet wat dat allemaal betekent, maar wat is erop tegen om een PDF te genereren? Daar zijn uitstekende toolkits voor te krijgen, incluis gratis. PDF is nml bedoeld om geprint te worden, en kun je ook als zodanig opmaken. Hoge resolutie, paginering, font embedding, etc.

Daarbij, offertes/facturen/pakbonnen uitprinten is normaal dat dat via PDF loopt. Want dan kun je ze ook opslaan en/of e-mailen.

[Verwijderd]

Hallo Thanatos,

Het opslag formaat is geen issue. Het gaat om het printen. PDF moet evengoed gerenderd worden.
De klant krijgt zijn offertes en facturen inderdaad per PDF in de email in dit systeem.
Daarnaast worden facturen in een database opgeslagen en niet in PDF vorm ;-).

We hebben voor HTML gekozen om klanten middels eigen personeel zelf de mogelijkheid te geven hun facturen/pakbonnen/pakket labels/adres labels e.d. aan te passen.

Bedankt voor het meedenken.

[Janoz]

Verwijderd schreef op maandag 13 april 2009 @ 20:14:
Hallo Thanatos,

Het opslag formaat is geen issue. Het gaat om het printen. PDF moet evengoed gerenderd worden.

Maar PDF is oneindig veel bruikbaarder in een situatie waar je moet gaan printen. Je argumentatie waarom je PDF opzij schuift raakt kant nog wal.

Ik krijg trouwens de hele thread al een beetje het idee dat je de verkeerde problemen aan het oplossen bent.

[Patriot]

Janoz schreef op maandag 13 april 2009 @ 20:26:
[...]


Maar PDF is oneindig veel bruikbaarder in een situatie waar je moet gaan printen. Je argumentatie waarom je PDF opzij schuift raakt kant nog wal.

Heb je hem niet gewoon verkeerd begrepen? Wat hij volgens mij bedoelde is dat of het nou in HTML of in PHP gaat gebeuren, die break naar de volgende pagina moet er sowieso in zitten.

De echte reden om PDF aan de kant te schuiven had te maken met de aanpasbaarheid. Of dat een valide reden is laat ik in het midden.

[Verwijderd]

Janoz schreef op maandag 13 april 2009 @ 20:26:
[...]


Maar PDF is oneindig veel bruikbaarder in een situatie waar je moet gaan printen. Je argumentatie waarom je PDF opzij schuift raakt kant nog wal.

Ik krijg trouwens de hele thread al een beetje het idee dat je de verkeerde problemen aan het oplossen bent.

En jij weet wellicht een gratis library voor .NET (voor commercieel gebruik) die ik in een zonder interventie van de gebruiker een PDF uitprint + een gratis .NET library (voor commercieel gebruik) die me in staat stelt gemakkelijk PDF templates op te stellen, te interpreteren en te parsen?

Daarnaast is HTML een stuk efficiënter in dit scenario (Server verstuurd HTML via callback naar client software, dit kunnen soms flinke documenten zijn) wat betreft data die op en neer gestuurd wordt. Zo kan ik in HTML plaatjes ergens anders dan op mijn applicatie server hosten, waar in PDF de plaatjes embedded zouden zijn (toch?).

Wellicht was het niet duidelijk, maar het gaat hier niet om documenten die een gebruiker ooit zelf opent of aanpast. Enkel output van een systeem dat bij een client afgedrukt wordt in .NET client software. Het probleem zelf heeft niets met "web" te maken, er komt geen browser of email client bij kijken.

De CSS oplossing heeft zich de afgelopen weken in productie bewezen ;-). Maar bedankt voor de kritische blik.