From: Alex F. <afo...@us...> - 2022-02-10 06:13:31
|
--- ** [bugs:#444] Table column width rounding can result in uneven column widths** **Status:** open **Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich **Last Updated:** Thu Feb 10, 2022 06:13 AM UTC **Owner:** nobody In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%). The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer. --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Alex F. <afo...@us...> - 2022-02-10 08:11:39
|
And if it's necessary for the width to be an integer for some reason, then an alternative fix could be to keep track of the accumulated error, and round up or down depending on which would minimize the error. In this case, the column widths should get set to 13, 12, 13, 12, etc. which would distribute the error across the columns, instead of having the last column off by such a large amount. --- ** [bugs:#444] Table column width rounding can result in uneven column widths** **Status:** open **Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich **Last Updated:** Thu Feb 10, 2022 06:13 AM UTC **Owner:** nobody In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%). The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer. --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Günter M. <mi...@us...> - 2022-02-11 10:25:07
|
Thank you for the report. Unless the problem is fixed, there is a workaround: Tables works fine with Docutils 0.18.1 and `rst2html5.py` "out of the box", because of the new default (colwidths-auto). https://docutils.sourceforge.io/RELEASE-NOTES.html#release-0-18-2021-10-26 With "html4css1" and "latex", you can use the config setting `table-style: colwidths-auto` or command line option `--table-style=colwidth-auto` (for the complete document) or ``:widths: auto`` on individual tables. This should also work for Docutils 0.17. Compare: ~~~ .. table:: :width: 100% :widths: auto === === === === === === === === x x x x x x x x === === === === === === === === .. table:: :width: 100% :widths: grid === === === === === === === === x x x x x x x x === === === === === === === === ~~~ --- ** [bugs:#444] Table column width rounding can result in uneven column widths** **Status:** open **Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich **Last Updated:** Thu Feb 10, 2022 06:18 AM UTC **Owner:** nobody In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%). The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer. --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Alex F. <afo...@us...> - 2022-02-11 21:25:04
|
Here is what I have tried, all in combination with :width: 100%: With no :widths:, all columns in HTML output are 13%, so the last column is too narrow. In LaTeX output, the table doesn't fit the page width (:width: 100% seems to be ignored). With :widths auto, the column widths in HTML are not specified, and hence the columns are all different widths, depending on the contents. In LaTeX output, the table doesn't fit the page width (:width: 100% seems to be ignored). With :widths: 1 1 1 1 1 1 1 1 or :widths: grid, all columns in HTML output are 13%, so the last column is too narrow. In LaTeX output, the table fits the full page width and all columns are the same width. Also note that I am using docutils via sphinx, I'm not sure if sphinx messes with anything in between. --- ** [bugs:#444] Table column width rounding can result in uneven column widths** **Status:** open **Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich **Last Updated:** Thu Feb 10, 2022 06:18 AM UTC **Owner:** nobody In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%). The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer. --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Günter M. <mi...@us...> - 2022-02-19 23:58:42
|
- **status**: open --> open-fixed - **Comment**: Fixed in [r9009]. The Docutils LaTeX writer already uses 3 digit precision and fixed the "ignored width" bug with the new algorithm for table column widths in release 0.18 (cf. [bugs:#422]). Sphinx uses a LaTeX writer fork so using Docutils >= 0.18 will not fix Sphinx behaviour "automagically". Thank you for your report. --- ** [bugs:#444] Table column width rounding can result in uneven column widths** **Status:** open-fixed **Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich **Last Updated:** Fri Feb 11, 2022 09:25 PM UTC **Owner:** nobody In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%). The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer. --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Alex F. <afo...@us...> - 2022-02-20 00:41:14
|
Thanks for the fix! All I need is that there is a way to specify things in the rst so that both the HTML and the LaTeX output look OK, so if that means specifying :widths: grid or explicit widths, then that's not a problem. The bigger issue, however, is that Arch Linux appears to be holding back the docutils package due to some issue between docutils and recommonmark, which is particularly annoying as recommonmark seems to be deprecated. But that's beyond the scope of this issue. --- ** [bugs:#444] Table column width rounding can result in uneven column widths** **Status:** open-fixed **Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich **Last Updated:** Sat Feb 19, 2022 11:42 PM UTC **Owner:** nobody In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%). The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer. --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Günter M. <mi...@us...> - 2022-02-20 19:01:00
|
> that's not a problem. The bigger issue, however, is that Arch Linux > appears to be holding back the docutils package due to some issue > between docutils and recommonmark Sphinx introduced an upper bound on the Docutils version as a precaution. If you want to experiment, you may install a repository snapshot https://docutils.sourceforge.io/#snapshots It should work with a not too old Sphinx but may need customization of the CSS style sheets due to recent changes in HTML5 writer. --- ** [bugs:#444] Table column width rounding can result in uneven column widths** **Status:** open-fixed **Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich **Last Updated:** Sun Feb 20, 2022 05:55 AM UTC **Owner:** nobody In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%). The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer. --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Adam T. <aa-...@us...> - 2022-02-20 01:08:22
|
> Arch Linux appears to be holding back the docutils package due to some issue between docutils and recommonmark Do you have a link to a tracker issue for Arch at all? Equally, would it be of any use to have a statement from a Docutils maintainer to help with this? A --- ** [bugs:#444] Table column width rounding can result in uneven column widths** **Status:** open-fixed **Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich **Last Updated:** Sun Feb 20, 2022 12:34 AM UTC **Owner:** nobody In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%). The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer. --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Alex F. <afo...@us...> - 2022-02-20 05:55:18
|
The only information I have found so far is https://github.com/archlinux/svntogit-community/commit/efcd10954b3fe906dd7395e6b7fbdc4f5c7b1a69 which references https://github.com/sphinx-doc/sphinx/issues/9049 I don't know if there is an Arch issue anywhere that references this. --- ** [bugs:#444] Table column width rounding can result in uneven column widths** **Status:** open-fixed **Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich **Last Updated:** Sun Feb 20, 2022 12:54 AM UTC **Owner:** nobody In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%). The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer. --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |
From: Günter M. <mi...@us...> - 2022-07-06 06:48:36
|
- **status**: open-fixed --> closed-fixed - **Comment**: The table collumn bug is fixed in Release 0.19 (2022-07-05). Docutils 0.19 should also work nice with "recommonmark" and the development version of Sphinx. --- ** [bugs:#444] Table column width rounding can result in uneven column widths** **Status:** closed-fixed **Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich **Last Updated:** Sun Feb 20, 2022 05:55 AM UTC **Owner:** nobody In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%). The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer. --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |