Afbeelding in koptekst layout verkooporder (SYLRRA)

[Johan]

nou ja, ik had wat problemen met het testen, dan zoek je even zo'n code op, waarmee je over de volle functionaliteit beschikt. Maar u hebt
gelijk, zo hoort het niet. 


Ik ben enigzins illegaal aan de gang, maar het doel was: het is een praktische tool, en ik wilde graag dat jullie er ook naar zouden kijken. Als het goed bevalt schaf ik een licentie aan, bevalt het niet, dan is het snel van de pc af.

Illegaal is het verkeerde woord, ik vind het alleen zo flauw dat je verplicht bent een officieele licentie te moeten hebben voor tijdelijk gebruik (igv testen)

Ik wil dus absoluut niet aanzetten tot misbruik. Derhalve het hele serial verhaal er even uitgehaald. Je hebt wel gelijk dat dat eignelijk niet mag.

[Johan]

http://www.lincolnco.com

Ook dit is een praktische tool

kunnnen jullie het volgende beoordelen:

ConServR: Converting Application Files
Convert files between popular application formats

    * ConServR for Windows
    * ConServR for Linux

ConServR converts popular application and graphic file formats such as MS Office, Adobe PDF, HTML, Lotus Smart Suite, HP-PCL, and PostScript to output formats such as text, TIFF, PDF, PostScript, HTML, JPEG, and RTF.
ConServR combines Lincoln's expertise in conversion technology with the latest processing technology to support high-throughput document conversion applications.
Common applications include:

    * Fax Solutions - Fax servers and fax broadcast services accept native documents that must be converted to a TIFF format for faxing

    * Document Management - As solutions for managing and archiving documents migrate to the Web, users of such systems need to convert stored documents from their original file format to a viewable file format

   
    * Email - ConServR translates documents into easily-read, non-executable, rendered documents, solving issues with attachments that contain viruses, unavailability of necessary viewers, and senders who do not want to transmit documents that can be modified

Runs On:    Windows
Linux
Interface:    C++, C
VB
Java
TCP/IP
GUI (Java Client)

Met andere woorden: Het klinkt alsof dit te integreren is in Heart Profit. Maar ik ben geen programmeur, kan iemand van jullie knappe koppen beoordelen wat hier mee is te doen. De convertertool van lincoln werkt even goed als die van verypdf. Het verschil is alleen dat het lijkt alsof LINCOLN te integreren valt in Profit.

[Richard Masseling]

Hallo Johan,

je aangepaste Export-menu staat inmiddels bij je op het systeem.

[Johan]

Iin de bijlage enige toelichting van LINCOLN zelf.

Aanpassen Printbeheer m.b.t. automatische omzetting van de print output naar een PDF writer wanneer nodig (en dit is nodig bij in elk geval emailen).
N.b.: Dit stelt minder voor dan het lijkt, want het printen zelf gaat naar de betreffende PDF Queue (zie hierna).
3 uur.

Systeemparameter PDF Queue voor emailen.
Let op : De gekozen PDF writer zal z'n output naar een "dirigeerbare" lokatie moeten kunnen sturen (want, ze moet worden opgepikt door de programmatuur die ze als attachment gaat emailen).

Maar ja, dit is geen Writer (/printer), maar een converter. Hoe groot is deze ramp? Ik zou zeggen:

Je hebt een prfile.prn, en na het afdrukken start je die converter, de input is altijd c:\troep\prfile.prn (althans, nu nog) en de output filenaam en locatie mag je opgeven, (of ook kunt programeren per printfunctie?). Zodoende kan een andere toepassing van Heart die gecreerde pdf daarvandaan oppikken en mailen naar (soms automatisch geselecteerde) geadresseerden.

[Peter Stordiau]

Het heeft wel z'n invloed, maar het is nog even moeilijk te overzien welke precies. Het verschil : je print niet naar een PDF Queue maar naar iets anders (in jouw geval SCHERM), waarbij je daarna het onderscheid moet gaan maken. Is heus wel te doen.

[Johan]

Maar als pdf printen toch onder een aparte knop komt: Is het dan zo lastig om ipv c:\troep\prfile.prn naar bijvoorbeeld c:\troep\pdffile.prn die pcl kode's te printen? (om vervolgens pdffile.prn om te zetten in pdffile.pdf) dan print je niet meer zoals nu naar SCHERM

Uiteraard blijf ik van mening dat we, in ieder geval bij de variabele layouts, iets zouden moeten verzinnen met herkenbare pdf-bestandsnamen, opdat in die bestandsnaam een (herkenbaar) ordernummer / relatie id of iets dergelijks in zit.

[Peter Stordiau]

Maar als pdf printen toch onder een aparte knop komt: Is het dan zo lastig

Nee. Heb ik dat gezegd dan ?

Uiteraard blijf ik van mening

Zal best. Maar die mening heb je niet kenbaar gemaakt, en zo toch (elders) dan denk je zeker dat iemand dat alhier weet ?
Mijn tip : zeg wat je wilt funktoineel, en bemoei je minder met de oplossing.
Mijn idee : nog een paar posts en dit topic is ook weer een chaos.

