Design & Print: Content and flow

[sinus]

Hi,

With this tool (D&P) we can do really  a lot.
We can design a whole book with footers, headers, Title-page, group-pages and so on.

Working at the moment with a big catalog, I miss only one big thing and one small one.

Say, we have a catalog with 300 chairs (or fruits or persons ...).
We have for example 2 images per page.

Hence the whole book has about 150 pages.

1) is it possible to add "automatically" a page of content? (Inhaltsverzeichnis) Maybe with variables? Or antother clever trick?
Say, a small image and the page on where this image is.
See my attachement, what I mean.
It is created with the cool variable from Mario for the image: {Group:{Print.Container.ZOrder}.File.FullName}
But what is still necessary to have a content-page is simply the page on where the image is printed.

I do not think, if this is possible. Specialy because IMatch has first to "print" a page, before it know the page for this image.
Hence maybe such a content must be at the end (what would also very good!).
I tried some things, but had no luck.

Does anybody know an answer for this?

2) the second question is simple and far not that important like the question above.
we can replicate "down", "to the right" and "to the right and down".
Is there a possibility to replicate "down and to the right"?
Then we can do several columns (Spalten), like the flow in some newspapers.
I think, this is simply not possble, because not often used.

As always, maybe I do overlook something what is in the help.

Hmmm, even both is not possible, I like this tool D&P. It give us really a lot of possibilities. 

[Mario]

1. No idea. Doing table of contents is beyond what D&P can do at the moment. This is nothing you usually need for contact sheets or photo books...

I think this would be doable, but complex. For example, IMatch first has to render all pages, then produce the TOC and then re-render all pages because adding a TOC of course changes all page numbers, may swap left/right pages and so on. Just one of the many problems.

It took Microsoft years to get this working reliably (so-so) in Word... 

2. I think with "down and to the right" instead of "right and down" you mean that D&P should offer another flow option to first fill down and then across?
I'm not sure why such a mode does not exist, but I reckon that this was technically difficult. Maybe. I don't remember.

Feel free to add feature requests and if you get a a sufficient number of backers, I'll look into it. I don't try to implement In-Design or Publisher or Scribus here.

Just look how large the Adobe In-Design team is:

https://indesignsecrets.com/meet-2015-indesign-team.php

plus all the Adobe resources they have access to. One Mario cannot beat that and work on the rest of IMatch...

[sinus]

1. No idea. Doing table of contents is beyond what D&P can do at the moment. This is nothing you usually need for contact sheets or photo books...

For contact sheets I agree. But for photo books finally it would be a cool thing and I have seen it several times.
Makes also sense and specialy with IMatch it would quite natural, because we could add small images and the page number.

I think this would be doable, but complex. For example, IMatch first has to render all pages, then produce the TOC and then re-render all pages because adding a TOC of course changes all page numbers, may swap left/right pages and so on. Just one of the many problems.

Hence it is not possible yet, what I fully understand.
I first thought, after all IMatch renders also the page-numbers. So IMatch could "simply" store internally during a rendering of all pages the filenames of a page and the pagenumber.
And finally IMatch could offer as a last page to print these filenames and pages.

But you know all the problems exactly and if it it not possible in a reasonable time, so it is not possible.  No problems.
Finally we can always doing such a thing "handy".

I tried different things. It worked not.
What was very compromising was to use your cool variable:
{Group:{Print.Container.ZOrder}.File.FullName}

I could print all images small. Then I added the real page with a small script into a metadata-field.  So each image had the correct page number in the metas.
So I added a second text-container with this variable (I tried also others):
{Group:{Print.Container.ZOrder}.File.MD.XMP::photoshop\TransmissionReference\TransmissionReference\0}

First I thought: success ... but then I realised, with these two containers D&P created always only the first line, went not to the second line.
Means instead say 20 images it printed only the first line with 5 images (depending on the amount of cells).
Both containers I setted to "replicate to the right and down".
But it replicated only to the right.

