Proposal: support to style configuration files

[jodros]

As I mentioned in another discussion,

I'd like to know what you think about adding this. I'll give examples based on what I'm doing in my own extension:

The program parses a configuration file, let's say a toml one:

[fonts]   # [family, size, weight, variant, style, color]
main      = ["Cormorant Garamond", "13pt", 400, "", "", false]

After parsed, it'll be added to SILE.scratch at the very beginning of core/sile.lua.

• Why in core/sile.lua and not otherwise, like a package?
  My first implementation used to be a dedicated package, but I couldn't call the options in the core files, what is essencial to do something like this:

SILE.settings:declare({ parameter = "font.family", type = "string or nil", default = SILE.scratch.styles.fonts.main[1] or "Gentium Plus" })
SILE.settings:declare({ parameter = "font.size", type = "number or integer", default = SILE.length(SILE.scratch.styles.fonts.main[2]) or 11})
SILE.settings:declare({ parameter = "font.weight", type = "integer", default = SILE.scratch.styles.fonts.main[3] or "400" })
SILE.settings:declare({ parameter = "font.variant", type = "string", default = SILE.scratch.styles.fonts.main[4] or "normal" })
SILE.settings:declare({ parameter = "font.style", type = "string", default = SILE.scratch.styles.fonts.main[5] or  "" })

Then the program will start already applying the settings in the config file.

Other interesting feature SILE could have that I did recently in my module is support to multiple config files, one for the working directory (with the highest priority) and another in home in a folder like .sile or .config/sile.

The argument: this would allow the end-user to reuse their favorite settings as many as they want, and moreover this would reduce the amount of commands to write in the .sil files, since almost anything can be covered by it, as I'm doing for alignments, main language, paper size, frame set declaration, spacing between lines or paragraphs, etc...

[Omikhleia]

