[cl-pdf-devel] Representation of basic PDF objects

[Marc Battyani]

"Arthur Lemmens" <alemmens at xs4all.nl> wrote:
>
> Yes, something like that feels more Lispy to me than the way it's
> currently done. After sleeping on it, I still have the feeling that
> sooner or later we'll want to move towards representing each separate
> PDF dictionary type by a full-fledged CLOS class, with each slot
> corresponding to a key in the dictionary. It should not be too much
> work to build a table that maps the case-sensitive PDF key names to
> Lisp's normal way of naming symbols. But I'm probably not going to
> do that this week, and next week I'm on holiday.

I'm don't think it will be a good idea, who will have to create big clos
objects because they are potentially lots of slots even if most of them are
never used. You will also have to write a write-object method for each of
them and the memory footprint will be higher. All this for no advantage when
you generate pdf and only a small one when you parse one. And parsing is
very seldom used compared to writing. IMO even if I had to rewrite cl-pdf
now I will stick to the alist or plist model.

BTW my most important problem (and probably yours too) is the lack of time.
So I would very much prefer that we work on new functionnalities and
features rather than trying to update something that works already pretty
well. ;-)

For instance the charts I wrote are rather crude, there is no support for
unicode, etc.

Marc