Berichten

Ik realiseer me ineens dat ImageMagick ook wel degelijk dat soort informatie levert, indien aanwezig.
Zie hier: (even snel ge googled)
http://www.sitepoint.com/forums/showthread.php?t=527038

Ik denk dat daar wel wat relevante informatie bijstaat, althans... voor het begrip van...
Even lezende, wordt me al snel duidelijk dat ImageMagick of de eerder genoemde jpeg metadata toolkit
de beste opties zal leveren om de informatie te achterhalen uit images van met name digitale
camera\'s... Maar of je daar binnen de scope van Acumuls wat aan hebt is ten tweede.

[17]

- sorry voor een kleine fout in mijn laatste post:

byte 16-18: vertical pixel density, ofwel vertical densiteit

zal natuurlijk
byte 17-18: vertical pixel density, ofwel vertical densiteit
moeten zijn

Nee hoor Bert-Jan... dat is zeer zeker geen domme vraag.
Er zijn voor een aantal bestandsformaten inderdaad methoden om deze informatie terug te halen.
Voor JPEG word die informatie ergens in een bitmasker weggeschreven (lees: binair)
Er zijn een aantal open source libraries beschikbaar om die info te krijgen, maar het komt vaak neer op hetzelfde patroon.
Een bekende library is de \"PHP JPEG Metadata Toolkit\", maar ik meen dat deze beperkt is tot JPEG informatie.

