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?

Lynn

Oh, honestly, I hadn't imagined Scribus would implement any of this natively; at least certainly not any time soon. For one thing, typesetting norms vary by language/region/medium and I have no idea whether these rules are applicable outside english-language book typesetting. I don't get the impression many people use Scribus for books, though I think it can work very well for it.

Out of the list, the only one I think is likely universal is preventing the last word of a paragraph from being automatically hyphenated. Perhaps it'd be possible to have a "don't hyphenate within X lines of the end of a paragraph"? Both Affinity and InDesign have toggles for this in their hyphenation settings.

But I know there's certainly bigger Scribus priorities, hence writing a script to automate that task in my projects. (I would definitely rank these fiddly bits way below style-based running headers.)

The initial reason I wrote my script to work with the XML instead of within Scribus directly is that I didn't see a method in the API to edit text that isn't visible on a page in Scribus. When doing book projects, I add pages in chunks as I finalize the text and unlink the text chain at each chapter break. That prevents ever having a really long text chain visible on-screen, and reduces lag when doing 200+ page projects. If I could only edit visible pages, I would have to remember to run the script four or six times per project rather than all at once at the beginning.