rlib-devel — RLIB Development Mailing List

Re: [Rlib-devel] Memory leaks

[William K. V. <wk...@us...>]

On Sun, 2005-06-05 at 11:55, Shannon Weyrick wrote:
> FWIW, this may be related to the segfaults I'm seeing in Apache (which 
> only happen after several reloads). Definitely seems like a memory issue.

This wouldn't be caused by memory leaks and I've not noticed any memory
overruns yet (I've not exercised all of the functionality, I.E. graphs).
Do you have a small test case or can you elaborate on
what rlib elements you are using?

Thanks,
William.

Re: [Rlib-devel] Memory leaks

[Bob D. <bd...@si...>]

> > 
> > Any chance you'll sign this http://rlib.sicompos.com/copyright_form.pdf
> > and send in a patch?
> 
> Can do.
> 

Great.  Let me know if you Fax or Mail it so I can be looking for it.

> 
> I'll be happy to I normally use "diff -u" format, is that OK?

Perfect

- Bob

Re: [Rlib-devel] Memory leaks

[Bob D. <bd...@si...>]

> FWIW, this may be related to the segfaults I'm seeing in Apache (which 
> only happen after several reloads). Definitely seems like a memory issue.

I'm not sure that not freeing something would cause a segfault...

I think the #1 cause for a segfault in RLIB is bad query/datasource and
not checking the return codes...

We use RLIB in 2 production environments so we stomp out any crashes we
see.  I have not fixed any in the past month or so....

> 
> Bob, any headway on the HTML/trim_links output issues?

Err no... I've been out of town/ busy catching up with other things.
Hopefully this week I'll have some time to poke @ it.


-- 
Bob Doan <bd...@si...>

Re: [Rlib-devel] Memory leaks

[William K. V. <wk...@us...>]

Hello Bob,
On Sun, 2005-06-05 at 11:11, Bob Doan wrote:
> On Sat, 2005-06-04 at 02:31 -0600, William K. Volkman wrote:
> > 	While perusing the source code I noticed that the
> > usage of libxml2 xmlGetProp was incorrect, the result of the
> > call should be freed via xmlFree.  I've made numerous fixes
> > to parsexml.c and free.c to fix the oversight.  
> 
> Hymm.. your right.
> 
> Any chance you'll sign this http://rlib.sicompos.com/copyright_form.pdf
> and send in a patch?

Can do.

> 
> 
> > While testing
> > those changes however I noticed that memory appeared to
> > be leaking at a value equal to the size of the report.  After
> > much pondering and stepping through things with gdb I've
> > located the cause however fixing it is non-trivial (removing
> > the memory leak fixes for libxml2 usage might help).  What
> > is happening is this, if a part only has one report a call
> > is made to rlib_evaulate_single_report_variables, which
> > in turn calls rlib_resolve_report_fields.  Later in the
> > make_report routine a call is made to rlib_layout_part_tr
> > which again will trigger a call to rlib_resolve_report_fields.
> > Thus stepping on the results of the first call and leaking
> > about a reports worth of memory.  
> 
> 
> > I'm not certain on how
> > to proceed from here, perhaps coding an equivalent of
> > rlib_report_free that only destroys the "dynamically"
> > allocated portions of the report, or perhaps add look before
> > allocating to the rlib_resolve_report_fields routine.  Anyway
> > since "parts" are the newly implemented feature it would
> > probably be best for me to punt and let the designer think
> > about what the rlib_evaulate_single_report_variables routine
> > is to accomplish and how best to do so.  If someone would like
> > the patches I made to parsexml.c and free.c let me know.
> 
> To fix this double free probably in rlib_layout_part_tr check 
> "report->is_the_only_report" and don't call it again if it is TRUE

Well that seems to be an elegantly simple fix, I'll try it and let you
know.

> Thanks for pointing these out.
> 
> Will you be able to send in a patch fixing all of this?

I'll be happy to I normally use "diff -u" format, is that OK?

Cheers,
William.

Re: [Rlib-devel] Rlib and python interface

