Thread: [Rlib-devel] RPDF font embedding

Brought to you by: chet99, woobster

rlib-devel

[Rlib-devel] RPDF font embedding

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

Re: [Rlib-devel] RPDF font embedding

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

Re: [Rlib-devel] RPDF font embedding

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

Re: [Rlib-devel] RPDF font embedding

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

Re: [Rlib-devel] RPDF font embedding

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

Re: [Rlib-devel] RPDF font embedding

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

[PATCH] PDF Object references made dynamic Re: [Rlib-devel] RPDF font embedding

From: Zoltan B. <zb...@du...> - 2006-01-17 09:32:19

Attachments: rlib-1.3.7-rpdf-dynamic-objects.patch

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

Re: [PATCH] RPDF link to GNOME-VFS Re: [Rlib-devel] RPDF font embedding

From: Zoltan B. <zb...@du...> - 2006-01-17 10:03:44

Attachments: rlib-1.3.7-rpdf-use-gnomevfs.patch

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

Re: [PATCH] RPDF link to GNOME-VFS Re: [Rlib-devel] RPDF font embedding

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

[Rlib-devel] [PATCH] Use ZLIB to compress page contents

From: Zoltan B. <zb...@du...> - 2006-01-18 10:26:21

Attachments: rlib-1.3.7-rpdf-compress-pagecontents.patch

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