show in html is a bit hard to read

[juliohm]

Hi, I am opening this issue just to confirm that this is the intended behavior of show in html:

The numeric values are so shifted to the right that it is a bit hard to associate the values with the correct headers. Any chance this alignment could be changed to a centered alignment?

[bkamins]

The idea was to align numeric values to a decimal point. But I can see that in fact we do not do this anyway (we do it in text/plain).

But maybe the easiest way to go is to add vertical lines clearly showing columns. What do you think @ronisbr?

[ronisbr]

Hi @juliohm !

That huge padding is strange. The columns should be sized to fit the longest cell, which in this case is the header / subheader. I cannot reproduce the results in Jupyter. Take a look how I see a table with the same set of data:

How can we replicate it?

But maybe the easiest way to go is to add vertical lines clearly showing columns.

I personally hate vertical lines :D Furthermore, I am not sure if there is a way to easily do this kind of modification inside Jupyter.

[juliohm]

We are using Quarto in this case. Perhaps we get different behavior in HTML behavior depending on the plataform? We have other table types there with PrettyTables.jl and they look nice with columns centered. It is only DataFrame that is showing this issue. Em sex., 8 de set. de 2023 18:59, Ronan Arraes Jardim Chagas < ***@***.***> escreveu:

…

Hi @juliohm <https://github.com/juliohm> ! That huge padding is strange. The columns should be sized to fit the longest cell, which in this case is the header / subheader. I cannot reproduce the results in Jupyter. Take a look how I see a table with the same set of data: [image: Captura de Tela 2023-09-08 às 18 43 29] <https://user-images.githubusercontent.com/1068295/266736151-e92240e0-d549-40be-9338-466fc3efbfe3.png> How can we replicate it? But maybe the easiest way to go is to add vertical lines clearly showing columns. I personally hate vertical lines :D Furthermore, I am not sure if there is a way to easily do this kind of modification inside Jupyter. — Reply to this email directly, view it on GitHub <#3378 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZQW3OGUB7JG76VXEPCGMLXZOIMXANCNFSM6AAAAAA4QVUURM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[bkamins]

Maybe some CSS configuration in Quatro could resolve the issue?

[juliohm]

Will report ot here if I find something. Thank you all! Em sáb., 9 de set. de 2023 08:10, Bogumił Kamiński ***@***.***> escreveu:

…

Maybe some CSS configuration in Quatro could resolve the issue? — Reply to this email directly, view it on GitHub <#3378 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZQW3MOTRG63EM3NHULUN3XZRFARANCNFSM6AAAAAA4QVUURM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ronisbr]

@juliohm in the mean time, you can pass alignment = :c to show to improve things in Quarto:

show(stdout, MIME("text/html"), df; alignment = :c)

@bkamins I think it will be really hard to provide a default that will work in every environment. Maybe it is time to revisit that old request to provide a way to set default options when printing tables. Thus, each user can customize depending on the environment.

My suggestion is to add Preferences.jl to PrettyTables.jl, replacing any configuration if a specific preference is set. Hence, the options there will take precedence to everything: default PrettyTables.jl values and also DataFrames.jl customizations.

What do you think?

[bkamins]

Having thought about it I saw the following aspects:

• should setting be per session or across sessions
• should setting affect all tables or only a specific table
• if we set option "A" should it disable any other customizations or only option "A" should be affected

While there can be several answers to these questions I, tentatively, came to the conclusion that a mechanism similar to what plotting backends provide might be sensible:

• users could register display settings (call them "themes"); PrettyTables.jl itself could also provide several in-built settings (these settings should be per MIME). The API for registering a theme would need to be worked out.
• then in run time user could run something like PrettyTables.activate_themes(the sequence of themes to be activated as consecutive positional arguments) then the activated themes would override the settings passed by the user (i.e. they would be applied after kwargs passed by the user were processed). Running PrettyTables.activate_themes() would disable all themes. The sequence of themes would be accepted because they would be applied in sequence (as they potentially could overlap).

CC @nalimilan

[ronisbr]

I fully agree with this approach of having themes for each backend. I will do some testing to check if it does not introduce too much overhead. The last time (I think in Julia 1.2 or 1.3) I tried to do something like this, the package was taking more than 1s to print a table for the first time.