sile-typesetter / casile Goto Github PK

My generated .sil file has:

\Header[id=potential-solutions,level=1,type=section]{Potential solutions}

\Header[id=business-as-mission,level=2,type=subsection]{Business as Mission}

The output:

Using renderings would be a lot easier if they optionally had transparent backgrounds.

This could be done in POVRay except that we would loose the shadows on the "surface". Perhaps that's a useful output too, but another way might be to borrow from the film world and green screen the renderings using a known surface color that can be used to cut out the finished product without loosing alpha values on shadows.

Some layouts such as business cards don't have bindings and shouldn't render as softback books. A layout type for "stacks" should be added for non-bound multi-page outputs.

Coil, comb or spiral bindings have larger margin requirements and deserve their own renderings. These can probably be lumped together with options for different tweaks but only one of the above per target.

CaSILE used on the system doesn't need initializing, but used as a submodule we need to trigger the automake system.

Re-purpose the make init rule in rules to check that CaSILE is in a usable condition, and build if necessary (bootstrap, configure, make).

This kind of init can probably default to production mode to avoid all the node module dependencies that are development related.

Amazon's maximum cover image size is less than ePub recommendations (such as for Play Books) so we're going to have to split these up into different images, possibly even at different aspect ratios.

See image:

Some builds (such as app, ekran, business card stacks, all the coil bindings, etc.) can actually have a back cover added as the last page in a PDF. This will require the cover PDF to be a two page gig.

Current makefile load order:

1. casile.mk
2. Project rules file(s)
3. rules.mk

Now, where do we load localized make variables? Currently in №3, because languages are set by project (or CLI run) most reasonable in №2. That leaves them unusable in №2. Which mean projects can't avail themselves of localized strings.

Obviously the current makefile hackery to even have localized strings is, well, dirty. We should come up with something cleaner, preferably moving localization to Fluent and loading strings earlier to be used earlier too.

Here's an MWE:

\begin[papersize=a5,class=book]{document}
\script[src=casile/casile]
Here is an unquoted paragraph. Lorem ipsum dolor sit amet, consectetur
adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore
magna aliqua.

\begin{quote}
Here is a quoted paragraph. Lorem ipsum dolor sit amet, consectetur
adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore
magna aliqua.
\end{quote}

\end{document}

My own project have in the past conflated "edition" with "printing". Having run into a project for which the difference mattered I realize the meta data for this as well as the way it is presented is important enough come up with a standard for it.

See also #23.

Figure out a way to splice in related ISBNs (such as of original language versions, alternate printings, etc.) into the meta data. This can be used in the play books related ISBN field, for building website listings, and so forth.

Many layouts are useful for their generic purpose but won't be exactly the size used for a given print (e.g. the business card layout). Some mechanism needs to allow a specific project (or even target) override the layout dimensions. Similar to how crop & bleed can be changed for example.

The CI runners are great as long as they happen to be running on one of my own Arch Linux based systems with all the dependencies installed. Unfortunately this isn't very portable or new adopter friendly. Somehow I need to get CaSILE working under other CI runners. Candidates include:

• Travis CI (Ubuntu based images)
• Gitlab CI (Docker? Kubernets?)
• ...?

Detect containers (e.g. Docker) at build time and scan different paths for setup using perhaps autocfg.

Munging PDFs around with cpdf, pdfjam, pdftk, etc. is producing final outputs that don't have all the book related meta data we started with.

Many projects make not need a project specific Makefile at all. Given the option to invoke CaSILE as a CLI tool instead of as a submodule or other fixed path relative to the project, it seem like some options will be better set a different way.

I'm thinking specifically of the language, layout, and output location options. We already have a project wide meta data YAML option, extending that to cover some basic settings seems to make sense to me.

This will require the rules file parsing the YAML (we already depend on yq so that should be easy), and also probably a Rust crate so the CLI can do it directly. Alternatively the Rust CLI can just read it and output the relevant values in Makefile format to be sourced before the CaSILE rules file.

