Closed azriel91 closed 4 years ago
Hmn, it's neat. To improve, maybe we will copy rust formatting
i.e:
println!("Hello {arg}!", arg = "world")
.---------. .-----------. .---.
( Alice {a} ) ----> / Bob {b,c} / -> ( {d} )
`---------' '-----------' `---'
.---------. .----------. .-.
( Apple {a} ) ----> / Ball {b} / -> ({e})
`---------' '----------' `-'
( ͡° ͜ʖ ͡°)
#Legend:
a = {color: red }
b = {color: blue }
c = {opacity: 0.5 }
d = "Hello world!"
e = {text = "Foo", color: red, opacity: 0.5, font-size: 8px}
Might as well color the emoji faces: ( ͡° ͜ʖ ͡°) = {color: brown}
Haven't started the ground work for this one, but thinking of something like using css as the syntax for the styling.
Using .
for class and #
for id
.---------. .-----------. .--.
( Alice {.a}) ----> / Bob {.b.c}/ -> ({.d})
`---------' '-----------' `--'
.---------. .-----------. .-.
( Apple $.a ) ----> / Ball $.b.c/ -> ($#e)
`---------' '-----------' `-'
.a {color: red } .b {color: blue } .c {opacity: 0.5 } .d{ text: "Hello world!"}
@ivanceras Would the diagram with the class and id specified get more space? Where
+-----------+
| Alice $.a |
+-----------+
# Legend:
.a { color: red }
Would be render as:
+-----------+
| Alice |
+-----------+
or
+-------+
| Alice |
+-------+
@pickfire It would like be the first one, since there could be scribbles connecting to the left side of the box, which means shrinking the box would make the surrounding scribbles out of place. I haven't started any work on this yet, since I hit a wall on recognizing bigger shapes such as circle, rect, etc. This needs a different algorithm than the current implementation.
@ivanceras I would like to help out on this project too since there aren't many good alternatives online where the second would be rendered in which I feel like the extra whitespace for style is useless. (I prefer the second)
As well, CJK characters without needing to decrease the whitespace would be nice:
+---+
| 一 |
+---+
From what I know, the current project uses links between characters with neighbour characters to determine what needs to be drawn, doesn't it identify like say box, circle, cloud, some other predefined shapes ...
@pickfire, if you prefer the second one, then it would be very difficult to have a coherent render. illustration
As for the CJK, CJK are 2 space width in terminals while just ~1.5 space width in browsers and any other GUI-based text editor. I'm sticking with the terminal 2 space width, it's much simpler to deal than ~1.5 width.
True for the CJK case, if it would be like a box in the terminal, I rather it be render the same in svg. If there by any chance that the current reader is able to determine the content of the box and render it again without really matching each character that creates the box? Say, identify the box first before the content.
No, the current implementation only determine the location of the character relative to the number of character from the left of the line, summing all character widths from the left of it.
Have you tried recognizing shapes rather than matching each character to svg? Any downside? As far as I know, I never seen any projects doing this.
That's the plan, recognizing the shape at higher level, but the algorithm to use doesn't look very simple. If you can show something like that, then I'd be happy to include it in the project.
@ivanceras Well, I need to do some research before that. I might come back to this afterward.
The initial issue description said
"Also, what about people wanting to style lines? Maybe we leave that as a separate topic."
I would definitely like to style lines (in particular, color).
This is a must have feature! +1
Took me awhile to get back to work on this, but I think I've completed the needed algorithms to solve this issue. Stay tuned.
I'm taking the design route originally proposed by @azriel91 since it is easier to parse.
I only modify the colon
to be equal sign
and css styles follow right after the # Legend:
marker (only 1 \n
)
.---------. .-----------.
( Alice {a} ) ----> / Bob {b,c} /
`---------' '-----------'
.---------. .----------.
( Apple {a} ) ----> / Ball {b} /
`---------' '----------'
# Legend:
a = { color: red }
b = { color: blue }
c = { opacity: 0.5 }
This was a huge rewrite and a disconnect of the core code. It's now sitting on the a different branch since most of the nice behavior is not yet ported into this new architecture. Please check the code out. https://github.com/ivanceras/svgbob/tree/rewrite3-vectorize
I need help with:
@ivanceras Is it possible to reuse the same legend?
@pickfire , yes it is possible to reuse the legend for other shapes, as it is implemented like a class in html/css.
There is another thing, kinda belongs here. Typesetting is horrible atm. It would be nice if that could be styled a bit too. At least set if text is aligned left, centered or right.
@virtualritz typesetting is not a focus on this project. Typesetting is better suited with markdown, tex, asciidoc, etc. Svgbob aim is to be a quick and handy tool to create good enough graphical diagrams, which you can enhance with other tools such as inkscape, then embed it the final documents.
@ivanceras I am not talking about typsetting long text. I am solely about how text is aligned/composed inside a box, for example.
.-----------------.
.->| root |<-.
| '-----------------' |
| |
.--------┴--------. .--------┴--------.
| transform | | transform |
'-----------------' '-----------------'
^ ^
.--------┴--------. .--------┴--------.
| transform | | camera |
'-----------------' '-----------------'
^ ^
.--------┴--------. .--------┴--------.
| attributes | | screen |
'-----------------' '-----------------'
^ ^
.--------┴--------. .--------┴--------.
| material (osl) | | output layer |
'-----------------' '-----------------'
^
:
Let's say I want the text to be centered in each box above.
Also note that the brackets (
& )
in material (osl)
are considered part of the graphic (when they should be part of the text). There should be a way to tell svgbob so.
P.S. something weird happens with the 2n topmost arrow when I try this on https://ivanceras.github.io/svgbob-editor/.
@virtualritz this need a little more time supporting that usecase. Also, I just updated the demo to use the lastest version of svgbob, without the complete nice behavior taken of the previous version. Those are yet to be ported over to the new architecture rewrite.
Is there a selector in the Legend for the default fill and stroke values? Like, if I wanted to set the style for the Mind Map example, how would I set the colors for the lines?
Nevermind, I figured it out.
solid= { stroke:red; }
Raising this out of this thread to not digress too much.
Should svgbob allow the ability to style nodes? It would be nice to be able to do it so that diagrams can be represented in text and still support colour. The ascii version of the diagram is not very readable with styling information included in each node. @ivanceras gave an example of using single letters to represent colour, but I foresee potential use cases for additional styling.
I've copied a bit of the post and edited it to see what it may look like:
Also, what about people wanting to style lines? Maybe we leave that as a separate topic.