Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multipage command to split an SVG into smaller, slightly overlapping SVGs #149

Open
LoicGoulefert opened this issue Jan 3, 2021 · 3 comments

Comments

@LoicGoulefert
Copy link
Contributor

Usage

vpype read input.svg multipage -i a3 -o a4

Command options:

  • -i, --input-format: a1, ..., a6, as well as vpype supported units
  • -o, --output-format: same as -i, must be compatible with -i
  • -s, --seam-width: control the "seam zone" size between output files

Description

multipage splits a file into smaller, slightly overlapping files. Say input file format is a3, outputs formats would be 2 slightly smaller than a4 files (if -o a4 is used), or 4 slightly smaller than a5 files (if -o a5 is used), and so on.
multipage should always consider input files as portrait oriented.
As the output files are intended to be drawn on the same piece of paper, multipage rotates by 180° the output files making up the bottom half of the input file.
To avoid having a visible seam between the output files, multipage creates a "seam-zone", and randomizes the crop on the lines within this zone. Lines fully contained in the "seam-zone" should not be cropped.

@abey79
Copy link
Owner

abey79 commented Jan 3, 2021

Some late night feedback in no particular order:

  • --input-format should be dropped and the current page size (defaulting to the current bounds) should be used

  • generally: size should be used instead of format for page sizes for consistency (I recently changed that because both where inconsistently used before)

  • I like the approach of: "given output page size and the current page size/bounds, automatically compute in how many parts it must be split" 👍🏻

  • Some kind of --margin should be added, to specify how close to the border the output can go.

  • Layer management might be a tough one. The command should probably be a global_processor similar to e.g. trim (so with a --layer parameter accepting one or multiple layer ids or all, i.e vp.LayerType(accept_multiple=True)). So we have to deal with splitting N input layers in M pieces (depending on output page size). If each of the M pieces for each of the N input layers are put in separate layers, that's N*M layers at the end. Are we happy about this? I think so, because of the following:

    • Multiple layers are typically used for multiple colours, so the user likely wants that to be preserved for each output pages.
    • If not, then the user can use lmove to merge input layers to minimise the number of output layers.
  • An alternative way of doing this would be to build the multi-page support into write instead of in a dedicated multipage command. Or to make a new multiwrite command that mimics write but will generate multiple files if needed. That would certainly require refactoring the writing backend, to factor out the actual output generation from the layout, possibly in the spirit of Create Read/Write API. #116

  • (At this stage, I'm getting a little scared of this feature to be honest 😄)

  • multipage should always consider input files as portrait oriented.

    Why is that? It could take whatever current page size/bounds aspect ratio and decide on the best output aspect ratio, depending on the splitting.

@LoicGoulefert
Copy link
Contributor Author

Agreed with all of your remarks.

  • multipage should always consider input files as portrait oriented.

Why is that? It could take whatever current page size/bounds aspect ratio and decide on the best output aspect ratio, depending on the splitting.

I was thinking that most plotters draw on a landscape oriented page, so having an a3 file should result in 2 a4, landscape oriented files, instead of two 42 x 14.85cm files, but that was poorly worded !

  • (At this stage, I'm getting a little scared of this feature to be honest 😄)

Same here, especially if this involves touching the write command as you mentionned.

@LoicGoulefert
Copy link
Contributor Author

Specification evolution

Examples

vpype read a3_file.svg   # a3 file with 1 layers
    multipage -o a4         # we now have 2x1 layers, and page format is a4
    write --page 1 --page 2 output.svg

yields 2 a4 format files output_1.svg, output_2.svg. Each output file has 1 layer, labelled "1".

vpype read a2_file.svg   # a2 file with 3 layers
    multipage -o a4         # we now have 3x4 layers, and page format is a4
    write --page 1..3 --page 4..6 --page 7..9 --page 10..12 output.svg

yields 4 a4 format files output_1.svg, output_2.svg, output_3.svg and output_4.svg. Each output file has 3 layers, labelled "1", "2", and "3", which are consistent with the original a2_file.svg layers.

New features involved

  • multipage command
  • layer range argument, i.e. 1..3
  • --page option for the write command

multipage options:

  • -o, --output-size: output size
  • --overlap: control the overlap size between output files. If not specified, defaults to 0, and will result in a clean cut between output files. Otherwise, will result in an interlaced cut. (was previously --seam-zone)

Layer range argument: support the a..b range syntax. 1..3 would select layers 1, 2 and 3.

--page option for write: write a file with the selected layers at the current file size. If this command is used multiple times, an appendix is added to the output file argument.
[...] write --page 1..3 output.svg creates a single file output.svg.
[...] write --page 1..3 --page 4..6 output.svg creates 2 files, output_1.svg and output_2.svg.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants