Michael Meeks wrote: > Sure - that's the draw:data stuff - the QR code is ~trivial to > re-generate from the raw data; so in this case: > > draw:engine="org.libreoffice.draw.barcode" > draw:data="this is the QR code content"> > Ah, that's quite nice!
> > See above - I might miss the broader picture, but I think easiest > > would be direct embedding of the graphic. Would also solve your bitmap > > question. > > Fair cop. Of course the problem is really a bit larger than this > though: we want to be able to have 'field' or other equivalent > functionality that lets people easily automate / populate QR codes via > scripting / database'y bits (I guess). > > It'd also be rather ideal to be able to eg. render the page-number > field using python in some arbitrary / fun way =) [ growing flowers or > whatever ]. > > So the question is mostly - which foundation to try to build that thing > on =) > > Does the CustomShape stuff look like a sensible foundation on which to > build that ? I guess I'd really like some custom field-like > functionality too ;-) > Compared to e.g. svg, custom shapes appear pretty limited in expressiveness. OTOH, you get interaction capabilities (those broadness-of-smile handles) for free. For the all-generic-use-whatever-complex-rendering approach, I'd personally stick an svg image in with custom (comments, or foreign-namespace) data content, that an extension can then update. For your flowery page number, probably a custom shape is just fine. ;) In the end, I probably have no clear idea what your field/scripting/database use case really entails. There's XForms, which claims to solve those things & world hunger, but hey. :) Cheers, -- Thorsten
signature.asc
Description: Digital signature
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
