acii art renderer #2353
acii art renderer #2353
Conversation
```fish
for f in docs/**.d2
set -l dir (dirname $f)
set -l name (basename $f .d2)
if [ $name = "in" ]
set name out
end
if [ $name = "input" ]
set name output
end
go run main.go $f $dir/$name.txt
end
```
|
still quite big though 😅 let me know if you have some request |
There was a problem hiding this comment.
Yeah these are too large. I'm looking for diagrams that can be inlined into code. There should be no padding too.
I'm not quite sure how that can be achieved, because the layout engine gives a certain layout with those long lengths of edges. Shortening those edges would lead to overlaps of objects/text. The bounty placed on the issue is reward for solving that problem.
|
apparently treating it as image processing problem works! However,
|
|
@alixander does the size looks reasonable to you? (ignore the missing text/label, it's bug on my side 😂) |
|
The size looks reasonable!
|
It has the caveat that some diagram might get too wide, but sure. |
|
also reasonable to add further constraints as you see fit, e.g. only rectangles |
|
random inspiration https://diagon.arthursonzogni.com/#GraphDAG 
|
seems like the layout engine always came up with the optimal width
|
Hi, @DrSensor is this still being worked on? |
|
Sorry for the long break, currently it work fine and look decent on dagre layout despite it has some silly quirk (only NOTE: It will struggle on complex big diagram that has many vertex line but there is no way around this. the least user can do is try to use other layout. I kinda want to keep this approach instead of limit it to ELK layout. Should I continue or is this good enough? |
/claim #924
close #924
see
docs/**.txtfor the examples output