Color issues and configuration

[DannyBen]

I am having the same problems as mentioned in #43 where colors are not rendered properly.

It is my opinion that the behavior should be modified, as the colors generated in such cases in all themes do not represent their original form at all and are printed as pale white.

But - as I realize this is unlikely to change - I was looking for the ~/.config/termtosvg configuration folder, and could not find it. Was this configuration method removed in later versions? Is there a way to configure colors of existing themes or just add themes without dealing with the template files themselves?

EDIT:

I see the INI was removed here - which is a shame....
So is there no way to easily customize colors now, other than creating new templates?

[nbedos]

It is my opinion that the behavior should be modified, as the colors generated in such cases in all themes do not represent their original form at all and are printed as pale white.

How would you suggest to modify the current behavior? The "original form" of a color is defined by the configuration of the terminal emulator you're using. In order to render the right colors, termtosvg would have to:

1. read the configuration of all the terminal emulators installed on your machine
2. find out which terminal emulator runs the current shell
3. render the animation using the configuration of the terminal emulator

Step 2 and 3 are possible, but step 1 is a lot work.

I see the INI was removed here - which is a shame....
So is there no way to easily customize colors now, other than creating new templates?

Yes, the configuration file was removed and you have to create new templates to set the colors you want. It's not much different, really.

[DannyBen]

I am sorry, I must have missed something obvious.

1. Why would a normally "yellow" terminal color, render as white in all themes? It should remain yellow-ish in all or most themes.
2. I have looked at the templates folder. Each template is a full, complicated SVG which does not look like a template, but rather like an output of termtosvg - have I looked at the wrong place? If not, then I really do not see how this is the same as adding a bunch of colors in an INI file, sorry.

The thing I like in termtosvg over the alternatives is the simplicity and the fact that everything is done in a single tool, but contrary to the other tools - it does not "work out of the box" for me (and probably for other people that get the coloring wrong).

[nbedos]

Why would a normally "yellow" terminal color, render as white in all themes? It should remain yellow-ish in all or most themes.

Oh, I understand now. Yes, you're right, I'll fix that.

I have looked at the templates folder. Each template is a full, complicated SVG which does not look like a template, but rather like an output of termtosvg - have I looked at the wrong place? If not, then I really do not see how this is the same as adding a bunch of colors in an INI file, sorry.

You did look at the right place. You're right that default templates should be simpler. I may have abused the fact that a full blown animation can be used as a template. I'll try and fix that too.

[DannyBen]

Oh great. If you need more details from me, or if there is anything I can do to help, let me know.

[nbedos]

@DannyBen I'm working on this branch: https://github.com/nbedos/termtosvg/tree/bug/templates

I've added a few templates (powershell, putty, terminal_app, ubuntu, xterm) based on the color schemes defined here : https://en.wikipedia.org/wiki/ANSI_escape_code#Colors
I've also removed as much code as possible from all the templates so that they are easier to modify.

I still need to update the examples in docs/ and the README. Let me know what you think.

[DannyBen]

Nicolas - the new templates look much better and easier to edit.

I still have a few thoughts - not sure if any of them is of interest to you - and of course I am not saying this as criticism, but as hopefully constructive personal opinion.

Have at least one standard theme

There should be at least one template where the standard ANSI (16) colors are converted to the SVG "as is" - meaning, green should be green, red should be red.

(Looking at the template colors more carefully, I believe this is done in all the new templates, so this is great).

Separation of "layout" from "color theme"

Right now, termtosvg uses the concept "template" for two (usually-) separate things: Layout and Color Theme. I feel it might be easier to maintain and update if these are separated. I am also saying this because I understand that once upon a time, you did have this separation in the form of a separate INI file for color scheme.

I was looking at some of the templates, and noticed they are identical, with the exception of the colors section. This, to me, is a code smell - these are copy-pasted templates, with only an inner thing changed, which means they are all one layout, and different skins.

---

In any case, if you want me to test something, just let me know. Keep in mind I am not writing python, so I might need some hints as to how to use a non-released version (since I am usually just "pip installing").

[rec]

FYI, I came here with exactly the same issue (termtosvg did not represent terminal colors as generated), patched in the bug/templates branch, and this worked perfectly for me.