EXIF (http://php.net/exif) is een andere manier, maar is aan wat voorwaarden verbonden en ik weet niet uit mijn
hoofd of die ook de dpi ondersteunt.

Andere images slaan deze informatie vaak helemaal niet op en worden dan met een ingestelde standaardwaarde
gebruikt (bijv bij printen), waardoor deze er soms helemaal niet uitziet zoals de bedoeling was.

Maar dan nog loop je eigenlijk veel vaker tegen een ander probleem aan: heel veel image converters,
waaronder GD voor PHP, slaan deze informatie gewoonweg helemaal niet op. Waardoor je veelal een gok moet doen
voor de DPI. Gelukkig is 96 DPI wel vaak een defaultsetting in vele overige pakketten.

Een veelgehanteerde methode is deze:
lees de JPEG direct, met name bytes (karakters) 14-18.
- byte 14: 01, X and Y density unit specifier (00: none, pixel ratios, 01: DPI,02: DPC)
- bytes 15-16: horizontal pixel density, ofwel de horizontale densiteit
- byte 16-18: vertical pixel density, ofwel vertical densiteit

in principe is het dan dus zo dat indien byte 14 de waarde 01 heeft, het volgende paar van 2 bytes (4 in totaal dus)
de DPI aangeven. (Even uit mijn hoofd: ik weet niet of dat in Big-endian of Little-endian order is... deze orders houden in of je de binaire tekenreeks (8 bits per byte) van links naar rechts moet lezen of juist andersom)

Ik meen me verder ergens nog te herinneren dat voor JPEG tegenwoordig eigenlijk niet meer 1 standaard is en dat sommige digitale camera\'s
een ander info formaat hanteren. Zodoende geeft de JPEG niet meer in alle gevallen de correcte informatie terug.

Ik hoop dat je hier iets mee kan?
Anders verneem ik dat vast wel van je

Beste allen: hetgeen hier vermeld wordt is niet geheel waar.
@Bert-Jan: ik meen dat ik je dit ooit toegemaild heb mbt het plaatsjes verhaal en de imlpementaties ervan.
Zie eventueel ontvangen emails door mij.

Om e.e.a even in een keer duidelijk te stellen:

- FPDF werkt, net als alle (?) PDF implementaties met een DPI van 72. In menselijke termen: voor elke Inch (2.54 cm) zijn er 72 beeldpunten.
- Plaatjes worden vaak tot zeer vaak met GD (veelal mbv PHP) gegenereerd. GD gebruikt vandaag de dag intern een DPI waarde van 96: 96 beeldpunten per inch.

In deze specifieke gevallen, klopt exact wat hier vermeld wordt.
Helaas slaan de meeste image converters de DPI informatie NIET op.
Images zijn echter in het geheel NIET beperkt op een bepaalde DPI. Een plaatje dat direct
uit een scanner komt, is vaak gescand op 300 DPI! Goede imageconverters zullen dit zonder meer
gewoon converteren en daadwerkelijk 300 DPI gebruiken. In de praktijk echter is 96 DPI een
zeer veel toegepaste waarde.

De omrekeningsfactor komt dus nu goed uit, maar dit is niet altijd het geval.
Hiervoor zal van het bronbestand altijd de DPI waarde bekend moeten zijn. In JPEG bestanden
wordt dat al vaker opgeslagen, omdat het formaat van JPEG daar definities voor heeft.

Als nu de standaard omrekenfactor 72/25.4 is, en je een bestand van 300 DPI wilt kunnen gebruiken,
is de omrekenfactor bijv al (300/72) * 72/25.4 = 300/25.4.

Kortom: de omrekenfactor is rechtevenredig met de DPI van het BRONBESTAND!

Ik hoop dat ik hiermee ook meteen de vraag van finalwebsites heb beantwoord:
omdat je in de meeste gevallen de DPI niet terug kunt halen uit het bronbestand,
is eenduidig uitrekenen van de hoogte/breedte door FPDF niet altijd een oplossing en
zal ook niet altijd leiden tot correcte resultaten!

Wat betreft Bert-Jan\'s
\"3.779527559

de gulden snede van FPDF\"
JA.... maar alleen als de DPI van de bron ook daadwerkelijk 96 is!

Beste Bert-Jan,

Slechts een klein puntje, maar wel een belangrijke.
Als ik een logo selecteer en deze rechts laat uitlijnen, overschrijdt
deze (in mijn geval) de pagina.
[edit: het gaat om facturen op PDF formaat; Word heb ik niet bekeken]

Ik heb voor de zekerheid meerdere afmetingen logo gebruikt, maar het probleem blijft.
Hoe groter het logo wordt, hoe groter de afwijking.

Kan het zijn dat er iets foutiefs is met de afmetingen van het plaatje of dat er ergens een margin fout insluipt?

Klein programmeerfoutje?

Groet,

Rogier

Nee die kende ik nog niet...
Maar ben al aan het kijken

Het ziet er wel veelbelovend uit.

Bert-jan,

Ik zal de factuur straks even doorsturen zoals gevraagd.
Het kan heel even duren, maar uiterlijk vanavond heb je hem in de mail.

Wat betreft FPDF template classes: helaas, ik heb ze niet (althans... als ik begrijp dat je classes bedoelt voor
template gebaseerd genereren van een PDF).
Het ligt wel in mijn bedoeling om er zelf te maken indien ik ze ook niet vinden kan, maar ik vrees dat ik
daar toch even goed over na moet denken wat betreft implementatie.
Wegens de toch vrij moeilijke implementatie van het PDF protocol zelf is dat toch niet het makkelijkste dat ik me kan voorstellen.

Ik had zelf gehoopt dat FPDI me verder kon helpen, maar die template klasse is meer om standaard templates in te voegen in FPDF.
Ik geloof niet dat daar standaard methodes waren voor templates zoals ik denk dat je ze bedoelt (met [waarde] \'tags\')

Zie http://www.setasign.de/products/pdf-php-solutions/fpdi/

Helaas is template based nu net datgene dat NIET beschikbaar is onder fpdf en hun script database.

Mijn eigen klasse om facturatie te realiseren was een voorbeeld van een behoorlijk specifieke implementatie.
Juist omdat acumulus hiervoor al mogelijkheden biedt, heb ik besloten om me aan te melden (op aanraden van een vriend)

Ik heb al wel een aantal specifieke implementaties met FPDF geschreven voor andere systemen,
maar deze hadden meer betrekking op toevoegen van standaard hoofdstuk-, paragraaf- en imagelayers
via een collectie klasse. Niet datgene wat nodig is voor Acumulus zelf... helaas.

Ik ben wel bereid eventueel hulp te verlenen bij problemen of implementatie met FPDF als je dat zou willen.
Mijn eigen \'basis\'-klasse is feitelijk een samenvoeging van de meest essentiele scripts van de fpdf database.
(denk hierbij aan de 40bit encryptie methode, Alpha based png images, custom headers/footers en de extended graphics modes)
 
Ik las nogal wat over macro\'s, maar hoop daar geen enkel gebruik van te hoeven maken.
Mijn uiteindelijke bedoeling is om helemaal niets meer te hoeven doen aan facturatie die direct vanuit acumulus komt,
met het oog op een eerdere opmerking dat een digitale factuur exact hetzelfde moet zijn als de (papieren) versie
die een klant ontvangt...  

Enfin,
houdt de mailbox in de gaten en alvast bedankt weer voor de reactie.

Groet,

Rogier

Bert-jan,

dank je voor de reactie.
Heb ik het wel goed dat een logo altijd een plaatje is?

Dat is misschien niet echt handig, omdat ik dan OF mijn bedrijfslogo OF een adreslogo moet maken.

Tevens zag ik dat jullie alles genereren mbv FPDF  .
Nu ben ik misschien een beetje cheeky, maar ik ben erg bekend met FPDF (hint).
Ook mijn voorbeeld (zie eerdere reply) is nl. gemaakt met fpdf

In hoeverre is het te verwachten dat eventuele template gebaseerde aanpassingen worden
geimplementeerd en in welk tijdsbestek?
En in hoeverre liggen bovenstaande wensen op een TODO-lijstje?

Alvast bedankt!

Groet,

Rogier

Geachte heren,

Bij deze sluit ik me hierbij aan.

Niet alleen zie ik graag het adres van de onderneming, maar daarbij de volledige details, te weten (in gegeven volgorde):
- naam onderneming
- adresgegevens onderneming
- Telefoonnummer
- KvK inschrijfnummer
- Bank- of gironummer
- IBAN
- BIC
- BTW nummer onderneming
- eventueel website van onderneming

[edit: ook een checkbox in de facturatie instellingen om dit wel/niet te doen voor de mensen die met briefpapier werken]

Daarnaast zou ik persoonlijk graag de volgende extra regels willen zien bij een factuur of offerte:
- BTW Nummer van de ontvangende, indien relevant of aanwezig
- IBAN als BIC nummer van de ontvangende, indien relevant (mogelijk door instellingen/opties facturen?)

E.e.a zou overigens wel betekenen dat het BTW nummer zoals deze in de huidige vorm verschijnt in de factuur
(onder de kop \"Factuur\") een andere locatie krijgt.

Ook zou het betekenen dat bij de invoer van een nieuwe relatie het KvK nummer, IBAN en/of BIC zou moeten worden ingevuld,
evenals bij de invoer van de gegevens van de onderneming.

Is het tevens ook mogelijk een debiteurencode mee te geven bij relaties?
Of is deze er reeds?

Groet,

Rogier

PS: Siel: ik kan, indien gewenst, wel een voorbeeld facturatie sturen met bovenstaande wensen.
Neem in dat geval even contact op