better line-from-box characters

[mreinstein]

rather than:

+--------+
|        |
|        +---
|        |
+--------+

give me:

+--------+
|        |
|        ├----
|        |
+--------+

the 4 characters: ├, ┬, ┴, ┤

[MMK21Hub]

Those are not ASCII characters AFAIK

[mreinstein]

The service already provides a non-ascii drawing mode:

[vashnt707]

Yes but the screenshot is for the non-editable view which I guess does a simple replacement of ascii characters with non-ascii characters from the current, fixed snapshot of the diagram. However if non-ascii characters are brought into editing view, they would require to abide by all controls to select, adjust, connect and so on. This will also create uneven thickness/thinness in certain parts of the diagram. Moreover the main motivation behind ascii diagram is to ensure a no-worry output. This benefit is possibly a very important factor which pushes development forward.

Note that if you are interest in just viewing in lines-mode using non-ascii characters, you can check corresponding code and make modifications. A PR can help others too.

[mreinstein]

Moreover the main motivation behind ascii diagram is to ensure a no-worry output.

I think this brings up an interesting question: what is the intended "render target" for ascii flow output. There are 2 obvious ones that come to mind for me as an end user:

• embed an ascii diagram in a text file (especially code, so I can diagram software development inline with code)
• embed an ascii diagram in a terminal window, either as some kind of artwork, or as part of an ascii based ui

I don't know if asciiflow truly declares it's intention for one or the other. I assume it is a lowest common denominator ascii output tool. The downside of assuming lowest common denominator is we can't leverage capabilities that are present in the render target:

• most console terminals these days can render non-ascii characters and even colors
• most text/code editors can render non-ascii characters (reasonable utf8 support)

supporting different feature sets depending on which "render target" one intends to embed in would open up using the nice features available in these environments. This could be a super nice thing for asciiflow 3, assuming there ever is one.

[vashnt707]

Yes it will help if the project goal talks about render target as you said. I typically encourage scope to be lean especially for projects like these in order to motivate continued development and contributions. Anyways, not sure if there is going to be an asciiflow3 :)

[Qix-]

Asciiflow 3 will (eventually) have this support. The existing codebase is not very well set up to handle a different output (I know that sounds strange, just take my word for it).

Also, I apologize for the gross delay on Asciiflow 3. The project was handed off to me at a time free time was plentiful but a number of things in my life changed and I've been spending the better part of a year getting them back on track.

This is a feature I've always wanted out of the project, too, and asciiflow 3 is designed with this usecase in mind.

[mreinstein]

I apologize for the gross delay on Asciiflow 3.

No need to apologize; Asciiflow in it's current form is great! I completely understand that this is a volunteer project.

asciiflow 3 is designed with this usecase in mind

based on this wording, it sounds like af3 is already in progress? Is there a roadmap or explicit goal with a version 3?

[Qix-]

It is, just hasn't seen progress for a while :sweat_smile:

Yes, AF3 is meant to address most of the issues people have today. The main thing is that the existing codebase cared strictly about ASCII characters but has since seen an obvious need for more than just that. Plus, double-width characters are completely broken in the existing codebase (e.g. Asian languages) and I'm sure RTL (Arabic) support is lacking too.

All things Id like to address in the new version.

Plus a new design, and it's compatible with Electron for those who use it frequently enough (though it will be hosted at the existing URL as well).

[Qix-]

Merging into #143.