The page layouts should remove the existing frameset first rather than just adding new ones.

The Docker build should use Fluent to get a list of locales supported in CaSILE, then regenerate the containerized system's locale library using that list so other shell tools (may) be localized to match.

If you forget to add a language at all or add an invalid one is is either confusingly ignored (default language used, should warn) or the next argument is treated as the language. A validator that checks that it is BCP47 parsable would be nice.

Add explicit signature (printing press layout / sheet folding) handling for books on a per-format basis. 4/8/16/32 sheet, blank page content, warnings about optimizing for a specific signature, etc.

One thing I keep running into when doing booklets is that using a 32 page signature works out great for booklets that are about 30 pages anyway, but running over to 33 pages is just not an option. Either optional content to drop if an overrun is detected, a build time warning or error, or a formatting value to tweak and try again would be nice.

POV is absurdly slow compared to what shader folks are doing these days. And who says books can't be modeled page by page in a shader?

https://twitter.com/lorenschmidt/status/1397271574315683841
https://twitter.com/lorenschmidt/status/1397383182966734858

I think that CaSILE can probably be adapted as a way to typeset mdBook format sources and/or use mdBook as an output format for online book publications from sources already setup for publishing via CaSILE. This merits further research.

While working on Fontship I realized the song and dance that CaSILE does building everything locally then making hard links in a pub directory for things people probably want to keep is a bit of a mess. Also it is problematic on some file systems.

The solution I came up with there that I liked and should probably implement here too was to hide all the intermediate artifacts in a build directory and only place final products (what currently goes in PUBDIR) into the project directory. This makes the project workspace a lot less messy, allows build artifacts to be stored on a RAM disk if desired, and doesn't require any special permissions.

We need a target that can be extended per project for testing that basic properties came out right before syncing the results. An example might be imposing a check that a stapled booklet came out to exactly the planned page count:

check:  myproject_check

.PHONY: myproject_check
myproject_check: books
    test $(call pagecount,bookname-a6-stapled.pdf) -eq 32

The crop/resize process for 3D renderings has started returning sizes with regular widths (e.g. 4000px) but irregular heights (e.g. 5995px). These should be maintained as 4×6 aspect pictures somehow.

See previously #55.

Some projects may have extra dependencies. Right now we offer a hook where they can check for them and utility functions to look for example fonts, but no really way to satisfy them. For the sake of CI builds there should be some normalized way of specifying packages that need to be installed into the Docker container before runs. This is in addition to checking for them for the sake of local runs.