[William K. V. <wk...@us...>]

Hello Bob,
On Sun, 2005-06-05 at 08:22, Bob Doan wrote:
> Patch looks correct.  Right now I only maintain the PHP bindings by
> hand.  
> 
> Right now there are a few things the Python(And other SWIG Interfaces)
> interface doesn't have, would you be willing to do any of these?  I have
> manually done these in PHP
These all look doable, I will have to do a little research on how to
implement the callbacks though, I don't think it will be too hard.

> 1) Array Data Source:  Use a 2D array as a data source
> 
> 2) Signals/Callbacks:  Right now in PHP we can attach to events in the
> RLIB engine and it will call back to a PHP function to do whatever...
> 
> 3) "m.xxx" environment variables.  In PHP it looks at the global symbol
> table for xxx and gets the value it needs

Should be easy.

> 
> 4) Custom functions.  Add custom functions to the engine that RLIB does
> not provide.  So in PHP:
> 
> rlib_add_function($rlib, "test", "test_function", 2);
> 
> function mike_roth($a, $b) {
> 	return "pancakes are yummier then $a and $b";
> }
> 
> Then in the RLIB XML:
> 
> you would do: ..... value="test('bacon', 'eggs')"
> 
If/when I get callbacks working this could naturally fall out of that.

> 
> Obviously if you did these things I would start making the bindings by
> hand in the future (Normally it's a copy and paste job)

My experience with SWIG is that it can be a quick way to get a prototype
set of bindings however in the long run, for stability, it is best to
switch to an interface developed specifically for the library.  The
pro-dominant reasons being object reference counting and memory
management.  Boost did a better job however is C++ and then of course
there is the strange C+python meld of Pyrex.

> Also, just out of curiosity what are you trying to use RLIB for?

We are a small startup company doing electronic transaction processing
and because of my work load we just hired a programmer to develop
reporting however accounting was having a nightmare trying to reconcile
our bank transactions to daily processing.  I was looking for a quick
way to get a report done, found rlib, and tried it.  It worked great ;-)
I usually hack code on the weekends to keep me relaxed so I thought
I could offer to build a custom python interface for you.

Thanks, 
William.

Re: [Rlib-devel] Memory leaks

[Shannon W. <we...@ro...>]

Bob Doan wrote:
> On Sat, 2005-06-04 at 02:31 -0600, William K. Volkman wrote:
> 
>>Hello,
>>	While perusing the source code I noticed that the
>>usage of libxml2 xmlGetProp was incorrect, the result of the
>>call should be freed via xmlFree.  I've made numerous fixes
>>to parsexml.c and free.c to fix the oversight.  
> 
> 
> Hymm.. your right.
> 
..
> 
> To fix this double free probably in rlib_layout_part_tr check 
> "report->is_the_only_report" and don't call it again if it is TRUE
> 
> Thanks for pointing these out.
> 
> Will you be able to send in a patch fixing all of this?
> 
> - Bob
> 

FWIW, this may be related to the segfaults I'm seeing in Apache (which 
only happen after several reloads). Definitely seems like a memory issue.

Bob, any headway on the HTML/trim_links output issues?

Thanks,
Shannon

Re: [Rlib-devel] Memory leaks

[Bob D. <bd...@si...>]

On Sat, 2005-06-04 at 02:31 -0600, William K. Volkman wrote:
> Hello,
> 	While perusing the source code I noticed that the
> usage of libxml2 xmlGetProp was incorrect, the result of the
> call should be freed via xmlFree.  I've made numerous fixes
> to parsexml.c and free.c to fix the oversight.  

Hymm.. your right.

Any chance you'll sign this http://rlib.sicompos.com/copyright_form.pdf
and send in a patch?


