Menu
▾
▴
rlib-devel — RLIB Development Mailing List
You can subscribe to this list here.
| 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
|
|
From: Zoltan B. <zb...@du...> - 2006-03-15 22:10:15
|
Hi,
I wanted to display a percent computed from two fields.
This doesn't work:
str(val(field1)/val(field)*100.0,3,2)
Although this does work:
str((val(field1)/val(field))*100.0,3,2)
Note the extra parentheses. This is what I got in the terminal (RLIB=20
didn't crashed, though):
RLIB EXPERIENCED A FATAL MATH ERROR WHILE TRYING TO PREFORM THE=20
FOLLOWING OPERATION: str
* Error on Line 86: The Expression Was=20
[str(val(field1)/val(field2)*100.0,3,2)]
* DATA TYPES ARE [UNKNOWN] [UNKNOWN] [UNKNOWN]
PCODE Execution Error: str( Didn't Work
PCODE Execution Error: [str(val(field2)/val(field2)*100.0,3,2)] on line [=
86]
RLIB can't parse A / B * C but it can parse (A / B) * C.
Is it documented somewhere?
E.g. explicit parentheses are not only needed but required?
Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi
|
|
From: Zoltan B. <zb...@du...> - 2006-02-16 21:33:13
|
Hi,
recent changes in RLIB broke compilation under Windows:
1) RPDF uses localtime_r() and only localtime() exists under MinGW.
2) After my "leaner linking" patch the ODBC input lib fails to link
because it uses GLIB. It seems that the Windows linker requires
explicit dependencies for dynamic modules, where e.g. Linux
can resolve unknown symbols at run time.
Fixes for the above two are attached, and another one for removing
one unneeded #include from the ODBC input lib.
Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi
|
|
From: <ne...@ci...> - 2006-02-10 00:32:33
|
DQobJEJGTUEzJE4lYSE8JWskRz89JDdMdSQ0JDYkJCReJDskcyEjO2QkTyU7JWwlVjZmM1pJdCRI JCQkJkE0OXFFODMrJE4jMyMwQmUwSj5lJE40ezonPFQkLD04JF4kayEiJTMlXyVlJUslRiUjJHJF fTNnJDckRiQkJGtCdDBmOSVIfiRIPz0kNyReJDkhIzRKQzEkS0BiTEAkJCQ/JDckXiQ5JEghIj9N OkokTj13QC0kLDAmP00kckM1JDklMyVfJWUlSyVGJSMkRyQ5ISMkPSROJGgkJiRKNFg3OCRLNj1M IyROJCIka0NLQC0kTyUzJUElaSReJEclIiUvJTslOSQ3JEYyPCQ1JCQbKEIgGyRCJTMlQSVpISEb KEJodHRwOi8vYXdnLndlYmNodS5jb20vY2FzYW5vdmEvPzE5MzQbJEIhISRHJTslbBsoQiANChsk QiVWNmYzWkl0JEg4ITp3JDckRiRiJGkkKCRsJFA9d0AtJE40aTxMPz9JVSQtJE4lVyVtJVUlIyE8 JWskSE8iTW1AaCRyOCskazt2JCwkRyQtJF4kOSEjJCpCVCRBJDckRiQqJGokXiQ5ISMbKEINCg0K DQoNCg0KLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vDQobJEIlYSE8JWtJVE1XJE5K fSRPJDMkQSRpJEslYSE8JWskciItGyhCDQpjb25jZXB0M19uZXRAeWFob28uY2ENCg0KDQo= |
|
From: Zoltan B. <zb...@du...> - 2006-02-07 19:42:05
|
Hi, while the previous patch was needed, it wasn't enough. rlib_align_text() didn't take UTF-8 strings into account correctly. New patch follows, please review. Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
|
From: Zoltan B. <zb...@du...> - 2006-02-07 00:41:08
|
Hi, I got a crash at line 387 in libsrc/formatstring.c, it turned out that the allocated buffer is too small for UTF-8 strings. Patch is attached. I got another crash in layout.c but I didn't have time to hunt it down ye= t. Here's a diagnostics from GCC4 with the bounds checking extension: layout.c:612:Bounds error: attempt to reference memory overrunning the=20 end of an object. layout.c:612: Pointer value: 0x4, Size: 1 layout.c:612: Object `realloc': layout.c:612: Address in memory: 0x0 .. 0x3 layout.c:612: Size: 20 bytes layout.c:612: Element size: 1 bytes layout.c:612: Number of elements: 20 layout.c:612: Storage class: heap ** NUTS.. WE CRASHED Kil=E9p=E9s (core dumped) Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
|
From: Aldo N. B. <al...@gm...> - 2006-01-31 01:56:56
|
On 1/31/06, Aldo Nicolas Bruno <al...@gm...> wrote: > > config.h.in is generated w/ autoheader when you run autogen.sh before > > you build from CVS > no, maybe that for you works, but not for me, I don't know exactly why. > I'be also tried to run autoheader manually, but it does not generate anyt= hing > (I'm of course using the lastest CVS) > I've fixed the problem: it seems that in some systems autoconf lacks of acconfig.h. A possible fix maybe to always distribute it with the sources. (in attachment the acconfig.h). It just worked for me. Best regards, aldox -- Aldo Nicolas Bruno Referente del LUG San Fidenzio - http://www.lugsanfidenzio.org/ Sviluppatore del progetto GEPAL - http://www.gepal.org/ Home page: http://aldox86.blogspot.com/ GPG Public Key: http://keyserver.veridis.com:11371/export?id=3D-3100218920628447415 |
|
From: Aldo N. B. <al...@gm...> - 2006-01-31 01:38:47
|
Hi,
sorry for the very delayed reply
On 1/1/06, Bob Doan <bd...@si...> wrote:
> Sorry for the delayed response.
no problem
> First can you send patches in unified diff format so they are easier to
> read. (diff -u)
Ok sorry
> Your patch would break RLIB detecting if it should build Python
> bindings.
> Before I could apply the acsite.m4 stuff I would need to better
> understand why it's better across distributions. What's wrong w/ the
> existing detection?
Sorry again I just used a system that was known to work well
I've corrected your version now, and it is much cleaner
hereis the patch:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D python.patch =3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- configure.in.orig=092006-01-31 01:36:16.000000000 +0100
+++ configure.in=092006-01-31 01:59:02.000000000 +0100
@@ -353,13 +353,30 @@
PYTHON_CFLAGS=3D""
PYTHON_EXTENSION_DIR=3D""
if test x$enable_python =3D xyes; then
+
=09AM_PATH_PYTHON($python_version)
-=09if test x$PYTHON_VERSION =3D x$python_version; then
-=09=09eval python_foo=3D$PYTHON_PREFIX
+=09
+=09## if test x$PYTHON_VERSION =3D x$python_version; then
+=09##what if the version is bigger?=09
+=09## remember that AM_PATH_PYTHON gives
+=09## a python version >=3D$python_version
+
+=09## we must check the PYTHON variable instead, like this:
+=09if test x$PYTHON !=3D x":"; then=09
+=09=09#eval python_foo=3D$PYTHON_PREFIX
+=09=09## PYTHON_PREFIX variable is not yet functional in Automake
+=09=09## now it just uses the value of ${prefix} :(
+=09=09## so when looking for Python.h, if the ${prefix} of the
+=09=09## application does not match with that of python
+=09=09## (say he have python installed under /usr and rlib
+=09=09## under /usr/local) and we'll mostly fail to compile.
+=09=09## we have to guess it by hand: Idea: the `dirname' command
+=09=09python_foo=3D`dirname $PYTHON`/..
+=09=09
=09=09AC_CHECK_HEADERS($python_foo/include/python$PYTHON_VERSION/Python.h,=
python_header=3Dyes,python_header=3Dno)
=09=09if test x$python_header =3D xyes; then
=09=09=09AC_DEFINE(HAVE_PYTHON,1,[Build with PYTHON support])
-=09=09=09PYTHON_CFLAGS=3D"-I $PYTHON_PREFIX/include/python$PYTHON_VERSION"
+=09=09=09PYTHON_CFLAGS=3D"-I$python_foo/include/python$PYTHON_VERSION"
=09=09=09PYTHON_EXTENSION_DIR=3D$pyexecdir
=09=09else
=09=09=09enable_python=3Dno
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D python.patch =3D=3D=
=3D=3D=3D=3D=3D=3D[end]=3D=3D=3D
> config.h.in is generated w/ autoheader when you run autogen.sh before
> you build from CVS
no, maybe that for you works, but not for me, I don't know exactly why.
I'be also tried to run autoheader manually, but it does not generate anythi=
ng
(I'm of course using the lastest CVS)
> I have no idea why the documentation does not compile :( I am in the
> process of moving all RLIB documentation to a wiki (newrlib.sicom.com)
:(
Best regards,
aldox
--
Aldo Nicolas Bruno
Referente del LUG San Fidenzio - http://www.lugsanfidenzio.org/
Sviluppatore del progetto GEPAL - http://www.gepal.org/
Home page: http://aldox86.blogspot.com/
GPG Public Key:
http://keyserver.veridis.com:11371/export?id=3D-3100218920628447415
|
|
From: Bob D. <bd...@si...> - 2006-01-23 15:00:22
|
Hi, Patch looks good except I would prefer compression be optional at run time as well. If we had something like: rpdf_enable_compression(struct rpdf *pdf, gboolean setting) And have a flag in the rpdf struct. =20 We could then have an output parameter in rlib to set it on. Thanks! - Bob On Sun, 2006-01-22 at 15:26 +0100, Zoltan Boszormenyi wrote: > Hi, >=20 > Zoltan Boszormenyi =C3=ADrta: >=20 > > Now it's getting embarrassing... Fix again. Use this patch instead of= =20 > > the previous. > > > > Zoltan Boszormenyi =C3=ADrta: > > > >> Another fix. :-( This time incremental against the previous one. > >> - Don't free something I didn't allocated. > >> - Some white space fixes. > > > > > > > > Also check the return value of deflateEnd(), too. > > > > Best regards, > > Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi >=20 >=20 > here's a slightly cheaper version of the patch, as deflateInit() > is done only in rpdf_new() and deflateEnd() is done in rpdf_free(). > Instead, deflateReset() is used in rpdf_add_page_content_compressed(). >=20 > $ time for i in `seq 1 1000` ; do ./test >test1.pdf ; done >=20 > real 0m2.359s > user 0m1.041s > sys 0m1.311s >=20 > Now the 1000 iterations took only 201 msecs more than without compressi= on. > Also, should any error happen during compression, the next content won'= t be > compressed. It should only happen under OOM condition and I guess it's=20 > very unlikely. >=20 > Best regards, > Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi >=20 |
|
From: Zoltan B. <zb...@du...> - 2006-01-22 13:51:00
|
Hi, Zoltan Boszormenyi =C3=ADrta: > Now it's getting embarrassing... Fix again. Use this patch instead of=20 > the previous. > > Zoltan Boszormenyi =C3=ADrta: > >> Another fix. :-( This time incremental against the previous one. >> - Don't free something I didn't allocated. >> - Some white space fixes. > > > > Also check the return value of deflateEnd(), too. > > Best regards, > Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi here's a slightly cheaper version of the patch, as deflateInit() is done only in rpdf_new() and deflateEnd() is done in rpdf_free(). Instead, deflateReset() is used in rpdf_add_page_content_compressed(). $ time for i in `seq 1 1000` ; do ./test >test1.pdf ; done real 0m2.359s user 0m1.041s sys 0m1.311s Now the 1000 iterations took only 201 msecs more than without compression= . Also, should any error happen during compression, the next content won't = be compressed. It should only happen under OOM condition and I guess it's=20 very unlikely. Best regards, Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi |
|
From: Zoltan B. <zb...@du...> - 2006-01-18 12:54:42
|
Now it's getting embarrassing... Fix again. Use this patch instead of=20 the previous. Zoltan Boszormenyi =C3=ADrta: > Another fix. :-( This time incremental against the previous one. > - Don't free something I didn't allocated. > - Some white space fixes. Also check the return value of deflateEnd(), too. Best regards, Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi |
|
From: Zoltan B. <zb...@du...> - 2006-01-18 11:38:38
|
Another fix. :-( This time incremental against the previous one. - Don't free something I didn't allocated. - Some white space fixes. Best regards, Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi |
|
From: Zoltan B. <zb...@du...> - 2006-01-18 11:32:35
|
Hi, the previous patch needed a little fix. I replaced c_stream.avail_out with c_stream.total_out two places after the compressing was done, so the correct stream size is used. Updated patch is attached. Also I did a little benchmarking: Best time out of 5 runs for uncompressed streams: time for i in `seq 1 1000`; do ./test >test4.pdf ; done real 0m2.108s user 0m0.862s sys 0m1.240s Best time out of 5 runs for compressed streams: $ time for i in `seq 1 1000`; do ./test >test3.pdf ; done real 0m2.475s user 0m1.073s sys 0m1.393s Difference in total time: 367 msec or 17% increase $ ls -l test3.pdf test4.pdf -rw-rw-r-- 1 zozo zozo 2569 jan 18 12:14 test3.pdf -rw-rw-r-- 1 zozo zozo 3004 jan 18 12:12 test4.pdf About 14.5% decrease in size. Here is the results of one of my reports that has a very small recordset. Uncompressed: $ time for i in `seq 1 1000`; do ./ptgriport Bolt2 szallitolista 0=20 2005-01-01 2005-12-31 ; done real 1m3.501s user 0m32.082s sys 0m18.655s Compressed: $ time for i in `seq 1 1000`; do ./ptgriport Bolt2 szallitolista 0=20 2005-01-01 2005-12-31 ; done real 1m4.142s user 0m32.178s sys 0m18.393s The performance difference is negligible, 642 msec, about 1% increase. The database access times dominate here mostly. But look at the file size= s: $ ls -l /tmp/szallitolista.pdf* -rw-rw-r-- 1 zozo zozo 1676 jan 18 12:54 /tmp/szallitolista.pdf -rw-rw-r-- 1 zozo zozo 5402 jan 18 12:49=20 /tmp/szallitolista.pdf.uncompressed With a much larger recordset that produce more than one pages, or when the pages contain more information, the much larger decrease in size will justify the time spent in compression as less data will be written out. Also if used from PHP through a browser, the smaller file will be transferred faster. The network is slower than disks. Best regards, Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi |
|
From: Zoltan B. <zb...@du...> - 2006-01-18 10:26:21
|
Hi, the attached patch uses ZLIB to compress the /Contents object. The facility can be used later to compress embedded fonts, too. It should be applied over the dynamic object numbering patch. Best regards, Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi |
|
From: Zoltan B. <zb...@du...> - 2006-01-17 21:38:54
|
Hi, please don't apply this yet, RPDF needs more massaging before font embedding can be made to work, until then it's just unneeded ballast. Here are some things that will be needed: - Use ZLIB to compress object streams (embedded fonts can be large, page /Contents streams can also be compressed, etc.) - Common /Resources object. E.g. images used more than once can be included only once. and maybe others. I am reading FPDF back and forth, until I fully understand how it works. (As FPDF is public domain, no one can complain that I use ideas from there. I cannot take the implementation as-is since it's written in PHP...) The previous patch about dynamic object numbering stands on its own. Best regards, Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi |
|
From: Zoltan B. <zb...@du...> - 2006-01-17 10:03:44
|
Hi, here's the first part of font embedding, that only contains the configure.in and Makefile.am machinery to make RPDF link to GNOME-VFS. Also the previously sent two new testprograms: - gnomevfscopy.c that was copied almost literally from the documentation of GNOME-VFS, and - gnomevfstest.c to list all fonts under URI "fonts:///" and copy one of them (BitStream Vera Sans) to $HOME. Best regards, Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi |
|
From: Zoltan B. <zb...@du...> - 2006-01-17 09:32:19
|
Hi,
as I just noticed, both forward and backward and
even circular references are allowed between objects
in a PDF file. RPDF now was made in a way so certain
objects get fixed object numbers.
The attached patch alters this, so the object numbering
becomes dynamic. This is needed later to allow font embedding,
since embedded fonts are made up of more than one objects,
so mechanically adding numbers of annotations, pages, fonts and
images isn't correct anymore.
The patch does the following:
- struct rpdf_page_info, struct rpdf_font_object and
struct rpdf_object gained a new member: gint object_number
- rpdf_object_append() returns the object number it just added
- Two new static functions introduced that are used to
keep track of forward/circular references:
gint rpdf_object_number_skip(struct rpdf *pdf);
void rpdf_object_insert(struct rpdf *pdf, gint object_number,
gboolean put_wrapper, GString *contents,
gchar *stream, gint stream_length);
- rpdf_finalize_objects() now uses the object_number field,
instead of the pdf->object_count that was also incremented here.
- rpdf_make_page_images() and rpdf_make_page_annot_list()
aren't needed anymore, what they did are now done in
rpdf_make_page_image_obj() and rpdf_make_page_annot_obj(),
respectively.
- rpdf_finalize() was rearranged/rewritten so it uses
dynamic object numbering.
- Warnings about unused local variables were silenced in
obj_concat() and rpdf_make_page_stream().
Usage of the: rpdf_object_number_skip() and rpdf_object_insert():
1. Assign object numbers at your will with rpdf_object_number_skip().
2. Use these object numbers later in rpdf_object_insert()
after some or every rpdf_object_append() occurences.
Occurences of rpdf_object_insert() have to be in the same order
as the occurences of rpdf_object_number_skip(), e.g.:
obj1 =3D rpdf_object_number_skip();
obj2 =3D rpdf_object_number_skip();
obj3 =3D rpdf_object_number_skip();
// ... rpdf_object_append(); ...
rpdf_object_insert(..., obj1, ...);
rpdf_object_insert(..., obj2, ...);
rpdf_object_insert(..., obj3, ...);
The test program rlib/rpdf/test.c (URL link, image embedding,
basic font usage) and some reports of mine I tested still work
correctly. Please review.
Best regards,
Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi
|
|
From: Zoltan B. <zb...@du...> - 2006-01-15 18:02:53
|
Zoltan Boszormenyi =C3=ADrta: > Hi, > > Bob Doan =C3=ADrta: > >> Hey, >> >> Patch looks good so far! You probably want to update from CVS, I've >> =20 >> > > Thanks! OK, I update my local CVS copy, although I did a checkout on=20 > Monday. :-) > I will send a newer patch soon. > >> been playing in RPDF a little. I made some gchar * GStrings for speed >> improvement. In general, RLIB is now 2x faster with some of the >> speedups I made over the past few days. One of the worst things it wa= s >> doing was doing a getlocale on every format! That's quite expensive >> because it has to do a getenv. >> =20 >> > > Impressive speedup. > >> We probably don't want to check for ttf2pt1 on rpdf_new because that >> would be expensive. We probably only want to check for it once if we >> are actually going to embed fonts. >> =20 >> > > What about doing it on the first rpdf_new()? > A global static variable may keep this info. On second thought, I would like to introduce rpdf_init() so the test for ttf2pt1 can be done here, and later, when we are actually embed fonts, the generated font metrics can be collected in a hash table with the same key as the fonts themselves. The hash table could also be initialized here. Also, rpdf_shutdown() destroys the info. >> We also might want to be able to cache the results of ttf2pt1 in some >> sorta binary form to load from in order to optionally speed up interna= l >> font loading. Maybe provide some sorta utility w/ RLIB to do it. > The cached metrics could also be saved in rpdf_shutdown and reloaded next time in rpdf_init(). >> In general you are headed in the right direction and it looks good. H= ow >> far do you plan on taking this? Is your plan to only support fixed >> width fonts in RLIB or were you thinking about variable width fonts? > I guess you want to compete with CrystalReports in the long term. :-) A visual editor would also come handy... Best regards, Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi |
|
From: Zoltan B. <zb...@du...> - 2006-01-12 07:04:39
|
Hi, Bob Doan =C3=ADrta: >Hey, > >Patch looks good so far! You probably want to update from CVS, I've > =20 > Thanks! OK, I update my local CVS copy, although I did a checkout on=20 Monday. :-) I will send a newer patch soon. >been playing in RPDF a little. I made some gchar * GStrings for speed >improvement. In general, RLIB is now 2x faster with some of the >speedups I made over the past few days. One of the worst things it was >doing was doing a getlocale on every format! That's quite expensive >because it has to do a getenv. > =20 > Impressive speedup. >We probably don't want to check for ttf2pt1 on rpdf_new because that >would be expensive. We probably only want to check for it once if we >are actually going to embed fonts. > =20 > What about doing it on the first rpdf_new()? A global static variable may keep this info. >We also might want to be able to cache the results of ttf2pt1 in some >sorta binary form to load from in order to optionally speed up internal >font loading. Maybe provide some sorta utility w/ RLIB to do it. > =20 > OK, good idea. >In general you are headed in the right direction and it looks good. How >far do you plan on taking this? Is your plan to only support fixed >width fonts in RLIB or were you thinking about variable width fonts? > =20 > I would like to be able to use any fonts I can find on the system in RLIB and any codepage. Best regards, Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi |
|
From: Bob D. <bd...@si...> - 2006-01-12 00:20:46
|
Hey, Patch looks good so far! You probably want to update from CVS, I've been playing in RPDF a little. I made some gchar * GStrings for speed improvement. In general, RLIB is now 2x faster with some of the speedups I made over the past few days. One of the worst things it was doing was doing a getlocale on every format! That's quite expensive because it has to do a getenv. We probably don't want to check for ttf2pt1 on rpdf_new because that would be expensive. We probably only want to check for it once if we are actually going to embed fonts. We also might want to be able to cache the results of ttf2pt1 in some sorta binary form to load from in order to optionally speed up internal font loading. Maybe provide some sorta utility w/ RLIB to do it. In general you are headed in the right direction and it looks good. How far do you plan on taking this? Is your plan to only support fixed width fonts in RLIB or were you thinking about variable width fonts? Thanks! - Bob On Thu, 2006-01-12 at 00:56 +0100, Zoltan Boszormenyi wrote: > Hi, > > Bob Doan írta: > > >Hi Zoltan, > > > >I like GNOME-VFS as a solution. If we add support for gnome-vfs we > >could probably make use of it in other File IO places. > > > >It would have to be a compile time option and a fallback to flat files > >(as you say) > > > >- Bob > > > > just a heads up, that I am progressing. :-) > I have done the following: > - a little configure.in and Makefile.am magic to detect and use GNOME-VFS, > it can be disabled manually > - reordered rpdf_set_font() a little, so it finds already used fonts first, > It will implicitely use rpdf_add_font() if it doesn't find the given > font name and encoding among the builtins. > - rpdf_object_append() returns the current object#, > it is needed for embedding fonts, as objects cross-referenced by each > other > - struct _rpdf_fonts gained two new members, stream and stream_length > - GNOME-VFS is used for reading in the file and detecting the MIME type, > so I can distinguish between TrueType and Type1 fonts, when only a > font name > is given, or normal file operations are used and the .ttf and .pfb > suffixes > are checked for if full path is given for the file. > > And it doesn't crash. :-) > > The font binaries already appear in the PDF, but XPDF complains > about them and doesn't use them. But it doesn't crash, so the structures > are correct but details are missing. :-) > > You will need to have ttf2pt1 on the system, it will be used to > extract the font metrics from the font file, e.g. rpdf_text_width() will > need it. > I think I will detect its presence in rpdf_new(), if not found, font > embedding will be > runtime disabled. > > Would you like to see the patch in this incomplete/non-working state? > > Best regards, > Zoltán Böszörményi -- Bob Doan <bd...@si...> |
|
From: Zoltan B. <zb...@du...> - 2006-01-11 23:21:57
|
Hi,
Bob Doan =C3=ADrta:
>Hi Zoltan,
>
>I like GNOME-VFS as a solution. If we add support for gnome-vfs we
>could probably make use of it in other File IO places.
>
>It would have to be a compile time option and a fallback to flat files
>(as you say)
>
>- Bob =20
>
just a heads up, that I am progressing. :-)
I have done the following:
- a little configure.in and Makefile.am magic to detect and use GNOME-VFS=
,
it can be disabled manually
- reordered rpdf_set_font() a little, so it finds already used fonts firs=
t,
It will implicitely use rpdf_add_font() if it doesn't find the given
font name and encoding among the builtins.
- rpdf_object_append() returns the current object#,
it is needed for embedding fonts, as objects cross-referenced by each=20
other
- struct _rpdf_fonts gained two new members, stream and stream_length
- GNOME-VFS is used for reading in the file and detecting the MIME type,
so I can distinguish between TrueType and Type1 fonts, when only a=20
font name
is given, or normal file operations are used and the .ttf and .pfb=20
suffixes
are checked for if full path is given for the file.
And it doesn't crash. :-)
The font binaries already appear in the PDF, but XPDF complains
about them and doesn't use them. But it doesn't crash, so the structures
are correct but details are missing. :-)
You will need to have ttf2pt1 on the system, it will be used to
extract the font metrics from the font file, e.g. rpdf_text_width() will=20
need it.
I think I will detect its presence in rpdf_new(), if not found, font=20
embedding will be
runtime disabled.
Would you like to see the patch in this incomplete/non-working state?
Best regards,
Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi
|
|
From: Bob D. <bd...@si...> - 2006-01-09 21:08:45
|
Hi Zoltan, I like GNOME-VFS as a solution. If we add support for gnome-vfs we could probably make use of it in other File IO places. It would have to be a compile time option and a fallback to flat files (as you say) - Bob On Mon, 2006-01-09 at 22:34 +0100, Zoltan Boszormenyi wrote: > Hi, >=20 > I am thinking about adding font embedding to RPDF > in such a way so it can easily finds font files just by giving > it the fonts' symbolic names. The solution is: GNOME-VFS. > You can easily browse through all fonts even in Nautilus > just by going to fonts:/// and it even gives you the file sizes > and modification times in list view. > Is it acceptable for RLIB to have such a strong requirement? > Anyway, it already expects GTK+ 2.x installed as it uses GLib 2.x. > I am thinking about being able to manually disabling it, and > in this case the full path should be given. What do you think? >=20 > Best regards, > Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=C4=9Ak > _______________________________________________ > Rlib-devel mailing list > Rli...@li... > https://lists.sourceforge.net/lists/listinfo/rlib-devel |
|
From: Zoltan B. <zb...@du...> - 2006-01-09 20:59:38
|
Hi, I am thinking about adding font embedding to RPDF in such a way so it can easily finds font files just by giving it the fonts' symbolic names. The solution is: GNOME-VFS. You can easily browse through all fonts even in Nautilus just by going to fonts:/// and it even gives you the file sizes and modification times in list view. Is it acceptable for RLIB to have such a strong requirement? Anyway, it already expects GTK+ 2.x installed as it uses GLib 2.x. I am thinking about being able to manually disabling it, and in this case the full path should be given. What do you think? Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
|
From: Zoltan B. <zb...@du...> - 2006-01-08 15:20:05
|
Hi, Bob Doan =EDrta: >Zoltan, > >I added forward only cursor support to the ODBC driver. MSSQL and MySQL >should now work. Can you let me know if I broke anything on your end. >Just a heads up.=20 > >Brian -- If you want to try it w/ your MSSQL you can download the latest >RLIB: http://www.sicom.com/~bdoan/rlib-1.3.7.tar.gz > >- Bob > =20 > It works OK. Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
|
From: Bob D. <bd...@si...> - 2006-01-07 20:53:09
|
Zoltan, I added forward only cursor support to the ODBC driver. MSSQL and MySQL should now work. Can you let me know if I broke anything on your end. Just a heads up. Brian -- If you want to try it w/ your MSSQL you can download the latest RLIB: http://www.sicom.com/~bdoan/rlib-1.3.7.tar.gz - Bob -- Bob Doan <bd...@si...> |
|
From: Bob D. <bd...@si...> - 2006-01-06 15:05:23
|
Applied Thanks! - Bob On Thu, 2006-01-05 at 23:55 +0100, Zoltan Boszormenyi wrote: > Hi, >=20 > I just noticed that every input modules and rlib.so.1.3.7 are linked to= =20 > everything > that was detected during ./configure, e.g. postgres.so is linked to=20 > libmysqlclient.so > and libodbc.so, too. They don't need to be, and it defeats the very=20 > purpose of using > dynamically opened input modules and the fine grained RPM packaging is = also > broken in this context. E.g. rlib-odbc cannot be installed where e.g.=20 > mysql isn't installed. >=20 > I have solved it in the attached patch. Now everything is linked to the= used > libraries only. >=20 > Best regards, > Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi >=20 |
6 messages has been excluded from this view by a project administrator.
