Feature request: enforce consistent whitespace for exported SWC files

[carshadi]

Currently, exported SWCs can have mixed tabs and spaces between columns, which causes some software to complain. We should enforce single spaces between columns for better compatibility with other software.

[tferr]

Agree. The only think to patch is SNPoint, something like:

    public static StringReader collectionAsReader(
        final Collection<SWCPoint> points)
    {
        final String SEP = " ";
        final StringBuilder sb = new StringBuilder();
        for (final SWCPoint p : points) {
            sb.append(p.id).append(SEP) //
                .append(p.type).append(SEP) // see https://github.com/morphonets/SNT/issues/147
                .append(String.format(Locale.US, "%.6f", p.x)).append(SEP) //
                .append(String.format(Locale.US, "%.6f", p.y)).append(SEP) //
                .append(String.format(Locale.US, "%.6f", p.z)).append(SEP) //
                .append(String.format(Locale.US, "%.6f", p.radius)).append(SEP) //
                .append(p.parent).append(System.lineSeparator()); 
        }
        return new StringReader(sb.toString());
    }

Related: right now we are using System.lineSeparator() to separate lines. That means in \n in UNIX by \r\n in Windows. @carshadi, what about the line separator. Keep as-is?

[carshadi]

The line separator is probably fine as-is

[tferr]

They recommend only "\n", but I agree we can keep that as-is for now as I am not sure which scripts out there are parsing files with hardwired separators. Also, d5a784542c13ca77747cfbc143c0abbedd2fd997 adds support for the "new" SWC type flags, listed in the updated SWC specification. The only issue is that some of these integers were used by FORK_POINT and END_POINT, but I think nobody was using them!?

These are the new tags:

[carshadi]

looks good

The only issue is that some of these integers were used by FORK_POINT and END_POINT, but I think nobody was using them!?

yeah, I know Janelia uses FORK_POINT==5 and END_POINT==6, but that information is already encoded in the tree structure so there is no good reason to use the type tags for them, imo.