|
|
tocgenerator-levels.patch (616 bytes) |
|
|
Tab stops need to be setup via the Stylist to actually make it look good of course :) |
|
|
And I might add a qMin(lvl, 4) to guard against weird behavior if large values are accidentally entered? |
|
|
Here is a patch with qmin(4, lvl) added tocgenerator-levels-qmin4.patch (625 bytes) |
|
|
Here's a screenshot illustrating the crucial part: scribus_tableofcontents_parameter.png (41,285 bytes) |
|
|
... just a thought: wouldn't it be better to apply a different styles for each level of the TOC? (personally, i normally prefer not to indent the TOC) the simplest way to do so, might be to add a checkbox: [ ] Use indexed style names for the table of contents some notes: - I don't know what would be a good label for the new checkbox... but the one above might be good enough to get started... or you can always use the style and remove the checkbox... - if the checkbox is checked, only style names that end in 1 are shown in "Paragraph Style" - for each level use the style with the same name as the one that has been chosen and the correct index (toc_1 -> toc_2; if the style does not exist, use the "highest" that exists) this might be added in a second step, after the attached patch has been accepted. |
|
|
I do see this as out of scope for my efforts, but I'm not opposed to having more flexibility. BTW, not indenting subsection is already the default behavior, because the default style doesn't have any tab stops defined. To get the indent you need to define a tab stop. |
|
|
i gave up on the idea of adding support for multiple TOC styles in the TOC frame. (in favor of a python only solution) since now there is a ok way to create style based multilevel TOCs, i would prefer to see some work towards a real style based TOC in scribus that replaces the current implementation rather than putting more efforts in a tool that is basically broken by design. |
|
|
Given the trivial nature of the change, I don't see why long term future development should prevent my patch from being applied, as it immediately makes the toc generator more useful. |
|
|
yes, it's a trivial patch. and it should be a trivial thing to accept it. the problem with it, is that -- in my eyes -- adding a tab is the wrong way to do the multilevel TOC. it really should apply different styles. that is not a huge problem per se. but i really fear that if the tab "feature" gets added now, future versions of the TOC might need to support that too (the team has a hard time removing features, even if it's very likely that nobody uses them). and that would be a useless complexity. (and scribus is full of such things!) all in all: i still believe that the current TOC tool is not usable (for trivial TOCs you'd better write them as text; for complex ones you won't be able to fill the attributes with the titles and it's really impossible to make sure that edits in the titles are reflected in the attributes). the script i've wrote make it usable, if there is the support for a multilevel TOC. but if you need to run a script, why would you want it to fill the attribute and then run the TOC tool and still not get proper styles in the TOC... if you can run a better script that directly fills the TOC? i understand that you did some work and it would be a pity to throw it away... but, in this case, it might be for the better (in exchange you get a nice script that creates TOCs with styles : - ) |
|
|
That's a concern I get, though it's 2023, and Scribus still doesn't have multi-level ToC, so I'm not exactly hopeful for a "proper" implementation of multi-level ToC any time soon, and while I totally get you've had to prioritize given limited resources... Given there's no real alternative on the horizon, isn't the tiny long term risk worth taking, so Scribus gains this fairly rudimentary function? |
|
|
as said, you can use the script i've put in my github repository... utnik tested it and i fixed a couple of bugs already that he has reported... on the other side, i'm all for having a real TOC (and remove the thing that is now in scribus) and maybe my script can be used as a prototype for the real thing in scribus. |
|
|
I thought you had given up on that... Presumably you mean: https://github.com/aoloe/scribus-script-repository/tree/master/table-of-contents BTW, I'd suggest using (by default) 'Heading 1', 'Heading 2', 'Heading 3' and 'Content 1', 'Content 2', 'Content 3' respectively, since this is what LibreOffice Writer uses. |
|
|
@ale, I've just tested table-of-contents.py but it doesn't seem to account for Document Sections, which incorrect page numbers are generated for non-trivial documents. |
|
|
@ale also overwriting whatever frame is currently selection isn't ideal either, it would be rather nice if the Destination Frame from the Table of Contents properties could be used. |
|
|
Multilevel TOC would be nice. Doing this with a TAB though is (1)cumbersome and (2) unintuitive. As for how I'd implement the feature - which is probably a lot of work - I'd add a checkbox to the paragraph styles "Use in TOC". This should give a sub-style (maybe another Tab in the Styles-Section dubbed ToC-Style; that has all the style-features a Paragraph allows). Then on generating the ToC, the ToC-Substyle would be used for the ToC. An easier way would be to create another Paragraph-Style automatically when that check-box is set, and name it ToC-{ParagraphName}. Which would probably be a lot easier to implement. This should give an intuitive way of doing the multilevel ToC. The more hidden ToC-Approach, that would build on what's currently there, would be to add a fixed Attribute of "ToC-Style". It's probably even quicker to implement, but, as others have already said, more prone to errors. |
- Anonymous
