>>> (I know that Holger Klemm (from multimedia4linux.de) made a >>> lua-script >>> for such a thing.-) >> >> That sounds great. I'm curious how it is implemented. > It's done with montage and mogrify (from ImageMagick) and > exiftool. > The code is here:-) > https://multimedia4linux.de/index.php/bildbearbeitung/darktable/darktable-plugin-digitaler-kontaktabzug
It looks quite nice -- a good range of features. So nice that I'm a bit hesitant to make a quick version in the print view which does a subset. But I suppose what print view could bring to it is that there's already a good GUI-oriented way to set up boxes and fill them with images. And that print code already does the work of scaling images to a common DPI and converting to a common colorspace, So there isn't that much remaining work to do. Current print view creates a hand-constructed PDF and sends it to CUPS or Turboprint. Output to file would either hand-construct a composite image or ask Cairo library to do this, then can output with the help of existing imageio code. Future work could allow for a more "automatic" way of creating boxes, e.g. in a grid. I'm not sure if the other things (image labels, title for the grid) are totally out of scope, though. I've used all sorts of awkward ways to do similar work -- ImageMagick command line, dragging images around in GIMP, either Scribus or Inkscape (can't remember), Libreoffice Draw. This does really seem like something which it would be nice for darktable to do. Query is that once print view has a really layout code, does it cease to be print view, and become something else (multi-image layout, with options to print or export to a file)? Another query is whether the monolithic "print settings" in the right panel gets split into a couple modules, with one remaining "print settings" (with a print button), one handling "image layout" (what's currently in print settings under that name, plus any more options), and as well an export module (as in lighttable: file type, resolution, an export button, etc.). I seem to recall that the code is so tightly interwoven that the split would, internally, be a challenging one. >>> It seems for me, that the presets are stored in data.db as a >>> BLOB, >>> so I can't find out quickly, what went wrong. >> >> You may have some control of this. Try adjusting "store XMP tags >> in compressed format" in the storage tab of preferences to >> "never". > This settings doesn't help.-( I had "only large entries" before. > I "lost" the first column of the image areas but can't create new > areas because I got the message "maximum image per page reached" > (Is there a small typo? Should it be written as "maximum images > per page reached"?) Alas. The basic point is probably just that the system doesn't work for saving presets of multiple image positions. And parsing the blobs won't change that. ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to darktable-user+unsubscr...@lists.darktable.org
