[barcode] PNG output patch

[David Santinoli]

On Tue, Jun 02, 2009 at 10:58:33AM +0200, Alessandro Rubini wrote:
> 
> > - add an extra argument to Barcode_Print (would break
> > compatibility);
> 
> Yes, that's an issue.
>  
> > - add an extra member to struct Barcode_Item, and a new function to
> > set it (Barcode_Config, maybe?) before calling Barcode_Print.
> 
> I prefer this way.

Fine.
What about the actual implementation of Barcode_Config?  Maybe an
ioctl-style function, although requiring more verbosity from the user,
would be acceptably future-proof.  Something along the line of

  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);

(this might also provide emulation for Barcode_Position.)

Alternatively, a more targeted function could be defined, e.g.

  Barcode_Text_Font("/path/to/my/font.ttf");

(We could also get rid of such a function altogether, asking the user to
set Barcode_Item.ttf_path directly, but the function approach seems
cleaner to me.)

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?

Thanks,
 David

PS the final version of the patch will also include GIF output with very
little extra code.
JPEG output, too, could come for (almost) free, but would it make sense?