Utility script for book typesetting - stub line endings, hyphens, frame breaks

Previous topic - Next topic

Lynn

There's been a few requests scattered throughout the forum from folks looking for ways to implement certain book typesetting norms:
  • The last word of a paragraph should never be hyphenated
  • According to some sources, the penultimate line of the paragraph shouldn't be hyphenated
  • If the last word of a paragraph breaks to its own line, it should be longer than a certain minimum length. Short last lines are called "stubs" or "runts"
  • Words that are already hyphenated, like "pell-mell" shouldn't be given additionally hyphenated by the software
  • Chapters generally begin after a frame break

I implemented all that in one script, plus an extra feature to apply a character style the first X characters/words or up to a delimiter at the beginning of a selected paragraph style (handy for when you want each chapter to start with a few words in small caps, though I suspect I'd probably end up manually adjusting them).

https://github.com/notwhelmedyet/ScribusTypesetting/blob/main/runtsAndStuff.py

Since there's no way to mark in a Scribus XML file (yet, waiting on Ale's patch to get accepted) that a word shouldn't be hyphenated, the script needs to be run after the whole document has hyphenation applied. It will selectively go through and remove the unwanted hyphens.

There's also no "frame break right" option in Scribus so the script only inserts one frame break. If you needed each chapter to start on the right, you'd still need to add an extra break as needed while cleaning up your file. The script assumes you've already applied the style for chapter titles because I always import my text with that pre-styled; if you have a different workflow you could just toggle that option off and do your frame breaks later.

It saves a copy of the file so there's no worries about it corrupting anything & has variant code so it works in 1.7.1+ and 1.5-1.6 versions of Scribus.

As is my typical style, the script opens a series of menus where you can pick the operations it will run; if you hate menus you could save a copy where you remove those dialogs and hard code the settings.

a.l.e

Very interesting summary.

Personally, I have a hard time believing that Scribus will be able to add all or even any of the rules you mention.

The main hurdle I see: adding an algorithm that is somehow performant and that will manage to never produce a really bad result. In one pass.

... And this with the limited number of contributors currently active in Scribus...

But, what I think might be possible, is to get Scribus to give information about the possible and enhancing the scripter API to allow a more or less automatic enhancement of the text flow through Python scripts.
A bit like what you are doing with your script, but with interactions with the document's frames and not by tweaking the XML in the .sla.

What do you think about it?