rlib-devel Mailing List for RLIB -Report Engine (Page 13)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

> > What is the license on the nl_langinfo stuff? 
> 
> GPL

Are you sure it's GPL??  nl_langinfo stuff in glibc is LGPL.  Did you
write this or did you get it from somewhere else?

- bob

Bob Doan =C3=ADrta:
> Thank you!  Thank you!  Thank you!
>=20
> Have you actually produced a report in windows? ;)

Not yet. And there is a bug still in my RLIB work.
When "make" is finished, "ldd libr.dll" produces the library list
I expect. When I run "make install", libr.dll is relinked
and after that, the DLL file is not what ldd expects.
I am trying to do something with it.

> I'm going to assume=20
>=20
> DEF_FILE=3Dlibrpdf.def
> if WIN32
> def_ldflags=3D-Wl,--output-def,$(DEF_FILE) -export-dynamic -avoid-versi=
on
> endif
>=20
> Is the magic required to make the windows dll's.

Almost. The "-no-undefined" linker option and
the occurence of AC_LIBTOOL_WIN32_DLL before
AC_PROG_LIBTOOL does most of the work.
The -export-dynamic is something I am not sure is needed
but the -avoid-version is because I wanted to too libr.dll
instead of libr-1.dll or libr-1-3-3.dll.

> What is the license on the nl_langinfo stuff?=20

GPL

> We should do something nice about strfmon.  One would think it's lgpl'd
> code and if it is we might want to include it.
>=20
> Out of curiousity do you have any experiences packaging WIN32 programs?

Very little.

> I think it would be in RLIB's best interest to have a nice installable
> package (Most windows users probably won't want to go through what you
> went through in order to get this going ;))
>=20
> I see you fixed my automake flaws.  Were you planning on making a RLIB
> RPM?

That was the first thing I did on Linux. :-) I will send my RPM
specfile, too.

> Thanks for the strings.  I'll test w/ them tomorrow.

You're welcome.

> The bottom line is the patch looks very nice.  When do you think you
> will find yourself near a printer to print/sign the (c) thingie??? :)

Today. I am going back to my primary work.

Best regards,
Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi

Thank you!  Thank you!  Thank you!

Have you actually produced a report in windows? ;)

I'm going to assume 

DEF_FILE=librpdf.def
if WIN32
def_ldflags=-Wl,--output-def,$(DEF_FILE) -export-dynamic -avoid-version
endif

Is the magic required to make the windows dll's.

What is the license on the nl_langinfo stuff? 

We should do something nice about strfmon.  One would think it's lgpl'd
code and if it is we might want to include it.

Out of curiousity do you have any experiences packaging WIN32 programs?
I think it would be in RLIB's best interest to have a nice installable
package (Most windows users probably won't want to go through what you
went through in order to get this going ;))

I see you fixed my automake flaws.  Were you planning on making a RLIB
RPM?

Thanks for the strings.  I'll test w/ them tomorrow.

The bottom line is the patch looks very nice.  When do you think you
will find yourself near a printer to print/sign the (c) thingie??? :)

- bob