Following on the success of (Docker images for SILE](sile-typesetter/sile#520) I would like to setup images for CaSILE.

This is a bit more complex, first because there are a ton more dependencies involved and secondly because I/O is a bit more complicated and CaSILE as currently designed expects to be a submodule on a source repo. We're going to need a new architecture to pull this off.

I'm currently thinking of a couple of layers to keep the size down for folks that don't need all the options:

1. "one pair of socks" edition: Markdown→PDF
2. "swiss army" edition: +cover & bindings, +Epub/mobi, Docx & friends
3. "kit and caboodle" edition: +3D rendered promotional stuff

Note this will go a long way towards resolving #24.

At the very least bound books have page count increments of 2. Staple or other folded bindings need increments of 4. The bound formats should know this and pad as appropriate.

Currently the env $LANG variable, if set, is used to parse our locale from. In the event it is not set or set to something like "c", make sure we fall back to our default gracefully.

Book series with lots of targets in one project are taking a long time to build. For the most part this could be split up with one runner per target. This way they could be run in parallel on several build machines.

Series targets (series_promotionals, series_renderings, and their ilke) would need to run after artifacts from all segments are collected.

See docs: https://docs.github.com/en/actions/reference/workflow-commands-for-github-actions#stopping-and-starting-workflow-commands

We already detect runs in GHA‌ anyway, instead of the usual CLI output we can bracket the output of each target with special commands to get pretty output that can be expanded for details.

I added a business card page layout but it was for a specific project that had odd cut sheet requirements and it turned out not to be a standard business card size. This should get replaced with a proper card size ad any project specific requirements moved to that project.

Setup an alias or some other block in interactive shells spawned through the CLI to keep CaSILE from being run recursively inside itself (which might serve a purpose later but at this point is just a mistake).

Lines in a recipe may have make specific prefixes that are not part of the shell script syntax (@ for no-echo, - for no error, etc.) These need to be striped before running eval on them and possibly replaced with some other handling.

With SILE itself being built with automake the check_dependencies target as a part of the runtime rules file doesn't make much sense any more. All those checks (or most of them) should move to configure.ac.

Notable make normalize_markdown and make normalize_references can't be used against only one target in a project. This should be fixed as it's possible to break things and sometimes working on a branch it's really nice to only touch one target's related files.

By default just reversing the bleed value should work, but the cover renderings could include a safe zone box when in DRAFT mode as part of the design check process.

Meta data for each book is merged from a series of sources or layers:

1. CaSILE defaults
2. Publisher toolkit
3. Project wide meta data
4. Target specific meta data

These sources are currently merged (hopefully in that order) and the combined output is used when building each target. Unfortunately the merge happening right now is kind of brutal and only considers top level keys in the meta data. It is not a deep merge / meld. This makes it hard to override specific values without potentially duplicating chunks much larger than the bit you want to actually override.

Preferably some sort of tree merge would happen where values could be overwritten or even erased, but also spliced into. Most notably list elements should probably be extended rather than replaced by default, although a way to clear values is also needed. This will probably require an overhaul of the data types we already use and something to walk the tree and handle each element type differently.

So that when browsing ePub books you can see the page number in the print edition.

See also: https://twitter.com/daniel_hede/status/1230843597429276673

Right now the paper size, frame layout, and style sheet are kind of tied at the hip. It would be more flexible if these were split so they could be mixed and matched.

Hard cover bindings

• Need different binding geometries
• Include flyleaf sheets
• Should render differently

Per [this issue](https://github.com/sile-typesetter/sile/issues/666] SILE has it's own org namespace on Github now. It might make sense to migrate this there as well. It is not a dependency for SILE, nor does it even require SILE to use (only the PDF output option depends on SILE). But it was conceived as a framework for using SILE in a larger publishing workflow. Arguably Pandoc is actually more central to gluing everything together, I can't imagine extricating SILE either.

Thoughts @simoncozens?

Staple bindings are a little bit different than glue ones and should have metrics and crop marks specific to the task. Also they should render a little differently.

Not all books have the binding on the left.

Trying to control the rendered size of images in a text, I used the "link attributes" syntax:

![Hand composition, by Wilhei on Wikipedia](concepts/512px-Handsatz.jpg){ width=120pt }

In LaTeX this renders to \includegraphics[width=120pt]{concepts/512px-Handsatz.jpg}, but the SILE writer only passes on:

\img[src=concepts/512px-Handsatz.jpg]

(Dropping the width and the caption.) The caption would be nice, but width/height attributes are essential.

Some of the {markdown,reference}_normalization rules are to be expected in normal usage, others are really errors that should not be made in the input. It would be helpful to have some sort of linting process that would highlight the mistakes that shouldn't be made any more, or perhaps a CI phase that corrects them but notifies the offender (using git blame) of their mistake.

See also #90.

Some projects have books in more than one language. It should be possible to generate artifacts with proper language artifacts per-target.

The make normalize_references target finds *.md files which are not part of the project and operates on them. It only works after a make clean or similar, and even then with an error because of the files that get made during the build process. The list should be filtered against git ls-files.

The make split_chapters target bombs when content is found before the first chapter ... or maybe all the time. The $of variable is set to blank until processing the first chapter which results in the shell not being able to start the redirect.