Mijn vraag : Wil je per ongeluk nu deze converter gebruiken voor de oplossing van het PDF verhaal, of niet ?
Als het even kan niet 200 overwegingen of 600 vragen, maar gewoon Ja of Nee met desnoods een heeeel klein vraagje.

Edit : Met "deze converter" bedoelde ik dus Lincoln. En, het maakt mij dus niet uit, als jij je output er maar uit krijgt zoals je wilt. Als dit met die eerdere "writer" ook goed lukt, moet je zelf eerst even kiezen.
En Pascal, jij (en iedereen) mag best meekiezen. Stel dat jij net die andere kiest, moet die (methode) dus ook worden ontwikkeld. Geeft niets, maar kost je wel geld natuurlijk).

[Johan]

Maar als pdf printen toch onder een aparte knop komt: Is het dan zo lastig

Nee. Heb ik dat gezegd dan ?

Nee, inderdaad, er stond namelijk bij jouw al achter dat het wel te doen zou zijn. Dus die opmerking was even fout van me.

Persoonlijk vind ik het erg plezierig om met die PCL-Codes te kunnen werken.
Dit waarschijnlijk vooral vanwege  de onbekendheid met andere methoden en / of technieken. Voordeel is ook, dat we nauwelijks iets hoeven te doen aan de bestaande drivers.

Maar daarmee is niet gezegd dat de zo pas door Johan genoemde voordelen zaligmakend zijn om te kiezen voor een pcl-pdf printer / convertor.

Wil je per ongeluk nu deze converter gebruiken voor de oplossing van het PDF verhaal, of niet ?

Hiermee suggereer je naar mijn idee dat een convertor niet ideaal is. Maar voor mij geldt 1 ding: Als het met een PDF-printer niet lukt, dan maar met een convertor. Dus JA: Het mag van mij een convertor zijn.

Voordelen die ik er in zie:
- De prfile.prn komt altijd op dezelfde directory te staan.
- Per printfunctie zou je (per bedrijf / gebruiker etc.) op moeten kunnen geven op welke directory de PDF moet komen te staan.
- Op diezelfde manier moet er (hopelijk) ook iets met bestandsnamen mogelijk zijn. Dus ik hoop dat er per printfunctie middels 'variabelen' een bestandsnaam op te bouwen is. .

Wie zoekt even mee en heeft wellicht nog een beter idee!?

[Peter Stordiau]

Wie zoekt even mee en heeft wellicht nog een beter idee!?

Waar ik graag aan toevoeg dat als niemand nu (!) betere ideeën heeft, dan wel denkt "daar kijk ik later nog wel eens naar", het zodirekt voor Johan wordt gemaakt, hij zeker tevreden zal zijn, maar "jij" wellicht niet en je dan alsnog aan de gang kunt. Ofwel :

We kunnen het beter nu goed doen, waarbij wij heus zo veel mogelijk mee "oordelen".

