Migrating from my own package to resilient...

[jodros]

I'm migrating my projects to resilient and now I'm missing two features that are really important for me.

• Is there a way to have a user-level default .silm file to be inherited by every other silm project, in order to not have to copy and paste the same file for every new project since I always use the same configuration? For example, have a ~/.config/sile/default.silm with my name set in the metadata section, my favorite font, those packages I use every time, etc., and when it comes to run a new project, I'd just specify its chapters and other new specifications (and of course being able to overwrite those options set in default.silm).

• How can one declare new individual frames or even new layouts from the .silm or .yml files? ¹

  • I'd like to create a lot of different frames layouts and be able to switch between them throughout the book.
  • I'd like to change other frames dimensions besides content, like footnotes or folio without touching the source code.
  • I'd like to have more than just one content frame². And declare/modify them without touching the source as well.

Both were features of my "defunct" config.sile package.

Footnotes

1. I'm not talking about just defining the dimensions of content frame, e.g. using the geometry layout option. ↩

2. Including multiple column layouts ↩

[Omikhleia]

Regarding the first point

I considered it briefly at some point, and (at the time) rejected it for several reasons:

• At project initialization, it's not too difficult to have an external tooling for copying and setting up a master file and basic folder hierarchy (images, book templates etc.), without needing model-level inheritance at the master file level. E.g. I've a very basic NodeJS-based CLI for my own use (quite specialized in its current form, hence never shared): it sets up a folder tree, copies some resources and writes up a master file with my usual starting setup. It could be made nicer and more generic, but the point is that it doesn't require extending the master document format.
• I like to view a "book" as a "standalone object" (you can zip its content, share the archive, and voilà! without dependencies outside of its scope), which would be defeated if some bits come from a ~/.config/... folder i.e. not located close to the project...
• And I have objections for anything that lives in a user folder (~/.config/...):
  • I never run SILE on my host, but only via docker images, and I never expose my top-level folder to these images (separation of concern and security concerns when running other software in these images)
  • It often ends up cluttered with left-over crusts of previous versions, that remain unnoticed (and are problematic when one runs several versions of a software)
  • Hidden (dot-prefixed) folders are evil 🤣

This being said, while I was reluctant for master files, inheritance and transclusion at style file level is something that might see the light (#89), though I'm not fully sure how I'd implement it. I had a prototype, but it's a long way from covering the topic correctly.

Regarding the second point

• Being able to be to switch between layouts throughout the book is something I also need - In the linked example, I need the front matter and back matter to use a classic layout, while the main matter need the "marginal" layout due to the heavy annotations in margin... I used a hack here, but I know where to go from it at some point.¹

• Your two other bullets would need a rationale to understand the need, because I think there's a source of potential confusion: page layout vs. content layout. In the grand target scheme:

  • page layouts define how the main blocks (= normally only the footer, header, text block and side margins) are organized.
    • They are "more or less" standardized (though they are currently modular and we could add more)²
    • One of the thing I tried to address (at the cost of flexibility) is that no end-user should even have to type magical arcane stuff such as top = "11.6%ph" or bottom(footnotes)+3%ph" (where do this percentage come from, by the way? No one knows)
  • How the content is organized in the text block is a whole different topic.
    • A two-column layout isn't even a real thing... One might want (chapter/section etc.) headings spanning to some extent, and bare text be on N columns, for instance)...
    • ... but grid-based layout systems (not the grid layout from SILE's grid package) are these kind of things:
      
    • ... and they are not within the possibilities of the current typesetter and page builder from SILE's core.

So what? One needs a whole new typesetter and page builder there.
And SILE's frame implementation breaks at every corner. And footnotes are not implemented as they ought. And multi-column needs a lot more than it seems at first glance.

It goes far beyond what a "collection of classes and packages" for SILE can do -- It would be a whole rewriting of many other lower-level components, with no compatibility ensured.

Footnotes

1. It would have to support higher level "book sections" (covering in part frontmatter, backmatter, appendices etc. #19), which can have a different layout. ↩

2. Doh I still haven't pushed that nice additional layout for pocket-sized books, discussed long ago with a knowledgeable party. I had forgotten it 🤣 ↩

[Omikhleia]

Addendum - Some nice introductions for concepts:

• modular grid layouts
• what SILE calls a "grid", i.e. actually a baseline gird