Svg axis and text opacity

[rocky]

@mmatera with a change to the text opacity, I think we get most of the axis ugliness addressed. Also there is one slight adjustment to how svg <text ..../> is set up.

Let me know what you think.

[mmatera]

OK, I like this, but actually, to improve the axis labels the best would be to implement the Align property, in a way that the labels of the y-axis be aligned to the right, and the labels of the x axis be aligned to the top.

[rocky]

OK, I like this, but actually, to improve the axis labels the best would be to implement the Align property, in a way that the labels of the y-axis be aligned to the right, and the labels of the x axis be aligned to the top.

Absolutely, but let me give the broader context around why I did this and did this now.

@mmatera At this point, I'd like to have a release in about 24hours and I am trying to understand what will make the cut and what won't.

I was borderline on this, until I spent some time with the code to glean how much of a mess we would have to undo in the future, how ugly it looks, and the benefit. With the merge in (thank you), I think this should go in. I would like some of the commits (like the one where you are just removing print statements that in my opinion shouldn't have been commited in the first place) squashed.

• StringSplit: adding support for handling lists as a first argument #1216 I think is okay to go in, right?
• Checks for CellsToTeX support #1215 I think is sort of okay, but I'd like a version of CellsToTeX in packages even if not all of it works. The author says that's okay. If you are not up for doing the work, I'll shepard this part in
• Singletonize Symbol System`List #1213 I guess is okay, right?
• Use ToString in test/help to handle unicode characters #1212 iis okay, right?
• Improve read expressions #1217 is ready?

The PRs labled "needs work" I would like deferred

• Evaluation formating refactory #1222
• Charencodesymbols #1214
• Knot theory fixes #1199

These appear to as broken:

• Fix D and Derivative #1220
• Graphics overhault #1132 (and those with numbers lower than that likewise)

These I would like deferred to another release

• Unicode replace strings symbols mmatera #1178
• Fixcomparisons #1209

Since there is already a lot of changes here including some big ones, if there is anything that is not ready and can be deferred I would prefer they get deferred. I would rather have two smaller releases than one big one.

Your thoughts?

[mmatera]

@mmatera At this point, I'd like to have a release in about 24hours and I am trying to understand what will make the cut and what won't.

Completely agree. I think with the transparency it actually looks nicer...

I was borderline on this, until I spent some time with the code to glean how much of a mess we would have to undo in the future, how ugly it looks, and the benefit. With the merge in (thank you), I think this should go in. I would like some of the commits (like the one where you are just removing print statements that in my opinion shouldn't have been commited in the first place) squashed.

I guess I did it the squash...

Regarding the rest:

#1216
#1213
#1212
#1217
are ready. #1215 is ready, in the sense that the test is ready. If you can also ship the package, go ahead, but still, I do not have any subset of the package working, just tests that eventually will detect when the package does something interesting.

I would also keep #1209, because it actually improves a lot the support of the kernel in comparisons. I guess it could be a little bit better implemented, but not a lot.

#1199 collect some of the previous PRs, so you do not need to merge it.

[mmatera]

Regarding #1220, this is something that we should fix as soon as possible after we finish with the release since many other things depend on the ability to handle derivatives.

[rocky]

@mmatera At this point, I'd like to have a release in about 24hours and I am trying to understand what will make the cut and what won't.

Completely agree. I think with the transparency it actually looks nicer...

I was borderline on this, until I spent some time with the code to glean how much of a mess we would have to undo in the future, how ugly it looks, and the benefit. With the merge in (thank you), I think this should go in. I would like some of the commits (like the one where you are just removing print statements that in my opinion shouldn't have been commited in the first place) squashed.

I guess I did it the squash...

Regarding the rest:

#1216
#1213
#1212
#1217
are ready.

Merged now.

#1215 is ready, in the sense that the test is ready. If you can also ship the package, go ahead, but still, I do not have any subset of the package working, just tests that eventually will detect when the package does something interesting.

I just looked at in more detail. #1215 not ready.

I would also keep #1209, because it actually improves a lot the support of the kernel in comparisons. I guess it could be a little bit better implemented, but not a lot.

I am not going to have time to go over #1209. From what I saw before it needs a refactor to make it more scalable, and at the same time we can increase the number of passing test cases.

So let's defer and after the release, let's work on this.

I will add a section in the release notes what's will be coming soon.

#1199 collect some of the previous PRs, so you do not need to merge it.

It has been closed.