Is it just me, or is this whole sub-system in need of a reboot? No offense to the developers who have worked on it.
I've spent a few hours trying to figure out how to make it so that the formatting will actually work to allow a useable pdf in the descendancy report. But I don't really understand what the heck is going on to produce the report. If you look at the source of the html version it looks like the whole report is made up of divs with absolute positioning and dimensions in points(??!!) with things layered on top of each other. There are double-spaces between words without using (a bad idea and probably one cause of formatting errors) and even the blank spaces are made up of empty divs it looks like. The footer is inconsistent in size and formatting between the first and other pages of the pdf version. Another probable cause of formatting issues is the fonts used. Arial in html and dejavu sans in the pdf. Anybody that's ever substituted 1 font for another will tell you that point size varies between different fonts. 8 points in one font can be like 12 points in another, so using absolute positioning and precisely sized divs just doesn't work well.
Looking at the php I'm not sure if tcpdf is even being used and if it is, it's a very old version compared to what is available on the tcpdf site. Just briefly looking at tcpdf it seems to be capable of outputting html and pdf and handling formatting, headers, footers and pagination. Which the report engine doesn't seem to be taking advantage of. But maybe I'm completely wrong about that.
It kind of seems to me like the report engine is trying to draw a picture by telling the monitor what to do with each pixel instead of just supplying an image.
Can someone that actually understands how the report engine and the various xml templates work try and explain things a bit? I have a good grasp of html but very basic php skills.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't think the forums of phpgedview are very active, Your question is in my opinion a very critical one and not being answered upon gives me a double feeling. Either no one uses the report engine, or everybody resides on another forum.
It's now a year later and there's still no answer.
Good Luck in 2010! Gerrit Bon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looking at the html descendancy report in v4.2.3, there are still places where multiple "normal" spaces are used, which of course render as a single space by a web browser. In one I've just generated I can see several 4-space gaps in the source.
The PDF however looks a lot better, and I do not see the inconsistencies mentioned. The only problem I would foresee is that the footer is too close to the paper edge, and therefore would be cropped (at best).
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mark:
If the footer is too close to the paper edge, you're using the wrong paper size. The default is A4, which is somewhat longer and a bit narrower than Letter.
The Reports sub-system has been completely re-written.
We know that there are still LOADS of problems with HTML reports. We've been concentrating on PDF reports, and will tackle HTML and possibly TeX as time permits.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Spaces are difficult. There are language variable that contains " ", such as pgv_lang, since the English don't use "born on BIRT:DATE", but other languages are using it.
So this text becomes:
bornpgv_langBIRT:DATE
The footer is too close? How close? Is the text cropped? Do you have a sample?
If you are into the reports, you can always override the defaults document settings by using:
<PGVRDoc bottommargin="" footermargin="">
-Im
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not overly worried about spaces in html reports. The rendering takes care of them, and the odd "extra" byte here and there is tiny.
But the PDF one, eg descendancy, just because the paper size is A4, doesn't mean that you should fill the entire page. Nearly all printers have a non-printable margin.
Yes, the date is almost entirely cropped off at the bottom of the page (just see the very top of the numbers, lowercase letters are not visible at all).
Which file has the document settings?
Mark
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have printed a couple of reports but no text was never cropped. Could this be a printer setting? Because this is not the paper size… The text ends up on the same line on all page sizes, counted in points, from the papers bottom.
Anyway… you can override the defaults in the xml files. Just add
footermargin="30"
into the existing PGVRDoc element. In the descendancy.xml, that would be on line: 38
If 30 point's is not enough, try 35 etc….
-Im
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is it just me, or is this whole sub-system in need of a reboot? No offense to the developers who have worked on it.
I've spent a few hours trying to figure out how to make it so that the formatting will actually work to allow a useable pdf in the descendancy report. But I don't really understand what the heck is going on to produce the report. If you look at the source of the html version it looks like the whole report is made up of divs with absolute positioning and dimensions in points(??!!) with things layered on top of each other. There are double-spaces between words without using (a bad idea and probably one cause of formatting errors) and even the blank spaces are made up of empty divs it looks like. The footer is inconsistent in size and formatting between the first and other pages of the pdf version. Another probable cause of formatting issues is the fonts used. Arial in html and dejavu sans in the pdf. Anybody that's ever substituted 1 font for another will tell you that point size varies between different fonts. 8 points in one font can be like 12 points in another, so using absolute positioning and precisely sized divs just doesn't work well.
Looking at the php I'm not sure if tcpdf is even being used and if it is, it's a very old version compared to what is available on the tcpdf site. Just briefly looking at tcpdf it seems to be capable of outputting html and pdf and handling formatting, headers, footers and pagination. Which the report engine doesn't seem to be taking advantage of. But maybe I'm completely wrong about that.
It kind of seems to me like the report engine is trying to draw a picture by telling the monitor what to do with each pixel instead of just supplying an image.
Can someone that actually understands how the report engine and the various xml templates work try and explain things a bit? I have a good grasp of html but very basic php skills.
I don't think the forums of phpgedview are very active, Your question is in my opinion a very critical one and not being answered upon gives me a double feeling. Either no one uses the report engine, or everybody resides on another forum.
It's now a year later and there's still no answer.
Good Luck in 2010! Gerrit Bon.
Looking at the html descendancy report in v4.2.3, there are still places where multiple "normal" spaces are used, which of course render as a single space by a web browser. In one I've just generated I can see several 4-space gaps in the source.
The PDF however looks a lot better, and I do not see the inconsistencies mentioned. The only problem I would foresee is that the footer is too close to the paper edge, and therefore would be cropped (at best).
Mark
Mark:
If the footer is too close to the paper edge, you're using the wrong paper size. The default is A4, which is somewhat longer and a bit narrower than Letter.
The Reports sub-system has been completely re-written.
We know that there are still LOADS of problems with HTML reports. We've been concentrating on PDF reports, and will tackle HTML and possibly TeX as time permits.
Mark,
Spaces are difficult. There are language variable that contains " ", such as pgv_lang, since the English don't use "born on BIRT:DATE", but other languages are using it.
So this text becomes:
bornpgv_langBIRT:DATE
The footer is too close? How close? Is the text cropped? Do you have a sample?
If you are into the reports, you can always override the defaults document settings by using:
<PGVRDoc bottommargin="" footermargin="">
-Im
I'm not overly worried about spaces in html reports. The rendering takes care of them, and the odd "extra" byte here and there is tiny.
But the PDF one, eg descendancy, just because the paper size is A4, doesn't mean that you should fill the entire page. Nearly all printers have a non-printable margin.
Yes, the date is almost entirely cropped off at the bottom of the page (just see the very top of the numbers, lowercase letters are not visible at all).
Which file has the document settings?
Mark
I have printed a couple of reports but no text was never cropped. Could this be a printer setting? Because this is not the paper size… The text ends up on the same line on all page sizes, counted in points, from the papers bottom.
Anyway… you can override the defaults in the xml files. Just add
footermargin="30"
into the existing PGVRDoc element. In the descendancy.xml, that would be on line: 38
If 30 point's is not enough, try 35 etc….
-Im