[ANN] PrettyTables.jl v0.11

Hi!

I just asked for registration of PrettyTables v0.11. There is some improvements and bug fixes in all backends. However, the major change in this release is the alignment system based on anchors for the text backend. Now, you can define regexes in columns that creates anchors to align the text. Hence, we can, for example, align floating points very easily:

Notice that the alignment with anchors also works with the global column alignment:

55 Likes

Great. Thanks @Ronis_BR

1 Like

This is very neat! Kudos!

Is it possible and, if yes, are there plans to extend this alignment functionality to other output formats, like markdown and LaTeX?

2 Likes

For markdown, certainly. I am planning to create a custom markdown backend based on a (very very) much simple version of Text backend. However, for LaTeX, I can do this as soon as someone tell me how it can be done :smiley:

3 Likes

It’s projects like this that make me think that being able to switch from rmarkdown is on the horizon for Julia users. Nice work

2 Likes

This is great!

FWIW, I’ve done it before in a dirty way (by splitting columns in three and aligning integer and decimal parts left and right of the center column that was filled with dots)

Anyway, maybe one could instead do the same thing you have for the REPL right now and it’s just a matter of combining it with something like what this Stackoverflow thread suggests?

1 Like

Sounds like a good place to use Latexify?

PrettyTables already has a super robust Latex backend, it’s just a matter of keeping feature parity between the 3 output formats

2 Likes

Note that PrettyTables v0.11.0 forces a downgrade of DataFrames,

1 Like

I will patch it.

3 Likes

Done Release v0.22.4 · JuliaData/DataFrames.jl · GitHub

6 Likes

Thank you very much Bogumil. Now the upgrade works nicely.

1 Like

Hi!

I need help. I am cleaning the code so that we can reach v1.0 in which Text back-end will be declared stable. In this process I am correcting some terrible choices I did in the past. For example, I was creating two auxiliary tables, one with the strings and another with the cell lengths. My original idea was to save a lot of calls to textwidth. However, it turns out that textwidth is incredibly fast, way faster than allocating an array with the same size of the printed table.

Hence, I did a lot of modifications to master trying to clean everything I can. This reduced allocation, and improved the performance a little bit. The only minor drawback is when you have Markdown cells. In this case, I cannot use textwidth because those cells has ANSI escape characters. Thus, I need to remove them and then compute the width. Conclusion: printing cells with Markdown is a little slower (1 to 5% in my benchmarks).

Thus, I will appreciate if anyone can clone master and do a stress test to see if I missed something. Of course, all the tests are passing, but I could have overlooked something given the amount of configurations we have.