@isaac Laid out looks really interesting, thanks! I’ll see what it can do for auto layouts and such. Same for scribus.
1 Like
I haven’t been following this thread but in the past I made a small newsletter using Inkscape. It was a single edition and by my own volition when I was volunteering with a non-profit. It probably wouldn’t be a good idea to use Inkscape for designing a photo book because it can be buggy and, as far as I know, it doesn’t have proper color management.
What I found useful at the time was creating templates with placeholders for text and images. Each placeholder would have a variable to which I would link an object. Each page would be a new layer. Then I would export every layer and combine them into a publication using a PDF editor. It was so long ago, so I forgot exactly how I did it.
I do calendars for the family in inkscape every year, about 8 individual ones, and the biggest issue is the missing multipage support. I see this feature on the horizon (or on inkscape roadmap) for >> 10 years, and am still waiting. Dealing with 8 X 13 svg files every year.
I even did a little photo book like that.
1 Like
Yes, the pace of their development is pretty slow 
. (I wonder if it is worth it to add the Inkscape community to this forum even though it isn’t exactly for photography to grant them more visibility.)
I would not say that in general, for some features the development is pretty fast, I would say the feature development is rather web-centric and the web does not care about multipage documents.
From my side +1 for adding the inkscape community since for me adding a photo to an end product such as a calendar or a book cover or … is part of the photographic process. But most people today think only about Facebook or their blog as destination for their photos.
I don’t think inkacape is the best tool for the job here, but it is certainly a program that is straight forward and will make a PDF.
Digging into Scribus more, my main question is how to present the information without it being a desktop publishing primer. Even as I see it now, this will be a fairly lengthy article and there are so many places where if you don’t get it just right (color management, bleed, trim), it just won’t look right.
Inkscape may be part of such a project, e.g. for the cover design.
Probably an example project could help as a golden thread for an article like that.
I would say, that the todo list should look like this:
- Create a (small) photo book in Scribus manually, to check if it is the right tool.
- I can write a Lua script, that exports the selected images in darktable and starts scribus with parameters. (It is possible to start Scribus with parameter, that runs a script in Scribus.)
- We need a Python script in Scribus that does the work there. There are already the scripts @paperdigits found. Someone needs to modify this scripts to run with parameters from the command line and without GUI.If that is done we can call this script from the Lua script in dt.
The ordering in darktable is a minor point and could be earliest fixed in a release next year, because dt is in feature freeze for 2.4. Perhaps you can write a bug report with a detailed description, how this should look like. It is possible to tag photos in dt. And it is possible to write a simple Lua script to export the selected photos and name the files like the tags. But that is of cause not very user friendly.
2 Likes
To scribus darktable interaction: I don’t think a scribus export is necessary as long as there is no two-way communication. From my experience I know that after exporting the photos there is a lot of work on the layout and moving the images around and changing the images etc. and this would require to be able to go back to the raw developer at every state of the layout. If this is not possible, the initial layout could be generated without darktable interaction, because it would be only the initial design.
The ordered collections point would be the more important one since it would help in the preselection of the photos. While I could write a feature request, I have done too many of them and feel a guilty conscience already (is this correct English?).
@chris could you describe the ideal workflow you would like to have?
And don’t feel guilty. If it is a useful feature a lot of people will benefit.
Which one do you mean? The sorting thing? This was described in this thread before (see the big blue sketch).
And the scribus darktable interaction? What I mean is that an image could be linked between scribus and darktable, such that a change in darktable will update the image in scribus and that you have the possibility in scribus to e.g. right click and select a context menu entry to get back into darkroom of darktable with the image opened. An explicit export would not be required in that case, but an UI for linking the image in dt and scribus would be necessary.
One important aspect (this feature idea I already described somewhere else here on pixls.us) would be that the crop in darktable is only used for an initial crop in scribus and that the image parts cropped away are available if necessary, e.g. to fill page bleed etc. A change of crop in scribus should not be reflected back to darktable, since in darktable it is an artist’s decision which crop is selected and in scribus it is the designer’s need to deviate from the artist’s decision 
.
Edit: Found the discussion I referred to before: Feature request/idea that concerns several programs/projects: Crop info in metadata instead of cropped image - #36 by Jonas_Wagner. If you make it to read half of the thread, please continue to the end, there are some positive turns in the second half 
.
I think dark table would really only need to keep track of the export location, as you can tell scribus to reload the image from disk.
I’m all for automation, but if you don’t understand the problem domain (DTP/page layout) the automation isn’t going to be good.
For this purpose, the export location would probably be a hidden cache folder, e.g. the darktable config folder. Some little problems would have to be solved anyway, e.g. the cache would have to be rebuilt if it is deleted (automatically triggered by scribus or manually from darktable), scribus would have to trigger the export from darktable if something is missing, scribus would have to watch the cache for changes etc.
Therefore I said above
(… while I still think the raster image bounding box crop thing would be extremely useful and the sortable collections feature would be useful anyway).
Feature freeze starts coming Saturday. So if you hurry up … 