> While testing
> those changes however I noticed that memory appeared to
> be leaking at a value equal to the size of the report.  After
> much pondering and stepping through things with gdb I've
> located the cause however fixing it is non-trivial (removing
> the memory leak fixes for libxml2 usage might help).  What
> is happening is this, if a part only has one report a call
> is made to rlib_evaulate_single_report_variables, which
> in turn calls rlib_resolve_report_fields.  Later in the
> make_report routine a call is made to rlib_layout_part_tr
> which again will trigger a call to rlib_resolve_report_fields.
> Thus stepping on the results of the first call and leaking
> about a reports worth of memory.  


> I'm not certain on how
> to proceed from here, perhaps coding an equivalent of
> rlib_report_free that only destroys the "dynamically"
> allocated portions of the report, or perhaps add look before
> allocating to the rlib_resolve_report_fields routine.  Anyway
> since "parts" are the newly implemented feature it would
> probably be best for me to punt and let the designer think
> about what the rlib_evaulate_single_report_variables routine
> is to accomplish and how best to do so.  If someone would like
> the patches I made to parsexml.c and free.c let me know.

To fix this double free probably in rlib_layout_part_tr check 
"report->is_the_only_report" and don't call it again if it is TRUE

Thanks for pointing these out.

Will you be able to send in a patch fixing all of this?

- Bob

Re: [Rlib-devel] Rlib and python interface

[Bob D. <bd...@si...>]

Hi,

Patch looks correct.  Right now I only maintain the PHP bindings by
hand.  

Right now there are a few things the Python(And other SWIG Interfaces)
interface doesn't have, would you be willing to do any of these?  I have
manually done these in PHP

1) Array Data Source:  Use a 2D array as a data source

2) Signals/Callbacks:  Right now in PHP we can attach to events in the
RLIB engine and it will call back to a PHP function to do whatever...

3) "m.xxx" environment variables.  In PHP it looks at the global symbol
table for xxx and gets the value it needs

4) Custom functions.  Add custom functions to the engine that RLIB does
not provide.  So in PHP:

rlib_add_function($rlib, "test", "test_function", 2);

function mike_roth($a, $b) {
	return "pancakes are yummier then $a and $b";
}

Then in the RLIB XML:

you would do: ..... value="test('bacon', 'eggs')"

======

