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

[Dmitri Ivanov]

Hello Marc and Arthur,

| Marc Battyani wrote:
|
|> "Arthur Lemmens" <alemmens at xs4all.nl> wrote:
| >> Mapping names to symbols, dictionaries to property lists
| >> and null to nil would make for a more elegant mapping than
| >> what CL-PDF seems to be using now, I think. CL-PDF seems to
| >> use Lisp strings for names, and :null for NIL.
|>
|> Hum... I prefer the current mapping.
|> Names are case sensitive so symbols are not a good representation
|
| Well, symbols are case sensitive too. But it is a good point that
| I hadn't thought of yet.
|
|> Also you have to generate names for fonts and other temporary pdf
|> objects. You would end up with lots of symbols! (and symbols are heavy
|> weight objects compared to string) Alists are as nice as property
|> lists IMO but they work with strings. The true/false is not a real
|> problem, IIRC there is only one place where a true is used and none
|> with false.
|
| You look at this from the point of view of generating PDF, but at the
| moment I'm looking at it with the idea of parsing and editing existing
| PDF documents. That gives a slightly different perspective on stuff
| like this. As a matter of fact, at the moment I'm even considering the
| idea of (semi-automatically) defining a CLOS class for each kind of PDF
| object with separate slots for corresponding to each dictionary key.
| That way, you could edit any element of the document by using the right
| (setf slot-value). But this may be overkill, and it may take more time
| than I can spend right now.

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.

--
Sincerely,
Dmitri Ivanov
lisp.ystok.ru