mjsull/chromatiblock

Colinear block visualisation tool

chromatiblock's Issues

Parallelization

Not an issue, but can chromatiblock be parallelized (with the option to specify a number of threads)? :)

Allow alignments with no core blocks

Demo on H. pylori is down

Hello,

As said in the title, the demo for H. pylori linked in your ReadMe is down; it returns an error 404 when following the link on your ReadMe (supposedly redirecting toward https://mjsull.github.com/chromatiblock/H_pylori.html ).

Is there any other demo available somewhere?

Thank you!

Gene labels on core blocks

Hi,
I was wonder how to add gene annotations (the triangles) to core blocks? In your examples (and my own data), I can only get the annotations to appear on noncore blocks using the -gb and -gl flags.

Thanks!
Tony

Graphing error around single core block

Hi:

I'm looking at gene rearrangement in the neighbourhood flanking a single core block in related plasmid sequences - when the core block is oriented in the strand=+ direction, the sequence is correctly graphed in left flank -> core -> right flank order.

However, when the orientation of the core block is reversed (strand=-), the sequence is graphed as core -> left+right flank, with the non-core blocks from both flanks overlaid over each other on the right. Nothing is plotted to the left of the core block (refer to the last 2nd-4th row of the attached screenshot)

Chromatiblock was installed and executed on a fresh conda env (Python 3.8.6) as recommended by the Github.

Thanks!
Weizhen

Provide more helpful error messages

I have been trying to run your tool on some E. coli sequences and I ran into a few errors. (I am using Version: 0.3.0 installed with conda.)

The first is when I inserted a bunch of predicted plasmid contigs. They were quite different contigs and not everything could be aligned into a 'core genome'. However, the only message Chromatiblock provided was "IndexError: list index out of range" (see below). If you could provide a little message with a clue for the user what the actual problem could be and how to fix this, that would be much appreciated.

Traceback (most recent call last):
  File "/miniconda3/envs/chromatiblock/bin/Chromatiblock.py", line 1410, in <module>
    order_blocks_core(block_dict)
  File "/miniconda3/envs/chromatiblock/bin/Chromatiblock.py", line 668, in order_blocks_core
    if k.block == core_order[0][0]:
IndexError: list index out of range

The second error was with a set of whole genomes (scaffolds from a WGS experiment). Chromatiblock started collecting fasta sequences into the input.fasta file, but stopped halfway. It just stopped, without a warning. I found the message "fasta entry duplicated" in a log file, but when I checked the input files, there were no duplicate fasta header lines. Besides, Chromatiblock seems to just count the sequences (naming them 0_0, 0_1, 0_2, ... 0_n), so I don't see how a duplicate would be a problem in the end. Will it not just become one of those numbers to Chromatiblock? Anyway, in such a case it would be helpful to know what the duplicate is, and where to find it (what file it is in). (E.g. print 'fasta' and 'zename' in line 444 of Chromatiblock.py.) That would also help users prepare their files properly for Chromatiblock.

Genome name labels in the interactive plot

Hi, again not an issue but a recommendation for the interactive plot: Maybe the genome names could be listed on the left side of the MSA and colinear-blocks ? This way I don't always have to look up the order.

Mention runtime dep on remote svg-pan-zoom.min.js

<script src="http://ariutta.github.io/svg-pan-zoom/dist/svg-pan-zoom.min.js"></script>\n'

An error with file concatenation

Hello.
I ran the script like this:
chromatiblock -d ~/beastruns/chromatiblock/raw/ -w ~/beastruns/chromatiblock/tmp -o figure.svg
and it sad this to me:

error: parse error in /home/alexander/beastruns/chromatiblock/tmp/input.fasta on line 1: empty sequence
Traceback (most recent call last):
  File "/Software/chromatiblock", line 1479, in <module>
    block_dict = get_blocks(args.working_directory, name_dict, seq_dict, gene_list, cats)
  File "/Software/chromatiblock", line 562, in get_blocks
    with open(sibel_dir + '/blocks_coords.txt') as f:
FileNotFoundError: [Errno 2] No such file or directory: '/home/alexander/beastruns/chromatiblock/tmp/blocks_coords.txt'

The ~/beastruns/chromatiblock/raw/ directory contains 85 separate fasta sequences.
I've checked the input.fasta file and sure enough, it was empty. Then i tried to run it like this:
chromatiblock -f ~/beastruns/chromatiblock/raw/* --force --keep -w ~/beastruns/chromatiblock/tmp -o figure.svg
and it failed due to wrong file concatenation.

error: parse error in /home/alexander/beastruns/chromatiblock/tmp/input.fasta on line 2: illegal character: >
Traceback (most recent call last):
  File "/home/alexander/miniconda3/envs/chromatiblock/bin/chromatiblock", line 1479, in <module>
    block_dict = get_blocks(args.working_directory, name_dict, seq_dict, gene_list, cats)
  File "/home/alexander/miniconda3/envs/chromatiblock/bin/chromatiblock", line 562, in get_blocks
    with open(sibel_dir + '/blocks_coords.txt') as f:
FileNotFoundError: [Errno 2] No such file or directory: '/home/alexander/beastruns/chromatiblock/tmp/blocks_coords.txt'

The sequences were like:
>0_0
atatata>1_0
tatatata>2_0
etc.

I traced the error back to write_fasta_sibel function and changed line 423 to
out.write(line+'\n')
Now it works with -f ~/beastruns/chromatiblock/raw/*, but -d ~/beastruns/chromatiblock/raw/ still writes an empty file.

Also, it says
No core blocks found. No regions >1000bp were found once in all genomes. Please use more closely related genomes.
though i set minimum block size to 100, is it ok?

Error making final image

I ran chromatiblock on a simple dataset and it worked great, however when I added in more genomes, order, and gene annotations as per the advanced example, I get the following error:

./chromatiblock -w ./working -o image.pdf -gf trnastart.txt -l orderlist.txt -c categories.txt -d ./

Simplification stage 1 of 4

Enumerating vertices of the graph, then performing bulge removal...

[..................................................]

Simplification stage 2 of 4

Enumerating vertices of the graph, then performing bulge removal...

[..................................................]

Simplification stage 3 of 4

Enumerating vertices of the graph, then performing bulge removal...

[..................................................]

Simplification stage 4 of 4

Enumerating vertices of the graph, then performing bulge removal...

[..................................................]

Finding synteny blocks and generating the output...

Traceback (most recent call last):

File "./chromatiblock", line 1555, in

draw_blocks(core_array, noncore_pos, core_size, args.out, args.genome_height, args.gap, legend_size, args.working_directory, args.ppi, args.categorise != None, args.svg_pan_zoom_location, args.hue_start, args.hue_end)

File "./chromatiblock", line 1283, in draw_blocks

svg.drawOutRect(figure_width / 100 + 50 + gap, curr_y, figure_width / 200, genome_height, color, out_color)

TypeError: unsupported operand type(s) for +: 'float' and 'NoneType'

Here is a link to download the full input and working directory from the run that failed.
Thanks!

Add --version

% ./Chromatiblock.py --version
Chromatiblock 0.3.0

to stdout and return code 0

Consider renaming script to "chromatiblock"

Looks more professional?
And matches repo name
and run as chromatiblock rather than python Chromatiblock.py
you know, in case you rewrite it in Perl one day :-P

Problem with cariosvg

I've narrowed it down to a particular genome (B_erythrophleiGAS401.fna) from NCBI that is causing it to error. Here is a smaller dataset of two genomes that gives a similar error using the newest version of chromatiblock. The output I get is in the output file, also posted here:

./chromatiblock -w ./ -o image.pdf -d ./

output:

Simplification stage 1 of 4
Enumerating vertices of the graph, then performing bulge removal...
[..................................................]
Simplification stage 2 of 4
Enumerating vertices of the graph, then performing bulge removal...
[..................................................]
Simplification stage 3 of 4
Enumerating vertices of the graph, then performing bulge removal...
[..................................................]
Simplification stage 4 of 4
Enumerating vertices of the graph, then performing bulge removal...
[..................................................]
Finding synteny blocks and generating the output...
Traceback (most recent call last):
File "/local/cluster/lib/python3.7/xml/etree/ElementTree.py", line 1630, in feed
self.parser.Parse(data, 0)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 3, column 9

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "./chromatiblock", line 1555, in
draw_blocks(core_array, noncore_pos, core_size, args.out, args.genome_height, args.gap, legend_size, args.working_directory, args.ppi, args.categorise != None, args.svg_pan_zoom_location, args.hue_start, args.hue_end)
File "./chromatiblock", line 1351, in draw_blocks
cairosvg.svg2pdf(url=os.path.join(working_dir, "temp.svg"), write_to=out_file, dpi=ppi)
File "/local/cluster/lib/python3.7/site-packages/cairosvg/init.py", line 80, in svg2pdf
output_height=output_height)
File "/local/cluster/lib/python3.7/site-packages/cairosvg/surface.py", line 144, in convert
**kwargs)
File "/local/cluster/lib/python3.7/site-packages/cairosvg/parser.py", line 407, in init
forbid_external=not unsafe)
File "/local/cluster/lib/python3.7/site-packages/defusedxml/common.py", line 131, in fromstring
parser.feed(text)
File "/local/cluster/lib/python3.7/xml/etree/ElementTree.py", line 1632, in feed
self._raiseerror(v)
File "/local/cluster/lib/python3.7/xml/etree/ElementTree.py", line 1531, in _raiseerror
raise err
xml.etree.ElementTree.ParseError: not well-formed (invalid token): line 3, column 9

Thanks!

testdataset.tar.gz

Originally posted by @alexweisberg in #6 (comment)

Question regarding -gb

Hello!

I´ve been using Chromatiblock, and have managed to produce apparently correct visualizations. I´ve tried adding a protein list containing various aminoacid sequences for annotation using -gb, however, some of these (which I am sure exist in the genome, given that I am taking the protein annotations from those genomes for the visualization) are not showing. I would then like to know if there is a maximum number of proteins to be displayed, or a minimum distance between them that exist for them to be shown.

Thanks in advance!

JOSS Review

🔗 openjournals/joss-reviews#2451

I'll put in this issue my comments. So far I really enjoyed trying this tool that looks really useful.

Paper

• C. difficile is not italicized

Documentation and repository structure

The section "Demo" should be expanded (as it could be the very first attempt of using the software by a user) adding:

• A short description of the dataset
• A short description of the task to accomplish (e.g. use of custom categories colours)
• A link to the expected output
  (H. pylori output is linked in the paragraph above and can be easily missed)

A section describing the produced output:

• The -o switch can be described better, it's not immediately clear that can be used to select a different output format by changing the extension.
• A concise guide to interpreting the image produced
• An explanation of the intermediate files produced (or it could be an idea to delete the intermediate folder by default,
  unless --keep-intermediates or similar is specified. In this way it would not be so necessary to describe the files)

Minor issues:

• License file contains placeholders:
  <program> Copyright (C) <year> <name of author>
• An explicit "CONTRIBUTING.md" could be helpful,
  as it's common practice to have one
• Readability of README.md can be improved. Examples:
  • Version and License are rendered as subtitles,
    they can be written as simple text on a single line (or badges like )
  • Program flags are rendered as titles and they look very big on a browser.
    I assume they are automatically generated from the documentation
    so they can remain as they are if it's unpractical to change this.
  • Use of lists could improve readability (e.g. requirements, parameters,...)

Usability

Summary: the program works as expected and is simple to run.

Dependency check

The program if invoked with -h provides the expected documentation.
If invoked without parameters will print "No input files found use -f or -d", and I would add "Type --help for usage".

Downloading the repository and trying to run the program without installing the dependencies results in:

/bin/sh: Sibelia: command not found
Traceback (most recent call last):
  File "./chromatiblock", line 1548, in <module>
    block_dict = get_blocks(args.working_directory, name_dict, seq_dict, gene_list, cats)
  File "./chromatiblock", line 690, in get_blocks
    with open(sibel_dir + '/blocks_coords.txt') as f:
FileNotFoundError: [Errno 2] No such file or directory: 'simple_wd/blocks_coords.txt'

For beginner users, this might not be an easy to understand message, and I would suggest to consider adding a "dependency check".

Output

Here I found some issues:

1. The produced image should have the labels for each genome [edit: see #9].
2. Trying to produce an svg output failed for me (conda installation, command issued chromatiblock -d simple_demo -w simple_wd -o H_pylori.pdf -l simple_demo/order_list.txt, output here). I couldn't open the file with Inkscape.
3. Trying to produce a pdf output failed (conda installation):

Traceback (most recent call last):
  File "/Users/telatina/miniconda3/envs/chromatiblock/lib/python3.8/xml/etree/ElementTree.py", line 1693, in feed
    self.parser.Parse(data, 0)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 3, column 9

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./chromatiblock", line 1555, in <module>
    draw_blocks(core_array, noncore_pos, core_size, args.out, args.genome_height, args.gap, legend_size, args.working_directory, args.ppi, args.categorise != None, args.svg_pan_zoom_location, args.hue_start, args.hue_end)
  File "./chromatiblock", line 1351, in draw_blocks
    cairosvg.svg2pdf(url=os.path.join(working_dir, "temp.svg"), write_to=out_file, dpi=ppi)
  File "/Users/telatina/miniconda3/envs/chromatiblock/lib/python3.8/site-packages/cairosvg/__init__.py", line 76, in svg2pdf
    return surface.PDFSurface.convert(
  File "/Users/telatina/miniconda3/envs/chromatiblock/lib/python3.8/site-packages/cairosvg/surface.py", line 142, in convert
    tree = Tree(
  File "/Users/telatina/miniconda3/envs/chromatiblock/lib/python3.8/site-packages/cairosvg/parser.py", line 405, in __init__
    tree = ElementTree.fromstring(
  File "/Users/telatina/miniconda3/envs/chromatiblock/lib/python3.8/site-packages/defusedxml/common.py", line 131, in fromstring
    parser.feed(text)
  File "/Users/telatina/miniconda3/envs/chromatiblock/lib/python3.8/xml/etree/ElementTree.py", line 1695, in feed
    self._raiseerror(v)
  File "/Users/telatina/miniconda3/envs/chromatiblock/lib/python3.8/xml/etree/ElementTree.py", line 1602, in _raiseerror
    raise err
xml.etree.ElementTree.ParseError: not well-formed (invalid token): line 3, column 

Code

The code lacks comments, and this makes it hard to contribute to it. This should be improved before publication.

Comment/Question: Both SVG and HTML are hardcoded in the script. While I understand that this makes more portable the script and removes the problem of missing external files, I wonder if using specialized libraries would make the program more future-proof.

Tests

Since there are no automatic tests, it would be useful to add a bash script that automatically:

• Downloads the simple example
• Produces all possible output formats
• Checks the produced files
• Summarizes which succeeded/failed

Error size

Hi:

I don't receive any error when I execute the code, but there is an issue with the dimensions of the legend or the chromatic figure when I generate an HTML file. Here are some pictures of the error I am experiencing.


I am using chromatiblock 1.0.0/Python 3.12.0

JOSS Review

Hi @mjsull,

Chromatiblock is a great tool that I think many people fill find useful. For the most part I had no issues going from multiple FASTAs to Chromatiblock output.

Unfortunately in the current version (from Conda), there is an issue with the SVG output (also affects PDF and PNG outputs) that will need to be fixed to complete this review. I don't foresee this being a huge issue to fix since at first glance it appears to be syntax related.

Below are my comments related to openjournals/joss-reviews#2451. While reading my comments, please keep in mind, many of them are minor and only suggestions for usability improvements.

Feel free to reach out for clarifications.

Thank you for such a great tool!
Robert

Major Issue

Currently the SVG creation has an issue which also breaks PDF and PNG creation.

Here's output from trying to open the produced SVG in Firefox. It opened in Inkscape but was a truncated version the HTML output.

XML Parsing Error: not well-formed
Location: file:///F:/review/test.svg
Line Number 3, Column 10:
 <a href=test_files/0.html>  <rect stroke="#5b0a0a" stroke-opacity="1.000000" stroke-alignment="inner"
---------^

PDF and PNG also produce similar error: xml.etree.ElementTree.ParseError: not well-formed (invalid token): line 3, column 9

SVG and HTML outputs for your review

Paper Comments

1. Italics for C. difficile

2. The genus (Clostridium) is given in Figure 1's description, but I think it should also be given at first mention in the main text.

An example of a global alignment of 28 complete C. difficile genomes is shown in Fig. 1A.

An example of a global alignment of 28 complete Clostridium difficile genomes is shown in Fig. 1A.

3. A list of Assembly accessions for the 28 genomes should be included, otherwise it should be mentioned they were randomly selected.

Chromatiblock README Comments

Major Comments

1. I think the README has everything needed to get up and going with Chromaticblock, but the layout could be improved. Currently the formatting makes it easy to overlook things (examples: optional tools) and some things just kind of blend in together (example: the demos). Again the text is there, just needs to be more readable.

Minor Comments

1. For the installation section, I think changing the formatting a little would help separate the two ways of setting up Chromaticblock. Example:

Installation

Via Conda

From Source

Requirements

Optional

2. Typo in Installation Via Conda. (environemtn)

3. The link in Direct Download is broken. It looks like it also points to a previous release. An alternative could be to add a Github Release (latest by date) badge from shields.io could with this for future releases.

4. requirements section
   a. Capitalize header (Requirements)
   b. A subheader named Optional would help separate whats needed. At the moment, only Python >= 3.6.0 is all I see because the bold.
   c. Typo in Sibelia description (autmoatic)
   d. Some file formats are all caps (PDF, PNG) some are not (svg, html)
   e. Include links to the optional tools

5. In Figure Description
   a. Italics on Cdiff
   b. "ge-nomes" typo

Chromatiblock Usage

My Environment

# OS
cat /proc/version
Linux version 4.19.0-9-amd64 ([email protected]) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07)

# Conda
conda --version
conda 4.8.3

# Setup
conda create -y -n chromatiblock-review -c conda-forge -c bioconda chromatiblock

Major Comments

1. The full usage should be printed out with exit code 0 (currently 1) if no arguments are given with chromatiblock. Otherwise, at minimum the required parameters should be described (-f or -d, -w, and -o).

chromatiblock
No input files found use -f or -d

2. The usage should be improved with the use of positional arguments or subparsers. Currently there is no separation between the required arguments and truly optional arguments. I think based on the either or for -f and -d, subparsers would be easiest to implement.

3. Working directory is a required parameter (https://github.com/mjsull/chromatiblock/blob/master/chromatiblock#L1489), but its not in the usage epilog (https://github.com/mjsull/chromatiblock/blob/master/chromatiblock#L1428-L1432)

4. If no extension is given (e.g. -o test) for the output file, it checks to see if test.svg exists (after its already rerun everything) and if so doesn't overwrite it (https://github.com/mjsull/chromatiblock/blob/master/chromatiblock#L1356-L1360). But this check is made pointless if chromatiblock is run again with -o test.svg since the existing test.svg will be overwritten (https://github.com/mjsull/chromatiblock/blob/master/chromatiblock#L1344-L1345) because the check doesn't happen.

5. SVG file that was generated did not work. Attached my outputs for your inspection. When opening the SVG with Chrome or Firefox I get:

XML Parsing Error: not well-formed
Location: file:///F:/review/test.svg
Line Number 3, Column 10:
 <a href=test_files/0.html>  <rect stroke="#5b0a0a" stroke-opacity="1.000000" stroke-alignment="inner"
---------^

6. PDF could not be created with conda install, which I think is related to the previous comment related to the SVG issue.

Traceback (most recent call last):
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/lib/python3.8/xml/etree/ElementTree.py", line 1693, in feed
    self.parser.Parse(data, 0)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 3, column 9

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/bin/chromatiblock", line 1555, in <module>
    draw_blocks(core_array, noncore_pos, core_size, args.out, args.genome_height, args.gap, legend_size, args.working_directory, args.ppi, args.categorise != None, args.svg_pan_zoom_location, args.hue_start, args.hue_end)
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/bin/chromatiblock", line 1351, in draw_blocks
    cairosvg.svg2pdf(url=os.path.join(working_dir, "temp.svg"), write_to=out_file, dpi=ppi)
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/lib/python3.8/site-packages/cairosvg/__init__.py", line 76, in svg2pdf
    return surface.PDFSurface.convert(
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/lib/python3.8/site-packages/cairosvg/surface.py", line 142, in convert
    tree = Tree(
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/lib/python3.8/site-packages/cairosvg/parser.py", line 405, in __init__
    tree = ElementTree.fromstring(
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/lib/python3.8/site-packages/defusedxml/common.py", line 131, in fromstring
    parser.feed(text)
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/lib/python3.8/xml/etree/ElementTree.py", line 1695, in feed
    self._raiseerror(v)
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/lib/python3.8/xml/etree/ElementTree.py", line 1602, in _raiseerror
    raise err
xml.etree.ElementTree.ParseError: not well-formed (invalid token): line 3, column 9

7. Same issue with PNGs

Traceback (most recent call last):
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/lib/python3.8/xml/etree/ElementTree.py", line 1693, in feed
    self.parser.Parse(data, 0)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 3, column 9

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/bin/chromatiblock", line 1555, in <module>
    draw_blocks(core_array, noncore_pos, core_size, args.out, args.genome_height, args.gap, legend_size, args.working_directory, args.ppi, args.categorise != None, args.svg_pan_zoom_location, args.hue_start, args.hue_end)
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/bin/chromatiblock", line 1353, in draw_blocks
    cairosvg.svg2png(url=os.path.join(working_dir, "temp.svg"), write_to=out_file, dpi=ppi)
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/lib/python3.8/site-packages/cairosvg/__init__.py", line 66, in svg2png
    return surface.PNGSurface.convert(
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/lib/python3.8/site-packages/cairosvg/surface.py", line 142, in convert
    tree = Tree(
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/lib/python3.8/site-packages/cairosvg/parser.py", line 405, in __init__
    tree = ElementTree.fromstring(
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/lib/python3.8/site-packages/defusedxml/common.py", line 131, in fromstring
    parser.feed(text)
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/lib/python3.8/xml/etree/ElementTree.py", line 1695, in feed
    self._raiseerror(v)
  File "/home/rpetit/miniconda3/envs/chromatiblock-review/lib/python3.8/xml/etree/ElementTree.py", line 1602, in _raiseerror
    raise err
xml.etree.ElementTree.ParseError: not well-formed (invalid token): line 3, column 9

Minor Comments

1. Version needs a newline added to it (https://github.com/mjsull/chromatiblock/blob/master/chromatiblock#L1469)

(chromatiblock-review) rpetit@ogston:~/review$ chromatiblock --version
Version 0.4.2(chromatiblock-review) rpetit@ogston:~/review$

2. --input_directory checks for common extensions (https://github.com/mjsull/chromatiblock/blob/master/chromatiblock#L1481). Heads up the Genbank files downloaded from NCBI Assembly, they will have 'gbff' extension. Might be useful to allow the user to specify the extension(s).

3. It would be useful to add the parameter in the missing -w and -o messages. E.g. "Please specify a working directory (-w)."

4. -o/--out I think would be better split into something like --output_format (default: svg (could use choices) and --prefix (default: chromatiblock). Because at the moment, a typo in in the extension will cause a SVG file to be created. Example: -o test.htm would give test.htm.svg. This could at least prevent the user from completing a chromatiblock run only to find out they goofed on the extension.

5. Currently existing outputs and working directories are overwritten. It might be useful to notify the user and exit unless they force existing outputs to be overwritten (e.g. --force).

6. Is it necessary to keep the working directory? Alternative is to delete, and have the user request it kept.

7. With the the PDF and PNG, being a SVG conversion, I think would be useful to output HTML or Images (SVG,PNG,PDF). Currently if I ask for SVG, and change my mind to PDF, chromatiblock reruns everything to just convert the SVG to PDF. So if I want all three images I have to run Chromatiblock three times.