Obviously if you did these things I would start making the bindings by
hand in the future (Normally it's a copy and paste job)

Also, just out of curiosity what are you trying to use RLIB for?

- Bob

[Rlib-devel] Memory leaks

[William K. V. <wk...@us...>]

Hello,
	While perusing the source code I noticed that the
usage of libxml2 xmlGetProp was incorrect, the result of the
call should be freed via xmlFree.  I've made numerous fixes
to parsexml.c and free.c to fix the oversight.  While testing
those changes however I noticed that memory appeared to
be leaking at a value equal to the size of the report.  After
much pondering and stepping through things with gdb I've
located the cause however fixing it is non-trivial (removing
the memory leak fixes for libxml2 usage might help).  What
is happening is this, if a part only has one report a call
is made to rlib_evaulate_single_report_variables, which
in turn calls rlib_resolve_report_fields.  Later in the
make_report routine a call is made to rlib_layout_part_tr
which again will trigger a call to rlib_resolve_report_fields.
Thus stepping on the results of the first call and leaking
about a reports worth of memory.  I'm not certain on how
to proceed from here, perhaps coding an equivalent of
rlib_report_free that only destroys the "dynamically"
allocated portions of the report, or perhaps add look before
allocating to the rlib_resolve_report_fields routine.  Anyway
since "parts" are the newly implemented feature it would
probably be best for me to punt and let the designer think
about what the rlib_evaulate_single_report_variables routine
is to accomplish and how best to do so.  If someone would like
the patches I made to parsexml.c and free.c let me know.

Kind regards,
William.

[Rlib-devel] Rlib and python interface

[William K. V. <wk...@us...>]

Hello,
	I've been playing with Rlib for a couple of days and
been successful at getting some quick reports done.  One
problem I noticed was that rlib_get_output was not working
when images were included in reports.  Although it appears
that the python interface was originally done with SWIG I
didn't find the interface files.  My hope is that you've
only used SWIG to get the initial interface done and that
moving forward, changes would be made by editing the
python.c file.  Is that correct?  If so I would be willing
to spend some time cleaning up the python interface and
perhaps making it more "pythonic".  Anyway the fix to
get_output was trivial, patch attached.

Thank you,
William.

[Rlib-devel] New C# Bindings and Such

[Bob D. <bd...@si...>]

All,

I resynced all the bindings to the latest API.  This time I wrote a
script to do it so doing this in the future will be much easier and less
error prone

I also added c# bindings which work! :)

So At this moment we have

API: c, php, perl, python, java, c#

INPUTS: mysql, postgresql, xml, array data sources, odbc (which brings
in tons of other databases)

OUTPUTS: PDF, HTML, TXT, CSV

40+ functions inside the RLIB engine

Parts, graphs, custom functions, split details (mailing labels) call
backs, iterations, spec files, utf8, locales, and a working win32 port.

All wrapped up in a nice GPL package

I never could have imagined how much RLIB was going to improve when we
GPL'd it 2 years ago, and I think the best is yet to come.

Here are my plans:

For the next 2-3 months I want to make the documentation perfect and
provide nice RPMS/ Windows installers to get RLIB

I worked more on the WIKI some more over the weekend:

http://newrlib.sicom.com/

Anyone can add documentation.  Please document things that you know of.
If you don't know what something does just stub it out w/ a TODO.

I plan to have a lot of examples in the documentation.  You can see that
from what I have so far.  Please please please help document.  I suck at
it.

Thanks!

- bob

-- 
Bob Doan <bd...@si...>

Re: [Rlib-devel] Locale problem in RLIB

[Bob D. <bd...@si...>]

Applied!

I'm still thinking about your proposal for the setlocale stuff but since
this makes things more better We'll go with this for today

Thanks!

On Sun, 2005-05-15 at 21:51 +0200, Zoltan Boszormenyi wrote:
> Zoltan Boszormenyi írta:
> > But it didn't fix the sum, its still displayed with decimal dot
> > instead of a comma. All the other numbers above it contains comma.
> > They come directly from the SQL query. In RLIB's datasources,
> > the values are actually strings, aren't they? The actual values aren't
> > converted to numbers and back to strings, I suppose.
> > Only the report variables are treated differently.
> 
> Only a small fix was needed for
> libsrc/formatstring.c::rlib_number_sprintf()
> to fix it, and now the report variables also displayed with
> correct decimal separator according to the locale settings.
> 
> Best regards,
> Zoltán Böszörményi
-- 
Bob Doan <bd...@si...>

Re: [Rlib-devel] Locale problem in RLIB

[Zoltan B. <zb...@du...>]

Zoltan Boszormenyi =EDrta:
> But it didn't fix the sum, its still displayed with decimal dot
> instead of a comma. All the other numbers above it contains comma.
> They come directly from the SQL query. In RLIB's datasources,
> the values are actually strings, aren't they? The actual values aren't
> converted to numbers and back to strings, I suppose.
> Only the report variables are treated differently.

Only a small fix was needed for
libsrc/formatstring.c::rlib_number_sprintf()
to fix it, and now the report variables also displayed with
correct decimal separator according to the locale settings.

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

Re: [Rlib-devel] Locale problem in RLIB

[Zoltan B. <zb...@du...>]

Zoltan Boszormenyi =EDrta:
> Zoltan Boszormenyi =EDrta:
>=20
>> [val() (and other functions?)] doesn't conform to the locale settings,=
=20
>> it prints
>> decimal dots. I am investigating it.

I found that my original modification was correct. My "extra"
setlocale() call is needed. If you give a new locale to setlocale(),
then on error it returns NULL, on success it returns the newly set
locale. setlocale(LC_ALL, NULL) is needed to return the original locale.
But I saved some setlocale() calls anyway. I didn't recognize at first
that rpdf_make_page_stream() is called by rpdf_finalize(), so it's
enough to modify the locale in rpdf_finalize().

But it didn't fix the sum, its still displayed with decimal dot
instead of a comma. All the other numbers above it contains comma.
They come directly from the SQL query. In RLIB's datasources,
the values are actually strings, aren't they? The actual values aren't
converted to numbers and back to strings, I suppose.
Only the report variables are treated differently.

Besides that, my original proposal still stands.

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

Re: [Rlib-devel] Locale problem in RLIB

[Zoltan B. <zb...@du...>]

Zoltan Boszormenyi =EDrta:
> [val() (and other functions?)] doesn't conform to the locale settings, =
it prints
> decimal dots. I am investigating it.

How about changing rlib's locale behaviour?

I found that rlib_set_locale() changes the current locale
but doesn't save the current setting.

I would expect the following behaviour:

- If rlib_set_locale() was called, convert the given setting to UTF-8
   with make_utf8_locale() and save it. Also notice in struct rlib that
   we have set the locale.

- On every RLIB API call entry, remember the current locale locally.

   - If rlib_set_locale() was called, make the saved/converted setting
     current.

   - If rlib_set_locale() wasn't called, convert the currently set
     locale to utf8, make it current. (*)

- On exiting from the API call, restore the old locale we saved
   on entry.

(*) I know it makes RLIB slower but I don't know how much. I would have
to benchmark setlocale(). It may also be a NOP if the current locale is
already UTF-8 but you cannot know that

The advantage of the above is that RLIB doesn't suppose anything about
the current locale, e.g. one can play games with setlocale() between
RLIB API calls, so the locale setting may be different from the one
before rlib_init().

Call chains like this:

/************************************************/
   rlib_function1() {
     /* save locale */
     /* do something */
     /* restore locale */
   }
   rlib_function2() {
     /* save locale */
     /* do something that involves calling rlib_function1() */
     /* restore locale */
   }
/************************************************/

should be modified to this:

/************************************************/
   rlib_function1_internals() {
     /* do something */
   }
   rlib_function1() {
     /* save locale */
     rlib_function1_internals();
     /* restore locale */
   }
   rlib_function2() {
     /* save locale */
     /* do something that involves calling rlib_function1_internals() */
     /* restore locale */
   }
/************************************************/

so it doesn't make it even slower. It wouldn't cause bugs,
follow my proof:

Suppose the current locale is hu_HU in my application,
rlib_set_locale() is not called. The scenario would be:

1. In function2(): save current locale (hu_HU),
    convert it to UTF-8 -> hu_HU.utf8, call function1().

2. In function1(): save current locale (hu_HU.utf8),
    convert it to UTF-8, that's a NOP but extra work.
    On exit, restore the saved hu_HU.utf8.

3. On exit from function2(), restore hu_HU.

The other scenario is when I call rlib_set_locale() with e.g. en_US.
That seems to be converted to UTF-8 internally.

1. In function2(): save current locale (hu_HU), set the saved one
    (en_US.utf8), call function1().

2. In function1(): save the current locale (en_US.utf8) and set
    the saved one (en_US.utf8), again a NOP with extra work done.
    On exit, restore en_US.utf-8.

3. On exit from function2(), restore hu_HU.

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

Re: [Rlib-devel] Locale problem in RLIB

[Zoltan B. <zb...@du...>]

Bob Doan =EDrta:
>>Here it is. :-) It doesn't change the situation under Linux
>>e.g. the PDFs are still correctly readable with AcroRead, GV and XPDF
>>but RLIB didn't link under MingW, I must have been messed it
>>up somehow. Not the patch, my MingW installation.
>>I rechecked rlib-1.3.3 with my MingW installation's present state
>>and it's also doesn't link. I will reinstall it this evening.
>>In the meantime, would you please try to compile the present
>>CVS + this patch for me? ;-)
>>
>>
>>>If you do fix it @ the RPDF level perhaps you can biff the libsrc/pdf.=
c
>>>stuff also since RPDF is really the place to fix it
>>
>>I haven't touched that yet, the patch is for rpdf/rpdf.c only.
>>
>=20
>=20
> I believe the patch looks right.  in libsrc/pdf.c you could make
> USEPDFLOCALE 0 and give it a try.  Let me know if it still works for yo=
u
> in Windows and Linux.  This way we can clean libsrc/pdf.c

