ivanceras / svgbob

Convert your ascii diagram scribbles into happy little SVG
http://ivanceras.github.io/svgbob-editor/
Apache License 2.0
3.91k stars 112 forks source link

Ability to style diagram #11

Closed azriel91 closed 4 years ago

azriel91 commented 7 years ago

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:

 .---------.            .-----------.
( Alice {a} )  ---->   / Bob {b,c} /
 `---------'          '-----------'

 .---------.            .----------.
( Apple {a} )  ---->   / Ball {b} /
 `---------'          '----------'

# Legend:

a: { color: red }
b: { color: blue }
c: { opacity: 0.5 }

Also, what about people wanting to style lines? Maybe we leave that as a separate topic.

ivanceras commented 7 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}

ivanceras commented 7 years ago

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)
 `---------'           '-----------'        `-'

Legend:

.a {color: red } .b {color: blue } .c {opacity: 0.5 } .d{ text: "Hello world!"}

e{text:"Foo", color: red, opacity: 0.5, font-size: 8px}

pickfire commented 6 years ago

@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 |
+-------+
ivanceras commented 6 years ago

@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.

pickfire commented 6 years ago

@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 ...

ivanceras commented 6 years ago

@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.

pickfire commented 6 years ago

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.

ivanceras commented 6 years ago

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.

pickfire commented 6 years ago

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.

ivanceras commented 6 years ago

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.

pickfire commented 6 years ago

@ivanceras Well, I need to do some research before that. I might come back to this afterward.

haroldcarr commented 5 years ago

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).

virtualritz commented 4 years ago

This is a must have feature! +1

ivanceras commented 4 years ago

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.

ivanceras commented 4 years ago

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 }
ivanceras commented 4 years ago

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 commented 4 years ago

Screenshot from 2020-02-02 21-08-06

pickfire commented 4 years ago

@ivanceras Is it possible to reuse the same legend?

ivanceras commented 4 years ago

@pickfire , yes it is possible to reuse the legend for other shapes, as it is implemented like a class in html/css.

virtualritz commented 4 years ago

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.

ivanceras commented 4 years ago

@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.

virtualritz commented 4 years ago

@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/.

ivanceras commented 4 years ago

@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.

mdg-utility commented 2 years ago

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?

mdg-utility commented 2 years ago

Nevermind, I figured it out. solid= { stroke:red; }