feature/barcode feedback sought ...

[Michael Meeks]

Hi guys,

	So - I just checked some initial QR code integration into the
feature/barcode branch; it sort of works ;-) but it raises a number of
interesting questions and/or opportunities; and I'd love some quick
directional input from someone clueful =)

	First - what is it so far:

	* I hacked an existing smiley to add the (existing but
	  apparently un-used / buggy) custom draw:engine pieces thus:

    <draw:custom-shape draw:style-name="gr1" draw:text-style-name="P1"
draw:layer="layout" svg:width="8.128cm" svg:height="6.35cm"
svg:x="5.445cm" svg:y="5.064cm"

   draw:engine="org.libreoffice.draw.barcode" draw:data="LibreOffice
prototype, native QR code rendering, thanks to Collabora">
...
    </draw:custom-shape>

	It -looks- like this code was intended to add a rather sexy extension
point for custom shapes via the drawing::XCustomShapeEngine IDL file.
Usually I love to hate UNO - but in this case it looks like what could
be possible there is rather sexy.

	My -hope- is that this with minimal tweaking would allow me to have
arbitrary python plugins rendering interesting document content - and
also serializing their rendered state as an OLE-style preview to the
XML.

	Of course - I'd love to have some feedback on my sanity - quite
possibly this is utterly crazy; quite possibly there are 3x easier &
better ways to achieve the same thing (?) =)

	Known problems:

	* for QR codes (but prolly not bar-codes) the idea of
	  representing a bitmap as a ton of polypolygons is prolly
	  not the greatest idea.
		+ but while you can put arbitrary XShape's in there
		  I suspect serializing that into an attribute is
		  unlikely to work well.

	* no UI yet you need to

	* script-ability - I guess we'd want some field / data-driven
	  / easy-automation magic:
		+ would this work better as a field ?
		+ how about as a general draw shape (the svx draw shapes
		  seem pretty horrible).

	* bar-code specifications:
		+ some of the spec's are a bit strict: "no less
		  than 2mm between X and Y"
		+ that gives some UI / rendering / unit constraints
		+ currently not captured.

	* zint
		+ software quality appears to be dire
			+ hint if you are conditionally replacing
			  malloc with "alloca" on some platforms
			  with no other associated changes - something
			  is wrong.
		+ horribly un-maintained: pick the best of at least 3x
		  under-loved forks.
		  http://users.freedesktop.org/~michael/zint.tar.bz2
		  has a snapshot. 
		+ at least it renders more kinds of bar-codes than
		  is sensible

	Known bugs:

	* ODF / back-compatibility - we re-export the original (in my
	  case smiley) custom-shape which shows up as an unhelpful
	  fallback for older LibreOffice'n.

	* zint is sufficiently bad & closely tied to layout / text
	  rendering etc. it's prolly easier to re-write

	* no system-zint: we're internal / static only - and this is not
	  a good idea; but I'll list it here anyway for completeness.

	I have a blog entry with obligatory screenshot here:

	https://people.gnome.org/~michael/blog/2015-01-25.html

	I'd love to have some clue on how best to fiddle with this / re-work it
somewhere that it fits.

	And yes I have seen this plugin:

	http://extensions.openoffice.org/en/project/qr-code-generator

	which appears to use some google web plugin to render bitmaps
remotely ;-) not great if they contain confidential data etc.

	Thanks !

		Michael.

-- 
 michael.meeks at collabora.com  <><, Pseudo Engineer, itinerant idiot