I tried that and I had to fix that up since a setlocale()
call references a local variable in two functions that only declared
when USEPDFLOCALE=3D1. After that, I recreated my PDFs and found that
there is a change in the output. Now all the floating point numbers
are printed with the locale's decimal separator and the summing
variable that was declared in the XML as

<Variables>
   <Variable name=3D"ossz_sum" value=3D"val(mainquery.osszeg)" type=3D"su=
m"=20
resetonbreak=3D""/>
   </Variables>

still works correctly, e.g. it sums the field.  I was afraid that val()
may break. But it doesn't conform to the locale settings, it prints
decimal dots. I am investigating it.

Also, I found that I can save one setlocale() call from my previous
patch, as it always returns the current settings. That wasn't crystal
clear from the manpage. And there was a bug in there too, I used
strdup() only in one of the two functions but freed in both. :-(

Here's the updated patch that deletes setlocale() calls from
libsrc/pdf.c, too, and fixes my bug.

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

Re: [Rlib-devel] RFE Real national encodings, etc

[Bob D. <bd...@si...>]

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

Re: [Rlib-devel] Locale problem in RLIB

[Bob D. <bd...@si...>]

> Here it is. :-) It doesn't change the situation under Linux
> e.g. the PDFs are still correctly readable with AcroRead, GV and XPDF
> but RLIB didn't link under MingW, I must have been messed it
> up somehow. Not the patch, my MingW installation.
> I rechecked rlib-1.3.3 with my MingW installation's present state
> and it's also doesn't link. I will reinstall it this evening.
> In the meantime, would you please try to compile the present
> CVS + this patch for me? ;-)
> 
> > If you do fix it @ the RPDF level perhaps you can biff the libsrc/pdf.c
> > stuff also since RPDF is really the place to fix it
> 
> I haven't touched that yet, the patch is for rpdf/rpdf.c only.
> 

