Broken export?

[dmarts]

My diagram looks great on screen but when I try to export it gets mangled: https://asciiflow.com/#/share/eJyrVspLzE1VssorzcnRUcpJrEwtUrJSqo5RqohRsrI0NtGJUaoEsowsDICsktSKEiAnRunRlD3DDMXE5AFJBSoAnIY9mtLzaEoDbjSBGlY0Befll6flJGanAtlwcTM9sg2cg9fNSxQeTW8hO9BJ9RuQdPMNhrOx6SXdyJLUvMS8EjCbPL%2BQYe0U1FDcg8qdAVdpoocwi2RrILLTNmEVp8RInPkE1UjPvJLUorzUEkwjBzy3k51cCYaMKfachhoyjuHBhAI7JqaIxOBGl8KV9ggWhEWo6nuwpdU9uAstfFYDyWBjbJ6CZGhXZyMF7Jkb3VBDpIxBMNKAwEgPoRpvcYbXYgKWTdsF9ReskCIiVWHoIex31ABNKk3OTi2BpAXiii%2BFzLziksS85FRSLcMbdFANxsQF9Ax04wnkLAhAS5v4ADHGEQ1oY9gwQzFKtUq1AOFolO8%3D)

Any ideas?

[Great tool, I only just found it via Google so user error is highly likely. Usecase is creating box diagrams to embed in Gitlab markdown.]

[kwtj43]

Really like the tool as well -- seeing the same export issues running on Windows/Chrome.

[jaybh]

In select and move mode, when you select the area of the graphic, you will see a few rogue characters, especially along the edges of the boxes. In my experience, this happens mostly when I have made copies of shapes and moved them around. Deleting those unseen whitespace characters, helps render cleanly. I wonder if this can be taken care of in the code itself though, since it is a little tedious to weed out what I am suggesting.

[TimGremalm]

You can recreate this quite simple.

Draw a rectangle, select it and copy it.

          ┌───┐
          │   │
          └───┘

Paste it alongside the existing rectangle.

  ┌───┐  ┌───┐
  │   │  │   │
  └───┘  └───┘

When copying or exporting rectangle it will look like this:

  ┌───┐
 ┌───┐
  │     │
 │   │
  └───┘
 └───┘

It seems to insert new lines at the wrong place.

[fredEOF]

Just a small addition; it does not only affect the rectangles but every line of the selected copy (even if you copy an empty space). When pasting, an additional blank at the end of the line (after the last character) is added. If there is no character, it adds a blank (or carriage return?) at the beginning.

For me, it only happens on Chrome. (Version 88.0.4324.190) Can't recreate the behaviour with Firefox. (85.0.2 (64-Bit))

[Qwertylex]

in response to https://github.com/lewish/asciiflow/issues/185#issuecomment-830869630 I've noticed the same issue with placing a bunch of text next to another bunch of text, just like you did with the boxes. It doesn't happen in the legacy asciiflow.

how it should look:

EnCt2                                                                 #header
a80e955891759f0fc4ab486c5f710296a9670b13                              #hmac thingy1
a80e955891759f0fc4ab486c                                              #hmac thingy2 (ignored)
kdZZG4zw                                                              #salt
CgIx/E/aZlUBFnP6Gpw/xW1OLRfkDdZoFnJgaViAji11XEn1kqqXHK+PiMWA5uTS9W1H  #base64'd 8 byte nonce + aes256 ciphertext
IwEmS                                                                 #footer

how asciiflow exported it:

EnCt2                                                               
 #header
a80e955891759f0fc4ab486c5f710296a9670b13                            
 #hmac thingy1
a80e955891759f0fc4ab486c                                            
 #hmac thingy2 (ignored)
kdZZG4zw                                                            
 #salt
CgIx/E/aZlUBFnP6Gpw/xW1OLRfkDdZoFnJgaViAji11XEn1kqqXHK+PiMWA5uTS9W1H
 #base64'd 8 byte nonce + aes256 ciphertext
