Recommended Workflow
Directory Tree
The ideal workflow is to put Composer in a top-level .Composer
for each directory tree you want to manage, creating a structure similar to this:
.../.Composer
.../
.../tld/
.../tld/sub/
To save on disk space, using a central Composer install for multiple directory trees, the init target can be used to create a linked .Composer
directory:
make -f .../Makefile init
The directory tree can then be converted to a Composer documentation archive (Quick Start example):
make -f .Composer/Makefile install-all
make all-all
Customization
If specific settings need to be used, either globally or per-directory, .composer.mk
and .composer.yml
files can be created (see Configuration Settings, Quick Start example):
make template >.composer.mk && $EDITOR .composer.mk
make template.yml >.composer.yml && $EDITOR .composer.yml
Custom targets can also be defined, using standard GNU Make syntax (see Custom Targets).
Important Notes
GNU Make does not support file and directory names with spaces in them, and neither does Composer. Documentation archives which have such files or directories will produce unexpected results.
It is fully supported for input files to be symbolic links to files that reside outside the documentation archive:
cd .../tld
ln -rs .../README.md ./
make README.html
Similarly to source code, GNU Make is meant to only run one instance within the directory at a time, and Composer shares this requirement. It should be run as a single user, to avoid duplication and conflicts. Concurrent runs will produce unexpected results. It is highly recommended to set MAKEJOBS to a value greater than the default, to speed up processing.
It is best practice to install-force after every Composer upgrade, in case there are any changes to the Makefile
template (see Templates). Everything in Composer sources from the main Makefile
, so that is the only file which requires review to see what changes have been made between versions.
Next Steps
The archive is ready, and each directory is both a part of the collective and its own individual instance. Targets can be run per-file, per-directory, or recursively through an entire directory tree. The most commonly used targets are in Primary Targets.
Welcome to Composer. Happy Making!
Document Formatting
#WORKING:DOCS###################################################################
.../artifacts/pandoc/template.*
.../artifacts/pandoc/reference.*
.../artifacts/composer/composer-site.css
.../artifacts/composer/composer-html.css
As outlined in Overview and Principles, a primary goal of Composer is to produce beautiful and professional output. Pandoc does reasonably well at this, and yet its primary focus is document conversion, not document formatting. Composer fills this gap by specifically tuning a select list of the most commonly used document formats.
The input Markdown format used by Composer is the Pandoc default. However, the Pandoc Extensions list has been modified slightly. See that section and the Pandoc Markdown documentation for the exact list and details for each.
Further options for each document type are in Formatting Variables. All improvements not exposed as variables will apply to all documents created with a given instance of Composer.
Note that all the files referenced below are embedded in the ‘Embedded Files’ section of the Makefile
. They are exported by the +release target (using +setup), and will be overwritten whenever it is run.
Static Websites
Bootstrap is a leading web development framework, capable of building static webpages that behave dynamically. Static sites are very easy and inexpensive to host, and are extremely responsive compared to truly dynamic webpages.
Composer uses this framework to transform an archive of simple text files into a modern website, with the appearance and behavior of dynamically indexed pages.
#WORKING:DOCS###################################################################
.../artifacts/bootstrap/bootstrap.js
.../artifacts/bootstrap/bootstrap.css
.../artifacts/composer/composer.site.css
.../artifacts/composer/composer.site.overlay.light.css
.../artifacts/composer/composer.site.overlay.dark.css
.../artifacts/images/logo.img
.../artifacts/images/icon.img
Bootlint Bootswatch
.../bootswatch/docs/index.html
– Examples: Example Website / README.site.html
PDF
The default formatting for PDF is geared towards academic papers and the typesetting of printed books, instead of documents that are intended to be purely digital.
Internally, Pandoc first converts to LaTeX, and then uses TeX Live to convert into the final PDF. Composer inserts customized LaTeX to modify the final output:
.../artifacts/composer/composer-pdf.header
#WORK # …/artifacts/composer/composer.pdf.latex
– Example: README.pdf
Reveal.js Presentations
The CSS for Reveal.js presentations has been modified to create a more traditional and readable end result. The customized version is at:
.../artifacts/composer/composer-revealjs.css
#WORK # …/artifacts/composer/composer.revealjs.css
#WORK # rework this
It links in a default theme from the .../reveal.js/dist/theme
directory. Edit the location in the file, or use c_css to select a different theme.
It is set up so that a logo can be placed in the upper right hand corner on each slide, for presentations that need to be branded. Simply copy an image file to the logo location:
.../artifacts/images/logo.img
To have different logos for different directories (using Recommended Workflow, Configuration Settings and Precedence Rules):
#WORK # no longer the best way to do this… cd …/presentations cp …/logo.img ./ ln -rs …/.Composer/artifacts/composer/composer.revealjs.css ./.composer-revealjs.css echo ‘override c_type := revealjs’ >>./.composer.mk make all
– Example: README.revealjs.html
Microsoft Word & PowerPoint
The internal Pandoc templates for these are exported by Composer, so they are available for customization:
.../artifacts/pandoc/reference.docx
.../artifacts/pandoc/reference.pptx
They are not currently modified by Composer.
– Example: README.docx
Plain Text
This output format is still parsable by Pandoc as valid Markdown, but is formatted to read as pure plain text that is only 80
columns wide. There are cases where this conversion is desirable, such as technical documentation, where it is easier to write and format as Pandoc Markdown but the output needs to be in a universally accepted text layout and presentation.
Composer currently does not modify this format, other than using the --columns=80
and --wrap=auto
options to Pandoc.
Pandoc Markdown
Output Markdown that is specific to Pandoc. This is for linting or creating standardized versions of source files for shared archives.
Due to the expressed purposes of this format, Composer will never modify it.
Configuration Settings
#WORKING:DOCS###################################################################
Pandoc & Bootstrap (.composer.yml)
Composer uses .composer.mk
files for persistent settings and definition of Custom Targets. By default, they are chained together across their Makefile
tree (see COMPOSER_INCLUDE in Control Variables). A .composer.mk
in the main Composer directory will be global to all directories. The targets and settings in the most local file override all others (see Precedence Rules).
The easiest way to create new .composer.mk
and .composer.yml
files is with the template and template.yml targets (Quick Start example):
make template >.composer.mk && $EDITOR .composer.mk
make template.yml >.composer.yml && $EDITOR .composer.yml
All variable definitions must be in the override [variable] := [value]
format from the template target. Doing otherwise will result in unexpected behavior, and is not supported. The regular expression that is used to detect them:
override[[:space:]]+([^[:space:]]+)[[:space:]]+[:][=]
Variables can also be specified per-target, using GNU Make syntax:
README.%: override c_toc := 0
README.revealjs.html: override c_toc :=
In this case, there are multiple definitions that could apply to README.revealjs.html
, due to the %
wildcard. Since the most specific target match is used, the final value for c_toc would be empty.
Example configuration files:
.../.composer.mk
.../artifacts/.composer.yml
#WORK …/artifacts/README.site.yml …/README.site.html.yml
Precedence Rules
All processing in Composer is done in global-to-local order, so that the most local file or value always takes precedence.
Configuration Files
Both .composer.mk
and .composer.yml
files follow the model illustrated in COMPOSER_INCLUDE under Control Variables. This means that the values in the most local file override all others.
#WORKING:DOCS###################################################################
All values in .composer.mk
take precedence over everything else, including environment variables.
Variables & Aliases
Variable aliases, such as COMPOSER_DEBUGIT
/c_debug
/V
are prioritized in the order shown, with COMPOSER_*
taking precedence over c_*
, over the short alias.
Full COMPOSER_*
variable names should always be used in .composer.mk
files, to avoid being overwritten by recursive environment persistence.
Pandoc Options
#WORK # does not seem to be documented anywhere… test it, with examples here, regardless… # seems to be: yaml_metadata, –defaults, –metadata*, etc.
Specifying Dependencies
If there are files or directories that have dependencies on other files or directories being processed first, this can be done simply using GNU Make syntax in .composer.mk
:
LICENSE.html: README.html
subdirs-all-artifacts: subdirs-all-pandoc
This would require README.html
to be completed before LICENSE.html
, and for pandoc
to be processed before artifacts
. Directories need to be specified with the subdirs-all-*
syntax in order to avoid conflicts with target names (see Custom Targets).
Chaining of dependencies can be as complex and layered as GNU Make will support. Note that if a file or directory is set to depend on a target, that target will be run whenever the file or directory is called.
Custom Targets
If needed, custom targets can be defined inside a .composer.mk
file (see Configuration Settings), using standard GNU Make syntax. Naming them as *-export, *-clean or *-all will include them in runs of the respective targets. Targets with any other names will need to be run manually, or included in COMPOSER_TARGETS.
#WORK # …or, via Specifying Dependencies
There are a few limitations when naming custom targets. Targets starting with the regular expression [.+]
are hidden, and are skipped by auto-detection. Additionally, there is a list of reserved targets in Reserved, along with a list of reserved variables.
Any included .composer.mk
files are sourced early in the main Composer Makefile
, so matching targets and most variables will be overridden. In the case of conflicting targets, GNU Make will produce warning messages. Variables will have their values changed silently. Changing the values of internal Composer variables is not recommended or supported.
A final note is that *-export, *-clean and *-all targets are stripped from COMPOSER_TARGETS. In cases where this results in an empty COMPOSER_TARGETS, there will be a message and no actions will be taken.
Repository Versions
There are a few internal variables used by +update to select the repository and binary versions of integrated components (see Requirements). These are exposed for configuration, but only within .composer.mk
:
PANDOC_VER
(must be a binary version number)
PANDOC_CMT
(defaults to PANDOC_VER
)
YQ_VER
(must be a binary version number)
YQ_CMT
(defaults to YQ_VER
)
BOOTSTRAP_CMT
BOOTLINT_CMT
BOOTSWATCH_CMT
FONTAWES_CMT
WATERCSS_CMT
MDVIEWER_CMT
MDTHEMES_CMT
REVEALJS_CMT
FIREBASE_VER
(must be a binary version number)
FIREBASE_CMT
(defaults to FIREBASE_VER
)
Binaries for Pandoc, YQ and Google Firebase are installed in their respective directories. By moving or removing them, or changing the version numbers and foregoing all relevant variations of +update, the system versions will be used instead. This will work as long as the commit versions match, so that supporting files are in alignment, particularly for Pandoc.
It is possible that changing the versions will introduce incompatibilities with Composer, which are usually impacts to the prettification of output files (see Document Formatting). There may also be upstream changes to the command-line options for these tools.