I believe there are scenarios (but I'd like to collect them to be sure) where we'd like to overlay multiple SVG Tiler drawings on top of each other. For example, suppose we want multiple annotations on top of the same drawing. Or we want to work on two different grid layouts for two different parts of the drawing, e.g. separately handling corners, edges, and cells of a grid.
- We could introduce a new bracket syntax that renders multiple drawings into the same output, e.g.,
[ drawing1.asc drawing2.asc ]. Default output could be drawing1_drawing2.svg (?). Or pair with -O to specify the output filename, as in -O drawing12 [ drawing1.asc drawing2.asc ], or use > notation below.
- We could add a
+ argument for combining different parts together: ( mapping1.coffee drawing1.coffee ) + ( mapping2.coffee drawing2.coffee ). Again this could be prefixed by regular -O, or postfixed with >, to define the output filename.
- We could introduce a new argument like
-O that means "combine all the drawings until the next )". Something like --combine-into drawing12 drawing1.asc drawing2.asc (or just --combine?).
- We could add some postfix syntax like
drawing1.asc drawing2.asc >drawing12 (now which binds to everything backward to the previous (). This makes for more difficult command-line parsing, but might be nice.
- We could define a way for a single mapping file to process multiple drawing files, presumably with different mappings.
- One approach is for the mapping file to
import drawings and work with them directly (maybe expose the "loop over all tiles" rendering function so it can be called multiple times?).
- Another approach is for the mapping file to specifically request being given all the subdrawings of a multi-drawing file (currently xls or other spreadsheet formats). Not quite sure what this would look like, but we do have
subname for adapting to multiple sheets...
Internally, a Render object will probably need multiple jobs, each with mappings and drawing, and the mappings and drawing properties can still describe the current job (but can access the other jobs too).
An older idea was to extend Maketiles (#84) to an indentation-based language for specifying more complex jobs. For example, each output file could have relevant information below it like so:
output.svg:
general-mapping.coffee
layout.coffee
--tw 50 --th 50
( mapping1.coffee drawing1.txt )
( mapping2.coffee drawing2.txt )
I no longer like this style, though, because it's tedious to specify lots of different jobs that share parameters. Parentheses allow this in a more natural way I think.
I believe there are scenarios (but I'd like to collect them to be sure) where we'd like to overlay multiple SVG Tiler drawings on top of each other. For example, suppose we want multiple annotations on top of the same drawing. Or we want to work on two different grid layouts for two different parts of the drawing, e.g. separately handling corners, edges, and cells of a grid.
[ drawing1.asc drawing2.asc ]. Default output could bedrawing1_drawing2.svg(?). Or pair with-Oto specify the output filename, as in-O drawing12 [ drawing1.asc drawing2.asc ], or use>notation below.+argument for combining different parts together:( mapping1.coffee drawing1.coffee ) + ( mapping2.coffee drawing2.coffee ). Again this could be prefixed by regular-O, or postfixed with>, to define the output filename.-Othat means "combine all the drawings until the next)". Something like--combine-into drawing12 drawing1.asc drawing2.asc(or just--combine?).drawing1.asc drawing2.asc >drawing12(now which binds to everything backward to the previous(). This makes for more difficult command-line parsing, but might be nice.importdrawings and work with them directly (maybe expose the "loop over all tiles" rendering function so it can be called multiple times?).subnamefor adapting to multiple sheets...filename.xlsx#sheetName.Internally, a
Renderobject will probably need multiplejobs, each withmappingsanddrawing, and themappingsanddrawingproperties can still describe the current job (but can access the otherjobstoo).An older idea was to extend Maketiles (#84) to an indentation-based language for specifying more complex jobs. For example, each output file could have relevant information below it like so:
I no longer like this style, though, because it's tedious to specify lots of different jobs that share parameters. Parentheses allow this in a more natural way I think.