IwEmS                                                                 #footer

[InflexCZE]

I'm experiencing the same issue when copying elements (boxes, text, doesn't matter) on:

• Win 10.0.17763 Build 17763
• Chrome Version 91.0.4472.124 (Official Build) (64-bit)

Copy works fine as long as I copy only one line at a time, so I believe that one unwanted CR or LF appears at the end of each copied line, which then corrupts the diagram.

Awesome tool otherwise, keep up the good work 👍

[mifriis]

How can I help fix this issue?

It's been open since march, but looking at the code I can't figure out where to begin.

It's fixable either in the Copy Paste feature, where "ghosts" are added into a square. It's not treated as an empty square afterwards and must be manually deleted. If commitScratch(); checked for ghost squares/characters for example.

It could also be fixed in the export feature, but probably a dirtier place to do it. Here what ever value is in those ghost squares could be purged into a standard whitespace instead.

This is the only bug/problem I have with AsciiFlow, but it's a big one!

Here's the paste feature: https://github.com/lewish/asciiflow/blob/b79b1e4c768a228929dc2960b823694a0e46ae98/client/draw/select.ts#L27

It seems to insert a ghost character in the cell marked when you paste and can be provoked this way consistently. I have tried finding a way to debug what's in the canvas to see what ascii character is in the cell, but without success.

[fraserredmond]

A work-around until this is fixed properly...

Using the screenshot in FredEOF's comment above:

If you select the full width of the lines that are broken, empty cells will have a light-blue background, text/lines have a grey background. But some of the empty cells have a grey background too. Those are the cells breaking the export/copy.

Select those empty grey cells and press Delete and they'll change to a blue background.

One empty grey cell anywhere on the line is enough to break that line. For me, they seemed to occur most often to the right of a line.

[samba2]

Same here. Love the tool but as of today the export is broken. Thanks to the described workaround I nowadays plan for a "finishing phase" of my diagrams - just fiddle long enough with "select all" and "staring at + deleting odd rectangles" until the diagram exports flawlessly. For me this is around 5 min extra. Anyway, 🙏 fix this annoying bug.

[konradkar2]

Still broken for me on chrome, windows 11

[AlexAtkinson]

This shows up in a few cases, but for me it's most often seen when using the text mode, as any delete action causes a mysterious void. This void can be seen when selecting the area. While selecting the diagram reveals these voids, there is no way to fill them back in with the default character. This is the main issue for me.

Suggestion: Make the text mode [SPACE] character backfill with whatever the original character is, as this character is what is being respected by the export function.... OR, make the export function respect spaces as well.

Thanks. Love the tool. Keep it up.

[lewish]

Could anyone encountering this provide a bit more info about browser and OS? I have tried to recreate all the situations above, but have not been able to cause this to happen on Chrome + Linux.

I can probably just strip these unknown/whitespace characters at export but I'd like to understand how they are getting into the diagrams in the first place!

[Sieboldianus]

I did experience these characters on Chrome. I always only notice these characters when I want to export, after drawing a complex diagram or so. Then I go through them one by one and remove, so I can export correctly. I tried to reproduce, but could not so far.

[edit]

Now I was able to reproduce:

1. Draw, Select, and Copy (Cut) CTRL+X

2. Paste somewhere else. On the upper left, where the selection started, you'll see these characters. I could reproduce the behavior on all other copies/cuts. You can also see some more to the right of the vertical lines.

[kting28]

Could anyone encountering this provide a bit more info about browser and OS? I have tried to recreate all the situations above, but have not been able to cause this to happen on Chrome + Linux.

I can probably just strip these unknown/whitespace characters at export but I'd like to understand how they are getting into the diagrams in the first place!

I can reproduce on both Windows and Linux, with various chrome versions

Windows 11 Chrome Version 121.0.6167.185 (Official Build) (64-bit)

Linux Ubuntu 20 Chrome Version 114.0.5735.198 (Official Build) (64-bit)

[lewish]

Fixed in #279