On Fri, Jun 26, 2026 at 09:24:36PM +0100, Gavin Smith wrote:
> The CONVERTER type (defined in tta/C/main/converter_types.h) has quite
> a lot of fields, many of which are only relevant for the HTML output format.
> I would like to find a way of separating the format specific code from the
> converter object, now I am working on adding a new output format to the C
> code (Info/plain text).
>
> * Could there be output-format-specific types like HTML_CONVERTER that
> would contain a CONVERTER object (or pointer to the object), that would
> only be used in the code for that output format?
I do not think that it would be practical with the current approach with
a dispatch using functions, as the functions need to have the same
prototype for all the formats. Also there are fields that are common to
all the converters, though not that many. That being said, that would
be a good option if it is feasible, as it would allow to use a code
that is quite natural. So if you have an idea on how to modify the dispatch
in converter.c, that could be good.
> * Alternatively, the CONVERTER object could contain a void pointer to
> a structure for format-specific data.
That seems possible to me, but I think that it is inferior to the
option you prefer not to have below. It seems to me that having one
pointer for each of the possible format that need specific data
is similar, but better, as there is no need for casts and the
type checks can be done more easily. Like
/* common fields */
int converter_descriptor;
CONVERTER_INITIALIZATION_INFO *format_defaults;
/* format specific data */
HTML_CONVERTER *html;
PLAINTEXT_CONVERTER *plaintext;
...
Another advantage is that it is possible to have two formats
for one converter, for instance if we also do a converter to LaTeX, the
call to LaTeX conversion in the HTML converter could use the
LATEX_CONVERTER pointer of the HTML converter.
If we want to avoid unused memory and we are sure that some formats are
never used together for a conversion, we could even use a union, but if
we have no more than 20 output formats, I do not think that it is a
real issue.
> * Slightly more complicated, the CONVERTER object could contain a void
> pointer to a structure for format-specific data, which itself has a
> pointer back to the CONVERTER object. This would allow conversion back
> and forth between the two types with minimal casting, (e.g. CONVERTER and
> HTML_CONVERTER) with minimal casting, if that would be required.
I did not understand this one.
> * The CONVERTER object could have sub-objects for each output format
> (this would be close to what we have already). I'd prefer to avoid that
> if possible.
See above, I think that it is not such a bad solution.
--
Pat