Op dit moment zeg ik zelf dat een aansturing met PCL5 inderdaad beter lijkt, omdat je dan in theorie op het printen kunt ingrijpen zoals altijd (wat bijvoorbeeld te denken van een dubbelzijdige PDF hahaha -> waar toch iets in zit, want dubbelzijdig printen vergt een bijzondere aansturing ... snap je vanzelf als je een printer hebt die dubbelzijdig print, dan wel als je zo'n PDF handleiding - bedoeld voor dubbelzijdig afdrukken - juist niet dubbelzijdige afdrukt).

De "converter" methode lijkt mij ook flexibeler, c.q. kan gemakkelijker worden vervangen door een andere converter omdat het gewoon een stapje is wat er tussen zit, en wat inderdaad kan worden vervangen door een ander gelijkwaardig stapje. Dit is niet het geval met een PDF printer, die, om maar iets te noemen, standaard naar z'n eigen install directory zou kunnen "printen".

Ik houd het vooralsnog op de converter.

[pascal]

Naast koptekst willen we ook graag een voettekst in de layout, met een afbeelding.
Kunnen we nu onderstaande regels hiervoor gebruiken met gewijzigde rij-nummers en LOGO-naam?

Rij Kolom Vnr Tekst
1 1 0 %CHR(27)%*p1600x100Y
1 12 0 %IMG#LOGO%
1 12 1 %CHR(27)%&a-14R

[Peter Stordiau]

De "konstruktie" weet ik nu misschien wel : onderbrengen in Profit-Print-3. Die gaat dan Basisprijs EUR 200 kosten (is nu 175), en Marco  heeft die toevallig al (bijbetalen niet nodig). N.b.: zie ook button print pdf bij afdrukken facturen.

Eenieder die deze module heeft zal PDFs kunnen maken van iedere print middels de reeds klaarstaande PrPDF button die net als de PrScr button toestaat om naar de vastgelegde instelling te printen. Hoe dat in dit geval moet lopen is mij nog niet helemaal duidelijk, maar wanneer je de gekreëerde PDF niet naar het scherm print moet ze eruit komen op de bestaande Queue/Funktie koppeling die elders is vastgelegd (zoals gebruikelijk en daaraan verandert niets). Het lijkt me dat we niets met drivers van doen hebben anders dan de bestaande (en ook die blijven gewoon in gebruik om de print te kunnen kreëren), omdat de omzetting naar PDF gebeurt nadat de print is gemaakt (converter type dus). Hieruit zal wel volgen dat er een PCL driver gehanteerd moet worden, of wat het ook is wat de gekozen converter biedt met als eis : transparantie voor de gebruiker.
Merk op dat ik met "transparantie" mag bedoelen dat je nog nooit eerder een print met PCL drivers hebt gemaakt, maar zodra je dat eenmaal hebt (voor alle vormen van prints die je gebruikt) het er ook hetzelfde uitziet in de PDF.

De keuze voor de converter maken wij, en als iets het niet helemaal doet is dat onze schuld c.q. ons werk om het werkend te maken.
Als ik hierboven terug kijk, dan zou het "veryPDF PCL Converter" moeten worden, maar zo niet deze, dan een ander.
Merk op dat de licentiekosten (indien aan de orde) voor de uiteindelijke converter niet bij de prijs van de module in zit.

Let op :
Wat hiermee wordt geboden is het principe van het kunnen omzetten van een feitelijk willekeurige print naar een PDF. Dit betreft een file. Gelijk aan de PrScr button die bij gebruik de print op het scherm zal tonen met (automatisch) gebruik van de juiste driver, zal de PrPDF button deze file aanmaken in de Troep directory als zijnde de gebruikelijke plaats voor "print files". Denk maar aan Prfile.pdf. Hiermee kan je dus nog niets, behoudens opvragen maar wat niet standaard zal gebeuren. In SYPRS1 (printer icoontje links) kan wat mij betreft wel een optie daarvoor worden opgenomen.

De PDF file staat nu klaar voor allerlei verdere verwerking, waar voor wat betreft dit ontwerpje *niets* van aan de orde is. Enkele ideeën :

• Emailen van de klaarstaande Prfile.pdf als attachment vanuit CRM.
• Emailen van de PDF versie voor die funkties die automatisch emailen ondersteunen (zoals nu Orderbevestiging, Inkooporder).
• Opslagstruktuur + naamgeving voor archivering (automatisch).
• Een additionele button EmPDF naast PrScr e PrPDF die middels een popup om Relatie-Id en Kontaktpersoon-Id vraagt, de betreffende print print en daarna de email client opstart met daarin de geadresseerde ingevuld en de PDF als attachment al in zich heeft.

Dit soort zaken betreft maatwerk (allemaal in de kategorie "valt best mee"), en zal vervolgens onderdeel van Profit-Print-3 zijn.

[pascal]

De "konstruktie" weet ik nu misschien wel : onderbrengen in Profit-Print-3. Die gaat dan Basisprijs EUR 200 kosten (is nu 175)

Deze aanpassing met basisprijs 200 euro willen wij bij deze graag aanschaffen.

De verder genoemde mogelijkheden zien er goed uit. Ik denk dat veel van onze wensen hierin genoemd staan. Hopelijk kunnen we de kosten met meerdere klanten delen, zodat ieder z'n faire deel eraan meebetaalt.

De PDF file staat nu klaar voor allerlei verdere verwerking, waar voor wat betreft dit ontwerpje *niets* van aan de orde is. Enkele ideeën :

    * Emailen van de klaarstaande Prfile.pdf als attachment vanuit CRM.
    * Emailen van de PDF versie voor die funkties die automatisch emailen ondersteunen (zoals nu Orderbevestiging, Inkooporder).
    * Opslagstruktuur + naamgeving voor archivering (automatisch).
    * Een additionele button EmPDF naast PrScr e PrPDF die middels een popup om Relatie-Id en Kontaktpersoon-Id vraagt, de betreffende print print en daarna de email client opstart met daarin de geadresseerde ingevuld en de PDF als attachment al in zich heeft.

[mdekraa]

voorzover het helpt met mijn factuurprint verhaal sluit ik me graag aan bij het stuk van Pascal

mvg

Marco

[pascal]

De "konstruktie" weet ik nu misschien wel : onderbrengen in Profit-Print-3. Die gaat dan Basisprijs EUR 200 kosten (is nu 175)

Deze aanpassing met basisprijs 200 euro willen wij bij deze graag aanschaffen.

Ik zit net in Test te kijken (laatste aanpassing in Test is van 11-6-2009) en was benieuwd of Profit-Print-3 er bij ons al opstond. Via 3-3-2 Printen faktuur gekozen voor CTRL-F2, maar hier krijg ik de melding 'module nog niet geimplementeerd'.
Klopt dit of staat hij er al in en moet ik hem zelf nog instellen/configureren?

Ik heb de VeryPDF Converter inmiddels geinstalleerd om te testen. Ik kan hiermee wel handmatig een factuur prfile.prn omzetten naar een PDF, maar kom niet veel verder qua toevoegen layouts, lettertypes etc.
Iemand die al verder is dan mij?

[Peter Stordiau]

Het is nog niet klaar. Sorry.