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.me...@collabora.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
