From: Zoltan B. <zb...@du...> - 2005-05-14 18:12:58
|
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 |