PDF Export - Table column widths

I see how this user is setting a column width on a table directly. I would like to default the minimum column width in a way that will default a rule for any pdf export. I can’t expect my non-technical users to edit source.

I have a table with several smaller columns (containing a single sentence’s worth of text) followed by a column containing a paragraph’s worth of text. I want the lion’s share of the width in the exported pdf devoted to the last column, however what’s happening is too extreme. The sentence size columns are literally a single character or two in width (due to kerning looks like) including the headers.

There is actually some nuance here too. If a column only contains single character it would be ideal to be a single character width. The minimum should apply only before the column starts wrapping text.


Table source:
|=B|=Sentence Length|=Sentence Length|=Paragraph Length
|✅|This is a sentence length of content.|This is also a sentence length of content.|Writing a paragraphs worth of content about nothing is an interesting exercise. What can you say but that this is about nothing. It tells you nothing. It reminds me of Seinfeld. The content is about nothing! It actually has to be even longer than this. How long can I keep this up. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route.
|❌|This is a sentence length of content.|This is also a sentence length of content.|Writing a paragraphs worth of content about nothing is an interesting exercise. What can you say but that this is about nothing. It tells you nothing. It reminds me of Seinfeld. The content is about nothing! It actually has to be even longer than this. How long can I keep this up. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route.
|✅|This is a sentence length of content.|This is also a sentence length of content.|Writing a paragraphs worth of content about nothing is an interesting exercise. What can you say but that this is about nothing. It tells you nothing. It reminds me of Seinfeld. The content is about nothing! It actually has to be even longer than this. How long can I keep this up. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route. Maybe I just go the Bart Simpson at the chalk board route.

In XWiki web app:

In PDF Export:

Other thoughts:

The pdf view looks like it’s close to flexing the column width so that the row length is as short as possible, but for this case that doesn’t work out well. Part of the challenge is landscape/portrait (although making my browser window narrow always looks better in the webapp than the pdf export). Maybe a table just isn’t the ideal way to capture longer form data, and I can definitely reformat/restructure without using tables. It works well in the webapp itself though, which makes it frustrating. Maybe if there’s a way to make a rule that no column with text wrapping is say more than twice the width of any other wrapped column? Obviously there are cases that just will never work (adding more sentence length columns will quickly lead to no possible solution), but it looks to me like we aren’t there yet.


Example rules that I think will look better, but I don’t know how to implement:

So, the column with the cell with the most content should be say no more than twice the width of the other columns. Unless this results in cells with no wrapping, in which case those cells should be equal in width to their unwrapped content, yielding any remaining space to the column with the cell with the most content.

I’m not married to that “double” rule. It’s just an example. Very open to whatever will look best.


1 Like

Indeed this looks weird as the PDF Export is supposed to look similar to what you view in the browser (since we use the browser’s print feature).

@mflorea any idea?

Note that I can reproduce with paged.js or not, so it’s not related to pagedjs.

Table layout is not simple…

The reason the column widths are different between view and PDF export is because we’re setting the column widths explicitly before exporting to PDF. A table like:

|left|(% width="200px" %)right

becomes something like:

|(% width="35%" %)left|(% width="65%" %)right

Basically:

  • absolute widths are converted to relative widths
  • implicit (unspecified) widths are converted to explicit relative widths

We do this because:

  • absolute widths cause problems when printing to PDF (it’s impossible to respect the absolute width in the generated PDF)
  • without an explicit column width, the same column will have different widths on consecutive print pages, when the table is split on multiple print pages (we had users complaining about this)

The problem is that the explicit relative column width is influenced by the screen width, which most of the time is considerably larger than the width of the print page. I mean, 10% of the print page size may be too small compared to 10% of the screen size, i.e. a relative width that looks OK for the screen may be too small for the print page.

To overcome this, we could reduce the content width to match the print page width when computing the relative widths. This can be done with CSS from a custom PDF export template:

/* Style applied before printing. */
#xwikicontent {
  /* A4 width, used by default, but may depend on the PDF template. */
  max-width: 210mm;
}

@media print {
  /* ... print styles here, from the default PDF template ...*/

  #xwikicontent {
    /* No need to limit the content width once the relative table column
      widths have been computed. */
    max-width: none;
  }
}

If this still doesn’t look good for you then you need to apply some custom CSS to your tables. This can be done from the skin / color theme, if you need them both in view and PDF export, or from a custom PDF export template, if you want to limit them to PDF export.

Hope this helps,
Marius

1 Like

Thanks @mflorea for the explanations!

I think it would help to document this on https://extensions.xwiki.org/xwiki/bin/view/Extension/PDF%20Export%20Application/ WDYT?