From: Bob D. <bd...@si...> - 2005-05-14 13:05:51
|
On Sat, 2005-05-14 at 08:51 +0200, Zoltan Boszormenyi wrote: > Hi, > > I came across this site: http://www.fpdf.org/ > This stuff can also create PDFs but can also embed > fonts in given charsets in them. The whole stuff > is written in PHP and the license is freeware > for any (business or home) use so we could rewrite > it in C for RPDF. I was going to use that as my model for the font loading. Problem is I have been so busy w/ other things I have not had the chance. My guess is that you should be able to port it ;) If you make the font loading work in RPDF I can handle the plumbing in RLIB so it could use the different "fixed" fonts > > Also, how about modifying RLIB and RPDF in such a way > that field width could be given in some metric units > and also be able to use proportional fonts? > I showed RLIB to some of my collegues and they said > the reports would be nicer if the font wouldn't be courier. > PDF provides 14 default fonts and also the embedded ones. Two problems here. Having different field heights on the fixed font in RLIB would not be too hard at this point because a few months ago I made RLIB inspect the whole "line" for the max height because of images on a line. Non Fixed fonts are going to be harder. RLIB currently uses a FIXED layout engine and everything really boils down char counts of things. Like the "first_name" field is 20 chars long. RLIB knows say the width of a char of a 12 point font so it knows it will take up say 20(chars)*12(point)*(600 pix per point)/72.00(DPI) Rlib won't be able to do this because width_of("W") != width_of("i"). There are two ways to solve the problem. One is allow the user to specify the width of a field in percent so say first_name width is "20%" This is not exactly ideal because someone's first name might be "WWWWWWWWWWWWWWWWWWWWWWWWWWWW" which would be really wide and might not fit. The proper thing to do would then be to change RLIB from a 1 pass payout engine to a 2 pass layout engine for non fixed with fonts. It would lay things out much like HTML does. By first going though and looking at the widths of all the fields in a table and then determine the final width of the columns that way. But before any of this can happen we need to have font loading in RPDF ;) > > Also, it would be nice if the manual was more comprehensive. Agree. > I am just started using RLIB and the manual doesn't help too much. > I haven't used any reporting software before, so I am a real newbie > in this field. E.g. the manual doesn't document all internal variables, > I know totpages exists because you discussed it on the mailing list. > It required a fair amount of experimenting to find out that > a sum of a field across all records needs to be in <ReportFooter> > to be displayed at the end and doesn't need any breaks. > It's logical but not documented. A dummies' guide for RLIB with many > examples, please! ;-) We're working on it. I think I'm going to move the RLIB documentation to a wiki for a little while so everyone in the community can edit it. ************************************************************* Who out there in user land would be willing to help out???????? ************************************************************** For examples see: src/examples/php But we really need to beef things up. FYI this weekend I plan to poke @ c# support in RLIB and a script to automatically generate all the bindings and what not -- Bob Doan <bd...@si...> |