I believe the patch looks right.  in libsrc/pdf.c you could make
USEPDFLOCALE 0 and give it a try.  Let me know if it still works for you
in Windows and Linux.  This way we can clean libsrc/pdf.c

[Rlib-devel] RFE Real national encodings, etc

[Zoltan B. <zb...@du...>]

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.

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.

Also, it would be nice if the manual was more comprehensive.
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! ;-)

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

Re: [Rlib-devel] Locale problem in RLIB

[Zoltan B. <zb...@du...>]

Bob Doan =EDrta:
> Hello,
>=20
>=20
>>Hungarian problems again. :-)
>=20
>=20
> ;)
>=20
> What you want to do seems Fine.  I know Chet @ SICOM did something in
> libsrc/pdf.c which is **supposed** to not allow this to happen.  Have a
> look in there.  It should really be fixed in RPDF though.
>=20
> Feel free to make the patch :)

Here it is. :-) It doesn't change the situation under Linux
e.g. the PDFs are still correctly readable with AcroRead, GV and XPDF
but RLIB didn't link under MingW, I must have been messed it
up somehow. Not the patch, my MingW installation.
I rechecked rlib-1.3.3 with my MingW installation's present state
and it's also doesn't link. I will reinstall it this evening.
In the meantime, would you please try to compile the present
CVS + this patch for me? ;-)

> If you do fix it @ the RPDF level perhaps you can biff the libsrc/pdf.c
> stuff also since RPDF is really the place to fix it

I haven't touched that yet, the patch is for rpdf/rpdf.c only.

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

Re: [Rlib-devel] html.c suppress_head patch

[Bob D. <bd...@si...>]

Applied

Ty!

- bob