Good timing, thanks!

---

Separation of "layout" from "color theme"

This was also something else I noted. I wanted to tweak just a single color and suddenly, all this XML? I just wanna change a single color! :-)

Don't get me wrong - it's extremely logical to be rendering terminal interactions into SVG which is XML.

But for us, the users to customize stuff - well, most of the engineers I work with these days have never even used XML.

As a data point, Google started with XML in around 2003 and then dropped it in 2004, because mistakes in editing XML files were responsible for more production failures than any other cause...

---

So I think you should be protecting your users from the XML entirely!

What I want to do is fill out a tiny bit of JSON or a dict with all the information I need, and nothing else.

I want to say in Python:

Template('dracula', foreground='yellow')

or from the command line:

 $ termtosvg render my-movie.cast --template=dracula --parameters='{"foreground": "yellow"}'

I haven't really looked at the termtosvg code in detail, but I might be able to knock the above feature out pretty fast if you were interested...

What would happen would be that your template files would become actual Python templates and you would use format with a dictionary of values to fill it in before rendering it as SVG!

---

Anyway, thanks for an excellent package that I am already using in a production project (though I haven't rolled the movies out in a release yet as I'm still making them...)

[DannyBen]

I saw version 1.0.0 was released with the fix (thanks for that), so as far as I am concerned this issue can be closed, right?

[nbedos]

Separation of "layout" from "color theme"

Right now, termtosvg uses the concept "template" for two (usually-) separate things: Layout and Color Theme. I feel it might be easier to maintain and update if these are separated. I am also saying this because I understand that once upon a time, you did have this separation in the form of a separate INI file for color scheme.

I was looking at some of the templates, and noticed they are identical, with the exception of the colors section. This, to me, is a code smell - these are copy-pasted templates, with only an inner thing changed, which means they are all one layout, and different skins.

Yes, some color palettes are used in different templates and it's not ideal. But I find it a lot more convenient to have a single file which contains all the information needed to create an animation.

So I think you should be protecting your users from the XML entirely!

What I want to do is fill out a tiny bit of JSON or a dict with all the information I need, and nothing else.

I want to say in Python:

Template('dracula', foreground='yellow')

or from the command line:

 $ termtosvg render my-movie.cast --template=dracula --parameters='{"foreground": "yellow"}'

I think JSON is not an ideal format for configuration files since it does not allow comments.

Another reason I'd rather not implement a configuration file is that the time I'm willing to allocate to this project has been quite low for a while now. Sorry if that's make me anti-user-friendly.

As for the initial subject of this issue, I've released version 1.0.0 which includes the new templates.

[nbedos]

I saw version 1.0.0 was released with the fix (thanks for that), so as far as I am concerned this issue can be closed, right?

Yes, closed.

[rec]

$ termtosvg render my-movie.cast --template=dracula --parameters='{"foreground": "yellow"}' I think JSON is not an ideal format for configuration files since it does not allow comments.

I didn't talk about configuration files, only the command line. You wouldn't need a comment in the command line, would you? Using XML for new development in 2019 is... not usual. Decades of experience with XML has driven pretty well everyone away from it, because it's so extremely easy to make mistakes. Much of the world is doing web development now, for which JSON is the natural format. Generally, I use a YAML parser to read JSON - which works perfectly on classic JSON *and* allows JSON-with-comments-and-trailing commas or just YAML. This gives me the best of both worlds.

…

-- /t PGP Key: https://flowcrypt.com/pub/tom.ritchford@gmail.com *https://tom.ritchford.com <https://tom.ritchford.com>* *https://tom.swirly.com <https://tom.swirly.com>*

[DannyBen]

I am not sure how we got to talking about XML (or even JSON) for configuration, must be some miscommunication in the thread, or am I missing something?

But if we are on the subject, and without turning this into a religious discussion - I believe that YAML is hands down the best configuration format. Some tools today opt for other formats - such as TOML - which I find inferior and unclear - and JSON is just a tad friendlier than XML, not by much. YAML is easy to read, easy to write, parsable in practically every language, and is forgiving to many syntax errors.