As soon as I deleted the text-container with the variable, all images has been again here.
Maybe I did something wrong or this is a glitch or it can simply not work.
Finally this solution worked not.

Hence I think, I will first create the big pdf without any table of content.

Then I will create a second pdf (with another template) with the images and the pages from the metadata-field, this should be no problem.

And finally I can "patch" this pdfs with the "table content" to the big pdf (with acrobat reader) and so I will end with a photo-catalog with a proper table content.
Hence finally IMatch will also solve this problem for me! 

2. I think with "down and to the right" instead of "right and down" you mean that D&P should offer another flow option to first fill down and then across?
I'm not sure why such a mode does not exist, but I reckon that this was technically difficult. Maybe. I don't remember.

Feel free to add feature requests and if you get a a sufficient number of backers, I'll look into it. I don't try to implement In-Design or Publisher or Scribus here.

Just look how large the Adobe In-Design team is:

https://indesignsecrets.com/meet-2015-indesign-team.php

plus all the Adobe resources they have access to. One Mario cannot beat that and work on the rest of IMatch...

Yes, exactly, another flow option "first fill down and then to the right".
It seemed for me a logical option. But as you mentioned, maybe it was too complicated.

Maybe I will add a FR later, but since it is not that important, I will think about it.

And yes, the Adobe stuff is  quite impressive! 

Thanks for your answer.

[Mario]

And finally IMatch could offer as a last page to print these filenames and pages.

Most users want the table of contents in the front of the book, not the end. This means that all page numbers printed on the "image" pages need to account for the number of pages required by the TOC. And this page number depends on how many "image" pages are printed, so IMatch has to do two passes.

And this is just one of the many things involved by managing table of contents.
Another would be separate page numbers for the TOC and the image pages.
Or maybe TOCs per group.
...

I'm sure there is a handful of IMatch users who would use this, once in a while.
But I don't see me spending several weeks of precious development time for this - not unless many users request this.

[sinus]

And finally IMatch could offer as a last page to print these filenames and pages.

Most users want the table of contents in the front of the book, not the end. This means that all page numbers printed on the "image" pages need to account for the number of pages required by the TOC. And this page number depends on how many "image" pages are printed, so IMatch has to do two passes.

I agree. But if D&P would offer a TOC at the end of the document, not at the begin, this would be perfect enough for some users, because these users, who does printing such things, would be able to finally "cut" such a page from the end and paste it at the beginning, outside of IMatch.

I'm sure there is a handful of IMatch users who would use this, once in a while.
But I don't see me spending several weeks of precious development time for this - not unless many users request this.

I see this.
That is why I wrote here down my solution, what can be a solution for others, with the current D&P, without any change of you.

Although it would be fine having the possibility of a TOC (the only "real" thing, what is missing for a real book), it is ok for me.

And like you wrote, there are sure some users, who would like this, but not that many users, I guess.
Hence it is not necessary to spend time for this.

And, as I wrote several times in different posts, for most problems, what IMatch does not offer native directly a solution, we can find one with IMatch, but on another way.
We have only to think and try. 

For my project I will use my solution*, this will work very good.

*in short:
1) Create the "book" just normal
2) Check how many images one page has

3) In IMatch use a metadata-field to write down for each image the page-number. Check for this
a) the same sorting like in the book
b) the first page starts with the correct number (maybe not 1, but 5 or so), think at the numbering of the TOC itself
c) if possible, write a short script for this, but is not necessary of course

4) Open witht these image a new "book" in D&P and create a nice TOC (Table of content)
a) and as a text-container use the correct metadata-field with the page-number
b) you can for example create each image very small and place the page-number below
c) you can also be modern and create the page-number for example very big
d) You are really very free using different possibilites creating this TOC, like designing some images, blured and with a low opacity in the background and so on

5) After creating the pdf you can paste this (or these) TOC-pages at the beginning or the end of your "big" pdf. To do so, use Acrobat or there are several free tools for this task.
6) Enjoy your book with a nice TOC-page.