On Fri, 2005-05-13 at 10:09 -0400, Shannon Weyrick wrote:
> Hi,
> 
> This patch implements a new a parameter for suppressing <head> and 
> <body> tag at the start of an HTML report. This is necessary when the 
> report will be embedded in another web page.
> 
> Shannon
> plain text document attachment (html.diff)
> Index: html.c
> ===================================================================
> RCS file: /cvsroot/rlib/rlib/libsrc/html.c,v
> retrieving revision 1.57
> diff -u -r1.57 html.c
> --- html.c	2 May 2005 18:21:43 -0000	1.57
> +++ html.c	13 May 2005 14:10:22 -0000
> @@ -339,6 +339,7 @@
>  	gchar buf[MAXSTRLEN];
>  	gchar *meta;
>  	gchar *link;
> +    	gchar *suppress_head;
>  	gint pages_across = part->pages_across;
>  
>  	OUTPUT_PRIVATE(r)->top = g_new0(GSList *, pages_across);
> @@ -347,21 +348,29 @@
>  	link = g_hash_table_lookup(r->output_parameters, "trim_links");
>  	if(link != NULL)
>  		OUTPUT(r)->trim_links = TRUE;
> -	sprintf(buf, "<head>\n<style type=\"text/css\">\n");
> -	print_text(r, buf, FALSE);
> -	sprintf(buf, "pre { margin:0; padding:0; margin-top:0; margin-bottom:0;}\n");
> -	print_text(r, buf, FALSE);
> -	print_text(r, "DIV { position: absolute; left: 0; }\n", FALSE);
> -	print_text(r, "TABLE { border: 0; cellspacing: 0; cellpadding: 0; width: 100%; }\n", FALSE);
> -	print_text(r, "</style>\n", FALSE);
> -	
> -	meta = g_hash_table_lookup(r->output_parameters, "meta");
> -	if(meta != NULL)
> -		print_text(r, meta, FALSE);
> -		
> -	print_text(r, "</head>\n", FALSE);
> -	
> -	print_text(r, "<body><table><tr><td><pre>", FALSE);	
> +
> +    	suppress_head = g_hash_table_lookup(r->output_parameters, "suppress_head");
> +    	if(suppress_head == NULL) {
> +
> +    		sprintf(buf, "<head>\n<style type=\"text/css\">\n");
> +    		print_text(r, buf, FALSE);
> +    		sprintf(buf, "pre { margin:0; padding:0; margin-top:0; margin-bottom:0;}\n");
> +    		print_text(r, buf, FALSE);
> +    		print_text(r, "DIV { position: absolute; left: 0; }\n", FALSE);
> +    		print_text(r, "TABLE { border: 0; cellspacing: 0; cellpadding: 0; width: 100%; }\n", FALSE);
> +    		print_text(r, "</style>\n", FALSE);
> +	
> +    		meta = g_hash_table_lookup(r->output_parameters, "meta");
> +    		if(meta != NULL)
> +    			print_text(r, meta, FALSE);
> +    		
> +    		print_text(r, "</head>\n", FALSE);
> +    		print_text(r, "<body>\n", FALSE);
> +
> +    	}
> +
> +    	print_text(r, "<table><tr><td><pre>", FALSE);
> +
>  }
>  
>  static void rlib_html_end_part(rlib *r, struct rlib_part *part) {

[Rlib-devel] html.c suppress_head patch

[Shannon W. <swe...@ro...>]

Hi,

This patch implements a new a parameter for suppressing <head> and 
<body> tag at the start of an HTML report. This is necessary when the 
report will be embedded in another web page.

Shannon

Re: [Rlib-devel] Locale problem in RLIB

[Bob D. <bd...@si...>]

Hello,

> Hungarian problems again. :-)

;)

What you want to do seems Fine.  I know Chet @ SICOM did something in
libsrc/pdf.c which is **supposed** to not allow this to happen.  Have a
look in there.  It should really be fixed in RPDF though.

Feel free to make the patch :)

If you do fix it @ the RPDF level perhaps you can biff the libsrc/pdf.c
stuff also since RPDF is really the place to fix it


