The options file is JSON, not JavaScript, and JSON does not allow
comments. An options file with comments as shown in the current
example in README.md will fail to load.
This commit removes the comments. They do not seem important enough to
place them elsewhere.
Try to register all javascript files found in themes as handlebars
helpers.
Note that, unlike all other theme files currently, format directories
are ignored. I don't think there's a use case for format-specific
helpers, and this gives theme developers the flexibility to put them
either in top level files or organize them in subdirectories however
they see fit.
Note also that the theme format seems to be primarily documented in
<https://github.com/fresh-standard/fresh-themes>. This newly recognized
theme file type should be documented there should this branch be merged.
It seems that some time in the last couple years wkhtmltopdf's default
margins were changed from '10mm' to zero. As an alternative to #177,
this PR adds an option to pass in arbitrary wkhtmltopdf long arguments
and sets the default top and bottom margin to '10mm'.
Rebind Handlebars helpers to drop the pesky options hash for standalone
helpers that don't need it. Move block helpers (which do need the
Handlebars options/context) to a separate file for special handling.
Most themes should generate in < 1s but allow up to 30 seconds for
network latency when opening a remote file, or for fetching remote
resources (CSS, JS, etc) during a local build.
Fix output file name glitch, writing CSS files to destination folder,
and an issue where the process would evaporate before PDF/PNG generation
could complete.
Relax jsHint's barbaric and antiquated default behavior on triple-equals
null comparisons. Allow expressive, precise, and subtle expressions such
as CoffeeScript's use of "== null" for testing against null OR undefined
under the existential operator.
Add support for detection of invalid line breaks in JSON string values.
Fixes#137. Could be improved to fetch the column number and drop the
messy grabbing of the line number from the exception message via regex,
but currently the "jsonlint" library (not to be confused with
"json-lint") only emits an error string. Since this is also the library
that drives http://jsonlint.com, we'll accept the messy regex in return
for more robust error checking when our default json-lint path fails.
All of the above only necessary because standard JSON.parse error
handling is broken in all environments. : )