On Thu, 2005-04-14 at 01:14 +0200, Zoltan Boszormenyi wrote:
> > Bob Doan írta:
> >> I'm using your name as my test bed to make sure this all works.  :)
> 
> Here's another two test strings:
> 
> árvíztűrő tükörfúrógép
> ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP
> 
> They are the standard test strings in Hungary to see
> whether a charset conversion or a printer font really
> contains the lower- and uppercase Hungarian accented
> characters.
> 
> And now something completely the same.
> 
> Ladies and gentlemen!
> 
> <drumroll>
> 
> Allow me to introduce RLIB Windows port!
> 
> </drumroll>
> 
> Please review the Makefile.am changes.
> I made librpdf and libr to compile as normal DLLs
> and libr-odbc and the bindings/* as loadable modules.
> 
> There may still be rough edges, but that shouldn't be
> too hard to fix now.
> 
> This time I bzipped the patch so the mailing list filter
> lets it through the 40KB limit. It's yet another megapatch
> but now it's against the current CVS.
> 
> Cheers!
> 
> Best regards,
> Zoltán Böszörményi
-- 
Bob Doan <bd...@si...>

> Bob Doan =EDrta:
>> I'm using your name as my test bed to make sure this all works.  :)

Here's another two test strings:

=E1rv=EDzt=FBr=F5 t=FCk=F6rf=FAr=F3g=E9p
=C1RV=CDZT=DBR=D5 T=DCK=D6RF=DAR=D3G=C9P

They are the standard test strings in Hungary to see
whether a charset conversion or a printer font really
contains the lower- and uppercase Hungarian accented
characters.

And now something completely the same.

Ladies and gentlemen!

<drumroll>

Allow me to introduce RLIB Windows port!

</drumroll>

Please review the Makefile.am changes.
I made librpdf and libr to compile as normal DLLs
and libr-odbc and the bindings/* as loadable modules.

There may still be rough edges, but that shouldn't be
too hard to fix now.

This time I bzipped the patch so the mailing list filter
lets it through the 40KB limit. It's yet another megapatch
but now it's against the current CVS.

Cheers!

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

Bob Doan =EDrta:
>>I don't know the PDF internals enough to answer that.
>>I think for my purpose it would be enough to accept the strings
>>in UTF-8 and output them in ISO-8859-2. That would require only iconv.
>=20
>=20
>=20
> Ok.. I'm changing things around a bit from how it worked in RLIB 1.2.0
>=20
> How does this sound:
>=20
> 1) LIBXML is always utf8 and no work is needed there
>=20
> 2) DataSources could really be in any encoding.  I'll add a new api
> rlib_datasource_set_encoder(r, "data_source", "iconv decoding...");
>=20
> 3) Paramaters passed in from rlib_add_parameter don't need to be touche=
d
> because the user can do this on their own (it will be assumed they are
> in UTF8)
>=20
> In the actual engine RLIB will use g_utf8 functions to do all the strin=
g
> stuff (We have wrappers in util.h.. I'll preform an audit to make sure
> nothing has fallen out)
>=20
> Outputs:
>=20
> We will need to typically encode the output in order to make things
> work. =20
>=20
> so rlib_set_output_encoding(r, "iconv encoding");
>=20
> In PDF for sure we probably need to do this.  In HTML we need to do thi=
s
> **I think** and in the <HEAD> do something like
> content=3D"text/html;charset=3Diso-8859-2"

It's fine for me. Just yell when it works, I will test it.
In the meantime I think I figured out what's the difference
between how xine and rlib does. Black magic, thy name is automake! :-)

> I'm using your name as my test bed to make sure this all works.  :)

OK. :-)

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

> I don't know the PDF internals enough to answer that.
> I think for my purpose it would be enough to accept the strings
> in UTF-8 and output them in ISO-8859-2. That would require only iconv.

Ok.. I'm changing things around a bit from how it worked in RLIB 1.2.0

How does this sound:

1) LIBXML is always utf8 and no work is needed there

2) DataSources could really be in any encoding.  I'll add a new api
rlib_datasource_set_encoder(r, "data_source", "iconv decoding...");

3) Paramaters passed in from rlib_add_parameter don't need to be touched
because the user can do this on their own (it will be assumed they are
in UTF8)

In the actual engine RLIB will use g_utf8 functions to do all the string
stuff (We have wrappers in util.h.. I'll preform an audit to make sure
nothing has fallen out)

Outputs:

We will need to typically encode the output in order to make things
work.  

so rlib_set_output_encoding(r, "iconv encoding");

In PDF for sure we probably need to do this.  In HTML we need to do this
**I think** and in the <HEAD> do something like
content="text/html;charset=iso-8859-2" 

I'm using your name as my test bed to make sure this all works.  :)

- bob

> I was talking about how xine compiles its' shared libs and
> plugins, because under Windows even rlib/rpdf/test does not
> link because librpdf.a is empty. Somehow the non-static
> functions aren't exported.

Ahhhh... Ok :)
I get it

Good Luck w/ that.

- bob

Bob Doan =C3=ADrta:
> RLIB uses g_module stuff so it should not be doing any
> dlopen's.....?????

I was talking about how xine compiles its' shared libs and
plugins, because under Windows even rlib/rpdf/test does not
link because librpdf.a is empty. Somehow the non-static
functions aren't exported.

Best regards,
Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi

On Wed, 2005-04-13 at 18:14 +0200, Zoltan Boszormenyi wrote:
> Bob Doan =C3=ADrta:
> > Hym... Back when I was trying the port RLIB to windows I recall libto=
ol
> > not wanting to make a DLL.
> >=20
> > Dunno if you are having these problems.
> >=20
> > Did you try to manually create the dll w/ gcc?
> >=20
> > I also tried to manually make a dll and I don't think I could ever ge=
t
> > it to work.  I didn't have symbol problems, but I think it kept makin=
g a
> > static library.  I assume because of your work in windows you have mo=
re
> > experience w/ this
>=20
> I am looking at how Xine does all this.  Xine has a working Win32 port
> and it uses dlopen very heavily, too, to open all of its plugins.

RLIB uses g_module stuff so it should not be doing any
dlopen's.....?????

>=20
> > FYI, I'm working on UTF8 for you.  But I have a question.  Do you kno=
w
> > of any way to put UTF8 in PDF documents?  I kinda think its not going=
 to
> > work.  We can only go as far as Adobe's fonts support things.  RPDF
> > could be made utf8 friendly but it might be pointless unless it can b=
e
> > done inside a PDF document.
>=20
> I don't know the PDF internals enough to answer that.
> I think for my purpose it would be enough to accept the strings
> in UTF-8 and output them in ISO-8859-2. That would require only iconv.
>=20
> Best regards,
> Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi

Bob Doan =C3=ADrta:
> Hym... Back when I was trying the port RLIB to windows I recall libtool
> not wanting to make a DLL.
>=20
> Dunno if you are having these problems.
>=20
> Did you try to manually create the dll w/ gcc?
>=20
> I also tried to manually make a dll and I don't think I could ever get
> it to work.  I didn't have symbol problems, but I think it kept making =
a
> static library.  I assume because of your work in windows you have more
> experience w/ this

I am looking at how Xine does all this.  Xine has a working Win32 port
and it uses dlopen very heavily, too, to open all of its plugins.

> FYI, I'm working on UTF8 for you.  But I have a question.  Do you know
> of any way to put UTF8 in PDF documents?  I kinda think its not going t=
o
> work.  We can only go as far as Adobe's fonts support things.  RPDF
> could be made utf8 friendly but it might be pointless unless it can be
> done inside a PDF document.

I don't know the PDF internals enough to answer that.
I think for my purpose it would be enough to accept the strings
in UTF-8 and output them in ISO-8859-2. That would require only iconv.

Best regards,
Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi

Derek Giromini =C3=ADrta:
> Would the ODBC fix possibly address an issue my colleague and I have
> observed where obtaining a column of data from a small table in MySQL v=
ia
> ODBC was displaying a resultset with the first three rows of data missi=
ng
> and the last three rows of data repeat the last row of data in the tabl=
e? I
> haven't used the patch yet, but I haven't had enough time to delve into=
 this
> particular issue with ODBC along with overcoming the lack of SQLRowCoun=
t
> from Oracle.
>=20
> e.g. column in table:
>=20
> DATUM1
> DATUM2
> DATUM3
> DATUM4
> DATUM5
> DATUM6
> DATUM7
> DATUM8
>=20
> output from query:
>=20
> DATUM4
> DATUM5
> DATUM6
> DATUM7
> DATUM8
> DATUM8
> DATUM8
> DATUM8
>=20
> Cheers,
> --Derek Giromini

Exactly that was my problem. The patch fixes it.

Best regards,
Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi

I suspect so.  For sure the part about the last 3 rows.  

Can you try Zontan's first patch which only addresses the ODBC part and
let me know how it works?

I suspect writing an ODBC connector which doesn't need the row count
won't be that hard.  I just don't have anything to test it with (I don't
have oracle here)  

- bob

On Wed, 2005-04-13 at 07:35 -0500, Derek Giromini wrote:
> Would the ODBC fix possibly address an issue my colleague and I have
> observed where obtaining a column of data from a small table in MySQL via
> ODBC was displaying a resultset with the first three rows of data missing
> and the last three rows of data repeat the last row of data in the table? I
> haven't used the patch yet, but I haven't had enough time to delve into this
> particular issue with ODBC along with overcoming the lack of SQLRowCount
> from Oracle.
> 
> e.g. column in table:
> 
> DATUM1
> DATUM2
> DATUM3
> DATUM4
> DATUM5
> DATUM6
> DATUM7
> DATUM8
> 
> output from query:
> 
> DATUM4
> DATUM5
> DATUM6
> DATUM7
> DATUM8
> DATUM8
> DATUM8
> DATUM8
> 
> Cheers,
> --Derek Giromini
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Rlib-devel mailing list
> Rli...@li...
> https://lists.sourceforge.net/lists/listinfo/rlib-devel

Hym... Back when I was trying the port RLIB to windows I recall libtool
not wanting to make a DLL.

Dunno if you are having these problems.

Did you try to manually create the dll w/ gcc?

I also tried to manually make a dll and I don't think I could ever get
it to work.  I didn't have symbol problems, but I think it kept making a
static library.  I assume because of your work in windows you have more
experience w/ this

FYI, I'm working on UTF8 for you.  But I have a question.  Do you know
of any way to put UTF8 in PDF documents?  I kinda think its not going to
work.  We can only go as far as Adobe's fonts support things.  RPDF
could be made utf8 friendly but it might be pointless unless it can be
done inside a PDF document.

- bob

On Wed, 2005-04-13 at 06:38 +0200, Zoltan Boszormenyi wrote:
> Bob Doan =C3=ADrta:
> > Nice!
> >=20
> > Great work so far.
> >=20
> > Did you have any luck getting a rpdf.dll?  That is going to be much
>=20
> Unfortunately not. I tried to link it to everything glib2 and gmodule2
> are linked to: -lwsock32 -lkernel32 -lmsvcrt -lshlwapi, etc. No success.
>=20
> > easier then getting a rlib.dll.  rpdf only depends on GLIB2.
> >=20
> > Is there any chance you can work with RLIB's CVS?  Some stuff has
> > changed since the 1.3.2 release (Especially in output performance)
>=20
> OK, I will do a cvs checkout.
>=20
> Best regards,
> Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi

Would the ODBC fix possibly address an issue my colleague and I have
observed where obtaining a column of data from a small table in MySQL via
ODBC was displaying a resultset with the first three rows of data missing
and the last three rows of data repeat the last row of data in the table? I
haven't used the patch yet, but I haven't had enough time to delve into this
particular issue with ODBC along with overcoming the lack of SQLRowCount
from Oracle.

e.g. column in table:

DATUM1
DATUM2
DATUM3
DATUM4
DATUM5
DATUM6
DATUM7
DATUM8

output from query:

DATUM4
DATUM5
DATUM6
DATUM7
DATUM8
DATUM8
DATUM8
DATUM8

Cheers,
--Derek Giromini

Bob Doan =C3=ADrta:
> Nice!
>=20
> Great work so far.
>=20
> Did you have any luck getting a rpdf.dll?  That is going to be much

Unfortunately not. I tried to link it to everything glib2 and gmodule2
are linked to: -lwsock32 -lkernel32 -lmsvcrt -lshlwapi, etc. No success.

> easier then getting a rlib.dll.  rpdf only depends on GLIB2.
>=20
> Is there any chance you can work with RLIB's CVS?  Some stuff has
> changed since the 1.3.2 release (Especially in output performance)

OK, I will do a cvs checkout.

Best regards,
Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi

Nice!

Great work so far.

Did you have any luck getting a rpdf.dll?  That is going to be much
easier then getting a rlib.dll.  rpdf only depends on GLIB2.

Is there any chance you can work with RLIB's CVS?  Some stuff has
changed since the 1.3.2 release (Especially in output performance)

- bob

On Tue, 2005-04-12 at 11:26 +0200, Zoltan Boszormenyi wrote:
> Bob Doan =C3=ADrta:
> > Hello,
> >=20
> > On Mon, 2005-04-11 at 13:47 +0200, Zoltan Boszormenyi wrote:
> >=20
> >>Hi,
> >>
> >>I am experimenting with this report maker software to finally
> >>deploy it in a multiplatform environment. I make my (GPLed) program
> >>under Fedora Core 3/x86-64 and will compile it for Windows with MingW.
> >=20
> >=20
> > Cool!
>=20
> Thanks. :-)
>=20
> > One of the reasons UTF-8 support is half ass in RLIB is because UTF-8
> > PDF Support is not there at all.
>=20
> I see.
>=20
> > You should probably make your encoding "ISO-8859-2" in the xml here i=
n
> > order to make the characters come out correctly.
>=20
> Thinking about a bit more, the explicit encoding is correct, as
> the XML file itself IS UTF-8. libxml uses iconv and converts
> the strings to the encoding you feed it. I'll leave it as it is.
>=20
> > If you make RLIB compile in windows with MingGW I'll make sure UTF-8
> > Support works for you :).  Cygwin/mingw and -mno-cygwin have been
>=20
> Thanks. :-)
>=20
> > driving me nuts trying to make windows DLL's
>=20
> :-)
>=20
> > Yes.  I never use the ODBC stuff and I did it a year ago for some dud=
e
> > as a favor and I never maintained it or really checked that it worked
> > properly ;)
>=20
> ODBC is truly cross-platform, that's why I use it whenever I can.
>=20
> > Patch looks nice.  I'll apply it as soon as you sign the copyright
> > assignment.
>=20
> Thanks. Here's a much bigger patch, that also contains the previous one.
> What it does:
>=20
> - RLIB now uses the Glib2 GINT_TO_POINTER() and GPOINTER_TO_INT()
>    macros, as they compile without warnings and work everywhere.
>    The explicit casts "(type)var" do not.
> - Detects the host system at compilation time, so Windows/Cygwin/MingW
>    is distinguished.
> - Detects ODBC on Windows, includes <windows.h> before <sql.h>
>    and uses -lodbc32 instead of -lodbc.
> - Some Makefile.am magic, to help RPM packaging. It's not polite to
>    override ${libdir} and ${includedir} in subdirectories...
> - Detects presence of <langinfo.h> and uses internal implementation of
>    nl_langinfo() if missing.
> - Detects presence of <sys/resource.h> and disable crash detection
>    if missing.
> - RLIB already detects presence of <monetary.h> but does not follow
>    that if it's missing then strfmon() will also be missing. I just
>    replaced it with an sprintf(buf, "%.2lf", d) in this case. You may
>    have a better idea, though. :-)
> - On Cygwin/MingW, it detects older or newer compilers and uses
>    the proper -fnative-struct or -mms-bitfields compiler option.
>    Bitfields in structs are different on Windows.
> - Compiles everything with -D_GNU_SOURCE. It's mainly because of
>    llabs() declaration is missing if -D_ISO99_SOURCE is not defined
>    but this isn't enough: e.g. strcasecmp() is a GNU extension and
>    -D_GNU_SOURCE is needed to compile cleanly.
> - gettimeofday() is missing from MingW, the unique filename creation
>    in GD support needs this. I used tempnam() for this purpose if
>    gettimeofday() is not found. I haven't actually tested it, yet.
> - The previously sent ODBC fix and since <sql.h> is a system header
>    under Windows, its inclusion needs #define WINDOWS_LEAN_AND_MEAN 1
>    and also #include <windows.h>
> - Replaced bzero(x,y) with memset(x, 0, y) everywhere.
> - Deleted #include <sys/resource.h> where not needed.
> - Defined LC_MESSAGES if it's not already defined. Apparently, it's
>    missing under MingW.
> - rlib.pc do not list -lcpdf as linkage dependence.
>=20
> OK, so this megapatch enabled to compile RLIB under MingW-3.1.
> The compilation went without warnings on MingW, I still get some
> [u]int64 <-> long long size difference warnings under
> Fedora Core 3/x86-64. long long is 128 bits on 64 bit systems.
>=20
> Unfortunately, under MingW, only static libraries get built, even if I =
run
> ./configure --enable-shared
>=20
> I get this whenever the final libs are to be built:
>=20
> libtool: link: warning: undefined symbols not allowed in i686-pc-mingw3=
2=20
> shared libraries
>=20
> So if you want to use RLIB under MingW, you have to explicitly link to
> -lr -lrpdf -lr-odbc for now.
>=20
> And collecting the stuff for RLIB to actually link was quite tricky.
> I will make a short HOWTO to describe the procedure in some days.
>=20
> So, where's the UTF-8 support in RLIB? ;-)
>=20
> Best regards,
> Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi

Zoltan Boszormenyi =EDrta:
> So if you want to use RLIB under MingW, you have to explicitly link to
> -lr -lrpdf -lr-odbc for now.

It does not work, since the datasource libs are dlopen()ed.
I have to work out how to create the DLLs under MingW...

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

Bob Doan =EDrta:
> Hello,
>=20
> On Mon, 2005-04-11 at 13:47 +0200, Zoltan Boszormenyi wrote:
>=20
>>Hi,
>>
>>I am experimenting with this report maker software to finally
>>deploy it in a multiplatform environment. I make my (GPLed) program
>>under Fedora Core 3/x86-64 and will compile it for Windows with MingW.
>=20
>=20
> Cool!

Thanks. :-)

> One of the reasons UTF-8 support is half ass in RLIB is because UTF-8
> PDF Support is not there at all.

I see.

> You should probably make your encoding "ISO-8859-2" in the xml here in
> order to make the characters come out correctly.

Thinking about a bit more, the explicit encoding is correct, as
the XML file itself IS UTF-8. libxml uses iconv and converts
the strings to the encoding you feed it. I'll leave it as it is.

> If you make RLIB compile in windows with MingGW I'll make sure UTF-8
> Support works for you :).  Cygwin/mingw and -mno-cygwin have been

Thanks. :-)

> driving me nuts trying to make windows DLL's

:-)

> Yes.  I never use the ODBC stuff and I did it a year ago for some dude
> as a favor and I never maintained it or really checked that it worked
> properly ;)

ODBC is truly cross-platform, that's why I use it whenever I can.

> Patch looks nice.  I'll apply it as soon as you sign the copyright
> assignment.

Thanks. Here's a much bigger patch, that also contains the previous one.
What it does:

- RLIB now uses the Glib2 GINT_TO_POINTER() and GPOINTER_TO_INT()
   macros, as they compile without warnings and work everywhere.
   The explicit casts "(type)var" do not.
- Detects the host system at compilation time, so Windows/Cygwin/MingW
   is distinguished.
- Detects ODBC on Windows, includes <windows.h> before <sql.h>
   and uses -lodbc32 instead of -lodbc.
- Some Makefile.am magic, to help RPM packaging. It's not polite to
   override ${libdir} and ${includedir} in subdirectories...
- Detects presence of <langinfo.h> and uses internal implementation of
   nl_langinfo() if missing.
- Detects presence of <sys/resource.h> and disable crash detection
   if missing.
- RLIB already detects presence of <monetary.h> but does not follow
   that if it's missing then strfmon() will also be missing. I just
   replaced it with an sprintf(buf, "%.2lf", d) in this case. You may
   have a better idea, though. :-)
- On Cygwin/MingW, it detects older or newer compilers and uses
   the proper -fnative-struct or -mms-bitfields compiler option.
   Bitfields in structs are different on Windows.
- Compiles everything with -D_GNU_SOURCE. It's mainly because of
   llabs() declaration is missing if -D_ISO99_SOURCE is not defined
   but this isn't enough: e.g. strcasecmp() is a GNU extension and
   -D_GNU_SOURCE is needed to compile cleanly.
- gettimeofday() is missing from MingW, the unique filename creation
   in GD support needs this. I used tempnam() for this purpose if
   gettimeofday() is not found. I haven't actually tested it, yet.
- The previously sent ODBC fix and since <sql.h> is a system header
   under Windows, its inclusion needs #define WINDOWS_LEAN_AND_MEAN 1
   and also #include <windows.h>
- Replaced bzero(x,y) with memset(x, 0, y) everywhere.
- Deleted #include <sys/resource.h> where not needed.
- Defined LC_MESSAGES if it's not already defined. Apparently, it's
   missing under MingW.
- rlib.pc do not list -lcpdf as linkage dependence.

OK, so this megapatch enabled to compile RLIB under MingW-3.1.
The compilation went without warnings on MingW, I still get some
[u]int64 <-> long long size difference warnings under
Fedora Core 3/x86-64. long long is 128 bits on 64 bit systems.

Unfortunately, under MingW, only static libraries get built, even if I ru=
n
./configure --enable-shared

I get this whenever the final libs are to be built:

libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32=20
shared libraries

So if you want to use RLIB under MingW, you have to explicitly link to
-lr -lrpdf -lr-odbc for now.

And collecting the stuff for RLIB to actually link was quite tricky.
I will make a short HOWTO to describe the procedure in some days.

So, where's the UTF-8 support in RLIB? ;-)

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

Hello,

On Mon, 2005-04-11 at 13:47 +0200, Zoltan Boszormenyi wrote:
> Hi,
> 
> I am experimenting with this report maker software to finally
> deploy it in a multiplatform environment. I make my (GPLed) program
> under Fedora Core 3/x86-64 and will compile it for Windows with MingW.

Cool!

> 
> My software is special purpose software for business planning and
> invoicing for a subsidiary of the Hungarian national oil company.
> 
> I use GTK2 and ODBC as both work under both Linux and Windows.
> 
> I have first compiled rlib-1.3.2 with the --enable-utf8 option
> because under Fedora Core everything is UTF-8 encoded and GTK2
> also has a strong dependence on UTF-8 even on Windows.
> The report XML file is UTF-8 encoded, as I typed in some literals
> into it with Hungarian accented characters. My PostgreSQL database
> is created with UTF-8 encoding.

One of the reasons UTF-8 support is half ass in RLIB is because UTF-8
PDF Support is not there at all.

> 
> But UTF-8 in RLIB causes problems. All the literals and the strings
> that come from the data source are displayed incorrectly. And on the
> terminal, I got "Encoder was NULL" messages.

> Here's my code that tries to report something:
> 
> -------------------------------------------
> char *query = "some sqlquery...";
> 
>     r = rlib_init();
>     rlib_add_datasource_odbc(r, "mainsource", "ODBCDSN", "uid", "pwd");
>     rlib_add_query_as(r, "mainsource", query, "mainquery");
>     rlib_add_report(r, "rlibtest.xml");
>     rlib_set_output_format(r, RLIB_FORMAT_PDF);
>     rlib_execute(r);
>     output_type = rlib_get_content_type_as_text(r);
>     outbuf = rlib_get_output(r);
>     output_len = rlib_get_output_length(r);
> 
>     fn = open("out.pdf", O_RDWR|O_CREAT|O_TRUNC);
>     if (fn) {
>       write(fn, outbuf, output_len);
>       close(fn);
>     } else
>       printf("open() error: %s\n", strerror(errno));
> 
>     rlib_free(r);
> -------------------------------------------
> 
> After I recompiled rlib without UTF-8 support and set
> the connection string in the ODBC DSN to
> "set client_encoding='ISO-8859-2'" all the string are displayed
> correctly. I wasn't surprised by the strings it fetched from the
> query, but the literals in the XML file are still UTF-8. (?)
> The XML encoding is explicitely UTF-8, as the first line is:

You should probably make your encoding "ISO-8859-2" in the xml here in
order to make the characters come out correctly.

> 
> <?xml version="1.0" encoding="UTF-8"?>
> 
> OK then, I will have to set up two ODBC DSNs, one for the GTK2
> application, one for the report purposes. Not a big problem,
> but I would like to use only one. When will the UTF-8 usage
> be fixed in RLIB? Nudge, nudge. :-)

If you make RLIB compile in windows with MingGW I'll make sure UTF-8
Support works for you :).  Cygwin/mingw and -mno-cygwin have been
driving me nuts trying to make windows DLL's

> 
> The other, more serious problem is that if I use the ODBC
> input method in RLIB, the last record is repeated 4 times,
> somehow overwriting the first 3 records. And if the query
> gave less than 3 records (i.e. 0, 1 or 2) then RLIB crashes.
> 
> I.e. my query gave 54 records and for easy comparison,
> I put an ORDER BY clause into it. Running the query from psql
> shows that the first three records are missing and the
> last record is repeated four times in the PDF report produced
> by RLIB.  The same happened with the report in text format.
> 
> It did not happen when I tried using the native PostgreSQL
> call in RLIB, so I took a look into the ODBC input method
> and I found a strange next/previous state and row copying
> logic. I modified the inputs/odbc/odbc.c and it now uses
> SQLFetchScroll(hStmt, SQL_FETCH_{FIRST|NEXT|PRIOR|LAST}, 0)
> instead of just SQLFetch(hStmt). It fixed the problem for me.
> My ODBC 3.5 Developers Guide says that SQLFetchScroll() is
> defined in X/OPEN 95 CLI or under ODBC 3.0+. But it's
> CORE Conformance functionality, so it's kind of expected to work
> anywhere. Well, except ODBC 2.0 and lower, a.k.a in very old
> Win16 drivers. Hm, I just checked the www.unixodbc.org site and
> the MySQL and PostgreSQL drivers' ODBC versions are 2.5 and
> SQLFetchScroll() definitely works in the unixODBC PostgreSQL
> driver. I expect the same from the MySQL ODBC driver.
> 
> When the Windows port of RLIB is ready, ODBC will be the first
> input method that will work and it must work properly.

Yes.  I never use the ODBC stuff and I did it a year ago for some dude
as a favor and I never maintained it or really checked that it worked
properly ;)

> 
> So please, consider adding my patch to RLIB-1.3.3 or whatever the
> next version is.

> 
> I read the policy about patches at http://rlib.sicompos.com
> I will print, sign and send the copyright assignment but please
> allow me some days to actually do it. I don't have a printer
> at present and I am off-work to finish the above mentioned
> software, for my second work.

Cool!  Thanks

> 
> I will definitely send more patches towards you, to fix issues
> and warnings that pop up. I already found a solution for the
> "langinfo.h is missing under MingW", so one compilation error
> is fixed under Windows. The attached ODBC fix at least allows
> me to create my reports and test it under Linux.

Great!

> 
> And I have some warning fixes that follows the GTK2 development
> guideline, e.g. replacing (gpointer *)x with GINT_TO_POINTER(x).
> The macro works correctly under x86-64, where the explicit
> pointer conversion prints warnings.

Thanks!

Patch looks nice.  I'll apply it as soon as you sign the copyright
assignment.

- Bob

Hi,

I am experimenting with this report maker software to finally
deploy it in a multiplatform environment. I make my (GPLed) program
under Fedora Core 3/x86-64 and will compile it for Windows with MingW.

My software is special purpose software for business planning and
invoicing for a subsidiary of the Hungarian national oil company.

I use GTK2 and ODBC as both work under both Linux and Windows.

I have first compiled rlib-1.3.2 with the --enable-utf8 option
because under Fedora Core everything is UTF-8 encoded and GTK2
also has a strong dependence on UTF-8 even on Windows.
The report XML file is UTF-8 encoded, as I typed in some literals
into it with Hungarian accented characters. My PostgreSQL database
is created with UTF-8 encoding.

But UTF-8 in RLIB causes problems. All the literals and the strings
that come from the data source are displayed incorrectly. And on the
terminal, I got "Encoder was NULL" messages.

Here's my code that tries to report something:

-------------------------------------------
char *query =3D "some sqlquery...";

    r =3D rlib_init();
    rlib_add_datasource_odbc(r, "mainsource", "ODBCDSN", "uid", "pwd");
    rlib_add_query_as(r, "mainsource", query, "mainquery");
    rlib_add_report(r, "rlibtest.xml");
    rlib_set_output_format(r, RLIB_FORMAT_PDF);
    rlib_execute(r);
    output_type =3D rlib_get_content_type_as_text(r);
    outbuf =3D rlib_get_output(r);
    output_len =3D rlib_get_output_length(r);

    fn =3D open("out.pdf", O_RDWR|O_CREAT|O_TRUNC);
    if (fn) {
      write(fn, outbuf, output_len);
      close(fn);
    } else
      printf("open() error: %s\n", strerror(errno));

    rlib_free(r);
-------------------------------------------

After I recompiled rlib without UTF-8 support and set
the connection string in the ODBC DSN to
"set client_encoding=3D'ISO-8859-2'" all the string are displayed
correctly. I wasn't surprised by the strings it fetched from the
query, but the literals in the XML file are still UTF-8. (?)
The XML encoding is explicitely UTF-8, as the first line is:

<?xml version=3D"1.0" encoding=3D"UTF-8"?>

OK then, I will have to set up two ODBC DSNs, one for the GTK2
application, one for the report purposes. Not a big problem,
but I would like to use only one. When will the UTF-8 usage
be fixed in RLIB? Nudge, nudge. :-)

The other, more serious problem is that if I use the ODBC
input method in RLIB, the last record is repeated 4 times,
somehow overwriting the first 3 records. And if the query
gave less than 3 records (i.e. 0, 1 or 2) then RLIB crashes.

I.e. my query gave 54 records and for easy comparison,
I put an ORDER BY clause into it. Running the query from psql
shows that the first three records are missing and the
last record is repeated four times in the PDF report produced
by RLIB.  The same happened with the report in text format.

It did not happen when I tried using the native PostgreSQL
call in RLIB, so I took a look into the ODBC input method
and I found a strange next/previous state and row copying
logic. I modified the inputs/odbc/odbc.c and it now uses
SQLFetchScroll(hStmt, SQL_FETCH_{FIRST|NEXT|PRIOR|LAST}, 0)
instead of just SQLFetch(hStmt). It fixed the problem for me.
My ODBC 3.5 Developers Guide says that SQLFetchScroll() is
defined in X/OPEN 95 CLI or under ODBC 3.0+. But it's
CORE Conformance functionality, so it's kind of expected to work
anywhere. Well, except ODBC 2.0 and lower, a.k.a in very old
Win16 drivers. Hm, I just checked the www.unixodbc.org site and
the MySQL and PostgreSQL drivers' ODBC versions are 2.5 and
SQLFetchScroll() definitely works in the unixODBC PostgreSQL
driver. I expect the same from the MySQL ODBC driver.

When the Windows port of RLIB is ready, ODBC will be the first
input method that will work and it must work properly.

So please, consider adding my patch to RLIB-1.3.3 or whatever the
next version is.

I read the policy about patches at http://rlib.sicompos.com
I will print, sign and send the copyright assignment but please
allow me some days to actually do it. I don't have a printer
at present and I am off-work to finish the above mentioned
software, for my second work.

I will definitely send more patches towards you, to fix issues
and warnings that pop up. I already found a solution for the
"langinfo.h is missing under MingW", so one compilation error
is fixed under Windows. The attached ODBC fix at least allows
me to create my reports and test it under Linux.

And I have some warning fixes that follows the GTK2 development
guideline, e.g. replacing (gpointer *)x with GINT_TO_POINTER(x).
The macro works correctly under x86-64, where the explicit
pointer conversion prints warnings.

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

Bruno,

Do you want to use RLIB from c, php, python or java?

On Sun, 2005-04-10 at 02:38 +0200, Bruno Sadiez wrote:
> I was wondering if rlib could be used as part of an
> invoicing system I'm am writing.
> I would like to have more control over the pdf
> creation process and be able to feed rlib my own data
> without issuing  rlib_add_datasource and
> rlib_add_query_as.
> According to another post on this list, this seems
> possible.
> As my application also needs to issue xml files, my
> invoice data is contained in an xml tree (I'm using
> libxml2). FOP is too slow for what I need to do.
> 
> Thank you in advance
> Regards
> Bruno  
> 
> 
> 
> 	
> 
> 	
> 		
> __________________________________________________________________
> Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
> Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Rlib-devel mailing list
> Rli...@li...
> https://lists.sourceforge.net/lists/listinfo/rlib-devel
-- 
Bob Doan <bd...@si...>

I was wondering if rlib could be used as part of an
invoicing system I'm am writing.
I would like to have more control over the pdf
creation process and be able to feed rlib my own data
without issuing  rlib_add_datasource and
rlib_add_query_as.
According to another post on this list, this seems
possible.
As my application also needs to issue xml files, my
invoice data is contained in an xml tree (I'm using
libxml2). FOP is too slow for what I need to do.

Thank you in advance
Regards
Bruno  

__________________________________________________________________
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

Hey All,

I'm happy to announce the release of RLIB 1.3.2

RLIB 1.3.2 introduces a brand new GPL'd PDF generation library called
RPDF. This means that RLIB is now 100% GPL'd. RLIB 1.3.2 also restores
python and java functionality. The error checking has been greatly
improved in the engine. Documentation is now included in the release.
Some minor problems have been worked out in the graphing engine.

Download it from the usual place.

And enjoy the 1st version of RLIB which doesn't need CPDF!!!!!!!!!!

At this time I think we are getting very close to the next official
stable release.  We will probably only have one or two more "unstable"
versions.

ALSO:  Could a few of you out there share some example reports you
created in RLIB?  Right now here @ SICOM the best we have is counting
food and cars :)

- bob

Hi,

Patch looks good so far.  I use sf.net's CVS to develop out of btw....

Could you make your patches w/ -u so they are easier to read.

Also a manager @ roadsend sign our dual copy right assignment form?
http://rlib.sicompos.com/copyright_form.pdf

SICOM requires copyright assignment for certain types of code
contributions. This is so that SICOM can enforce the copyright in the
program as the owner of the entire program, or use a dual license on the
code. In other words, we don't have to drag you with us if we go to
court to defend the GPL, and we can use a dual license like Mozilla does
for commercial purposes. 

And fax it to me @ 215-489-2769

If you have any questions about the dual copyright let me know

On Mon, 2005-03-07 at 12:12 -0500, Shannon Weyrick wrote:
> Hi Bob,
> 
> Ok, great. I wasn't sure how it was inititialized as I'm not all that 
> familiar with glib.
> 
> I'm including another patch that's a little more adventurous. It allows 
> retrieval of errors messages from the input source. As I only have mysql 
> installed at the moment, the postgre and odbc input's don't actually 
> return an error message. Comments welcome. Note, this patch is not 
> against your latest release, but the one from last week.
> 
> So, although Roadsend's premier product is the compiler, we still do 
> consulting and software development work. This project is a reporting 
> engine for a school district that uses the SchoolMax system and various 
> other data sources (as well as Roadsend SiteManager and Portal system).
> 
> Shannon
> 
> Bob Doan wrote:
> 
> >Hi 
> >
> >Thanks for the patch!
> >
> >I applied the patch minus the "r->queries_count = 0;" because the struct
> >is bzero'd when its initialized.
> >
> >It also motivated me to fix a few other crashing situations if the
> >actual query failed to run.
> >
> >Curiosity question.  What would php compiler folks be doing w/ RLIB?
> >
> >- bob
> >  
> >
> 
> plain text document attachment (error_msgs.diff)
> diff -r rlib-1.3.2/inputs/mysql/mysql.c rlib-1.3.2-weyrick/inputs/mysql/mysql.c
> 213a214,218
> > static const gchar* rlib_mysql_get_error(gpointer input_ptr) {
> > 	struct input_filter *input = input_ptr;
> > 	return mysql_error(INPUT_PRIVATE(input)->mysql);
> > }
> > 
> 225a231
> > 	input->get_error = rlib_mysql_get_error;
> diff -r rlib-1.3.2/inputs/odbc/odbc.c rlib-1.3.2-weyrick/inputs/odbc/odbc.c
> 312a313,316
> > static const gchar * rlib_odbc_get_error(gpointer input_ptr) {
> > 	return "No error information";
> > }
> > 
> 325a330
> > 	input->get_error = rlib_odbc_get_error;
> diff -r rlib-1.3.2/inputs/postgre/postgre.c rlib-1.3.2-weyrick/inputs/postgre/postgre.c
> 175a176,179
> > static const gchar * rlib_postgre_get_error(gpointer input_ptr) {
> > 	return "No error information";
> > }
> > 
> 189a194
> > 	input->get_error = rlib_postgre_get_error;
> diff -r rlib-1.3.2/libsrc/api.c rlib-1.3.2-weyrick/libsrc/api.c
> 151c152
> < 			rlogit("Failed To Run A Query [%s]\n", r->queries[i].sql);
> ---
> > 			rlogit("Failed To Run A Query [%s]: %s\n", r->queries[i].sql, INPUT(r,i)->get_error(INPUT(r,i)));
> diff -r rlib-1.3.2/libsrc/rlib_input.h rlib-1.3.2-weyrick/libsrc/rlib_input.h
> 50a51
> > 	const gchar * (*get_error)(gpointer);
> 

Hi Bob,

Ok, great. I wasn't sure how it was inititialized as I'm not all that 
familiar with glib.

I'm including another patch that's a little more adventurous. It allows 
retrieval of errors messages from the input source. As I only have mysql 
installed at the moment, the postgre and odbc input's don't actually 
return an error message. Comments welcome. Note, this patch is not 
against your latest release, but the one from last week.

So, although Roadsend's premier product is the compiler, we still do 
consulting and software development work. This project is a reporting 
engine for a school district that uses the SchoolMax system and various 
other data sources (as well as Roadsend SiteManager and Portal system).

Shannon

Bob Doan wrote:

>Hi 
>
>Thanks for the patch!
>
>I applied the patch minus the "r->queries_count = 0;" because the struct
>is bzero'd when its initialized.
>
>It also motivated me to fix a few other crashing situations if the
>actual query failed to run.
>
>Curiosity question.  What would php compiler folks be doing w/ RLIB?
>
>- bob
>  
>

2003	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec (4)
2004	Jan (2)	Feb (4)	Mar (10)	Apr (2)	May (2)	Jun (2)	Jul (9)	Aug	Sep	Oct	Nov (2)	Dec (9)
2005	Jan (2)	Feb	Mar (8)	Apr (46)	May (16)	Jun (69)	Jul (27)	Aug (12)	Sep	Oct (11)	Nov	Dec (14)
2006	Jan (22)	Feb (4)	Mar (9)	Apr (1)	May	Jun (4)	Jul	Aug (1)	Sep (6)	Oct (5)	Nov (2)	Dec (16)
2007	Jan (1)	Feb	Mar (5)	Apr (3)	May (2)	Jun	Jul	Aug	Sep (2)	Oct (2)	Nov (2)	Dec (3)
2008	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (14)	Sep (10)	Oct	Nov	Dec
2009	Jan	Feb (3)	Mar	Apr (2)	May (7)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2010	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (2)	Oct (2)	Nov	Dec
2011	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec
2016	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (1)	Dec

rlib-devel Mailing List for RLIB -Report Engine (Page 13)

rlib-devel — RLIB Development Mailing List