[barcode] PNG output patch

[David Santinoli]

On Wed, Jun 03, 2009 at 03:58:20PM +0200, Alessandro Rubini wrote:
> >   Barcode_Config(BARCODE_CONFIG_FONT,"/path/to/my/font.ttf");
> >   Barcode_Config(BARCODE_CONFIG_FG_COLOR,0,255,0);
> >   Barcode_Config(BARCODE_CONFIG_BG_COLOR,255,255,255);
> 
> Yes, but I prefer to have only one more argument after the name,
> of type intptr_t (so either integer or pointer).

Would this require checking for availability of intptr_t in the autoconf
files?  That scares me. :-)
What about good old void * instead?


> > Whatever mechanism we choose, I see a potential problem with the
> > stand-alone "barcode" front-end.  Since the one-code-per-page case
> > (rather frequent, I think) is handled through
> > Barcode_Encode_and_Print, there would be no chance to invoke the
> > font-setting function, which in turn would cause the PNG backend to
> > fail.  Would it be OK to rewrite main.c unrolling
> > Barcode_Encode_and_Print?
> 
> Yes. I'd keep Encode_and_Print for postscript output, while using
> the config step for png.

Wouldn't an unrolled Barcode_Encode_and_Print (around main.c:546 in my
patched file) work for all formats?  I might be naive but I don't see
the need for differentiating paths here.


> > PS the final version of the patch will also include GIF output with
> > very little extra code.
> 
> Yes, once you have a bitmap format any other format is easy. But I
> wouldn't like to have GIF natively. GIF is dead, isn't it?

It's probably going the way of the dodo, but it's no longer encumbered
by patents nowadays, so IMHO it wouldn't harm (considered that its
addition is really trivial).  But if you prefer to support PNG alone,
it's fine with me.

David