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

[Arthur Lemmens]

Dmitri Ivanov wrote:

> I partially agree with both of you. I neither see real necessity to switch
> from alists to plists for dictionary representation, nor need to use symbols
> instead of strings pervasively. But to facilitate parsing, we should unify
> as much "atoms" as possible. Here is the excerpt from my rather old post:
>
> | For dictionary property names, I would recommend using symbols like
> |> |/Length| or keywords with corresponding string set as properties,
> |> e.g.:
> |
> | (setf (get :length 'pdf:namestring) "/Length")
> | (defmethod write-object ((obj keyword) &optional root-level)
> |   (declare (ignorable root-level))
> |   (write-string (or (get obj 'pdf:namestring) (symbol-name obj))
> |              *pdf-stream*))
> |
> | Strings are quite enough for the time being (generation), but could
> | lead to excessive memory consumption and performance degradation for
> | more complex tasks: parsing and editing.

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.

Regards,

Arthur Lemmens