In resilient.sile, I achieved something quite similar (using YAML rather than TOML, but that's not an essential point), with further distinctions. Styling there goes beyond fonts and color only:

• On inline content, it also encompasses casing, super and subscripts, etc. (most properties are actually (very loosely) derived from what "styles" in Word or LibreOffice may offer)
• As of block and sectioning elements, it also encompasses paragraphs, skips, indentation, numbering, etc.

Every style-aware command can define its own style(s), so lists for instance can be styled, etc. in a similar way. The concept is loosely inspired by CSS, but:

• without the "cascading" part (which is often complex and inappropriate for regular non-specialist users)
• with some basic inheritance mechanism (akin to what one would have in SCSS or SASS -- so as to extract and factor reusable parts of a style, rather than repeating it).

The advantage of a structured property-oriented format over a mere list, in my opinion, is that (1) it is more readable, and (2) it is extensible so other packages can leverage it with new constructs if needed.

I haven't proposed this upstream, because (1) I don't think it really belongs to the core distribution to impose a certain styling paradigm over another and (2) it's fairly hard to do right from the start -- on the latter point, typically, now that I am working on making slides, I realize I might want - and even need - to further refine what "sectioning" means and how to style full pages...

... this would reduce the amount of commands to write in the .sil files

As an aside note, SIL (.sil) files should perhaps not have that much of a special focus. (SILE is able to handle other input formats, and personally I would even go as far as suggesting that authoring documents in SIL is quite problematic, though this would be another debate on the pros and cons of it ;-)

... but I couldn't call the options in the core files, what is essential to do something like ...

It should be doable, though, from classes or packages, without having to tinker with core/sile.lua (which is probably too early anyhow to introduce such a strong dependency?)

I also tend to think that the SILE.scratch use is quite problematic and somewhat dirty, though it's hard to replace currently (and I used it too in my stuff). Perhaps we should reconsider it at some point, and at best avoid using it across package/class boundaries, so as not to depend on internal implementations (but rather on clean APIs).

[Omikhleia]

The program parses a configuration file, let's say a toml one:

[fonts]   # [family, size, weight, variant, style, color]
main      = ["Cormorant Garamond", "13pt", 400, "", "", false]

For comparison and discussion, in the resilient "styling paradigm" an equivalent style could be:

main:
  style:
    font:
      family: "Cormorant Garamond"
      size: "13pt"
      weight: 400

Well I don't use a "main" style currently, for historical reasons, but syntactically this is it -- with support too for style, color, features, and other things such as position (e.g. "super", useful for footnote styling) and case (e.g. "upper", useful in headings), etc.

[jodros]

Well I don't use a "main" style currently, for historical reasons

Now I'm curious to know about these historical reasons.

[Omikhleia]

Now I'm curious to know about these historical reasons.

#1543 notably comes to mind.

[Omikhleia]

Switch tongue-in-cheek on, with a grain of salt.

So as mentioned many months ago already, re·sil·ient has a style system of the kind mentioned here, which went through the fire for now 3+ years, with 3 published books to its credit at this point, all available online for free, to check their achievements.
Everything (ideally) can be styled in a consistent way. It's well documented, with a nice PDF guide. It's not (yet) perfect in all areas, but it works.

Question 1 is: Why would you want a different system in the core distribution? (I.e. what is this discussion here supposed to be?)
Question 2 is: What do you expect to achieve that re·sil·ient is not doing yet, without re-inventing the wheel and face the same challenges of a 3+ year experiment again? (I.e. which conclusion do you expect to differ with? How should they be addressed differently, then?)

If this discussion was a "question", I'd say it was answered.
If this discussion is an "idea", I'd day it has already been addressed, with provable results and in deeper ways than the initial proposal here.
Maybe this discussion should be closed? Or is there really some unaddressed point?

Switch tongue-in-cheek off, it's all about salt and pepper.

[Omikhleia]

Erm. Since the initial question here, by the way, re·sil·ient was leveraged with new styling features, notably "decorations". Skipping the details, let's head for a cool demo indeed:

(Question 3 with more tongue-in-cheek: How high is the sky we can reach?)

[Omikhleia]

this would reduce the amount of commands to write in the .sil files,

Question 4 with even more and more tongue-in-cheek: SIL files, really? (This obscure custom markup language?)

[Omikhleia]

Question 5 (now can we get real?): What is the most obvious way to complete this project without heavy monkey-patching, and a clear view of all the challenges at stake? 🤣

EDIT: Out of the 8 open "todo" items in that project at this time, resilient has 7 of them solved long ago.

[jodros]

Out of the 8 open "todo" items in that project at this time, resilient has 7 of them solved long ago.

Great, but why didn't you just solve them here in the core distribution, since you have a solution?

[Omikhleia]

Great, but why didn't you just solve them here in the core distribution, since you have a solution?

Heh, for some parts, I actually did push parts of my results upstream to the core, whenever possible in a clean way. E.g. Most of the hacks ideas from silex.sile have progressively been proposed upstream when they reached enough maturity, at some point. Some parts (e.g. languages (BCP47 etc.) still need a better solution than what I have "as a workaround", and language is my focus for 2025 - hence the little related things I started pushing upstream too (such as #2102), as it is the way towards a cleaner approach eventually, fixing things first... But some parts still await sile·nt (cool pun name for a New Typesetter, isn't it?)... When I get back to it at some points, with a clearer understanding... (Some preliminary results, e.g. multi-column attempts, were shown on our Gitter, but they never really worked well enough for the general case...). An example of the issues: the re·sil·ient styling paradigm has a feature for collapsing "consecutive skips" (cf. end of §2.4 in the current manual, and if you want to dig at the origin of it, see here). This works well... As long as we don't change too much the internals of the dummy pagebuilder we currently have (recomputing the whole page layout from top each time horizontal mode is left... So my sile·nt attempt, which also does a lot of the things differently, is better at some and worse at others, suddenly needs an additional API to commit or rollback indexes for a New Pagebuilder to tick in... And everything becomes much harder ;).

But anyway, do all things need to be "in the core distribution"? (or "Does a TeX-system has to encompass LaTeX/ConTeXt/etc. ?"). I can't say. But anyhow, re·sil·ient targets one thing: making a book from "front cover to backcover". The styling aspect is one "small" feature among others, and doesn't make much sense alone, and is in no way definitive in its current underlying implementation. E.g. in the whole picture, re·sil·ient also comes with EAN13 barcodes, 'cause a true book needs them anyway. The barcode package (a mere assembly of rules!) was rejected for inclusion in the core distribution (#1503), on certain assumptions to what belongs to the "core" and what does not. So as then suggested, I moved to 3rd-party packages. I don't say the decision was bad or good. I can't say, either. But then it's a whole bigger lot of things that gets dragged off eventually... (for styling, re·sil·ient reimplements the ToC, the lists -- which, you'll note, I however proposed in a trimmed-down version upstream --, the header logic, the footnotes, the sectioning commands... And so on... And eventually the "indexer" too. It's not an obvious decision for anyone...)

I don't know the path, except that I want to make and distribute books, so I'm enriching my collection towards that only goal ;-)

TL;DR. I don't have the solution. But I might have one among the possibilities.

[jodros]

Why would you want a different system in the core distribution?

I've just suggested that SILE should have a built-in way to handle configuration files, it doesn't need to be this or that one.

What do you expect to achieve that re·sil·ient is not doing yet

Absolutely nothing, I just realized that your module is way better than whatever I was about to create and I'm switching to it BTW.