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...>
|
