Re: [pdf-devel] Filter params type

[Juan Pedro Bolivar Puente]

> What do you mean with "to map" in this context? The contents of the
> parameters hash table for the LZW decoding filter would be something
> like:
> 
>        key                        value
> 
>   ... other fields
>   "EarlyChange"                 (void *)pdf_u32_t
>

By map I mean associate a key to a value.

One question, what's the benefit of getting a pdf_u32_t? I think that if
all values are stored as pdf_chart_t* strings we get lower coupling. For
example, think what if we want to add the capability of passing
parameters to the filter to the simple pdf-filter util. If it where
implemented like you purpose, we would have to write (sorry for the
pseudocode, don't remember the exact hash syntax)

/* Supose that given_param and given_param_value are strings specified
   by the user of the tool, for example: --param given_param
given_param_value */
if (strcmp (given_param, "EarlyChange") == 0)
  {
    pdf_hash_add_int32 (params, given_param, atoi (given_param_value));
  }

If we add another filter, we must add n_params if's like this. Do we
gain something? We still have to statically check the param value and
adapt it, it would be simpler to just have params structure and do:

if (strcmp (given_param, "EarlyChange") == 0)
  {
    lzw_params.early_change = atoi (given_param_value);
  }

In my humble opinion, if we make all params be encoded as pdf_char_t we
can just do:

  /* For any filter, just pass the param to it. If we add new filters,
there is no need to add new case's, the filter will get the value
anyway. The filter can return E_EBADDATA if the param was incorrect, for
example */
  pdf_hash_add_string (params, given_param, given_param_value);


> Note that we are going to implement the PDF dictionary objects in top
> of a pdf-hash variable, and we will have type checking in the
> implementation of pdf_dict_t.

What do you mean?

JP