Table of content attributes : get the text of the box automatically

Previous topic - Next topic

Jdarc

Hello,

When creating sections for a table of content, one has to create an attribute and give it a value.
It would be nice if the default value was the text contained in the box. Most of the time, it is the same thing.

And in the particular case, people change it themselves.

But I am pretty sure that the default behavior should be to copy the text of the box.

What do you think about it ?

Thanks

GarryP

Hello Jdarc, and welcome to the forum.

At first it seems like a good idea but what about situations where you add a TOC attribute to a text frame that contains the body text and not just a section name. It's quite common to do this as you're less likely to delete the body text than you are to delete the section title (e.g. if you're making major reformatting changes). Or your section headings might be images or illustrations. Automatically copying the whole text could mean that you get a TOC entry with thousands of words.

There could be an argument for automatically adding just the first sentence within the frame rather than the whole text though. It might be better than nothing as a default. However, then the problem of how you would define a "sentence" raises it's head. For example, your text frame could contain "Heading This is the first sentence." where "Heading" is formatted differently - as a paragraph - to the other text and has no full stop. It's more difficult than it looks.

On a related note: Coming up in 1.5, I believe there will be functions to use specific sections of text as "variables" so maybe this could be incorporated into the above. For example, define a section of the text as a variable and use that variable - automatically if one exists? - in the TOC value. If the text changes, the variable will change also and so will the TOC value. Or it's quite possible that this is a silly thing to be thinking.

Garry.

Jdarc

Hello GarryP,

Thanks for your welcome.

You may be right, but most of the time (reporter experience), when people choose a box to be in the toc, they just choose the title they prepared, not the whole box. But again, maybe it is not the case for the average user.

This and the slowdown Scribus shows on big documents with images and svgs are just the two points that hold this application back from the majors.

As far as the first point is concerned, it is just a slight change and the second point is just disabling the display of the page that are not in scope to improve responsiveness.

Just my 2 cents. I looked at the source code to patch it, but it seems very complicated as it is. Definitely not the kind of project you can be easily involved in. Will need more time to understand & help Scribus.

Bye :)


a.l.e

hi jdarc

i don't 100% get your question...

but all i can say about TOCs, is that one should really not use that in scribus.
in my eyes, the properties based TOC is as unfriendly as possible...

there have been patches for adding a style based TOC in 1.5svn, but i don't think that they have been integrated into the main code.

at some time there will be a real TOC in Scribus, but for now, you'd better add it manually... really!

GarryP

You're welcome Jdarc.

It's horses for courses as to how people use the TOC. Sometimes you choose the heading, sometimes the body text, sometimes something else. I've used it a few different ways myself. Everyone to their own.

As a.l.e (hello there) has mentioned above, it's long been known that TOC (and index) handling isn't great and there have been discussions about it for ages. And I agree that - especially if you have any specific formatting needs - manually generating the TOC (and other stuff like that) is probably best if you want to make sure it's right.

My documents are never very large so I don't really experience much slowdown except from my memory-starved machine in general. There are a few things you could try to speed things up a bit:

Image Display

* You can tell Scribus not to show images at all using "Document Setup / Display / Show Images - uncheck". It's a bit crude as it's for the whole document but it might come in handy sometimes.

* You can tell Scribus how to display an individual image by right-clicking and choosing "Preview Settings ->". You can specify a resolution or tell it to not display at all. Good for individual frames but I don't think there's a global "re-display everything again" function. (PDF export should not be affected by these settings, just the screen display.)

Neither of the above work for SVGs unfortunately. (You could try converting to EPS and putting that in an image frame but that's a step backwards. Might be okay for early page layout tests though.)

Layers

* If you're not really using layers much you could add each section to its own layer(s) then make the relevant layers visible/invisible as necessary. It's not a great solution but it might come in handy. (I've never done it myself so I don't know how well that would work in the real world.)

* Or you could put your images and SVGs onto separate layers and switch those layers off when you don't need to see them. (Unfortunately you have to switch between layers to move stuff around so that's not a great option either.)

Looking to the future, if you could take the time to come up with some kind of good solution in code then I'm sure the developers would be happy to take a look at it.

Cheers, Garry.