> Now I reached a phase where my program actually compiles and works
> under Windows, and links to RLIB. But the resulting PDF is unusable.
> Of course I saved it in an O_BINARY file. The problem is that printf(),
> et.al. are conforming to the locale settings, so controlling numbers
> in the PDFs are written as e.g.
> 
> /Frpdf0 9,000 Tf
> 
> instead of
> 
> /Frpdf0 9.000 Tf
> 
> since the decimal separator is a comma, not a dot here in Hungary.
> 
> A simple trick will do it (I fixed unixODBC this way in 2000):
> 
> -------------------------------------------
> char *saved_locale;
> 
> saved_locale = strdup(setlocale(LC_ALL, NULL));
> 
> /* national decimal separator here */
> setlocale(LC_ALL, "C");
> /* decimal dots strictly required here */
> setlocale(LC_ALL, saved_locale);
> /* national decimal separator again */
> free(saved_locale);
> -------------------------------------------
> 
> Fortunately setlocale() exists under MingW, too.
> 
> I haven't made a patch against RPDF yet, but you know better
> where to fix it.

[Rlib-devel] RLIB locale problems

[Zoltan B. <zb...@du...>]

Hi Bob,

I don't know whether you received my mail, I send it again.
I definitely havent't got it back from rlib-devel.

So, Hungarian problems again.

Now I reached a phase where my program actually compiles and works
under Windows, and links to RLIB. But the resulting PDF is unusable.
Of course I saved it in an O_BINARY file. The problem is that printf(),
et.al. are conforming to the locale settings, so controlling numbers
in the PDFs are written as e.g.

/Frpdf0 9,000 Tf

instead of

/Frpdf0 9.000 Tf

since the decimal separator is a comma, not a dot here in Hungary.

A simple trick will do it (I fixed unixODBC this way in 2000):

-------------------------------------------
char *saved_locale;

saved_locale =3D strdup(setlocale(LC_ALL, NULL));

/* national decimal separator here */
setlocale(LC_ALL, "C");
/* decimal dots strictly required here */
setlocale(LC_ALL, saved_locale);
/* national decimal separator again */
free(saved_locale);
-------------------------------------------

Fortunately setlocale() exists under MingW, too.

I haven't made a patch against RPDF yet, but you know better
where to fix it.

On a sidenote, I don't know why it doesn't happen
under Linux with GTK-2.4, I have to investigate it.
Here's the only difference at program initialization:

...
#ifdef NEED_WINDOWS_H
   locale =3D g_win32_getlocale();
#else
   locale =3D g_strdup("UTF-8");
#endif
   bind_textdomain_codeset (GETTEXT_PACKAGE, locale);
...

Maybe bind_textdomain_codeset() doesn't call setlocale()
but g_win32_getlocale() does.

AFAIK under GTK-1.2, either bindtextdomain() or gnome_init()
called setlocale(). Although I initialize GTK2 as

   gtk_set_locale ();
   gtk_init (&argc, &argv);

and my debugging printf() prints doubles with decimal comma,
RLIB produces correct PDFs under Linux. Strange.

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

[Rlib-devel] Locale problem in RLIB

[Zoltan B. <zb...@du...>]

Hi Bob,

Hungarian problems again. :-)

Now I reached a phase where my program actually compiles and works
under Windows, and links to RLIB. But the resulting PDF is unusable.
Of course I saved it in an O_BINARY file. The problem is that printf(),
et.al. are conforming to the locale settings, so controlling numbers
in the PDFs are written as e.g.

/Frpdf0 9,000 Tf

instead of

/Frpdf0 9.000 Tf

since the decimal separator is a comma, not a dot here in Hungary.

A simple trick will do it (I fixed unixODBC this way in 2000):

-------------------------------------------
char *saved_locale;

saved_locale =3D strdup(setlocale(LC_ALL, NULL));

/* national decimal separator here */
setlocale(LC_ALL, "C");
/* decimal dots strictly required here */
setlocale(LC_ALL, saved_locale);
/* national decimal separator again */
free(saved_locale);
-------------------------------------------

Fortunately setlocale() exists under MingW, too.

I haven't made a patch against RPDF yet, but you know better
where to fix it.

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi