hvalev
Set the minimum padding for header and seperator
Sometime we have large dataset and our tool that render the markdown have a size limit in some custom fields.
Is there a way to just use the minimal seperator to reduce the number of characters? For example:
Actually:
print(md.set_params(row_sep="markdown", quote=False, padding_width=0).get_markdown())
| _time | field1| field2|field3| field4 | field5 |
|-----------------------------|-------|--------|---------|---------------------|---------|
|2025-10-03T12:54:42.000+00:00|xxx|xxxx| 23456 |textextextextext|textextextext|
to
|_time|field1|field2|field3|field4|field5|
|-|-|-|-|-|-|
|2025-10-03T12:54:42.000+00:00|xxx|xxxx|23456|textextextextext|textextextext|
It still a valid markdown table for us and we limit the number of character considerably.
Do you think is it possible? Thank you
I haven't tried it, but it depends on the renderer. If it's a cli, I don't think it will work, but otherwise, it should. The standard markdown syntax doesn't actually use spaces, and the renderer should be able to convert it to a table
It's a web app and the markdown framework can render both tables in my examples. Our limitation is the size limitation of our custom field, and we need to leave only what is necessary. Extra spaces and dashes are unnecessary and consume a lot of characters
An easy solution would be to set the filler character as some exotic one that will never come up in the actual data and then replace that character in the generated markdown with nothing. I think this would do it
This solves the cell padding but not the separator dashes
I made a override classmethod like this:
from py_markdown_table.markdown_table import markdown_table
data = [
{
"_time": "2025-10-03T12:54:42.000+00:00",
"field1": "text text",
"field2": "aa bb cc",
"field3": "texttexttext--aaa",
"field4": "1112223344",
}
]
class markdown_table(markdown_table):
def __init__(self, data, skip_data_validation=False):
super().__init__(data, skip_data_validation)
def __get_row_sep_str(self):
row_sep_str = ""
for value in self.var_padding.values():
row_sep_str += "+" + "-" # * value removed
row_sep_str += "+"
return row_sep_str
def get_markdown(self):
"""Get the complete markdown table"""
# self.__update_meta_params()
self.var_padding = {key: 0 for key in md.var_padding}
data = self.get_header() + self.get_body()
if self.quote:
return "```" + data + "```"
return data
md = markdown_table(data)
md.set_params(quote=False, row_sep="markdown")
print(md.get_markdown())
|_time|field1|field2|field3|field4|
|-|-|-|-|-|
|2025-10-03T12:54:42.000+00:00|text text|aa bb cc|texttexttext--aaa|1112223344|
| _time | field1 | field2 | field3 | field4 |
|---|---|---|---|---|
| 2025-10-03T12:54:42.000+00:00 | text text | aa bb cc | texttexttext--aaa | 1112223344 |
It's a little dirty but what do you think?
maybe a method/option no_padding=True/False could be interesting?
I don't think it's needed. Just use md.set_params(quote=False, row_sep="markdown", padding_char="ü") and then call table = md.get_markdown().replace("ü", ""). I think this should do it.
Yes, I understood that part, but there is still the dash line separating the header and the lines:
|_time|field1|field2|field3|field4|
|-----------------------------|---------|--------|-----------------|----------|
|2025-10-03T12:54:42.000+00:00|text text|aa bb cc|texttexttext--aaa|1112223344|
Sometimes there are more than 4,000 dashes in a column, so yes, we have very large data in a cell :sweat_smile:
I see, then you could use regex to match dashes like -+ and compress it to one -. You can check exactly what the regex for that would look like. I don't want to change the code on my end, because the library is intended to support cli-s which don't automatically process markdown and render it unless you add all the spaces and dashes yourself to pad the columns
Keep the current behavior. However, in this type of case, where padding parameters already exist, why not add one that avoids multiplying spaces and dashes? As an optional feature, this should not be a breaking change, I think We like your library because it is lightweight and almost meets our needs, and you seem to be maintaining it, so this is a suggestion before we write custom code.
It's a fair point. I'll consider it, since the same request appeared sometime ago. I'll ping this when I figure out something minimally invasive