XWiki Platform
  1. XWiki Platform
  2. XWIKI-12192

Tables resized in wysiwyg overflow in the PDF export

    Details

    • Difficulty:
      Unknown
    • Similar issues:

      Description

      This issue is about the PDF export of tables made in the wysiwyg editor, but about showing the information in the PDF, not about the quality of the rendering ( not XWIKI-5627 ).

      How to reproduce (I did this in firefox browser, maybe it depends on the browser):

      • create a document, edit it in wysiwyg and add a table in it (2 lines 2 columns of which one is header)
      • fill in some text in the table
      • save and exit
      • export in PDF. You will obtain a table that fits the PDF page, with 2 equally large columns regardless of the content in those columns. See attachment Sandbox.TestTableExport-ok.pdf
      • re-edit the document in wysiwyg
      • when editing, the table can be selected and will receive in the corners some "controls" (little white squares that show that the element is selected and allow to resize it) - these controls will only be available on firefox (38.0), I couldn't get those handles on chrome or IE 11
      • pull one of these corners to re-size the table
        • in the flamingo skin the table just won't show at the size where you pulled it, but this is a different issue
        • in the colibri skin you'll see the table resizing to the size chosen with the controls
        • don't resize it to too small, stop at around 800px (3/4 of a screen, depending on your screen size)
      • save the document
      • export in pdf. You will obtain a result that resembles attachment Sandbox.TestTableExport-overflowing.pdf

      This is because, upon resizing the table in wysiwyg, it receives width parameter which is honored by the PDF export.

      This is even more bothering as there is no way to get rid of the set size in wysiwyg (clean table styles), you need to go to wiki syntax to do that.

      1. fop.xsl.diff
        0.9 kB
        Marius Dumitru Florea
      2. Sandbox_TestTableExport-ok.pdf
        22 kB
        Anca Luca
      3. Sandbox_TestTableExport-overflowing.pdf
        22 kB
        Anca Luca
      4. xhtml2fo.xsl.diff
        4 kB
        Marius Dumitru Florea
      5. xwiki_Sandbox_TableColumnLenghtExport_WebHome.pdf
        8 kB
        OlivierSeres
      1. print-preview-landscape.png
        496 kB
      2. print-preview-portrait.png
        406 kB
      3. Screen Shot 2017-01-20 at 09.40.03.png
        604 kB
      4. Screen Shot 2017-01-20 at 09.41.04.png
        297 kB

        Issue Links

          Activity

          Hide
          Vincent Massol added a comment -

          Note: I've quickly tried adding "max-width:100%" to generate "<table style="max-width: 100%">" in HTML but this doesn't change anything in the PDF export.

          Show
          Vincent Massol added a comment - Note: I've quickly tried adding "max-width:100%" to generate "<table style="max-width: 100%">" in HTML but this doesn't change anything in the PDF export.
          Hide
          Vincent Massol added a comment -

          OlivierSeres if you need a workaround, you'll need to edit the content and remove the width attributes. On the content above that gives:

          |**Title**|**Resume**|**Content**
          |Item 1|Column has variable lenght on CKeditor but not in PDF export|(((
          Eodem modo typi, qui nunc nobis videntur parum clari, fiant sollemnes in futurum.
          
          Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.Eodem modo typi, qui nunc nobis videntur parum clari, fiant sollemnes in futurum."Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?"
          
          "At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga.
          )))
          |Item2|Column has variable lenght on CKeditor but not in PDF export|(((
          odem modo typi, qui nunc nobis videntur parum clari, fiant sollemnes in futurum.
          
          Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.Eodem modo typi, qui nunc nobis videntur parum clari, fiant sollemnes in futurum."Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?"
          
          "At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. 
          )))
          

          ofc you don't get a perfect column sizes but it's better and possibly acceptable.

          Show
          Vincent Massol added a comment - OlivierSeres if you need a workaround, you'll need to edit the content and remove the width attributes. On the content above that gives: |**Title**|**Resume**|**Content** |Item 1|Column has variable lenght on CKeditor but not in PDF export|((( Eodem modo typi, qui nunc nobis videntur parum clari, fiant sollemnes in futurum. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.Eodem modo typi, qui nunc nobis videntur parum clari, fiant sollemnes in futurum."Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?" "At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. ))) |Item2|Column has variable lenght on CKeditor but not in PDF export|((( odem modo typi, qui nunc nobis videntur parum clari, fiant sollemnes in futurum. Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.Eodem modo typi, qui nunc nobis videntur parum clari, fiant sollemnes in futurum."Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?" "At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. ))) ofc you don't get a perfect column sizes but it's better and possibly acceptable.
          Hide
          Vincent Massol added a comment -

          Actually I made a mistake in my screenshots above for the browser print. You need to click in Xwiki on "Print Preview" first and then use the Print button for the browser. Or add "&xpage=print" to your URL.

          Show
          Vincent Massol added a comment - Actually I made a mistake in my screenshots above for the browser print. You need to click in Xwiki on "Print Preview" first and then use the Print button for the browser. Or add "&xpage=print" to your URL.
          Hide
          Anca Luca added a comment - - edited

          Anca Luca for images we have max-width:100%. I don't know if this will work for tables too.

          This is not what makes images fit the pdf, IMO, because the skin css is not included in the styling used in the PDF, so it cannot be this rule that makes images fit.
          IMO, for images it's the xsl-fo element that we use for them (something like external-graphics or so, we probably put nice attributes for it when generating it in xhtml2fo.xsl ).
          Inline style always endsup in the xhtml that is sent to xhmlt2fo.xsl and xhtml2fo.xsl transforms as much as possible from this style to xsl-fo style, so for the case of tables the problem is that some of these size attributes / inline style are copied to fo. The solution would probably be to add special handling of table elements in xhtml2fo.xsl and make sure we don't copy size style (if we were to use a solution similar to images).

          Show
          Anca Luca added a comment - - edited Anca Luca for images we have max-width:100%. I don't know if this will work for tables too. This is not what makes images fit the pdf, IMO, because the skin css is not included in the styling used in the PDF, so it cannot be this rule that makes images fit. IMO, for images it's the xsl-fo element that we use for them (something like external-graphics or so, we probably put nice attributes for it when generating it in xhtml2fo.xsl ). Inline style always endsup in the xhtml that is sent to xhmlt2fo.xsl and xhtml2fo.xsl transforms as much as possible from this style to xsl-fo style, so for the case of tables the problem is that some of these size attributes / inline style are copied to fo. The solution would probably be to add special handling of table elements in xhtml2fo.xsl and make sure we don't copy size style (if we were to use a solution similar to images).
          Hide
          Marius Dumitru Florea added a comment -

          Let me add the result of my investigation:

          • fo:table doesn't seem to support the max-width property. It's not listed on https://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_table and it doesn't have any effect when set on fo:table. So we can't limit the table width from fo:table.
          • Setting the width on fo:table-cell using percent is equivalent to setting the width to 0, probably because FOP can't compute the width of the parent fo:table-row
          • Setting the width on fo:table-cell using pixels or print-friendly units like cm works fine but your can easily make the table overflow. em units are also supported but not rem.
          • Setting the width on fo:table-column using percent works fine, probably because FOP can determine the width of the parent fo:table.
          • Setting the width on fo:table-column using other units works like on fo:table-cell.
          • As a consequence, setting the width on fo:table-column is more reliable than setting the width on fo:table-cell.
          • Using print-friendly units like cm on the web doesn't make much sense. We generate the tables on the web and they should look good both on the web and on print. Ideally we should use a unit that is good for both. See https://gist.github.com/basham/2175a16ab7c60ce8e001
          • The units that are good both for web and print are em, rem and %. FOP doesn't support rem and em can still overflow the table if you use large values so I would:
            • Use em for small columns where the content has fixed length (e.g. some numbers)
            • Use % otherwise
          • So far my conclusion is that we get the best results if we set the width on fo:table-column using either em or % (even if table layout is fixed). But how do we do this?
          • fo:table-column is generated from the col elements within a colgroup. The XWiki 2.1 table syntax doesn't have support for generating colgroup so we have two options:
            • Use the HTML macro
              <table>
                <colgroup>
                  <col style="width: 40%">
                  <col style="width: 60%">
                </colgroup>
                <tr>
                  <th>Lime</th>
                  <th>Lemon</th>
                </tr>
                <tr>
                  <td>Green</td>
                  <td>Yellow</td>
                </tr>
              </table>
              
            • Generate the colgroup during the PDF export by using the widths specified on the table cells. We have two options:
              • Try to determine which are the best table cells to read the width from. It's not always the first row and table cells can span multiple columns.. so it's not an easy task.
              • Let the user indicate the row that should be used to generate the colgroup. For instance:
                |(% colspan="2" %)Header
                (% class="fo-colgroup" %)|(% style="width: 10%" %)Lime|Lemon
                |Green|Yellow
                

                the 'fo-colgroup' CSS class could indicate that the second row should be used to generate the colgroup when exporting to PDF.

              • We can then modify xhtml2fo.xsl to generate fo:table-column elements from the HTML table row with class 'fo-colgroup'. Check the attached diff.
              • We still need to filter the width from fo:table-cell (otherwise it overwrites the width we set on fo:table-column). We can do this from fop.xsl. Check the attached diff.
          • So far we may have a solution for the wiki syntax. What about the WYSIWYG editor?
          • There are two problems:
            • When you resize a table column CKEditor generates pixel values. We would need to convert those values to %, either on save or right after the resize is done.
            • There's no easy way to add the "fo-colgroup" class on a table row. There are two options:
              • Expose this in the context menu (Row Properties)
              • Add a dedicated "style" in the Styles drop down from the tool bar
          Show
          Marius Dumitru Florea added a comment - Let me add the result of my investigation: fo:table doesn't seem to support the max-width property. It's not listed on https://www.w3.org/TR/2006/REC-xsl11-20061205/#fo_table and it doesn't have any effect when set on fo:table . So we can't limit the table width from fo:table . Setting the width on fo:table-cell using percent is equivalent to setting the width to 0, probably because FOP can't compute the width of the parent fo:table-row Setting the width on fo:table-cell using pixels or print-friendly units like cm works fine but your can easily make the table overflow. em units are also supported but not rem . Setting the width on fo:table-column using percent works fine, probably because FOP can determine the width of the parent fo:table . Setting the width on fo:table-column using other units works like on fo:table-cell . As a consequence, setting the width on fo:table-column is more reliable than setting the width on fo:table-cell . Using print-friendly units like cm on the web doesn't make much sense. We generate the tables on the web and they should look good both on the web and on print. Ideally we should use a unit that is good for both. See https://gist.github.com/basham/2175a16ab7c60ce8e001 The units that are good both for web and print are em , rem and % . FOP doesn't support rem and em can still overflow the table if you use large values so I would: Use em for small columns where the content has fixed length (e.g. some numbers) Use % otherwise So far my conclusion is that we get the best results if we set the width on fo:table-column using either em or % (even if table layout is fixed). But how do we do this? fo:table-column is generated from the col elements within a colgroup . The XWiki 2.1 table syntax doesn't have support for generating colgroup so we have two options: Use the HTML macro <table> <colgroup> <col style="width: 40%"> <col style="width: 60%"> </colgroup> <tr> <th>Lime</th> <th>Lemon</th> </tr> <tr> <td>Green</td> <td>Yellow</td> </tr> </table> Generate the colgroup during the PDF export by using the widths specified on the table cells. We have two options: Try to determine which are the best table cells to read the width from. It's not always the first row and table cells can span multiple columns.. so it's not an easy task. Let the user indicate the row that should be used to generate the colgroup . For instance: |(% colspan="2" %)Header (% class="fo-colgroup" %)|(% style="width: 10%" %)Lime|Lemon |Green|Yellow the 'fo-colgroup' CSS class could indicate that the second row should be used to generate the colgroup when exporting to PDF. We can then modify xhtml2fo.xsl to generate fo:table-column elements from the HTML table row with class 'fo-colgroup'. Check the attached diff. We still need to filter the width from fo:table-cell (otherwise it overwrites the width we set on fo:table-column ). We can do this from fop.xsl . Check the attached diff. So far we may have a solution for the wiki syntax. What about the WYSIWYG editor? There are two problems: When you resize a table column CKEditor generates pixel values. We would need to convert those values to % , either on save or right after the resize is done. There's no easy way to add the "fo-colgroup" class on a table row. There are two options: Expose this in the context menu (Row Properties) Add a dedicated "style" in the Styles drop down from the tool bar

            People

            • Assignee:
              Unassigned
              Reporter:
              Anca Luca
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Date of First Response: